KnowledgeNet IP Telephony Express (IPTX) 2.0 Student Guide PDF

IPTX
IP Telephony
Express
Version 2.0
Student Guide
Text Part Numbers: 97-2192-01
97-2193-01
97-2194-01
97-2195-01
Copyright 2005, Cisco Systems, Inc. All rights reserved.

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

Overview
Module Objectives
Describing Key Features of Cisco CallManager Express and CUE 1-3

Overview
Objectives
What Is Cisco CallManager Express? 1-4
What Is Cisco Unity Express? 1-6
How Do Cisco CallManager Express and Cisco Unity Express Work? 1-9
Licensing
Summary
Explaining Differences Between Traditional Telephony and VoIP 1-21

Overview
Objectives
Traditional Telephony
CO Switching Systems 1-25
PCM Theory
Basic Voice Encoding: Converting Digital to Analog 1-30
The Nyquist Theorem 1-31
Quantization
Coder-Decoder
Encapsulating Voice in IP Packets 1-39
RTP Packet Components 1-42
Summary
Understanding VoIP Challenges and Solutions 1-45

Overview
Objectives
Requirements of Voice in an IP Internetwork 1-46
Challenges in VoIP
Bandwidth Requirements in VoIP 1-56
Summary
Describing the Cisco CallManager Express Voice Packet Handling Methods 1-65
Overview
Objectives
IP Phone Calls
Packet Forwarding, Voice Packet Priority, and RTP Stream Information 1-72
WAN Call Setup
Summary
Module Summary
References
Module Self-Check
Module Self-Check Answer Key 1-85
1-1
1-1
1-3
1-3
1-14
1-19
1-21
1-21
1-22
1-29
1-32
1-34
1-44
1-45
1-45
1-54
1-63
1-65
1-65
1-66
1-74
1-78
1-79
1-80
1-81
Configuring Cisco CallManager Express 2-1

Overview
Module Objectives
2-1
2-1
Understanding Cisco CallManager Express Features and Functionality 2-3

Overview
Objectives
Key Benefits and Features 2-4
Supported Platforms and Telephones 2-8
Supported Protocols and Integration Options 2-26
Cisco CallManager Express Requirements 2-33
Cisco CallManager Express Restrictions 2-34
Summary
Configuring Cisco CallManager Express Network Parameters 2-37

Overview
Objectives
Voice VLANs
Configuring Voice VLANs 2-41
DHCP Service Setup
DHCP Relay Server
Network Time Protocol
Transcoding
Summary
Understanding the IP Phone Registration Process 2-81

Overview
Objectives
Files
IP Phone Information
Download and Registration 2-89
Summary
Defining Ephone-dn and Ephone 2-97

Overview
Objectives
Ephone-dn
Ephone
Type of Ephone-dns
Number of Ephone-dns 2-124
Summary
Describing Cisco CallManager Express Files 2-127

Overview
Objectives
Cisco CallManager Express Files 2-128
Bundled Cisco CallManager Express Files 2-129
Individual Cisco CallManager Express Files 2-131
GUI Files
Cisco CallManager ExpressTAPI Integration 2-134
Additional Files
Summary
Understanding Initial Phone Setup 2-137
Overview
Objectives
Setting Up Phones in a Cisco CallManager Express System 2-138
Manual Phone Setup
Partially Automated Phone Setup 2-150
Automated Phone Setup 2-154
Optional Parameters
Rebooting Cisco CallManager Express Phones 2-163
Setup Troubleshooting Tips 2-166
Verifying Cisco CallManager Express Phone Configuration 2-171
Summary
Module Summary
ii IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
2-3
2-3
2-36
2-37
2-37
2-38
2-44
2-51
2-54
2-59
2-79
2-81
2-81
2-82
2-88
2-95
2-97
2-97
2-99
2-102
2-108
2-126
2-127
2-127
2-132
2-135
2-136
2-137
2-137
2-139
2-159
2-172
2-173
References
Module Self-Check
2-173
2-174
Volume 2
Configuring PSTN Interfaces and Voice Dial Peers 3-1
Overview
Module Objectives
Understanding Analog and Digital Voice Interfaces 3-3

Overview
Objectives
Local-Loop Connections
Analog Voice Interfaces
Channel Associated Signaling Systems: T1 3-8
Channel Associated Signaling Systems: E1 3-10
Common-Channel Signaling Systems 3-12
PRI and BRI
Summary
Configuring Analog and Digital Voice Interfaces 3-15
3-3
3-3
3-4
3-5
3-13
3-14
Overview
Objectives
Foreign Exchange Station Port Configuration 3-17
Configuration Parameters 3-18
Foreign Exchange Office Port Configuration 3-20
Ear and Mouth Port Configuration 3-22
Timers and Timing
Digital Voice Port Configuration 3-26
Channel Associated Signaling Configuration 3-29
Common-Channel Signaling: BRI 3-31
Common-Channel Signaling: PRI 3-38
Summary
3-15
3-16
Overview
Objectives
What Is a Dial Peer?
Plain Old Telephone Service Dial Peers 3-49
Example
VoIP Dial Peers
Example
Destination-Pattern Options 3-53
Example
What Is the Default Dial Peer? 3-56
Example
Summary
3-45
3-45
3-46
Configuring Dial Peers 3-45
Understanding Call Setup and Digit Manipulation 3-59

Overview
Objectives
What Are Call Legs?
Example
End-to-End Calls
Matching Inbound Dial Peers 3-63
Matching Outbound Dial Peers 3-65
Copyright
3-1
3-1
2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 iii
3-24
3-43
3-50
3-51
3-52
3-55
3-57
3-58
3-59
3-59
3-60
3-60
3-61
Example
Digit Collection and Consumption 3-67
Example
What Is Digit Manipulation? 3-70
Example
PLAR
Summary
Understanding Class of Restriction 3-77
Overview
Objectives
Class of Restriction
Example: Incoming and Outgoing COR Example 3-79
Steps to Configure Class of Restriction 3-81
Example: Name the COR and Lists 3-82
Example: Define the COR Lists 3-83
Example: Apply the COR to the Dial Peer 3-84
Example: Apply the COR to Ephone-dns 3-85
Example: COR Used to Restrict Access Internally Within Cisco CallManager Express 3-86
Summary
Describing H.450.x Protocols 3-91
Overview
Objectives
H.450.x Series Protocols 3-92
Call Transfer Using H.450.2 3-93
Call Forwarding Using H.450.3 3-100
H.450.12
Issues and Workarounds for H.450.x Protocols 3-109
Summary
Module Summary
References
Module Self-Check
3-66
3-68
3-72
3-74
3-76
3-77
3-77
3-78
3-90
3-91
3-91
3-106
3-116
3-117
3-117
3-118
Configuring Additional Cisco CallManager Express Features 4-1

Overview
Module Objectives
Configuring Cisco CallManager Express GUI Features 4-3

Overview
Objectives
User Classes
Cisco CallManager Express GUI Prerequisites 4-7
Accessing the GUI
Configuring Administrative User Classes 4-15
Defining the Customer Administrator Credentials 4-20
Summary
Configuring Phone Features 4-27
Overview
Objectives
Call Transfer
Call Forwarding
Call Waiting
Call Park
IP Phone Display
Softkey Customization
Calling and Directory Features 4-60
Conferencing
Productivity Tools
Custom IP Phone Rings 4-78
iv IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
4-1
4-2
4-3
4-3
4-4
4-14
4-25
4-27
4-27
4-28
4-35
4-41
4-44
4-47
4-55
4-65
4-68
Example: Sample RingList.xml 4-80

Timer Settings
Music on Hold
Summary
Understanding Call Center Features 4-93
Overview
Objectives
Ephone Hunt Groups
Dynamic Hunt Group Login and Logout 4-104
Automatic Logout of a Hunt Group 4-106
B-ACD Service
Summary
Defining TAPI Support for Cisco CallManager Express 4-131

Overview
Objectives
Functions and Features 4-132
Cisco IOS TSP Configuration on the PC 4-134
Cisco IOS TSP Configuration on the Router 4-136
Modifying Cisco IOS TSP Configuration on the PC 4-137
Cisco CallManager Express and Microsoft CRM Integration 4-139
Summary
Describing Network Management for Cisco CallManager Express 4-143

Overview
Objectives
Syslog Messages and MIBs 4-144
Example: Syslog Messages 4-144
Billing Support
Example: Viewing the Account Code from the CLI 4-147
CDR
CNS
Summary
Reference
Module Summary
Reference
Module Self-Check
4-81
4-82
4-92
4-93
4-93
4-94
4-108
4-129
4-131
4-131
4-142
4-143
4-143
4-146
4-150
4-151
4-154
4-154
4-155
4-155
4-156
Volume 3
Configuring Cisco Unity Express Automated Attendant and Voice Mail 1
Overview
Module Objectives
Understanding Cisco Unity Express Features and Functionality 3

Overview
Objectives
Voice Mail Features
Auto Attendant Features
Management Features
System Functionality
Summary
Describing Cisco Unity Express Installation and Initialization 15
Overview
Objectives
Cisco Unity Express Software Download 16
Hardware Installation
IOS Router and Cisco CallManager Express Prerequisite Configuration 28
Connecting to the CUE Module 33
Copyright
2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 v
1
2
3
3
4
6
7
10
13
15
15
18
Restoring the Factory Defaults 35

Initial Configuration
CUE Initialization Wizard
Step 3: System Defaults 48
Restarting the CUE Module 52
Upgrading CUE Software and License 53
Summary
Configuring Cisco Unity Express Auto Attendant 75

Overview
Objectives
CUE Auto Attendant Operation 76
CUE AA Editor
Adding Variables
Variable Types
Step Reference: General Steps 89
Step Reference: User and Prompt Steps 93
Step Reference: Contact and Call Contact Steps 95
Step Reference: Media Steps 97
Validate the Script
Holiday List
Business Hours Schedule 104
Scripts and Prompts
Setting Up an Automated Attendant 120
Case Study
Emergency Alternate Greeting 142
Administration via TUI
Summary
Configuring Cisco Unity Express Users and Groups 147

Overview
Objectives
User Interface
User Configuration
Group Configuration
Group Mailboxes
Summary
Configuring Cisco Unity Express Voice Mail 189

Overview
Objectives
Voice Mail Entry Point and Port 190
Message Waiting Indicator Configuration 196
Broadcast Messages
Mailbox and Message Sizes and Defaults 207
Personal Mailboxes
VPIM Networking
Distribution Lists
Summary
Troubleshooting Cisco Unity Express 253
Overview
Objectives
Introduction and Tools
Gather Facts and Define Problem 254
Continue Gathering Facts 255
Consider Possibilities 255
Create and Implement the Action Plan 255
Observe Results
Repeat As Necessary 256
Document the Changes 256
Software Architecture Overview 286
vi IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
36
43
73
75
75
82
84
85
99
100
109
136
144
146
147
147
148
155
166
180
188
189
189
202
214
222
243
251
253
253
254
256
System-Level Troubleshooting 288

GUI Troubleshooting
Voice Mail and Automated Attendant 302
Summary
Module Summary
Reference
Module Self-Check
Module Self-Check Answer Key 322
296
316
317
317
318
Volume 4
Introducing IP Quality of Service 6-1
Overview
Module Objectives
6-1
6-1
Overview
Objectives
Quality of Service Defined 6-4
Converged Networks
Converged Networks Quality Issues 6-7
Lack of Bandwidth
End-to-End Delay
Example: Effects of Delay 6-12
Packet Loss
QoS Requirements
QoS Policy
QoS for Converged Networks 6-22
Example: Traffic Classification 6-23
Example: Defining QoS Policies 6-24
LAN QoS Considerations 6-25
Summary
6-3
6-3
Understanding Quality of Service 6-3
Describing the Differentiated Services Model 6-29

Overview
Objectives
Differentiated Services Model 6-30
DSCP Encoding
Per-Hop Behaviors
Backward Compatibility Using the Class Selector 6-38
Mapping CoS to Network Layer QoS 6-39
Summary
Understanding IP QoS Mechanisms 6-41

Overview
Objectives
QoS Mechanisms
Classification
Marking
Trust Boundaries
Congestion Management 6-48
Traffic Shaping
Compression
Link Fragmentation and Interleaving 6-51
Summary
Introducing Modular QoS CLI 6-53

Overview
Objectives
Introducing Modular QoS CLI 6-54
Modular QoS CLI Components 6-55
Copyright
2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 vii
6-5
6-9
6-11
6-15
6-17
6-20
6-27
6-29
6-29
6-32
6-33
6-40
6-41
6-41
6-42
6-43
6-44
6-45
6-49
6-50
6-52
6-53
6-53
Example: Configuring MQC 6-55

Class Maps
Configuring and Monitoring Class Maps 6-58
Example: Class-Map Example 6-58
Example: Using the match Command 6-60
Example: Nested Traffic Class to Combine match-any and match-all Characteristics in One
Traffic Class
Policy Maps
Configuring and Monitoring Policy Maps 6-63
Example: Policy Map 6-64
Example: Hierarchical Policy Map 6-67
Service Policy
Attaching Service Policies to Interfaces 6-71
Example: Complete MQC Configuration 6-71
Summary
Implementing AutoQoS 6-75
Overview
Objectives
AutoQoS
AutoQoS: Router Platforms 6-80
AutoQoS: Switch Platforms 6-81
AutoQoS Prerequisites
Configuring AutoQoS
Example: Configuring the AutoQoS VoIP Feature on a High-Speed Serial Interface 6-86
Example: Configuring the AutoQoS VoIP Feature on a Low-Speed Serial Interface 6-86
Example: Using the Port-Specific AutoQoS Macro 6-90
Monitoring AutoQoS
Example: show auto qos command and show auto qos interface command 6-93
Automation with Cisco AutoQoS 6-98
Summary
Case Study: QoS Mechanisms 6-101
Overview
Relevance
Objectives
Learner Skills and Knowledge 6-101
Required Resources 6-102
Job Aids
Outline
Case Study Verification 6-102
Review Customer QoS Requirements 6-103
Company Background 6-103
Customer Situation 6-103
Identify QoS Service Class Requirements 6-105
Identify Network Locations Where QoS Mechanisms Should be Applied 6-106
Present Your Solution 6-108
Case Study Answer Key 6-109
Module Summary
References
Module Self-Check Overview 6-116
6-56
6-60
6-62
6-70
6-73
6-75
6-75
6-76
6-83
6-85
6-92
6-99
6-101
6-101
6-101
6-102
6-102
6-113
6-114
Designing Cisco CallManager Express and Cisco Unity Express Networks 7-1
Overview
Module Objectives
Describing Deployment Scenarios and Design Considerations 7-3

Overview
Objectives
Standalone Cisco CallManager Express 7-4
viii IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
7-1
7-1
7-3
7-3
Cisco CallManager Express in SIP Network 7-8

Cisco CallManager Express Integration with Cisco CallManager 7-10
Cisco CallManager Express Migration to Cisco CallManager and SRST 7-13
Cisco CallManager Express H.323 Interoperability Solutions 7-15
Summary
Deploying Voice Mail with Cisco CallManager Express 7-27

Overview
Objectives
SIP Integration with Cisco Unity Express 7-28
Skinny Integration with Cisco Unity Server 7-29
Analog DTMF Integration 7-32
Router Configuration: Two Commands 7-35
Summary
Module Summary
References
Module Self-Check
Copyright
2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 ix
7-26
7-27
7-27
7-38
7-39
7-39
7-40
x IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
IPTX
Course Introduction
Overview
IP Telephony Express (IPTX) v2.0 provides an understanding of Cisco CallManager Express

and Cisco Unity Express (CUE) and of the challenges you face when configuring and
deploying the systems. The course presents Cisco Systems solutions and implementation
considerations for addressing those challenges.
Learner Skills and Knowledge

This subtopic lists the skills and knowledge that learners must possess to benefit fully from the
course.
Prerequisite Learner Skills

and Knowledge
LANs
WANs
IP Switching
IPTX
Basic Internetworking
Skills
PSTN Operations
and Technologies
PBX Essentials
2005 Cisco Systems, Inc. All rights reserved.
IPTX v2.07
Course Goal and Objectives
Upon completing this course, you will be able to meet these objectives:
Describe the similarities and differences between a traditional PSTN, voice networks, and
IP telephony solutions
Explain the processes and standards for voice digitization, compression, and digital
signaling as they relate to VoIP networks
Configure voice interfaces on Cisco voice-enabled equipment for connection to traditional,
nonpacketized telephony equipment
Configure the Cisco CallManager Express system from either the CLI or a GUI web
interface
Understand and configure the devices for and connections to the Cisco CallManager
Express system
Configure the call flows for POTS, VoIP, and default dial peers
Describe the fundamentals of VoIP and identify challenges and solutions regarding its
implementation
Install and configure the CUE module for voice mail services
Troubleshoot both Cisco CallManager Express and CUE
Apply QoS to the IP network with the use of the AutoQoS
Apply your knowledge of Cisco CallManager Express and CUE to deploy and design an
installation
2 IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
Course Flow Diagram
This topic covers the suggested flow of the course materials.
Course Flow Diagram

Day 1Day 2Day 3Day 4Day 5
Course
Introduction
A
M
Introducing
Cisco
CallManager
Express
Configuring
Cisco
CallManager
Express
Configuring
Additional Cisco
CallManager
Express Features
Configuring PSTN
Interfaces and
Voice Dial Peers
Configuring Cisco
Unity Express
Automated
Attendant and
Voice Mail
Configuring
Cisco Unity
Express
Automated
Attendant and
Voice Mail
Designing
Cisco
CallManager
Express and
Cisco Unity
Express
Networks
Lunch
P
M
Configuring
Cisco
CallManager
Express
Configuring PSTN
Interfaces and
Configuring Cisco
Voice Dial Peers
Unity Express
Automated
Attendant and
Configuring
Voice Mail
Additional Cisco
CallManager
Express Features
Introducing IP
Quality of
Service
Designing
Cisco
CallManager
Express and
Cisco Unity
Express
Networks
IPTX v2.011
The schedule reflects the recommended structure for this course. This structure allows enough
time for the instructor to present the course information and for you to work through the lab
activities. The exact timing of the subject materials and labs depends on the pace of your
specific class.
Copyright 2005, Cisco Systems, Inc. Course Introduction 3
Additional References
This topic presents the Cisco icons and symbols used in this course, as well as information on
where to find additional technical references.
Cisco Icons and Symbols

VoiceEnabled
Router
PBX
(small)
Network
Cloud,
White
Network
Cloud,
Standard
Color
Voice-Enabled
Communications
Server
PIX Firewall
(right and left)
Phone
IP Phone
PC
Si
Phone 2
ATM
Switch
Laptop
Multilayer Switch,
with Text, without Text,
and Subdued
Cisco
CallManager
Express
Generic
Softswitch
Workgroup
Web
Browser
Voice-Enabled
ATM Switch
Si
PBX/
Switch
Server
IPTX v2.012
Cisco Glossary of Terms

For additional information on Cisco terminology, refer to the Cisco Internetworking Terms and
Acronyms glossary of terms at
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm.
Module 1
Introducing Cisco CallManager

Express
Overview
Cisco CallManager Express is an integrated call-processing solution that is based on Cisco

midrange access routers using Cisco IOS software. Cisco CallManager Express delivers
telephony services for up to 240 users in a small- to medium-sized office. It is part of Cisco IP
Communications Solution and works in conjunction with the extended Cisco Systems product
portfolio, including routers, data switches, public switched telephone network (PSTN)
gateways, gatekeepers, Cisco Unity voice mail, and analog terminal adapters.
Cisco CallManager Express delivers a robust set of telephony features that are similar to those
commonly used by business users. Cisco CallManager Express is an optional feature of Cisco
IOS software and is available on a wide range of Cisco access routers that support as many as
240 IP Phones. This allows customers to take advantage of the benefits of IP communication
without the higher costs and complexity of deploying a server-based solution. Furthermore,
because the solution is based on the Cisco access router and IOS software, it is simple to deploy
and manage, especially for customers who already use IOS software products.
Cisco Unity Express (CUE) offers local voice-mail and automated attendant capabilities for IP
Phone users in a small office or branch location who are connected to Cisco CallManager or
Cisco CallManager Express. CUE is fully integrated into the branch office router, either on a
CUE network module (NM-CUE) or on a CUE advanced integration module (AIM-CUE).
Module Objectives
Upon completing this module, you will be able to describe the similarities and differences
between traditional telephony and Voice over IP (VoIP). This includes being able to meet these
objectives:
Describe the key features and functionality of the Cisco CallManager Express system
Explain the differences between traditional voice and VoIP
Describe the challenges and solutions associated with VoIP delivery in LAN and WAN
Describe the Cisco CallManager Express voice packet handling methods
1-2 IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
Lesson 1
Describing Key Features of

Cisco CallManager Express
and CUE
Overview
This lesson describes the key features and functionality of Cisco CallManager Express and
Cisco Unity Express (CUE). This includes the licensing scheme and the effect of licensing on
activation of features. Learners will be directed to the Cisco website for up-to-date information
on licensing.
Objectives
Upon completing this lesson, you will be able to explain the differences between traditional
voice and Voice over IP (VoIP). This includes being able to meet these objectives:
Define Cisco CallManager Express
Define CUE
Describe the functionality of Cisco CallManager Express and CUE
Describe licensing requirements and the effect of licensing on feature activation
What Is Cisco CallManager Express?

This topic describes the Cisco CallManager Express system.

Trunks
PSTN
WAN
Call processing for small-to medium-sized

deployments
VoIP integrated solution
Up to 240 IP Phones
IOS softwarebased solution
IPTX v2.01-2
Cisco CallManager Express is an integrated call-processing solution that is based on Cisco

midrange access routers that are using Cisco IOS software that delivers telephony services for
10 to 100 users in small offices. Cisco CallManager Express is part of Cisco IP
Communications Solution and works in conjunction with the extended Cisco Systems product
portfolio, including routers, data switches, public switched telephone network (PSTN)
gateways, gatekeepers, Cisco Unity voice mail, and analog telephone adaptors (ATA).
Cisco CallManager Express delivers a robust set of telephony features that are similar to those
commonly used by businesses. Cisco CallManager Express is an optional feature of Cisco IOS
software and is available on a wide range of Cisco access routers that support as many as 240
IP Phones. This allows customers to take advantage of the benefits of IP communications
without the higher cost and complexity of deploying a server-based solution. Because the
solution is based on the Cisco access router and IOS software, it is simple to deploy and
manage, especially for customers who already use IOS software products. Cisco CallManager
Express allows customers to scale IP telephony to a small or branch office site with a solution
that is easy to deploy, administer, and maintain.

(Cont.)
Integrated services routers
Multiservice access routers
2800
3800
3700
2600XM
1700
IPTX v2.01-3
Cisco CallManager Express enables Ciscos large portfolio of multiservice access routers and
integrated services routers to deliver features that are similar to low-end PBX and key system
features, creating a cost-effective, highly reliable, feature-rich IP communications solution for
the small office.
Cisco CallManager Express supports a new generation of intelligent IP Phones with robust
display capabilities. End users can easily customize these Phones based on their changing
needs.
Copyright 2005, Cisco Systems, Inc. Introducing Cisco CallManager Express 1-5
What Is Cisco Unity Express?

This topic describes the CUE system.
What Is Cisco Unity Express?

Voice mail and automated attendant for small and
branch offices
Fully integrated into Cisco 3800, 2800, 2600XM,
2691 and 3700 series access routers
Two form factors: NM-CUE and AIM-CUE
Two call control options: Cisco CallManager
Express and Cisco CallManager
IPTX v2.01-4
CUE offers local voice-mail and automated attendant capabilities for IP Phone users connected
to Cisco CallManager or Cisco CallManager Express in a small office or branch location. CUE
is fully integrated into the branch office router on either a CUE network module (NM-CUE) or
a CUE advanced integration module (AIM-CUE).
What Is Cisco Unity Express? (Cont.)

NM-CUE or
NM-CUE-EC
Voice message storage: 100 hours
Hard drive storage
Available as of Release 1.0
AIM-CUE
Cisco 3800, 3700,
2800, 2600XM,
and 2691 routers
Voice message storage: 8 hours with 512-MB

flash card or 14 hours with the 1-GB flash card
512-MB or 1-GB compact flash storage
Industrial-quality flash with prolonged life and
wear-leveling
Available as of Release 1.1
IPTX v2.01-5
CUE is currently available on either an NM-CUE, an NM-CUE enhanced capability (NMCUE-EC), or an AIM-CUE. The network-based modules are the more scalable and powerful
modules, but they do consume the whole slot in the chassis in which they reside. The AIMCUE resides on the motherboard of the router; it conserves valuable network module slots and
expands the number of Cisco router platforms on which both voice mail and analog interfaces
may be supported, thereby lowering the cost of an entry-level system.
The storage is either a hard drive in the NM-CUE and NM-CUE-EC or a flash card in the AIMCUE. The hard drive in the NM-CUE and NM-CUE-EC is not a field replaceable unit (FRU).
The whole module must be sent back to Cisco if a hard drive failure occurs. Flash memory has
a limited lifetime and must be replaced after a certain number of writes has occurred. In a
typical environment, this will be every three to five years.
Note
The flash module is an industrial grade flash; off-the-shelf flash cannot be used.
What Is Cisco Unity Express? (Cont.)

Voice Mail
Supports up to 100 subscriber mailboxes on the NM-CUE and

NM-CUE-EC
Supports up to 50 subscriber mailboxes on the AIM-CUE
Storage is configurable per subscriber
Automated Attendant
Has up to five automated attendants per system

Offers fully customizable script-driven menu structure and
menu nesting
Has time of day and day of week call treatment
Business hours can be defined
Holidays can be defined
IPTX v2.01-6
Voice mail is essential in most enterprises. Voice mail enables messages to be left for
subscribers when they are busy or do not answer a call in a specified amount of time.
An automated attendant is a device that automatically answers calls with an interactive
recording and allows callers to route their call to the desired person or department by entering
the appropriate extension using their telephone keypad. Businesses can customize the greeting
by adding information such as hours and directions.
CUE supports a built-in automated attendant along with its voice-mail capabilities.
How Do Cisco CallManager Express and Cisco

Unity Express Work?
This topic describes how Cisco CallManager Express and CUE work.
How Do Cisco CallManager Express and

Cisco Unity Express Work?
Cisco CallManager Express is an
IOS softwarebased call control agent.
Register
Register
Phones register with Cisco CallManager Express

and are then under its control.
IPTX v2.01-7
The Cisco CallManager Express system provides PBX-like features and functions for IP
Phones. These features are a result of the concept of a centralized point of control and
intelligence. The Cisco CallManager Express router provides all of the call control and
intelligence needed for IP Phones to place and receive calls. In a Cisco CallManager Express
deployment, the IP Phones are not capable of setting up a call by themselves. In fact, the IP
Phones are completely controlled by the Cisco CallManager Express system and are instructed
how to place and receive calls.
The IP Phones boot up and register with Cisco CallManager Express. If Cisco CallManager
Express is properly configured, calls will be able to be set up and torn down to and from the IP
Phones. The IP Phones and the Cisco CallManager Express router use Skinny Client Control
Protocol (SCCP) to communicate.
Note
Registration across a WAN is not supported. The IP Phones must be on the local LAN with
the Cisco CallManager Express router.

Cisco Unity Express Work? (Cont.)
Cisco CallManager Express is an
IOS softwarebased call control agent.
Phone A places call

to Phone B
SCCP
SCCP
RTP
Phone APhone B
RTP
Call Control is centralized on Cisco CallManager Express.

IPTX v2.01-8
When a call is placed between two IP Phones that are under the control of Cisco CallManager
Express, SCCP is used to set up the call. SCCP does not go between the two IP Phones, only
between the IP Phone and the Cisco CallManager Express system. After the call is set up, RealTime Transport Protocol (RTP) is used to carry the audio stream. RTP is a common protocol
that is used to carry time-sensitive traffic, such as voice and real-time video. RTP is carried
inside a User Datagram Protocol (UDP) segment, which is then carried inside an IP packet.
This is the sequence of events for a phone call:
Step 1
Phone A picks up the handset and dials the number of Phone B.
Step 2
The dialed digits are sent through SCCP to Cisco CallManager Express.
Step 3
Cisco CallManager Express knows the location of Phone B (because of the

registration) and its status (busy, on hook, off hook).
Step 4
Assuming that Phone B is on hook (available), Cisco CallManager Express sends an

SCCP message to tell Phone B about the incoming call and to tell it to ring.
Step 5
Phone B is answered.
Step 6
Cisco CallManager Express informs each IP Phone about the settings of the other
Phone and instructs both Phones to construct RTP connections.
Step 7
The IP Phones construct two one-way RTP connections for the voice to travel
across, one for Phone As voice to travel to B and one for Phone Bs voice to travel
to A.
Step 8
The call takes place.
Step 9
Phone B hangs up, and an SCCP message is sent to Cisco CallManager Express.
Step 10
Cisco CallManager Express sends an SCCP message to Phone A telling it that the
call has been disconnected.

Connection(s) to PSTN
Analog
Digital
PSTN
IPTX v2.01-9
Cisco CallManager Express can act as the PSTN gateway as well as manage the IP Phones.
There are different types of connections to the PSTN, including digital and analog. The type of
connection depends on the density of connections that is needed, the technology that is
available in the region, the cost of the connections, and the interfaces that are present on the
router.

Step 4Cisco CallManager
Express uses SIP to set up a
call to the CUE module.
CUE
SIP
Step 5The call is set up, and
voice flows between the CUE
and the PSTN gateway function
of the router.
PSTN
Step 2An
SCCP message
causes the IP
Phone to ring.
PSTN
Gateway
Function
Step 1A call arrives from the

PSTN that maps through DID to
the IP Phone whose extension
is 1000.
1000
Step 3No answer

occurs within the
set time value.
IPTX v2.01-10
Cisco CallManager Express and CUE interact when Cisco CallManager Express determines
that a call needs to go either to voice mail or to the automated attendant. The slide shows a call
from the PSTN being forwarded to voice mail using the following steps:
Step 1
A call arrives from the PSTN and, based on the called number, is mapped through
the use of direct inward dialing (DID) to an internal extension of 1000.
Step 2
Cisco CallManager Express sends an SCCP message to the IP Phone and causes the
IP Phone to ring.
Step 3
The timeout value for no answer to a forwarded call is exceeded, so Cisco

CallManager Express follows the forwarding instructions and forwards the call to
the CUE voice-mail pilot number.
Step 4
A session initiation protocol (SIP) message is sent to the CUE modules IP address
to set up a voice connection using one of the virtual voice ports.
Step 5
The CUE module has a free virtual voice port and answers the call via an SIP
message that goes back to Cisco CallManager Express. Two unidirectional RTP
streams are created between the PSTN gateway function of the router and CUE.

PSTN
H.323
H.323
Cisco CallManager
Express Cluster
WAN
H.323
SIP
WAN
PSTN
PSTN Gateway and
IP-to-IP Gateway
Functionality
IPTX v2.01-11
If one Cisco CallManager Express system needs to set up a call to an IP Phone that is under the
control of another Cisco CallManager Express system, then the H.323 protocol needs to be
used between the Cisco CallManager Express systems. This configuration allows for many
different deployments of Cisco CallManager Express to be integrated together through an IPbased WAN link.
The PSTN gateway function can be performed on the Cisco CallManager Express router or on
a separate standalone gateway. If a separate PSTN gateway is used, the additional functionality
of an IP-to-IP gateway can also be run on the router. This would enable the ability to translate
between H.323 and SIP.
Note
A local PSTN is needed for each site for, at the very least, 9-1-1 emergency calls.
Licensing
This topic describes the licensing for Cisco CallManager Express and CUE.
Licensing
Licensing for Cisco CallManager Express
Capable IOS image
Feature license for number of phones

Seat license per phone up to 240
Licensing for CUE
License for 12 mailboxes is included.

Additional licenses can be purchased for up to 100
mailboxes total on the NM-CUE and NM-CUE-EC.
Additional licenses can be purchased for up to 50
mailboxes total on the AIM-CUE.
IPTX v2.01-12
Both Cisco CallManager Express and CUE have licensing requirements. For Cisco
CallManager Express, first a capable IOS image must be installed on the router, then the proper
feature license must be purchased. The feature license defines how many phones will be
controlled with the Cisco CallManager Express software. The various feature licenses are as
follows:
Feature License FL-CCME-SMALL (up to 24 users)
Feature License FL-CCME-36 (up to 36 users)
Feature License FL-CCME-MEDIUM (up to 48 users)
In addition to the feature license, each analog phone controlled by an ATA and each IP Phone
requires a seat license. The Cisco CallManager Express seat license is fully transferable to a
Cisco CallManager seat license.
There are 12 licensed user mailboxes included with the CUE module when it is ordered. If
more than 12 mailboxes are needed or desired, a new license file must be installed on the CUE
module.
ISR Bundles
Offer savings and ease of ordering when
compared with ordering each of the components
separately.
Have flexible base package with option to add
additional service modules to provide customer
with complete solution.
Include IOS SP Services for voice gateway
services and features.
Can be easily upgraded.
Include DSP modules to support PSTN-to-IP
connectivity.
Allow country-specific PSTN analog or digital
module to meet customer needs.
Include Cisco IP Communications features
license.
Offer flexibility to choose appropriate CUE module
for voice mail.
IPTX v2.01-13
Cisco offers a broad choice of IP communications solutions for growing businesses. For
businesses with a need for secure IP data routing with full-service voice capabilities, the Cisco
CallManager Express Bundles offer an affordable entry point into Cisco IP Communications.
These turnkey communications solutions support up to 240 phones and deliver feature-rich call
processing with integrated routing and switching, as well as optional voice mail and automated
attendant.
Small businesses can expect to realize the following returns on their Cisco CallManager
Express Bundles investment:
Cost savings and productivity enhancements: The Cisco CallManager Express Bundles
are an affordable entry point into a converged IP environment that delivers cost savings and
productivity enhancements.
Investment protection: The Cisco CallManager Express Bundles are cost-effective, and
they integrate with existing legacy voice investments while allowing you to migrate to a
Cisco IP Communications system.
Ease of management: The bundle components are integrated within a single chassis,
resulting in turnkey installation and streamlined system management with a common GUI.
Growth: Designed to respond to your dynamic business needs, the Cisco CallManager
Express Bundles can be easily upgraded to support advanced voice applications and
additional users. The complete portfolio of the Cisco IP Communications Solution scales to
support up to 30,000 devices.
Support: With an excellent track record in supporting mission-critical voice applications,
Cisco and its certified partners provide full life-cycle support to deliver the Cisco
CallManager Express Bundles for a maximum return on investment.
Cisco offers a range of bundles tailored to meet the needs of your business. Each bundle
includes a Cisco IP access router for secure data routing, Cisco CallManager Express software
to support IP telephony, Cisco IOS SP Services software for voice gateway services, digital
signal processor (DSP) chips for PSTN calls, and memory. CUE may be added to the bundle in
order to have voice mail and automated attendant capabilities. The base Cisco CallManager
Express Bundles are designed to meet the diverse needs of businesses worldwide.
It is necessary to add the country-specific digital or analog trunk interfaces that are required to
connect to the PSTN or host PBX. To complete the solution, add Cisco IP Phones and Cisco
Catalyst data switches that support inline power.
The various bundles include the following SKUs:
2801-CCME/K9 2801-V router, DSP resources for 8 calls, 24 Cisco CallManager
Express seats, and IOS SP Services
3825-CCME/K9 3825-V/K9 router, DSP resources for 64 calls, 168 Cisco CallManager
Express seats, and IOSSP Services
3845-CCME/K9 3845-V/K9 router, DSP resources for 64 calls, 240 Cisco CallManager
Release Compatibility
Feature
12 Mailboxes
25 Mailboxes
50 Mailboxes
100 Mailboxes
Personal Mailboxes
12
25
50
100
General Delivery
Mailboxes
NM-CUE: Hours of
Storage
10
15
20
100
100
100
100
NM-CUE-EC: Hours of
Storage
NM-CUE: # of Ports
100
100
100
100
NM-CUE-EC: # of Ports
16
16
16
16
IPTX v2.01-14
There are four CUE license levels available on the NM-CUE and NM-CUE-EC. The hardware
associated with CUE (NM-CUE and AIM-CUE) must be purchased with an accompanying
license. Hardware and software are packaged together. Mailbox licenses are purchased
separately with the exception of the 12-mailbox license level that is included in the price of the
hardware-software bundle. Therefore, a minimum of 12 mailboxes must be ordered with each
CUE purchase.
CUE license files, such as Cisco IOS software, can be downloaded from http://cisco.com and
installed on any number of systems for which a license was purchased without change to the
file itself. When a license is purchased or when software from Cisco is used, or both, a
contractual obligation is created. The subscriber must abide by the terms spelled out in the
license agreement, including prohibitions regarding unauthorized replication of the software
and modification to the mailbox level of the license.
The capacity limitations on ports, subscribers, and mailboxes depend on whether CUE is
running on a network module or an advanced integration module and is controlled by the
license that is installed on the CUE application.
Release Compatibility (Cont.)

Feature
12 Mailboxes
25 Mailboxes
AIM-CUE, 512 MB: Hours

of Storage
Not Supported
AIM-CUE, 1GB: Hours of

Storage
14
14
14
Not Supported
AIM-CUE, 512 MB,

2600XM and 2691: # of
Ports
4*
Not Supported
AIM-CUE, 512 MB, 2800,

3700, and 3800: # of
Ports
6*
Not Supported
4*
Not Supported
Not Supported
AIM-CUE, 1GB, 2600XM

and 2691: # of Ports
AIM-CUE, 1GB, 2800,
3700 and 3800 : # of
Ports
50 Mailboxes 100 Mailboxes
*Not recommended because of port blocking and mailbox size

limitations
IPTX v2.01-15
There are three CUE license levels available with the AIM-CUE in the 512-MB model and
three license levels available with the AIM-CUE in the 1-GB model. The use of the 50-mailbox
license is discouraged when using the 512-MB model because of port and storage limitations.
The 50-port license is appropriate when using the 1-GB model installed in a 2800, 3700, or
3800 platform.
When the advanced integration module is located in the chassis of a 2600XM series or 2691
router, it is limited to a maximum of four simultaneous ports at any one time. This presents
some port blocking issues that may be manifested when the number of mailboxes approaches
the upper limit of 50.
Summary
This topic summarizes the key points discussed in this lesson.
Summary
Cisco CallManagerExpress is an optional feature
of CiscoIOS software and is available on a wide
range of Cisco access routers that support
asmany as 240 phones.
Cisco CallManagerExpress provides call
processing for IP Phones using SCCP.
CUE provides voice mail and automated attendant
for the small office or branch office.
CUE is fully integrated into Cisco 2600XM, 2691,
2800, 3700, and 3800 series access routers.
IPTX v2.01-16
Lesson 2
Explaining Differences
Between Traditional Telephony
and VoIP
Overview
This lesson explains the differences between traditional voice and Voice over IP (VoIP). This
includes a discussion of traditional telephony, pulse code modulation (PCM) theory, and the
basics of voice digitization. It also includes a discussion of the various compression schemes
that are used to transport voice using less bandwidth, using coder-decoder attributes, and
encapsulating voice in IP packets. In addition, the use of compressed Real-Time Transport
Protocol (cRTP) headers, including when and when not to use them, is discussed.
Objectives
Upon completing this lesson, you will be able to explain the differences between traditional
voice and VoIP. This includes being able to meet these objectives:
Identify the components, processes, and features of traditional telephony networks that
provide end-to-end call functionality
Identify the steps for converting analog signals to digital signals and the steps for
converting digital signals to analog signals; state the purpose of the Nyquist theorem;
explain quantization
Explain voice compression and coder-decoder standards; name two types of voice
compression techniques; list three common voice compression standards and their
bandwidth requirements
Describe the functions of RTP and RTCP as they relate to a VoIP network; describe how IP
voice headers are compressed using cRTP and how header size is reduced in order to
efficiently carry voice across the network using VoIP protocols and cRTP
Traditional Telephony
This topic introduces the components of traditional telephony networks. It describes how
central office (CO) switches function and how they make switching decisions, and it explores
PBX and key telephone system functionality in environments today. The topic also discusses
the three call-signaling types: supervisory, address, and informational.
Basic Components of a Telephony Network
IPTX v2.01-2
A number of components must be in place for an end-to-end call to succeed. These components
are shown in the figure and include the following:
Edge devices
Local loops
Private or CO switches
Trunks
Edge Devices
The two types of edge devices that are used in a telephony network include:
Analog telephones: Analog telephones are most common in home, small business, and
small office, home office (SOHO) environments. A direct connection to the public
switched telephone network (PSTN) is usually made by using analog telephones.
Proprietary analog telephones are occasionally used in conjunction with a PBX. These
phones provide additional functions, such as speakerphone, volume control, PBX messagewaiting indicator, call on hold, and personalized ringing.
Digital telephones: Digital telephones contain hardware to convert analog voice into a
digitized stream. Larger corporate environments with PBXs generally use digital
telephones. Digital telephones are typically proprietary, that is, they work with the PBX or
key system of that vendor only.
Local Loops
A local loop is the interface to the telephone company network. Typically, it is a single pair of
wires that carry a single conversation. A home or small business may have multiple local loops.
Private or CO Switches
The CO switch terminates the local loop and handles signaling, digit collection, call routing,
call setup, and call teardown.
A PBX switch is a privately owned switch located at the customers site. A PBX typically
interfaces with other components to provide additional services, such as voice mail.
Trunks
The primary function of a trunk is to provide the path between two switches. There are several
common trunk types, including:
Tie trunk: A dedicated circuit that connects PBXs directly
CO trunk: A direct connection between a local CO and a PBX
Interoffice trunk: A circuit that connects two local telephone company COs
Central Office Switches
IPTX v2.01-3
The figure shows a typical CO switch environment. The CO switch terminates the local loop
and makes the initial call-routing decision.
The call-routing function forwards the call to one of the following:
Another end-user telephone if it is connected to the same CO
Another CO switch
A tandem switch
The CO switch enables the telephone to work with the following components:
Battery: The battery is the source of power to both the circuit and the telephone it
determines the status of the circuit. When the handset is lifted to let current flow, the
telephone company provides the source that powers the circuit and the telephone. Because
the telephone company powers the telephone from the CO, electrical power outages should
not affect the basic telephone.
Note
Some telephones, such as cordless telephones, require a supplementary power source that
the subscriber supplies. Some cordless telephones may lose function during a power
outage.
Current detector: The current detector monitors the status of a circuit by detecting
whether it is open or closed. See the table Current Flow in a Typical Telephone.
Current Flow in a Typical Telephone

Handset
Circuit
Current Flow
On cradle On hook/open circuit No

Off cradle Off hook/closed circuit Yes
Dial tone generator: When the digit register is ready, the dial tone generator produces a
dial tone to acknowledge the request for service.
Digit register: The digit register receives the dialed digits.
Ring generator: When the switch detects a call for a specific subscriber, the ring generator
alerts the called party by sending a ring signal to that subscriber.
You must configure a PBX connection to a CO switch that matches the signaling of the CO
switch. This configuration ensures that the switch and the PBX can detect on hook, off hook,
and dialed digits coming from either direction.
CO Switching Systems
Switching systems provide three primary functions:
Call setup, routing, and teardown
Call supervision
Customer IDs and telephone numbers
CO switches switch calls between locally terminated telephones. If a call recipient is not locally
connected, the CO switch decides where to send the call based on its call-routing table. The call
then travels over a trunk to another CO or to an intermediate switch that may belong to an
inter-exchange carrier (IXC). Although intermediate switches do not provide a dial tone, they
act as hubs to connect other switches and provide interswitch call routing.
PSTN calls are traditionally circuit-switched, which guarantees end-to-end path and resources.
Therefore, as the PSTN sends a call from one switch to another, the same resource is associated
with the call until the call is terminated.
What Is a PBX?
IPTX v2.01-4
A PBX is a smaller, privately owned version of the CO switches that are used by telephone
companies.
In a corporate environment, where large numbers of staff need access to each other and to the
outside, individual telephone lines are not economically viable. Most businesses have a PBX
telephone system, a key telephone system, or Centrex service. Large offices, with more than 50
telephones or handsets, choose a PBX to connect users, both in-house and to the PSTN.
PBXs come in a variety of sizes, typically from 20 to 20,000 stations. The selection of a PBX is
important to most companies because a PBX has a typical life span of seven to ten years.
All PBXs offer a standard, basic set of calling features. Optional software provides additional
capabilities.
The figure illustrates the internal components of a PBX: it connects to telephone handsets using
line cards and to the local exchange using trunk cards.
A PBX has three major components:
Terminal interface: The terminal interface provides the connection between terminals and
PBX features that reside in the control complex. Terminals can include telephone handsets,
trunks, and lines. Common PBX features include dial tone and ringing.
Switching network: The switching network provides the transmission path between
two or more terminals in a conversation, such as when two telephones within an office
communicate over the switching network.
Control complex: The control complex provides the logic, memory, and processing for
call setup, call supervision, and call disconnection.
What Is a Key System?
IPTX v2.01-5
Small organizations and branch offices often use a key telephone system because a PBX has
functionality and extra features that they may not require. For example, unlike the central
answering position that is required for a PBX, a key system enables small businesses to have
distributed answering from any telephone.
Today, key telephone systems are either analog or digital and are microprocessor-based. Key
systems are typically installed in offices with 30 to 40 users, but can be scaled to support more
than 100 users.
A key system has three major components:
Key service unit: A key service unit (KSU) holds the system switching components,
power, intercom, line and station cards, and system logic.
System software: System software provides the operating system and calling-feature
software.
Telephones (instruments or handsets): Telephones allow the user to choose a free line
and dial out, usually by pressing a button on the telephone.
Basic Call Setup
IPTX v2.01-6
Call signaling, in its most basic form, is the capacity of a user to communicate a need for
service to a network. The call-signaling process requires the ability to detect a request for
termination of service, send addressing information, and provide progress reports to the
initiating party. This functionality corresponds to the three call-signaling types: supervisory,
address, and informational.
The figure shows the three major steps in an end-to-end call. These steps include:
Step 1
Local signaling originating side

The user signals the switch by going off hook and sending dialed digits through
the local loop.
Step 2
Network signaling
The switch makes a routing decision and signals the next, or terminating, switch
through the use of setup messages sent across a trunk.
Step 3
Local signaling terminating side

The terminating switch signals the call recipient by sending ringing voltage through
the local loop to the recipient telephone.
PCM Theory
This topic describes the process of converting analog signals to digital signals and converting
digital signals back to analog signals. The topic also describes the Nyquist theorem, which is
the basis for digital signal technology, and explains quantization and its techniques.
Digitizing Analog Signals

1. Sample the analog signal regularly.
2. Quantize the sample.
3. Encode the value into a binary expression.
4. (Optional) Compress the samples to reduce
bandwidth (multiplexing).
IPTX v2.01-7
Digitizing speech was a project first undertaken by the Bell System in the 1950s. The original
purpose of digitizing speech was to deploy more voice circuits with a smaller number of wires.
This evolved into the T1 and E1 transmission methods of today.
To convert an analog signal to a digital signal, you must perform these steps:
Note
The last step is optional.
Analog to Digital Signal Conversion

Step
Procedure
Description
1.
Sample the analog signal regularly. The sampling rate must be two times the highest
frequency in order to produce playback that appears
neither choppy nor too smooth.
2.
Quantize the sample. Quantization consists of a scale made up of eight

major divisions, or chords. Each chord is subdivided
into 16 equally spaced steps. The chords are not
equally spaced, but are actually finest near the
origin. Steps are equal within the chords, but
different when they are compared between the
chords. Finer graduations at the origin result in less
distortion for low-level tones.
3.
Encode the value into 8-bit digital

form.
PBX output is a continuous analog voice waveform.

T1 digital voice is a snapshot of the wave, encoded
in ones and zeros.
4.
(Optional) Compress the samples

to reduce bandwidth.
Although not essential to the conversion of analog

signals to digital, signal compression is widely used
to reduce bandwidth.
Three components in the analog-to-digital conversion process include:

Sampling: Sample the analog signal at periodic intervals. The output of sampling is a pulse
amplitude modulation (PAM) signal.
Quantization: Match the PAM signal to a segmented scale. This scale measures the
amplitude (height) of the PAM signal and assigns an integer number to define that
amplitude.
Encoding: Convert the integer base-10 number to a binary number. The output of encoding
is a binary expression in which each bit is either a 1 (pulse) or a 0 (no pulse).
This three-step process is repeated 8000 times per second for telephone voice channel service.
Use the optional fourth stepcompressionto save bandwidth. This optional step allows a
single channel to carry more voice calls.
Note
The most commonly used method for converting analog to digital is PCM.
Basic Voice Encoding: Converting Digital to Analog

After the receiving terminal at the far end receives the digital PCM signal, it must convert the
PCM signal back into an analog signal.
The process of converting digital signals back into analog signals includes two parts, decoding
and filtering:
Decoding: The received 8-bit word is decoded to recover the number that defines the
amplitude of that sample. This information is used to rebuild a PAM signal of the original
amplitude. This process is simply the reverse of the analog-to-digital conversion.
Filtering: The PAM signal passes through a properly designed filter, which reconstructs
the original analog wave form from its digitally-coded counterpart.
Nyquist Theorem
IPTX v2.01-8
The Nyquist Theorem

Digital signal technology is based on the premise stated in the Nyquist theorem: when a signal
is instantaneously sampled at the transmitter in regular intervals and has a rate of at least twice
the highest channel frequency, then the samples will contain sufficient information to allow an
accurate reconstruction of the signal at the receiver.
Example
Whereas the human ear can sense sounds from 20 to 20,000 Hz and speech encompasses
sounds from about 200 to 9000 Hz, the telephone channel was designed to operate at about
300 to 3400 Hz. This economical range carries enough fidelity to allow callers to identify
the party at the far end and sense their mood. Nyquist decided to extend the digitization to
4000 Hz, to capture higher-frequency sounds that the telephone channel may deliver.
Therefore, the highest frequency for voice is 4000 Hz, or 8000 samples per second, that is,
one sample every 125 microseconds.
If every sample is encoded in 8 bits, this works out to be 8000 samples a second times 8 bits per
sample. This results in a digital voice conversation requiring 64,000 bits per second. The
original digital data circuits that carried digital voice are known as DS0s and sized at 64,000
bits per second.
Quantization
IPTX v2.01-9
Quantization
Quantization involves dividing the range of amplitude values that are present in an analog
signal sample into a set of discrete steps that are closest in value to the original analog signal.
Each step is assigned a unique digital code word.
The figure depicts quantization. In this example, the x-axis is time and the y-axis is the voltage
value (the PAM).
The voltage range is divided into 16 segments (0 to 7 positive and 0 to 7 negative). Starting
with segment 0, each segment has fewer steps than the previous segment, which reduces the
noise-to-signal ratio and makes it uniform. This segmentation also corresponds closely to the
logarithmic behavior of the human ear. If a noise-to-signal ratio problem exists, it is resolved
by using a logarithmic scale to convert PAM to PCM.
Quantization Techniques
Linear
Uniform quantization
Logarithmic quantization
Compands the signal
Provides a more uniform signal-to-noise ratio
Two methods
a-law (most countries)
mu-law (Canada, United States, and Japan)
IPTX v2.01-10
Linear sampling of analog signals causes small-amplitude signals to have a higher noise-tosignal ratioand therefore poorer qualitythan larger-amplitude signals. The Bell System
developed the mu-law method of quantization, which is widely used in North America. The
International Telecommunication Union (ITU) modified the original mu-law method and
created a-law, which is used in countries outside North America.
By allowing smaller step functions at lower amplitudes rather than higher amplitudes, mu-law
and a-law provide a method of reducing the noise-to-signal method. Both mu-law and a-law
compand the signal; that is, they both compress the signal for transmission, then expand the
signal back to its original form at the other end.
Using mu-law and a-law results in a more accurate value for smaller amplitudes and uniform
signal-to-noise quantization ratio across the input range.
Both mu-law and a-law are linear approximations of a logarithmic input-output relationship.
They both generate 64-kbps bit streams using 8-bit code words to segment and quantize levels
within segments.
The difference between the original analog signal and the assigned quantization level is called
quantization error, which is the source of distortion in digital transmission systems.
Quantization error is any random disturbance or signal that interferes with the quality of the
transmission or the signal itself.
Note
For communication between a mu-law country and an a-law country, the mu-law country
must change its signaling to accommodate the a-law country.
Coder-Decoder
This topic describes two types of speech-coding schemes, waveform and source coding, and
compares G.729 and G.729a compression.
Voice-Compression Techniques
Waveform algorithms
PCM
ADPCM
Source algorithms
LD-CELP
CS-ACELP
IPTX v2.01-11
There are two voice-compression techniques.

Waveform algorithms (coders) function as follows:
Coders take sample analog signals at the rate of 8000 times per second.
Coders use predictive differential methods to reduce bandwidth, which reduction
strongly impacts voice quality.
Coders do not take advantage of speech characteristics.
Source algorithms function as follows:
Voice coders (vocoders) convert analog speech into digital speech, using a specific
compression scheme that is optimized for coding human speech.
Vocoders take advantage of speech characteristics.
Codebooks store specific predictive waveshapes of human speech. They match the
speech, encode the phrases, decode the waveshapes at the receiver by looking up the
codedphrase, and match the coded phrase to the stored waveshape in the receiver
codebook.
Example: Waveform Compression

PCM
Waveform coding scheme
ADPCM
Waveform coding scheme
Adaptive: automatic companding
Differential: changes encoded between
samples only
ITU standards:
G.711 rate: 64 kbps = (2 x 4 kHz) x 8 bits/sample
IPTX v2.01-12
Standard PCM is known as ITU standard G.711.

Adaptive differential PCM (ADPCM) coders, like other waveform coders, encode analog voice
signals into digital signals to predict future encodings by looking at the immediate past. The
adaptive feature of ADCPM reduces the number of bits per second that the PCM method
requires to encode voice signals.
ADPCM does this by taking 8000 samples per second of the analog voice signal and turning
them into a linear PCM sample. ADPCM then calculates the predicted value of the next sample,
based on the immediate past sample, and encodes the difference. The ADPCM process
generates 4-bit words, therefore generating 16 specific bit patterns.
The ADPCM algorithm from the ITU Telecommunication Standardization Sector (ITU-T)
(formerly the CCITT) transmits all 16 possible bit patterns. The ADPCM algorithm from the
American National Standards Institute (ANSI) uses 15 of the 16 possible bit patterns. The
ANSI ADPCM algorithm does not generate a 0000 pattern.
The ITU standards for compression are as follows:
G.711 rate: 64 kbps = (2 * 4 kHz) * 8 bits per sample
Example: Source Compression

CELP
Hybrid coding scheme
High-quality voice at low bit rates; processor
intensive
G.728: LD-CELP 16 kbps
G.729: CS-ACELP 8 kbps
G.729A variant 8 kbps, less processorintensive, allows more voice channels encoded
per digital signal processor
Annex-B variant VAD and CNG
IPTX v2.01-13
Code-excited linear prediction (CELP) compression transforms analog voice signals as follows:
The input to the coder is converted from an 8-bit PCM to a 16-bit linear PCM sample.
A codebook uses feedback to continuously learn and predict the voice waveform.
A white noise generator excites the coder.
The mathematical result (recipe) is sent to the far-end decoder for synthesis and generation
of the voice waveform.
Low-delay CELP (LD-CELP) is similar to Conjugate Structure Algebraic Code Excited Linear
Prediction (CS-ACELP) (see next paragraph) except:
LD-CELP uses a smaller codebook and operates at 16 kbps to minimize look-ahead delay,
keeping it to 2 to 5 ms.
The 10-bit codeword is produced from every five speech samples from the 8-kHz input.
Four of these 10-bit codewords are called a subframe, which takes approximately 2.5 ms to
encode.
Two of these subframes are combined into a 5-ms block for transmission. CS-ACELP is a
variation of CELP that performs these functions:
Codes on 80-byte frames, which take approximately 10 ms to buffer and process.
Adds a look-ahead of 5 ms. A look-ahead is a coding mechanism that continuously
analyzes, learns, and predicts the next waveshape.
Adds noise reduction and pitch-synthesis filtering to processing requirements.
Example
The Annex B variant adds voice activity detection (VAD) in strict compliance with G.729b
standards. When this coder-decoder (codec) variant is used, VAD is not tunable for music
threshold. However, when Cisco VAD is configured, music threshold is tunable.
G.729 and G.729A Comparison

Both are ITU standards.
Both are 8-kbps CS-ACELP.
G.729 is more complex and processor intensive.
G.729 is slightly higher quality than G.729A.
Compression delay is the same (10 to 20 ms).
Annex-B variant can be applied to either.
IPTX v2.01-14
G.729, G.729 Annex A (G.729a), G.729 Annex B (G.729b), and G.729a Annex B (G.729ab)
are variations of CS-ACELP.
There is little difference between the ITU recommendations for G.729 and G.729a. All of the
platforms that support G.729 also support G.729a.
G.729 is the compression algorithm that Cisco uses for high-quality 8-kbps voice. When G.729
is properly implemented, it sounds as good as the 32-kbps ADPCM. G.729 is a highcomplexity, processor-intensive compression algorithm that monopolizes processing resources.
Although G.729a is also an 8-kbps compression, it is not as processor-intensive as G.729. It is a
medium-complexity variant of G.729 with slightly lower voice quality. The quality of G.729a
is not as high as G.729 and is more susceptible to network irregularities such as delay,
variation, and tandeming. Tandeming causes distortion that occurs when speech is coded,
decoded, then coded and decoded again, much like the distortion that occurs when a videotape
is repeatedly copied.
Example
On Cisco IOS gateways, you must use the variant (G.729 or G.729a) that is related to the codec
complexity configuration on the voice card. This variant does not show up explicitly in the
Cisco IOS command-line interface (CLI) codec choice. For example, the CLI does not display
g729r8 (alpha code) as a codec option. However, if the voice card is defined as mediumcomplexity, then the g729r8 option is the G.729a codec.
G.729b is a high-complexity algorithm, and G.729ab is a medium-complexity variant of
G.729b with slightly lower voice quality. The difference between the G.729 and G.729b codecs
is that the G.729b codec provides built-in Internet Engineering Task Force (IETF) VAD and
comfort noise generation (CNG).
The following G.729 codec combinations interoperate:
G.729 and G.729a
G.729 and G.729
G.729a and G.729a
G.729b and G.729ab
G.729b and G.729b
G.729ab and G.729ab
Encapsulating Voice in IP Packets
This topic describes the functions of RTP and RTP Control Protocol (RTCP) as they relate to
the VoIP network. The topic also describes how IP voice headers are compressed using cRTP,
and it describes when to use cRTP.
Real-Time Transport Protocol

Provides end-to-end network functions and
delivery services for delay-sensitive, real-time
data, such as voice and video
Works with queuing to prioritize voice traffic over
other traffic
Services include:
Payload type identification
Sequence numbering
Time-stamping
Delivery monitoring
IPTX v2.01-15
RTP provides end-to-end network transport functions intended for applications that are
transmitting real-time data, such as audio and video. The functions include payload type
identification, sequence numbering, time-stamping, and delivery monitoring.
RTP typically runs on top of User Datagram Protocol (UDP) to utilize the multiplexing and
checksum services of that protocol. Although RTP is often used for unicast sessions, it is
primarily designed for multicast sessions. In addition to defining the roles of sender and
receiver, RTP also defines the roles of translator and mixer to support the multicast
requirements.
Example
RTP is a critical component of VoIP because it enables the destination device to reorder and
retime the voice packets before they are played out to the user. An RTP header contains a time
stamp and a sequence number, which allows the receiving device to buffer and remove jitter
and latency by synchronizing the packets to play back a continuous stream of sound. RTP
uses sequence numbers to order the packets only. RTP does not request retransmission if a
packet is lost.
For more information on RTP, refer to RFC 1889.
Real-Time Transport Control Protocol

Monitors the quality of the data distribution and
provides control information
Provides feedback on current network conditions
Allows hosts that are involved in an RTP session
to exchange information about monitoring and
controlling the session
Provides a separate flow from RTP for UDP
transport use
IPTX v2.01-16
RTCP monitors the quality of the data distribution and provides control information. RTCP
provides the following feedback on current network conditions:
RTCP provides a mechanism for hosts involved in an RTP session to exchange information
about monitoring and controlling the session. RTCP monitors the quality of such elements
as packet count, packet loss, delay, and inter-arrival jitter. RTCP transmits packets as a
percentage of session bandwidth, but at a specific rate of at least every 5 seconds.
The RTP standard states that the Network Time Protocol (NTP) time stamp is based on
synchronized clocks. The corresponding RTP time stamp is randomly generated and based
on data-packet sampling. Both NTP and RTP are included in RTCP packets by the sender
of the data.
RTCP provides a separate flow from RTP for transport use by UDP. When a voice stream
is assigned UDP port numbers, RTP is typically assigned an even-numbered port and
RTCP is assigned the next odd-numbered port. Each voice call has four ports assigned:
RTP plus RTCP in the transmit direction and RTP plus RTCP in the receive direction.
Example
Throughout the duration of each RTP call, the RTCP report packets are generated at least every
5 seconds. In the event of poor network conditions, a call may be disconnected because of high
packet loss. When using a packet analyzer to view packets, a network administrator can check
information in the RTCP header that includes packet count, octet count, number of packets lost,
and jitter. The RTCP header information helps in determining why calls are disconnected.
RTP Header Compression
RTP header compression saves bandwidth by

compressing packet headers across WAN links.
IPTX v2.01-17
Given the number of multiple protocols that are necessary to transport voice over an IP
network, the packet header can be large. You can use cRTP headers on a link-by-link basis to
save bandwidth.
Using cRTP compresses the IP/UDP/RTP header from 40 bytes to 2 bytes without UDP
checksums and from 40 bytes to 4 bytes with UDP checksums. RTP header compression is
especially beneficial when the RTP payload size is small, such as with compressed audio
payloads that are 20 bytes and 50 bytes.
In addition, cRTP assumes that most of the fields in the IP/UDP/RTP header do not change or
that the change is predictable. Static fields include source and destination IP addresses, source
and destination UDP port numbers, and many other fields in all three headers. The following
table illustrates the cRTP process for those fields in which the change is predictable.
cRTP
Stage
What Happens
The change is predictable. The sending side tracks the predicted change.
The predicted change is tracked. The sending side sends a hash of the header.
The receiving side predicts what the
constant change is.
The receiving side substitutes the original stored header and

calculates the changed fields.
An unexpected change occurs. The sending side sends the entire header without
compression.
RTP Packet Components

When speech samples are framed every 20 ms in a packet voice environment that is using
G.729, a payload of 20 bytes is generated. Without cRTP, the total packet size includes the
following components:
IP header (20 bytes)
UDP header (8 bytes)
RTP header (12 bytes)
Payload (20 bytes)
The header is twice the size of the payload: IP/UDP/RTP (20 + 8 + 12 = 40 bytes) versus the
payload (20 bytes). When generating packets every 20 ms on a slow link, the header consumes
a large portion of bandwidth.
As shown in the previous figure, RTP header compression reduces the header to 2 bytes. Now,
instead of the header being twice the size of the payload, the payload is ten times the size of the
compressed header.
When to Use RTP Header Compression
Congested WAN links

Slow links (less than 2 Mbps)
Bandwidth on a WAN interface that needs to be conserved
IPTX v2.01-18
You must configure cRTP on a specific serial interface or subinterface if you have any of these
conditions:
Congested WAN links
Slow links (less than 2 Mbps)
Bandwidth on a WAN interface that needs to be conserved
Compression works on a link-by-link basis and must be enabled for each link that has any of
those conditions. You must enable compression on both sides of the link for proper results.
Enabling compression on both ends of a low-bandwidth serial link can greatly reduce the
network overhead if there is a significant volume of RTP traffic on that slow link.
Note
Compression adds to processing overhead. You must check resource availability on each
device prior to turning on RTP header compression.
Example
If you want the router to compress RTP packets, use the ip rtp header-compression command.
The ip rtp header-compression command defaults to active mode when it is configured.
However,this command provides a passive mode setting in instances where you want the
router to compress RTP packets only if it has received compressed RTP on that interface. When
applying to a Frame Relay interface, use the frame-relay ip rtp header-compression
command.
By default, the software supports a total of 16 RTP header compression connections on an
interface. Depending on the traffic on the interface, you can change the number of header
compression connections with the ip rtp compression-connections number command.
Note
Do not use cRTP if the link is faster than 2 Mbps.
Summary
Summary
Traditional telephony networks are composed of edge devices
such as telephones, local loops, switches, and trunks.
CO switches terminate local loops and provide battery, current
detection, dial tone, ring generation, and the digit registers.
PBXs are privately owned switches that provide basic telephone
connectivity within a corporate environment and that connect to
supplementary services such as voice mail.
The three parts of the analog-to-digital conversion process are
sampling, quantization, and encoding.
The two parts of the digital-to-analog conversion process are
decoding and filtering.
Digital signal technology is based on the Nyquist theorem.
Quantization involves dividing the range of amplitude values of
an analog signal sample.
IPTX v2.01-19
Summary (Cont.)
The two techniques used for voice compression are waveform
compression and source compression.
G.729 and G.729A compression algorithms are similar variations of
CS-ACELP.
The three common voice compression standards are PCM, ADPCM,
and CELP.
RTP carries packetized audio traffic over an IP network.
RTCP provides feedback on the quality of the call, including
statistics on packet loss, delay, and jitter.
RTP header compression compresses the IP/UDP/RTP header in an
RTP data packet from 40 bytes to approximately 2 to 4 bytes mostof
the time.
RTP header compression is useful if you are running VoIP over
narrowband or slow links or if you need to conserve bandwidth ona
WAN interface.
IPTX v2.01-20
Lesson 3
Understanding VoIP
Challenges and Solutions
Overview
This lesson discusses the challenges and solutions that are associated with Voice over IP
(VoIP) delivery in LANs and WANs. This includes a discussion on the requirements for voice
delivery in an IP network, the challenges of VoIP, bandwidth requirements, and the need for
quality of service (QoS). In order to understand the QoS issues that you will encounter, you
need to be able to calculate the amount of bandwidth that will be consumed. Several variables
that affect total bandwidth are explained, as is the method for calculating and reducing total
bandwidth.
Objectives
Upon completing this lesson, you will be able to discuss the challenges and solutions associated
with VoIP. This includes being able to meet these objectives:
Determine the best method for improving delivery of voice packets with minimal loss,
delay, and jitter, taking into account the challenges associated with implementing Voice
over IP solutions
Discuss the challenges associated with voice delivery in an IP network
List the bandwidth requirements for various codecs and data links and describe methods to
reduce bandwidth consumption
Requirements of Voice in an IP Internetwork
This topic lists problems associated with implementation of real-time voice traffic in a besteffort IP internetwork and discusses the causes of packet loss, end-to-end delay, and jitter delay
in an IP internetwork. The topic then describes the methods you can use to ensure consistent
delivery and throughput of voice packets in an IP internetwork, and, finally, it describes how
Real-Time Transport Protocol (RTP) ensures consistent delivery order of voice packets in an
IP internetwork.
IP Network
IP is connectionless.
IP provides multiple paths from source to
destination.
IPTX v2.01-2
The traditional telephony network was originally designed to carry voice. The design of circuitswitched calls provides a guaranteed path and delay threshold between source and destination.
The IP network was originally designed to carry data. Data networks were not designed to carry
voice traffic. Although data traffic is best-effort traffic and can withstand some amount of
delay, jitter, and loss, voice traffic is real-time traffic that requires a certain QoS. In the absence
of any special QoS parameters, a voice packet is treated as just another data packet.
The user must have a well-engineered network, end to end, when running delay-sensitive
applications such as VoIP. Fine-tuning the network to adequately support VoIP involves a
series of protocols and features geared toward QoS.
Example
In the IP network shown in the figure, voice packets that enter the network at a constant rate
can reach the intended destination by a number of routes. Because each of these routes may
have different delay characteristics, the arrival rate of the packets may vary. This condition is
called jitter.
Another effect of multiple routes is that voice packets can arrive out of order. The voiceenabled router or gateway on the far end has to re-sort the packets and adjust the interpacket
interval for a proper-sounding voice playout.
Network transmission adds corruptive effects, such as noise, delay, echo, jitter, and packet loss,
to the speech signal. VoIP is susceptible to these network behaviors, which can degrade the
voice application.
If a VoIP network is to provide the same quality that users have come to expect from traditional
telephony services, then the network must ensure that the delay in transmitting a voice packet
across the network and the associated jitter do not exceed specific thresholds.
Packet Loss, Delay, and Jitter

Packet loss
Loss of packets severely degrades the voice
application.
Delay
VoIP typically tolerates delays up to 150 ms
before the quality of the call degrades.
Jitter
Instantaneous buffer use causes delay variation
in the same voice stream.
IPTX v2.01-3
In traditional telephony networks, voice has a guaranteed delay across the network through
strict bandwidth association with each voice stream. Configuring voice in a data network
environment requires network services with minimal packet loss, low delay, and minimal jitter.
Over the long term, packet loss, delay, and jitter all affect overall voice quality. These voice
quality problems are described here.
Packet loss: You can drop voice packets if the network quality is poor, if the network is
congested, or if there is too much variable delay in the network. Coder-decoder (codec)
algorithms can correct small amounts of loss, but too much loss can cause voice clipping
and skips. The chief cause of packet loss is network congestion.
Delay: End-to-end delay is the time that it takes the sending endpoint to send the packet to
the receiving endpoint. End-to-end delay consists of the following two components:
Fixed network delay: You should examine fixed network delay during the initial
design of the VoIP network. The International Telecommunication Union (ITU)
standard G.114 states that a one-way delay budget of 150 ms is acceptable for
high-quality voice. Research at Cisco Systems has shown that there is a negligible
difference in voice-quality scores between networks built with 200-ms delay budgets
and the public switched telephone network (PSTN). Examples of fixed network
delay include propagation delay of signals between the sending and receiving
endpoints, voice encoding delay, and voice packetization time for various
VoIP codecs.
Variable network delay: Congested egress queues and serialization delays on

network interfaces can cause variable packet delays. Serialization delay is a constant
function of link speed and packet size: the larger the packet is and the slower the
link-clocking speed is, the greater the serialization delay is. And although this ratio
is known, it can be considered variable because a larger data packet can enter the
egress queue at any time before a voice packet. If the voice packet must wait for the
data packet to serialize, the delay that is incurred by the voice packet is its own
serialization delay plus the serialization delay of the data packet in front of it.
Jitter: Jitter is the variation between the expected arrival of a packet and when it is actually
received. To compensate for these delay variations between voice packets in a
conversation, VoIP endpoints use jitter buffers to turn the delay variations into a constant
value so that voice can be played out smoothly. However, buffers can fill instantaneously
because network congestion can be encountered at any time within a network. This
instantaneous buffer use can lead to a difference in delay times between packets in the
same voice stream.
Example
When a calling party says, Good morning, how are you? the effect of packet loss, end-to-end
delay, and jitter can be heard as follows:
With packet loss, the called party hears, Good mning, w are you?
With end-to-end delay, the called party hears, Good morning, how are you?
With jitter, the called party hears, Good morning, how are you?
Consistent Throughput
Throughput is the amount of data transmitted
between two nodes in a given period.
Throughput is a function of bandwidth, error
performance, congestion, and other factors.
Tools for enhanced voice throughput include:
Queuing
Congestion avoidance
Header compression
RSVP
Fragmentation
IPTX v2.01-4
Throughput is the actual amount of useful data that is transmitted from a source to a
destination. The amount of data that is sent from the originating end is not necessarily the same
amount of data that comes out at the destination. The data stream may be affected by error
conditions in the network; for example, bits may be corrupted in transit, leaving the packet
unusable. Packets may also be dropped during times of congestion, potentially forcing a
retransmit, using twice the amount of bandwidth for that packet.
In the traditional telephony network, guaranteed bandwidth was associated with each voice
stream. Cisco IOS software uses a number of techniques to reliably deliver real-time voice
traffic across the modern data network. These techniques, which all work together to ensure
consistent delivery and throughput of voice packets, include the following:
Queuing: Queuing is the act of holding packets so that they can be handled with a specific
priority when leaving the router interface. Queuing enables routers and switches to handle
bursts of traffic, measure network congestion, prioritize traffic, and allocate bandwidth.
Cisco routers offer several different queuing mechanisms that can be implemented based on
traffic requirements. Low latency queuing (LLQ) is one of the newest Cisco queuing
mechanisms.
Congestion avoidance: Congestion avoidance techniques monitor network traffic loads.
The goal is to anticipate and avoid congestion at common network and internetwork
bottlenecks before it becomes a problem. These techniques provide preferential treatment
in congested situations for premium-class (priority) traffic, such as voice. At the same time,
these techniques maximize network throughput and capacity use and minimize packet loss
and delay. Weighted random early detection (WRED) is one of the QoS congestion
avoidance mechanisms that is used in IOS software.
Header compression: In the IP environment, voice is carried in RTP, which is carried in
User Datagram Protocol (UDP), which is then put inside an IP packet. This constitutes
40 bytes of an RTP/UDP/IP header. This header size is large when compared with the
typical voice payload of 20 bytes. Compressed RTP (cRTP) reduces the headers to 2 bytes
in most cases, thus saving considerable bandwidth and providing for better throughput.
Resource Reservation Protocol (RSVP): RSVP is a transport layer protocol that enables a
network to provide differentiated levels of service to specific flows of data. Unlike routing
protocols, RSVP is designed to manage flows of data rather than make decisions for each
individual datagram. Data flows consist of discrete sessions between specific source and
destination machines. Hosts use RSVP to request a QoS level from the network on behalf
of an application data stream. Routers use RSVP to deliver QoS requests to other routers
along the paths of the data stream. After an RSVP reservation is made, weighted fair
queuing (WFQ) is the mechanism that actually delivers the queue space at each device.
Voice calls in the IP environment can request RSVP service to provide guaranteed
bandwidth for a voice call in a congested environment.
Fragmentation: Fragmentation defines the maximum size for a data packet and is used in
the voice environment to prevent excessive serialization delays. Serialization delay is the
time that it takes to actually place the bits onto an interface. For example, a 1500-byte
packet takes 187 ms to leave the router over a 64-kbps link. If a best-effort data packet of
1500 bytes is sent, then real-time voice packets are queued until the large data packet is
transmitted. This delay is unacceptable for voice traffic. However, if best-effort data
packets are fragmented into smaller frames pieces, then they can be interleaved with realtime (voice) packets. In this way, both voice and data packets can be carried together on
low-speed links without causing excessive delay to the real-time voice traffic.
Reordering of Packets
IP assumes that packet-ordering problems exist.

RTP reorders packets.
IPTX v2.01-5
In traditional telephony networks, voice samples are carried in an orderly manner through the
use of time-division multiplexing (TDM). Because the path is circuit-switched, the path
between the source and destination is reserved for the duration of the call. All of the voice
samples stay in order as they are transmitted across the wire. But because IP provides
connectionless transport with the possibility of multiple paths between sites, voice packets can
arrive out of order at the destination, and because voice rides in UDP IP packets, there is no
automatic reordering of packets.
RTP provides end-to-end delivery services for data that requires real-time support, such as
interactive voice and video. According to RFC 1889, the services that are provided by RTP
include payload-type identification, sequence numbering, time stamping, and delivery
monitoring.
Example
In the figure, RTP reorders the voice packets through the use of sequence numbers before
playing them out to the user.
The table illustrates the various stages of packet reordering by RTP.
Sequencing of Packets by RTP
Stage
What Happens
Voice packets enter the network. IP assumes that packet-ordering problems exist.
RTP reorders the voice packets. The voice packets are put in order through the use of sequence
numbers.
RTP retimes the voice packets.
The voice packets are spaced according to the time stamp that
is contained in each RTP header.
The user hears the voice packets in order and with the same
timing as when the voice stream left the source.
RTCP 1 sends occasional report

packets for delivery monitoring.
Both the sender and receiver send occasional report packets

containing information such as the number of packets sent or
received, the octet count, and the number of lost packets.
RTCP = RTP Control Protocol
Challenges in VoIP
The traditional telephony network strives to provide the user with 99.99 percent uptime. This
corresponds to 5.25 minutes per year of downtime. Many data networks cannot make the same
claim. This topic describes methods that you can use to improve reliability and availability in
data networks.
Reliability and Availability

Traditional telephony networks claim 99.99 percent
uptime.
Data networks must consider reliability and
availability requirements when incorporating voice.
Methods for improving reliability and availability
include:
Redundant hardware
Redundant links
UPS
Proactive network management
IPTX v2.01-6
To provide telephony users the sameor close to the samelevel of service that they
experience with traditional telephony, the reliability and availability of the data network
takes on new importance.
When the data network goes down, it may not come back up for minutes or even hours. This
delay is unacceptable for telephony users because with network equipment such as voiceenabled routers, gateways, and switches for IP Phones, they find that their connectivity is
terminated. Administrators must, therefore, provide an uninterruptible power supply (UPS) to
these devices in addition to providing network availability. Previously, depending on the type
of connection they had, users received their power directly from the telephone company CO or
through a UPS that was connected to their keyswitch or PBX in the event of a power outage.
Now the network devices must have protected power in order to continue to function and
provide power to the end devices.
In traditional telephony, switches have multiple redundant connections to other switches. If
either a link or a switch becomes unavailable, the telephone company can route the call in
different ways, which is why telephone companies can claim a high availability rate.
High availability encompasses many areas of the network, and network reliability comes from
incorporating redundancy into the network design. In a fully redundant network, the following
components need to be duplicated:
Servers and call managers
Access layer devices, such as LAN switches
Distribution layer devices, such as routers or multilayer switches
Core layer devices, such as multilayer switches
Interconnections, such as WAN links, even through different providers
Power supplies and UPSs
In some data networks, a high level of availability and reliability is not critical enough to
warrant financing the hardware and links required to provide complete redundancy. But if voice
is layered onto the network, the required level of availability and reliability needs to be
revisited.
With the use of Cisco CallManager clusters provides a way to design redundant hardware in the
event of Cisco CallManager failure. When using gatekeepers, you can configure backup
devices as secondary gatekeepers in case the primary gatekeeper fails. When implementing
redundancy, you must also revisit the network infrastructure. Redundant devices and IOS
services, such as Hot Standby Router Protocol (HSRP), can provide high availability. For
proactive network monitoring and trouble reporting, a network management platform such as
CiscoWorks 2000 provides a high degree of responsiveness to network issues.
Bandwidth Requirements in VoIP
This topic describes the bandwidth that each codec uses, and it illustrates the impact of the
codec on total bandwidth as well as the effect of voice sample size on total bandwidth. This
topic also lists overhead sizes for various Layer 2 protocols; it discusses how to use codecs,
data links, and sample size to calculate the total bandwidth required for a VoIP call; and it
describes the effect of voice activity detection (VAD) on total bandwidth.
Bandwidth Implications of Codec
IPTX v2.01-7
One of the most important factors for the network administrator to consider when building
voice networks is proper capacity planning. Network administrators must understand how
much bandwidth is used for each VoIP call. With a thorough understanding of VoIP bandwidth,
the network administrator can apply capacity-planning tools.
The following is a list of codecs and their associated bandwidth:
The G.711 pulse code modulation (PCM) coding scheme uses the most bandwidth. It takes
samples 8000 times per second, each of which is 8 bits in length, for a total of 64,000 bps.
The G.726 adaptive differential PCM (ADPCM) coding schemes use somewhat less
bandwidth. Although each coding scheme takes samples 8000 times per second as G.711
PCM does, it uses 4, 3, or 2 bits for each sample. The 4, 3, or 2 bits for each sample results
in total bandwidths of 32,000 (G.726r32), 24,000 (G.726r24), or 16,000 bps (G.726r16),
respectively.
The G.728 low-delay code-excited linear prediction (LD-CELP) coding scheme
compresses PCM samples using codebook technology. It uses a total bandwidth of
16,000 bps.
The G.729 and G.729a Conjugate Structure Algebraic Code Excited Linear Prediction
(CS-ACELP) coding scheme compresses PCM using advanced codebook technology. It
uses 8000 bps total bandwidth.
The G.723 and G.723a multipulse maximum likelihood quantization (MPMLQ) coding
schemes use a look-ahead algorithm. These compression schemes result in 6300
(G.723r63) or 5300 bps (G.723r53), respectively.
The network administrator should balance the need for voice quality against the cost of
bandwidth in the network when choosing codecs. The higher the codec bandwidth is, the higher
the cost of each call is across the network.
Impact of Voice Samples
IPTX v2.01-8
Voice sample size is a variable that can affect the total bandwidth that is used. A voice sample
is defined as the digital output from a codec digital signal processor (DSP) that is encapsulated
into a protocol data unit (PDU). Cisco uses DSPs that generate samples based on digitization of
10 ms worth of audio. Cisco voice equipment encapsulates 20 ms of audio in each PDU by
default, regardless of the codec used. You can apply an optional configuration command to the
dial peer to vary the number of samples encapsulated. When you encapsulate more samples per
PDU, total bandwidth is reduced. However, encapsulating more samples per PDU can cause
larger PDUs, which can cause variable delay and severe gaps if PDUs are dropped.
Example
Using the simple formula Bytes_per_Sample = (Sample_Size * Codec_Bandwidth) / 8, it is
possible for you to determine the number of bytes encapsulated in a PDU based on the codec
bandwidth and the sample size (20 ms is default). If we apply G.711 numbers, the formula
reveals the following:
Bytes_per_Sample = (.020 * 64,000) / 8
Bytes_per_Sample = 160
The figure illustrates various codecs and sample sizes and the number of packets that are
required for VoIP to transmit 1 second of audio. The larger the sample size is, the larger the
packet is and the fewer the encapsulated samples are that have to be sent (which reduces
bandwidth).
Data-Link Overhead
Ethernet: 18 bytes of overhead
MLP: 6 bytes of overhead
Frame Relay Forum 12 (FRF.12): 6 bytes of
overhead
IPTX v2.01-9
Another contributing factor to bandwidth is the Layer 2 protocol that is used to transport VoIP.
Alone, VoIP carries a 40-byte IP/UDP/RTP header, assuming uncompressed RTP. Depending
on the Layer 2 protocol that is used, the overhead could grow substantially. As the Layer 2
overhead increases, the amount of bandwidth that is required to transport VoIP also increases.
The following points illustrate the Layer 2 overhead for various protocols:
Ethernet: Carries 18 bytes of overhead6 bytes for source MAC address, 6 bytes for
destination MAC address, 2 bytes for type, and 4 bytes for cyclic redundancy check (CRC)
Multilink PPP (MLP): Carries 6 bytes of overhead1 byte for flag, 1 byte for address,
2 bytes for control (or type), and 2 bytes for CRC
Frame Relay Forum 12 (FRF.12): Carries 6 bytes of overhead2 bytes for data-link
connection identifier (DLCI) header, 2 bytes for FRF.12, and 2 bytes for CRC (FRF.12 is
FRF.11 Annex C; FRF.11 is the implementation agreement for Voice over Frame Relay.)
Total Bandwidth Required
IPTX v2.01-10
Codec choice, data-link overhead, sample size, and even cRTP all have positive and negative
impacts on total bandwidth. To perform the calculations, you must have all of the contributing
factors as part of the equation:
More required bandwidth for the codec = more required total bandwidth
More overhead associated with the data link = more required total bandwidth
Larger sample size = less required total bandwidth
cRTP = significantly reduced required total bandwidth
Example
The formula Total_Bandwidth = ([Layer_2_Overhead + IP_UDP_RTP_Overhead +
Sample_Size] / Sample_Size) * Codec_Speed was used to produce the figure. For example,
assume a G.729 codec and a 20-byte sample size using Frame Relay without cRTP:
Total_Bandwidth = ([6 + 40 + 20] / 20) * 8000
Total_Bandwidth = 26,400 bps
Effect of VAD
IPTX v2.01-11
On average, an aggregate of 24 calls or more may contain 35 percent silence. With traditional
telephony voice networks, all voice calls use 64-kbps fixed-bandwidth links regardless of how
much of the call is conversation and how much is silence. With Cisco VoIP networks, all
conversation and silence is packetized. VAD suppresses packets of silence. Instead of sending
VoIP packets of silence, VoIP gateways interleave data traffic with VoIP conversations to more
effectively use network bandwidth. VAD is enabled by default for all VoIP calls.
VAD provides a maximum of 35 percent bandwidth savings based on an average volume of
more than 24 calls.
Note
Bandwidth savings of 35 percent is an average figure and does not take into account loud
background sounds, differences in languages, and other factors.
The savings are not realized on every individual voice call or on any specific point
measurement.
Note
For the purposes of network design and bandwidth engineering, VAD should not be taken
into account, especially on links that will carry fewer than 24 voice calls simultaneously.
Various features, such as Music on Hold (MOH) and a fax function, render VAD ineffective.
When the network is engineered for the full voice call bandwidth, all savings provided by VAD
are available to data applications.
Not only does VAD reduce the silence in VoIP conversations, but it also provides comfort
noise generation (CNG). Because silence can be mistaken for a disconnected call, CNG
provides locally generated white noise so that the call appears normally connected to both
parties.
Example
The figure shows examples of the VAD effect in a Frame Relay VoIP environment. In the
example using G.711 with a 160-byte payload, the bandwidth required is 82,400 bps. Turning
VAD on reduces the bandwidth utilization to 53,560 bps. This is a 35 percent savings of
bandwidth.
Summary
Summary
This lesson presented these key points:
IP networks need to use QoS parameters and protocols to

adequately support VoIP.
The characteristics of IP contribute to voice-traffic
problems, including packet loss, delay, and jitter.
Different codecs have different bandwidth requirements.
Voice sample size affects the bandwidth that is required.
Overhead in Layer 2 protocols affects the bandwidth that
is used.
Codec, Layer 2 protocol, sample size, and VAD must all be
used when calculating VoIP bandwidth.
IPTX v2.01-12
Summary (Cont.)
VAD can lower bandwidth use as much as 35 percent.
QoS mitigates delay, jitter, and packet loss in
converged voice and data networks.
QoS supports dedicated bandwidth, improves loss
characteristics, avoids and manages network
congestion, shapes network traffic, and sets traffic
priorities across the network.
IPTX v2.01-13
Lesson 4
Describing the Cisco

CallManager Express Voice
Packet Handling Methods
Overview
This lesson describes the Cisco CallManager Express voice packet handling methods. This
includes a discussion of IP phone calls, packet forwarding, priority and Real-Time Transport
Protocol (RTP) stream information, and WAN call setup.
Objectives
Upon completing this lesson, you will be able to describe the Cisco CallManager Express voice
packet handling methods. This includes being able to meet these objectives:
Describe the voice packet flow among various type of calls: calls between local IP Phones
(on-net call), calls between IP Phones and the PSTN (local calls), and calls from IP Phone
to IP Phone over a WAN (intersite calls)
Describe voice packet forwarding, voice packet priority, and RTP stream information
Describe the requirements for setting up WAN calls, including DTMF relay
IP Phone Calls
This topic describes the process and steps for setting up a local (on-net) call. It describes a call
to the public switched telephone network (PSTN) that uses Cisco CallManager Express as a
PSTN gateway; a call to the PSTN that uses a separate PSTN gateway that is not the Cisco
CallManager Express router; and a call flow that uses a WAN link to connect two IP Phones
registered to separate Cisco CallManager Express routers.
On-Net Calls
SCCP is sent between
IP Phones and Cisco
CallManager Express.
The voice connection is
carried in IP packets
between two IP Phones
and has voice samples
in an RTP segment.
There is no per-call
CPU loading on the
Cisco CallManager
Express router except
for call setup and
teardown.
Cisco CallManager
Express listens for
SCCP messages
on TCP port 2000.
SCCP
Signaling
SCCP
Signaling
RTP
RTP
10.10.0.100:1692210.10.0.101:18355
10001001
IPTX v2.01-2
The Cisco CallManager Express system provides centralized call control for IP Phones that
register with the system. This call control is achieved with Skinny Client Control Protocol
(SCCP), also referred to as skinny protocol. The IP Phone uses SCCP after bootup to register
with Cisco CallManager Express. At this point, the IP Phone cannot set up calls by itself and
must send messages to Cisco CallManager Express for even the simplest of actions. For
example, when the handset is lifted off hook, the IP Phone is instructed through an SCCP
message from the Cisco CallManager Express router to play a dial tone.
When the call is connected, the IP Phones use each others IP addresses to send the voice from
IP Phone to IP Phone. Voice traffic is very delay-sensitive and drop-sensitive and does not
withstand large jitter (variation in delay), so this voice is carried in the form of data payloads
inside RTP headers. RTP has been designed to transport real-time traffic, such as voice.
The following illustrates the steps for completing a call from one local IP Phone to another.
Step 1
An IP Phone with extension 1000 (Phone 1000) goes off hook for the 1000
extension.
Step 2
Cisco CallManager Express sends an SCCP message instructing Phone 1000 to play
a dial tone (which tells the caller that the system is ready to receive digits).
Step 3
The user on Phone 1000 dials the digits 1-0-0-1. As each digit is pressed, an SCCP
message is sent to the Cisco CallManager Express router, which analyzes the digits.
(After the first digit, Cisco CallManager Express sends an SCCP message telling the
IP Phone to stop playing the dial tone or, in some cases, to play a second dial tone.)
Step 4
A match is found to an IP Phone with extension 1001 (Phone 1001), and an SCCP
message is sent to the Phone 1001 informing it of an incoming call. This message
contains information about who is calling and instructions to Phone 1001 to play the
ring .wav file that is selected.
Step 5
Phone 1001 rings and is answered. An SCCP message is sent to Cisco CallManager
Express that says that extension 1001 has been answered.
Step 6
Cisco CallManager Express informs the IP Phones that are involved with the call of
the IP address, port, and coder-decoder (codec) that are to be used for the call.
Step 7
The two IP Phones set up RTP connections to each other, and the voice conversation
can flow.
Step 8
Cisco CallManager Express ceases to be involved in the call until the call is
transferred or terminated.
PSTN Calls with Cisco CallManager

Express As the PSTN Gateway
SCCP signaling is used
between the IP Phone and
Cisco CallManager Express.
PSTN
Voice
Appropriate signaling is used

between Cisco CallManager
Express and the PSTN.
RTP is used to carry traffic
between the IP Phone and the
router.
acts as an MTP.
Analog or Digital
Trunk(s)
Cisco
CallManager
Express
Voice over IP
UDP 16,384
32,768
Signaling
TCP 2000
Voice is sent to the PSTN.

IPTX v2.01-3
When calls are made to or from the PSTN and are coming from or destined for an IP Phone that
is under the control of Cisco CallManager Express, the RTP stream must be terminated on a
media termination point (MTP). The call must then be converted to the format that is
appropriate for the type of trunk that is going to the PSTN.
The following illustrates the steps for completing a call from one local IP Phone to a PSTN
destination with the Cisco CallManager Express router acting as the PSTN gateway:
Step 1
An IP Phone with extension 1000 goes off hook for the 1000 extension.
Step 2
Step 3
The user on Phone 1000 dials the digits of the PSTN destination. As each digit is
pressed, an SCCP message is sent to the Cisco CallManager Express router, which
analyzes the digits. (After the first digit, Cisco CallManager Express sends an SCCP
message telling the IP Phone to stop playing the dial tone or, in some cases, to play a
second dial tone.)
Step 4
A match is found to the PSTN destination, and a trunk, either analog or digital, is
seized by the Cisco CallManager Express router (which in this case is the PSTN
gateway).
Step 5
When the call is connected from the PSTN, an RTP stream is set up between the
IP Phone and the PSTN gateway. The RTP stream acts as an MTP. The voice inside
the RTP stream is converted to the format of the trunk that the voice goes across.
PSTN Calls with a Separate Voice Gateway

SCCP signaling is used
between the IP Phone
and Cisco CallManager
Express.
H.323 is used between
Cisco CallManager
Express and the PSTN
gateway.
RTP is used to carry traffic
between the IP Phone and
the voice gateway.
PSTN
Voice
Cisco
CallManager
Express
Analog or
Digital
Trunk(s)
PSTN
Gateway
H.323
RTP
The voice gateway acts

as an MTP.
SCCP
Signaling
Voice is sent to the PSTN

from the voice gateway.
IPTX v2.01-4
When calls are made to or from the PSTN that are coming from or destined for an IP Phone that
is under the control of Cisco CallManager Express, the RTP stream must be terminated on an
MTP. The following illustrates the steps for completing a call from one local IP Phone to a
PSTN destination when the Cisco CallManager Express system is not the PSTN gateway.
Step 1
An IP Phone with extension 1000 goes off hook for the 1000 extension.
Step 2
The Cisco CallManager Express system sends an SCCP message instructing Phone
1000 to play a dial tone (which tells the caller that the system is ready to receive
digits).
Step 3
The user on Phone 1000 dials the digits of the PSTN destination. As each digit is
pressed, an SCCP message is sent to the Cisco CallManager Express router, which
analyzes the digits. (After the first digit, Cisco CallManager Express sends an SCCP
message telling the IP Phone to stop playing the dial tone or, in some cases, to play a
second dial tone.)
Step 4
A match is found to the PSTN destination.
Step 5
Because Cisco CallManager Express does not physically terminate the trunk to the
PSTN terminated locally, it must signal the PSTN gateway to set up a connection to
the IP Phone. The call control protocol of either H.323 or session initiation protocol
(SIP) must be used to set up the call.
Step 6
On the PSTN gateway trunk, either analog or digital is used to connect to the PSTN.
Step 7
The IP Phone and the PSTN gateway set up an RTP session. The RTP stream is
converted to the format that the PSTN connection uses.
Step 8
The Cisco CallManager Express router ceases its involvement until the call is
transferred or terminated.
Intersite Calls
PSTN
IP WAN
SCCP
H.323 or SIP
1000
RTP
SCCP
2000
SCCP signaling is used between the IP Phone and Cisco CallManager

Express.
H.323 or SIP signaling is used between the Cisco CallManager Express
routers.
RTP is used to carry traffic between the IP Phones.
If Voice over IP is used on the WAN, the RTP header will be preserved.
IPTX v2.01-5
The following illustrates the steps for completing a call that starts from an IP Phone that is
under the control of one Cisco CallManager Express router and goes across a WAN link to an
IP Phone that is controlled by another Cisco CallManager Express router.
Step 1
An IP Phone with extension 1000 goes off hook.
Step 2
Step 3
The user on Phone 1000 dials the digits 2-0-0-0. As each digit is pressed, an SCCP
message is sent to the Cisco CallManager Express router, which analyzes the digits.
(After the first digit, Cisco CallManager Express sends an SCCP message telling the
IP Phone to stop playing the dial tone or, in some cases, to play a second dial tone.)
Step 4
A match is found to the dialed number, 2000, across the WAN link.
Step 5
Cisco CallManager Express uses the voice gateway function (in this case, the
Cisco CallManager Express router is the voice gateway) to set up a call to the
remote Cisco CallManager Express system. Either H.323 or SIP will be used to
set up this call.
Step 6
When the remote Cisco CallManager Express system receives the call setup message
for extension 2000, an SCCP message is sent to the IP Phone with extension 2000,
causing it to ring.
Step 7
When Phone 2000 is answered, an SCCP message goes from its Cisco CallManager
Express router to the IP Phone to which it is registered, informing the system that
the IP Phone answered the call.
Step 8
Via either H.323 or SIP, the remote Cisco CallManager Express router sends a
message that the call has been answered. The message is sent to the Cisco
CallManager Express router with which Phone 1000 is associated.
Step 9
Note
In this case, because the Cisco CallManager Express routers are the voice gateways,
the RTP packets traverse the routers. (However, to the routers, the RTP packets are
just data.) The Cisco CallManager Express router ceases to be involved in call
control until the call is transferred or terminated.
As long at the path across the WAN link is all IP-based, the RTP header will be preserved.
Packet Forwarding, Voice Packet Priority, and

RTP Stream Information
This topic describes the Quality of Service (QoS) markings, cost of service (CoS), and IP
precedence that the IP Phone places in voice packets at Layer 2 and Layer 3, respectively. The
topic also describes the concept of voice encapsulation.
Cisco CallManager Express Local QoS

A call has QoS markings on the Layer 2
header and in the IP packet header.
802.1q Trunk
Layer 2 CoS
Marking of 5
Layer 3 IP
Precedence
Marking of 5
These markings are used to give voice traffic

priority over most other types of data on the
network.
The Cisco CallManagerExpress system requires all
IP Phones under its control to be local on the same
LAN network.
IPTX v2.01-6
When voice is generated and put into IP packets on an IP Phone, both Layer 2 and Layer 3 QoS
markings are present. The Layer 2 marking is present only if the connection to the IP Phone is
an 802.1q trunk. An 802.1q trunk is the recommended configuration. The Layer 2 QoS marking
is called CoS. CoS has a range of 0 through 7, with 7 being the highest priority. When voice is
generated on the IP Phone and put into an 802.1q Ethernet header, a CoS marking of 5 is the
default. This marking allows the switch to give preferential treatment to voice frames.
There is an IP precedence marking in the Layer 3 IP header, which also has a range of 0
through 7 and also is set to 5 by default for voice that is generated on the IP Phone.
Note
Many QoS topics are covered in more detail in the module Introducing IP Quality of
Service.
RTP Stream Information

IP
UDP
RTP
Voice Payload
RTP
RTP headers carry voice across an IP-based network.
The RTP header is carried inside a UDP segment.
The UDP segment is carried inside IP packets.
UDP ports are randomly selected from 16,384 through 32,768.
If the whole path is Voice over IP, the RTP header will be preserved.
IPTX v2.01-7
Voice that is generated on an IP Phone is carried inside an RTP header. The RTP header is
encapsulated inside a User Datagram Protocol (UDP) segment. The UDP segment has a
randomly selected port for the current conversation, which will be in the range of 16,384
through 32,768. This UDP segment is then encapsulated inside an IP packet with an
IP precedence marking of 5. The IP packet is then put into an Ethernet frame and sent to the
attached switch. The RTP header will be unchanged as the long as the path is an all-IP-based
network.
WAN Call Setup
This topic explains the need for Call Admission Control (CAC) and describes what CAC is. It
also explains the need for dual tone multifrequency (DTMF) relay over a WAN.
The Need for Call Admission Control

CAC is useful for the WAN environment, where
bandwidth is often limited.
IP WAN
Is there enough bandwidth on the WAN for three

simultaneous calls?
If allowed, the third call will cause quality problems not only
for the third call, but also for all three calls.
The third call should be prevented.
IPTX v2.01-8
When calls are to be sent across an IP WAN link, saturation of the bandwidth is possible. When
there is not enough bandwidth, the effect on voice conversations can be significant. Packets are
dropped or queued up on the interface, which results in a significant degradation of service.
Insufficient bandwidth may be caused when voice traffic is sharing the link with other types of
data. Insufficient bandwidth may be managed through the use of QoS tools, using these tools
preference should be given to voice traffic. In addition, degradation of service results from too
much voice traffic on a link, which can cause all calls to receive poor quality.
For example, in the figure, it is assumed that there is enough bandwidth for two simultaneous
calls. If a third call is allowed to use the WAN, that third call and the other two calls will suffer
from choppy audio. The best practice is to prevent the third call from using the link.
In order to limit the number of calls across a WAN link, a CAC mechanism is needed. This
CAC mechanism can be set up to allow only a certain number of calls on a WAN link.
Call Admission Control Locally

CAC is not needed for traffic to IP Phones
because Cisco CallManager Express
assumes that the media is Ethernet LAN and
therefore that the bandwidth is effectively
unlimited.
IPTX v2.01-9
There is no need for a CAC mechanism locally between the IP Phones and Cisco CallManager
Express because all IP Phones under the control of Cisco CallManager Express must be
connected via LAN to the Cisco CallManager Express router. The much larger amount of
bandwidth on an Ethernet LAN negates the need for a CAC mechanism.
Call Admission Control Across WANs

CAC should be used for WAN links that could be even
temporarily saturated.
CAC is implemented through an H.323 mechanism
called a gatekeeper.
The voice gateway asks the gatekeeper if there is
enough bandwidth to set up the call with a specific
codec.
The gatekeeper answers the question with either an
affirmative or a negative response.
If the answer is negative, the dial plan of the voice
gateway must either connect the call using a secondary
path, like the PSTN, or give a fast busy signal to the
caller.
IPTX v2.01-10
Over WANs, the CAC mechanism is usually implemented through an H.323 mechanism called
a gatekeeper. The gatekeeper is consulted by the voice gateway (in many cases, the Cisco
CallManager Express router) to determine if sufficient bandwidth is available for the call to be
set up. The gatekeeper, which has been configured to allow a certain amount of bandwidth to
be available for voice, responds affirmatively or negatively. If the answer is affirmative, the
voice gateway sets up the call. If the answer is negative, the voice gateway either looks for
alternate ways to get to the destination or plays a fast busy signal.
The use of a gatekeeper ensures that no more than a certain amount of bandwidth is consumed
by voice traffic on a WAN.
Tip
A gatekeeper is used for other functions as well. For more information, go to

http://www.cisco.com/en/US/tech/tk652/tk701/technologies_tech_note09186a00800a8928.s
html.
DTMF Relay over the WAN

DTMF tones are normally carried in-band with
voice.
Low-bandwidth codecs such as G.729 are
designed for human voice, not for DTMF tones,
and they can distort DTMF tones carried in-band.
Symptoms of this problem are DTMF tones that are
interpreted as another digit or not detected at all.
The solution is to send DTMF tones out-of-band
in packets.
Various types of DTMF relay mechanisms exist.
IPTX v2.01-11
When calls are sent across a slower WAN link, low-bandwidth codecs are often used to
conserve bandwidth. These low-bandwidth codecs can have problems carrying DTMF digits.
The DTMF digits can be misinterpreted or not seen as valid tones when carried in-band with
voice. The G.729 codec is especially susceptible to these problems. The problems can show up
when voice mail is being checked and when interactive voice response (IVR) is being used.
Because of the problems arising from the use of low-bandwidth codecs, the DTMF digits
should be carried out-of-band from the voice.
The IP Phones in the Cisco CallManager Express system already use DTMF relay by using
SCCP when a digit is pressed on an IP Phone during call setup. After the call is dialed, the
DTMF relay and whether it will be used across a WAN link is defined on the voice gateway.
Note
If the G.711 codec is used everywhere, DTMF relay is not required, although implementing it
is still recommended. There is no adverse effect of implementing DTMF relay.
Summary
Summary
Local calls are set up and torn down by Cisco CallManager Express,
but the RTP goes between the two IP Phones.
SCCP is used between the IP Phones and Cisco CallManager
Express.
Calls to the PSTN can use the Cisco CallManager Express router as
the gateway or as a separate router.
The PSTN gateway must act as an MTP and convert the RTP stream
to and from the format of the connection to the PSTN.
Intersite calls that use an IP WAN link between sites preserve the
RTP headers.
Voice packets originating from the voice on the IP Phones have QoS
markings at Layers 2 and 3.
CAC should be used when going across low-bandwidth WAN links.
DTMF relay should be used when low-bandwidth codecs are used
across WAN links.
IPTX v2.01-12
Module Summary
This topic summarizes the key points discussed in this module.
Module Summary
Cisco CallManagerExpress provides the small to
midsize business with an integrated solution for call
control, voice mail, and data services.
Voice may be placed as data in packets through a
process of sampling the voice, quantizing the
samples, and encoding the value as a binary
expression.
Packet loss, delay, jitter, and the required bandwidth
all must be considered when configuring VoIP.
Cisco CallManagerExpress sets up calls through the
use of protocols such as SCCP, RTP, H.323, and SIP.
IPTX v2.01-1
When moving from a traditional telephony environment to a VoIP environment, it is important

to understand the differences and similarities. The VoIP process takes voice samples and
represents them as data, which is then collected into samples that are put into RTP segments.
The RTP segments are placed into UDP segments, then into IP packets. Finally, the IP packets
are placed into Ethernet frames and carried across the network.
You need to understand the challenges that you will encountered in the data environment when
you are designing and deploying Cisco CallManager Express. The challenges include delay,
jitter, packet loss, knowing the required bandwidth, and the need to give preference to VoIP
packets. You must be able to solve these challenges with the many IOS tools built into Cisco
An understanding of the basic call flows of Cisco CallManager Express is also essential to
understanding the issues and challenges. One of the most challenging situations is sending
VoIP across an IP WAN link to another site. Many issues arise when WAN links are involved.
These include bandwidth, CAC, QoS, and others.
References
For additional information, refer to these resources:
IP Communications Express Solution for the Small and Medium-Sized Office or Branch
Cisco CallManager Express with Cisco Unity Express.
http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_white_paper09186a00
80c637f.shtml.
Voice over IPPer-Call Bandwidth Consumption.
http://www.cisco.com/warp/public/788/pkt-voice-general/bwidth_consume.html#related
Cisco Systems, Inc. Voice Quality.
http://www.cisco.com/en/US/tech/tk652/tk698/tsd_technology_support_protocol_home.ht
ml
Cisco Systems, Inc. Voice Quality (Quality of Service for Voice over IP).
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_white_paper09186a00800d6b
73.shtml
Cisco CallManager Express 3.2 System Administrator Guide.
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_book09
186a00803416f7.html.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Q1) Which of the following best describes Cisco CallManager Express? (Source:
Describing Key Features of Cisco CallManager Express and CUE)
A) an optional feature of Cisco IOS software that supports up to 240 users
B) a standard feature of Cisco IOS software that supports up to 240 users
C) an optional feature of Cisco IOS software that supports up to 120 users
D) a standard feature of Cisco IOS software that supports up to 120 users
Q2) Cisco CallManager Express is available on IOS softwarebased multiservice access
routers including which three series? (Choose three.) (Source: Describing Key Features
of Cisco CallManager Express and CUE)
A) 3700 series
B) 2600 series
C) 3800 series
D) 1600 series
Q3) Which of the following best describes CUE? (Source: Describing Key Features of
Cisco CallManager Express and CUE)
A) available as a software upgrade
B) available in a network module form factor that supports up to 8 hours of voice
message storage
C) available in a network module form factor that supports up to 20 hours of voice
message storage
D) available in an advanced integration module form factor that supports up to 14
hours of voice message storage
Q4) CUE features include which of the following? (Source: Describing Key Features of
Cisco CallManager Express and CUE)
A) voice mail and automated attendant for large enterprise offices
B) two call control options: Cisco CallManager and Cisco CallManager Express
C) complete integration into Cisco 2600, 3600, and 3700 series routers
D) three form factors: software upgrade, network module, and AIM
Q5) The _____ defines how many phones will be controlled with the CallManager Express
software. (Source: Describing Key Features of Cisco CallManager Express and CUE)
A) feature license
B) specific Cisco CallManager Express
C) seat license
D) CUE license
enabled IOS image license
Q6) Which mailbox license is not available for the AIM-CUE? ((Source: Describing Key
Features of Cisco CallManager Express and CUE)
A) 12
B) 25
C) 50
D) 180
Q7) Cisco CallManager Express provides call processing for IP phones using _____.
(Source: Describing Key Features of Cisco CallManager Express and CUE)
A) RTP
B) H.323
C) PSTN
D) SCCP
Q8) Match the component of a telephony network with the function it performs. (Source:
Explaining Differences Between Traditional Telephony and VoIP)
A) private or CO switch
B) edge device
C) trunk
D) local loop
_____ 1. handles signaling, call routing, call setup, and call teardown
_____ 2. provides a path between two switches
_____ 3. connects to the PSTN
_____ 4. interfaces to the telephone company network
Q9) Which of these steps is optional in analog-to-digital conversion? (Source: Explaining
Differences Between Traditional Telephony and VoIP)
A) compression
B) encoding
C) quantization
D) sampling
Q10) Which two coding schemes are examples of waveform algorithms? (Choose two.)
(Source: Explaining Differences Between Traditional Telephony and VoIP)
A) PCM
B) ADPCM
C) CELP
D) LDCELP
E) CS-ACELP
Q11) To what size does cRTP compress the IP/UDP/RTP header without using UDP
checksums? (Source: Explaining Differences Between Traditional Telephony
and VoIP)
A) 2 bytes
B) 4 bytes
C) 8 bytes
D) 12 bytes
Q12) Which two factors have a minimal effect on data transmissions but negatively impact
voice transmissions? (Choose two.) (Source: Understanding VoIP Challenges and
Solutions)
A) high bandwidth
B) T1 links
C) packet loss
D) jitter
E) Layer 2 protocol
Q13) Which two Cisco IOS QoS features are employed in the output queue of the router?
(Choose two.) (Source: Understanding VoIP Challenges and Solutions)
A) FRF.12
B) IP to ATM CoS
C) CBWFQ
D) cRTP
E) RSVP
F) WRED
Q14) Which two Cisco QoS features are deployed in a WAN? (Choose two.) (Source:
Understanding VoIP Challenges and Solutions)
A) CAR
B) DWFQ
C) MLP with LFI
D) QoS policy propagation via BGP
E) cRTP
Q15) Which coding scheme requires the least bandwidth with compressed RTP applied?
(Source: Understanding VoIP Challenges and Solutions)
A) G.711
B) G.723
C) G.726
D) G.729
Q16) In which two call scenarios do the RTP packets, after the call is set up, continue to
traverse the CallManager Express router(s) for the remainder of the call until it is
transferred or terminated? (Choose two.) (Source: Describing the Cisco CallManager
Express Voice Packet Handling Methods)
A) local (on-net) calls
B) a call to the PSTN using the Cisco CallManager Express as a PSTN gateway
C) a call to the PSTN using a separate PSTN gateway that is not the CallManager
Express router
D) a call flow using a WAN link to connect two IP Phones registered to separate
Cisco CallManager Express routers that are acting as the voice gateways
E) all of the above
Q17) In which call scenario does the voice gateway act as a media termination point (MTP)?
(Source: Describing the Cisco CallManager Express Voice Packet Handling Methods)
A) a call between an IP Phone and the PSTN (local call)
B) a call between local IP Phones (on-net call)
C) a call using a WAN link to connect two IP Phones that are registered to
separate Cisco CallManager Express routers
D) none of the above
Q18) Layer 2 marking is: (Source: Describing the Cisco CallManager Express Voice Packet
Handling Methods)
A) 802.1q
B) QoS
C) CoS
D) CAC
Q19) An RTP header is encapsulated in: (Source: Describing the Cisco CallManager Express
Voice Packet Handling Methods)
A) a TCP segment
B) a UDP segment
C) either a TCP segment or a UDP segment, depending on which is supported by
the network
Q20) Which call scenario is most likely to require CAC? (Source: Describing the Cisco
CallManager Express Voice Packet Handling Methods)
A) a local (on-net) call
B) a call to the PSTN using Cisco CallManager Express as a PSTN gateway
C) a call to the PSTN using a separate PSTN gateway that is not the Cisco
CallManager Express router
D) a call flow using a WAN link to connect two IP Phones that are registered to
separate Cisco CallManager Express routers that are acting as the voice
gateways
Module Self-Check Answer Key

Q1) A
Q2) A, B, C
Q3) D
Q4) B
Q5) A
Q6) D
Q7) D
Q8) A, C, B, D
Q9) A
Q10) A, B
Q11) A
Q12) B, C
Q13) C, F
Q14) C, E
Q15) B
Q16) B, D
Q17) A
Q18) C
Q19) B
Q20) D
Module 2
Configuring Cisco
CallManager Express
Overview
This module describes the basic functionality of Cisco CallManager Express. This includes the
configuration of specific network components and services that are necessary for the proper
functioning of Cisco CallManager Express. The module also discusses the files that are
required to run the Phones and web-based GUI.
Module Objectives
Upon completing this module, you will be able to describe the features and functionality of
Cisco CallManager Express and Cisco Unity Express (CUE). You also will be able to configure
Cisco CallManager Express to support IP Phones. This includes being able to meet these
objectives:
Describe the key features and functionality of Cisco CallManager Express
Describe the key features and functionality of CUE
Configure Cisco CallManager Express network parameters and discuss the need for and
configuration of auxiliary VLANs, DHCP, DHCP relay, and NTP
Describe the IP Phone registration process
Define ephone-dn and ephone and describe examples and types
Describe the three ways to create an initial phone setup
Describe Cisco CallManager Express files
Lesson 1
Understanding Cisco
CallManager Express Features
and Functionality
Overview
This lesson introduces you to the key features and functionality of Cisco CallManager Express.
Objectives
Upon completing this lesson, you will be able to describe the key features and functionality of
Cisco CallManager Express. This ability includes being able to meet these objectives:
Identify the key benefits and features of Cisco CallManager Express
Describe the supported platforms and telephones for Cisco CallManager Express
Describe the supported protocols and integration options for Cisco CallManager Express
Describe Cisco CallManager Express requirements for licensing, memory, platforms,
Cisco IP Phone models, and software
Identify Cisco CallManager Express restrictions
Key Benefits and Features
This topic describes the key benefits and features of Cisco CallManager Express
Cisco CallManager Express Key Benefits

Extends capabilities to the small office that were
previously only available to larger enterprises
Reduces the TCO by delivering voice, video, and
data over a consolidated infrastructure
Is based on Cisco IOS software
Supports converged applications
Protects customer investment
Is administered by GUI or CLI
IPTX v2.02-2
IP telephony is currently undergoing explosive growth, driven by access to value-added

features and applications that only IP telephony can provide the end user with. This growth
allows Cisco CallManager Express benefits and features to be extended to the small office.
In addition, the cost benefits of converging voice, video, and data onto a single network is
fueling the rapid acceptance of IP telephony. The reduction in the total cost of ownership
(TCO) is one of the main benefits of the Cisco CallManager Express solution.
Because the solution is based on Cisco IOS software, existing experience with Cisco products
can be leveraged to offer simple configuration and deployment. Cisco CallManager Express
can be integrated into a multiservice router, allowing advantages of converged applications,
including content networking, video, quality of service (QoS), firewall, Ethernet, and extensible
markup language (XML) services.
The Cisco CallManager Express solution includes 100 percent investment protection for
customers if they need to migrate to a centralized Cisco CallManager architecture.
Administration and management is through either the familiar Cisco IOS software commandline interface (CLI) or a web-based GUI.
Cisco CallManager Express Key Features

Phone features
System features
Trunk features
Voice mail features
IPTX v2.02-3
Cisco CallManager Express has many high-level phone, system, trunk, and voice mail features.
Phone Features
The high-level phone features for Cisco CallManager Express are as follows:
Support for single-line and multiline Cisco IP Phones (Cisco IP Phones 7902G, 7905G,
7910G+SW, 7912G, 7920, 7940G, 7960G, 7970G, and 7971G-GE)
Support for the Cisco IP Conference Station 7935 and 7936
Support for analog phones on the Cisco CallManager Express router analog voice ports and
on the Cisco Analog Telephone Adaptor (ATA) 186 and 188
Support for fax machines
XML services on Cisco IP Phones
240 Phones per system
Six line appearances per each 7960G Phone
Eight line appearances per each 7970G and 7971G-GE Phone
On-hook dialing
Local directory lookup
Speed dial and last number redial
Idle URL, which can periodically push messages onto the screen of 7940G, 7960G, or
7970G Phones
Automated attendant functionality when the 7960G Phone is combined with the Cisco IP
Phone 7914 Expansion Module
Configurable ring types
Message Waiting Indicator (MWI)
Copyright 2005, Cisco Systems, Inc. Configuring Cisco CallManager Express 2-5
Customization of softkeys
Do Not Disturb (DND) feature to divert calls directly to voice mail
IP Phone display of DND state
Enable/disable call waiting notification per line
Monitor-line button speed dial
System Features
The high-level system features for Cisco CallManager Express are as follows:
Conferencing capabilities
Paging
Intercom
Call transfer consultative and blind
Call hold and call retrieve
Call pickup of on-hold calls
Call waiting
Tone on hold and tone on transfer for internal calls
Music on Hold (MOH) and music on transfer for external calls
MOH file on router
MOH live feed external source
Distinctive ringing internal versus external
International language support German, French, Italian, and Spanish
System speed dial option via XML service
Directory services using XML
Web-based GUI for moves, adds, and changes
GUI customization capabilities
Interactive voice response (IVR) Auto Attendant
Class of restriction to restrict calling capabilities
In-line power for IP Phones
Call transfer and call forwarding (standards-based H450.2 and H450.3)
Computer telephony integration (CTI) support with Telephony Application Programming
Interface (TAPI) Lite
Call Detail Record (CDR) generation via RADIUS
Interworking with Cisco and NetCentrex gatekeepers
Hookflash pass-through to a central office (CO) for analog phones
Date and time synchronization with Network Time Protocol (NTP)
Longest-idle hunt group
Hunt group dynamic login/logout
Hunt group statistics

Caller ID display for hunt group
Called name directory lookup for Dialed Number Identification Service (DNIS)
Called name display for overlay dialed number (DN)
Conference initiator drop-off
Consultative transfer for direct station select
Repeat night service notification every 12 seconds
Translation-profile support for ephone-dn
Trunk Features
The high-level trunk features for Cisco CallManager Express are as follows:
Direct inward dialing (DID) and direct outward dialing (DOD)
BRI/PRI support all switch types that IOS software supports
Caller identification display and blocking, calling name display, and automatic number
identification support
Analog Foreign Exchange Office (FXO), DID
Digital trunk support T1 and E1
WAN link support Frame Relay, ATM, Multilink PPP (MLP), and digital subscriber line
(DSL)
Network calls using H.323
Dedicated trunk mapping to phone button
H.323 to session initiation protocol (SIP) call routing to Cisco Unity Express (CUE)
RFC 2833 support over SIP trunks
Transcoding
Voice Mail Features

The high-level voice mail features for Cisco CallManager Express are as follows:
Integration with Cisco Unity voice mail
Integration with CUE voice mail
Third-party voice-mail integration H.323, analog dual tone multifrequency (DTMF)
Tip
The Cisco CallManager Express Administration Guide can be found at

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_book091
86a00803416f7.html.
Supported Platforms and Telephones
This topic describes the supported platforms and telephones of Cisco CallManager Express.
Supported Platforms
Cisco CallManager Express supports these
Cisco platforms:
IAD 243X Series (SP only)
2691
1751V
2801
1760
2811
2610XM
2821
2611XM
2851
2620XM
3725
2621XM
3745
2650XM
3825
2651XM
3845
IPTX v2.02-4
Cisco CallManager Express supports these Cisco platforms: IAD 243X Series (SP only),
1751V, 1760, 2610XM, 2611XM, 2620XM, 2621XM, 2650XM, 2651XM, 2691, 2801, 2811,
2821, 2851, 3725, 3745, 3825, and 3845.
Supported Platforms (Cont.)

Cisco CallManager
Express Platform
IAD 243X, 1751V, 1760,
2801
Maximum
Number of
Phones
24
License
FL-CCME-SMALL
2610XM, 2611XM, 2620XM,

2621XM, 2811
36
FL-CCME-36
2650XM, 2651XM, 2821
48
FL-CCME-MEDIUM
2691
FL-CCME-72
3825
72
96
144
192
168
3845
240
FL-CCME-240
2851
3725
3745
FL-CCME-96
FL-CCME-144
1 FL-CCME-192
FL-CCME-168
IPTX v2.02-5
Depending on the platform, Cisco CallManager Express supports up to 24, 36, 48, 72, 96,144,
168, 192 or 240 IP Phones. The licenses can be purchased and upgraded incrementally,
allowing the customer to purchase only the required number of licenses now with the ability to
grow in the future by purchasing additional licenses.
Example
ACME Company currently has an installation of 72 IP Phones, with each employee having an
IP Phone. ACME has also purchased a Cisco 3745 router because it plans to hire 38 additional
employees in the next year, for a total of 110 employees. All employees will need to have an
IP Phone. Initially, ACME purchased the feature license FL-CCME-96, which is the minimumsized license required to support 72 IP Phones. When the expansion to 110 IP Phones becomes
necessary, the feature license FL-CCME-SMALL must be purchased to add 24 IP Phones to the
Cisco CallManager Express system. The two licenses together will allow up to 120 IP Phones,
which will support the planned expansion to 110 IP Phones.
Supported IOS Images

Cisco CallManager Express 3.2.1 requires a
minimum of Cisco IOS Release 12.3(11)T.
The version of IOS 12.3(11)T must contain the IP
Voice feature set for all supported platforms
except the 1700 series.
The 1700 series router must have the VOX feature
set of IOS 12.3(11)T.
IPTX v2.02-6
Cisco CallManager Express 3.2.1 requires a minimum Cisco IOS Release version of 12.3(11)T.
The IOS version must also include the IP voice feature set to include the CallManager Express
functionality. Select the highest T version that will incorporate bug fixes in that version of IOS
software. For example, Cisco IOS Release 12.3(11)T3 would be preferred to Cisco IOS Release
12.3(11)T2.
When you are using the Cisco 1700 platform, the version of IOS software that is required is
Cisco IOS Release 12.3(11)T and it must contain the VOX feature set.
Cisco CallManager Express Scalability and

Memory Requirements
Memory recommendations may not be sufficient
for larger installations.
The memory that is needed depends upon:
The applications that are configured
The hardware platform
IPTX v2.02-7
Memory requirements for the Cisco CallManager Express router depend on the number of
IP Phones and which other applications may be configured on the router. For example, if
Network Address Translation (NAT) is also running on the router, the memory requirements
may be greater than if only Cisco CallManager Express is running on the router. The memory
that is installed in the router varies based on the hardware platform and is one factor that
determines the number of IP Phones the Cisco CallManager Express router will support.
Cisco IOS Release 12.3(11)T with Cisco CallManager Express 3.2.1
Platform
Phones
Extensions or
Directory Numbers
IAD 243X, 1760, 1760-V 24 120 64/128

1751V 24 120 32/128
2610XM, 2611XM,
2620XM, 2621XM, 2811
36 144 48/128
2650XM, 2651XM 48 192 48/128

2691 72 288 64/254
2801 24 120 64/128
2821 48 144 63/256
2851 96 288 64/254
3725 144 500 64/256
3745 192 500 64/256
3825 168 500 64/256
3845 240 720 65/256
Minimum
Recommended
Flash/RAM
Supported Telephones
7902G7905G7910G+SW7912G
7920
7935,
7936
7971G-GE
7940G7960G
7940 + 7914,
7960 + 7914
7970G
ATA 186, 188

IPTX v2.02-8
Cisco CallManager Express supports a new generation of intelligent Cisco IP Phones, including
the 7902G, 7905G, 7910G+SW, 7912G, 7920, 7935 and 7936 (conference stations), 7940G,
7960G, 7970G, 7971G-GE, 7940G + 7914, and 7960G + 7914. Regular analog phones and fax
machines are supported through the Cisco ATA 186 and 188 or Foreign Exchange Station
(FXS) ports on the Cisco CallManager Express router. All supported telephones use Skinny
Client Control Protocol (SCCP), often referred to as skinny protocol.
7902G Features
Common-area phone
G.711 and G.729 codecs
Single line
No display
SCCP support
Four programmable keys
Power over Ethernet
IPTX v2.02-9
The Cisco 7902G is a single-line IP Phone with fixed feature keys. These keys provide onetouch access to the redial, transfer, conference, and voice mail features. Consistent with other
Cisco IP Phones, the Cisco 7902G also supports in-line power, which allows the Phone to
receive power over the LAN. This capability gives the network administrator centralized power
control, which translates into greater network availability. The Cisco prestandard PoE is
supported.
7905G Features
Common-area phone
Call-monitoring mode
Single line
XML application protocol
SCCP support
Power over Ethernet
IPTX v2.02-10
The Cisco 7905G provides single-line access and four interactive softkeys, which guide the
user through call features and functions via the pixel-based liquid crystal display (LCD). The
graphic capability of the display provides a rich user experience by presenting calling
information, intuitive access to features, and language localization in future firmware releases.
The Cisco prestandard PoE is supported.
This IP Phone is appropriate for a common area that does not need a switch port for a PC to
connect to, such as a lobby.
7910G+SW Features
Common-area phone

Power over Ethernet
Call-monitoring mode
Single line
802.1q support
10/100 Ethernet switch port
No XML application support

SCCP support
IPTX v2.02-11
The Cisco 7910G+SW is a basic telephone that is used primarily in common-use areas (such as
lobbies, break rooms, and hallways) that require only basic features. The Cisco 7910G+SW
includes a Cisco two-port switch, making it suitable for user applications in which basic phone
functionality and an Ethernet device such as a PC are necessary. The Cisco prestandard PoE is
supported.
The 7910G+SW provides four dedicated feature buttons: line, hold, transfer, and settings. A
cluster of six feature access keys is located above the volume control rocker switch. These
access keys support message, conference, forwarding, speed dial, and redial features.
7912G Features
Single line
Lighted hold key
Call-monitoring function
SCCP support
802.1q support
Power over Ethernet
IPTX v2.02-12
The Cisco 7912G is a basic IP Phone with an Ethernet switch port, which provides a core set of
business features. This IP Phone is basically a Cisco 7905 with a switch port. This easy-to-use,
display-based IP Phone increases productivity while minimizing user training and delivers
network and application convergence. The Cisco prestandard PoE is supported.
This IP Phone is commonly used for basic users who have a need for both a PC and an IP Phone.
7920 Features
802.11b
Vibrate or ring
LEAP and WEP security
Mobility
QoS
SCCP support
IPTX v2.02-13
The Cisco 7920 is an easy-to-use IEEE 802.11b wireless IP Phone that provides comprehensive
voice communications in conjunction with Cisco CallManager Express and Cisco Aironet
1200, 1100, 350, and 340 Series of Wi-Fi (IEEE 802.11b) access points. As a key component
of the Cisco Architecture for Voice, Video and Integrated Data (AVVID) Wireless Solution,
the Cisco 7920 delivers seamless intelligent services such as security, mobility, QoS, and
management across an end-to-end Cisco network.
Note
A site survey is strongly advised before the use of this IP Phone.
7935 and 7936 Features

Conferencing
360-degree coverage
Power brick required
No XML application
SCCP support
External microphone
connection (7936 only)
IPTX v2.02-14
The Cisco 7935 and 7936 are IP-based, full-duplex conference stations for use on desktops.
These full-featured, hands-free stations can also be used in small- to medium-sized conference
rooms. In addition to the regular telephony keypad, the Cisco 7935 and 7936 provide three soft
keys and menu navigation keys that guide users through call features and functions.
The full-duplex design of the Cisco 7935 and 7936 offers superior voice quality, eliminating
echoes, clipped words, and reverberations, for more natural conversation. It features superior
sound quality with a digitally tuned speaker and three microphones, allowing conference
participants to move around while speaking.
Note
The Cisco IP Conference Stations 7935 and 7936 work best in small- to medium-sized
conference rooms, rather than large conference rooms.
7940G Features
Up to two line appearances
Power over Ethernet
XML application support
SCCP support
IPTX v2.02-15
The Cisco 7940G is a second-generation, full-featured IP Phone for low- to medium-traffic

users who require a minimum of directory numbers. It provides two programmable line
or feature buttons and four interactive softkeys, which guide users through call features
and functions. The Cisco prestandard PoE is supported.
7960G Features
Up to six line appearances
Power over Ethernet
SCCP support
IPTX v2.02-16
The Cisco 7960G is a second-generation, full-featured IP Phone primarily for manager and
executive needs. It provides six programmable line or feature buttons and four interactive
softkeys to guide users through call features and functions. The Cisco prestandard PoE is
supported.
7970G Features
Up to eight line appearances
Color touch screen
Power over Ethernet
External power required for
full screen brightness
SCCP support
Stereo jack sockets
IPTX v2.02-17
The Cisco IP Phone 7970G demonstrates the latest technology and advancements in
Voice over IP (VoIP) telephony. It not only addresses the needs of the executive or major
decision-maker, but also brings network data and applications to users without PCs. This stateof-the-art IP Phone includes a backlit, high-resolution color touch-screen display (320-x-234,
12-bit display with 4096 colors) for easy access to communication information, timesaving
applications, and feature usage. It also enables customers and developers to deliver more
innovative and productivity-enhancing XML applications to the display. Access to eight
telephone lines (or a combination of lines and direct access to telephony features), a highquality hands-free speakerphone, a built-in headset connection, and both Cisco prestandard
Power over Ethernet (PoE) and IEEE 802.3af PoE are supported.
7971G-GE Features
Up to eight line appearances
Color touch screen
Gigabit Ethernet switch port
Power over Ethernet
External power required for
full screen brightness
SCCP support
Stereo jack sockets
IPTX v2.02-18
First to provide unconstrained bandwidth to desktop applications, the Cisco IP Phone 7971G-GE
delivers the latest technology and advancements in Gigabit Ethernet VoIP telephony. It not
only addresses the needs of an executive or major decision-maker, but also brings network data
and applications to users quickly with its Gigabit Ethernet port for integration with a PC or
desktop server. The features of this state-of-the-art Gigabit Ethernet IP Phone are identical to
those of the Cisco IP Phone 7970G. The 7971G-GE Phone also includes a backlit, highresolution color touch-screen display (320-x-234, 12-bit display with 4096 colors) for easy
access to communication information, timesaving applications, and feature usage. It also helps
enable customers and developers to deliver more innovative and productivity-enhancing XML
applications to the display. Offering access to eight telephone lines (or a combination of lines
and direct access to telephony features), a high-quality, hands-free speakerphone, and a built-in
headset connection, the 7971G-GE Phone can be powered through IEEE 802.3af PoE or a local
power supply. The 7971G-GE does not support Cisco prestandard PoE.
Telephone Screens
Has pixel-based screen

Has multiple softkey buttons
along the bottom
Displays status of phone
Displays call information
Can be used to run
third-party or custom
XML applications
IPTX v2.02-19
The Cisco 7935, 7940G, 7960G, 7970G and 7971G-GE Phones all have a large, pixel-based
LCD. The pixel-based LCD displays features such as date and time, calling party name, calling
party number, digits dialed, and feature and line status.
The four softkey buttons change based on the current state of the call. This allows for the
buttons to be used more efficiently than if they were statically assigned. These buttons can also
be invoked and customized by a third party or a custom XML-based application.
Note
For more information on XML applications, please go to

http://cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter0
9186a00801e9e44.html.
Expansion Module 7914 Features
Adds on to 7960 Phone

Has 14 line appearances or
speed dials
Connects to the RS-232 port
on a 7940 Phone or 7960 Phone
Chains up to two
Has lighted button to convey
call state
Requires new stand
Requires power brick
IPTX v2.02-20
The Cisco IP Phone 7914 Expansion Module extends the capabilities of the Cisco IP Phone
7960 with additional buttons and an LCD. This expansion module adds 14 buttons to the
existing six buttons of the Cisco IP Phone 7960, increasing the total number of buttons to 20
when you add one 7914 Expansion Module and to 34 when you add two 7914 Expansion
Modules.
The large LCD of the 7914 Expansion Module enables users to quickly and easily identify
associated buttons. Using the Settings menu of the 7960 Phone, you can adjust the contrast of
the individual LCDs for the 7960 Phone and the 7914 Phone, if necessary.
Each of the 14 buttons on the 7914 Expansion Module can be programmed as an extension
number or a speed dial key, much like the 7960 Phone. In addition, the silent ring option for
shared lines mapped to the 7914 Phone, the fast transfer capability, and the busy lamp
capability are used to provide attendant console functionality. The 7914 Expansion Module
connects to the RS.232 port on the back of the 7960 Phone; a new stand and power brick are
required.
ATA 186 and 188 Features
Analog connectivity
186 two analog ports
188 two analog ports plus
10/100 switch port
Fax or analog phone
SCCP required for phone
H.323v2 support
H.323 required for fax
IPTX v2.02-21
The Cisco ATA 186 and 188 connect regular analog phones and fax machines to IP-based
telephony networks. Each of the two voice ports on the Cisco ATA 186 and 188 supports
independent telephone numbers, giving you two separate lines. In addition, the internal
Ethernet switch allows for a direct connection to a 10BASE-T Ethernet network and a
100BASE-TX Ethernet network via an RJ-45 interface.
When the ATA 186 or 188 is going to be used for analog phone connectivity, it should be
configured to use SCCP. However, when the ATA 186 or 188 is being used for fax
connectivity, it must use H.323 connectivity. The two analog ports of the ATA 186 or 188 must
both use the same protocol. As a result, the device can be used as either an analog phone or a
fax machine, but not both.
Note
Analog modem connections are supported only on an FXS port local to a router and are not
supported on the Cisco ATA 186 or 188.
Analog Phones
Fax
ATA
V
ATA
Analog
SCCP
H.323
SCCP
IPTX v2.02-22
Cisco CallManager Express can use both H.323 and SCCP to control IP Phones, analog phones,
and faxes.
Supported Protocols and Integration Options
This topic describes the supported protocols and integration options of Cisco CallManager Express.
SCCP Client Control Protocol

Cisco-proprietary protocol
Call control protocol
Lightweight protocol
Low memory requirements
Low complexity
Low CPU requirements
IPTX v2.02-23
Cisco CallManager Express software provides call processing for IP Phones using SCCP.
SCCP is the Cisco-proprietary protocol for real-time calls and conferencing over IP. This
generalized messaging set allows Cisco IP Phones to coexist in an H.323 environment. Savings
in memory size, processor power, and complexity are benefits of SCCP.
SCCP Phone Limitations

QoS, bandwidth, and CAC are not supported
within SCCP.
Complex connection paths can cause QoS
problems.
IP Phones should be connected locally to the
Cisco CallManager Express router.
IPTX v2.02-24
QoS, bandwidth management, and Call Admission Control (CAC) are not supported within the
SCCP context on Cisco CallManager Express. Complex connection paths could cause QoS
problems. Because of these factors, all IP phones must be connected locally to the Cisco
CallManager Express router.
H.323 Protocol
Support for voice, video, and data
Industry standard
Complex protocol
Higher complexity than SCCP
CAC functionality
Authentication
IPTX v2.02-25
H.323 is a specification for transmitting audio, video, and data across an IP network, including
the Internet. H.323 is an extension of the International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) standard H.320.
Tip
The ATA must be configured with H.323 when fax machines are connected to the analog
ports.
Examples of Recommended H.323

Connections
Cisco
CallManager
Cluster
Cisco
CallManager
Express
H.323
PSTN
H.323
WAN
ATA
H.323
H.323
Cisco
CallManager
Express
IPTX v2.02-26
This figure shows the H.323 protocol being used to connect the Cisco CallManager Express
routers together and to control the analog fax connected to the ATA.
H.323 Gatekeeper
Cisco CallManager Express can register to an
H.323 gatekeeper, ensuring that the WAN is not
oversubscribed.
H.323
WAN
Register
1000
2095551000
Register extension number,
E.164 number, or both
Register
Gatekeeper
2000
3095552000
Register extension number,
E.164 number, or both
IPTX v2.02-27
The Cisco CallManager Express system can be configured to register an ephone-dn with
an H.323 gatekeeper. In addition, the IP Phone can have both an extension number and an
E.164 number defined, and one or both of those numbers can be registered with the H.323
gatekeeper. H.323 can also be used to allow one Cisco CallManager Express to communicate
with another Cisco CallManager Express or with voice gateways. A router separate from Cisco
CallManager Express must be used if a gatekeeper is going to be configured.
The H.323 gatekeeper can provide the following functions:
CAC over a WAN link to ensure that the WAN link is not oversubscribed
Dial plan administration, which centralizes the dial plan for intersite numbering
IP-to-IP gatewaytoprovide a network-to-network point for billing and security and for
joining two VoIP call legs together
SIP Protocol
Emerging standard
Vendor-specific in most cases
Higher complexity than SCCP
Authentication
Based on other well-known protocols
IPTX v2.02-28
SIP was designed as a multimedia protocol that could take advantage of the architecture and
messages found in popular Internet applications. By using a distributed architecture with URLs
for naming and ASCII text-based messages, SIP attempts to take advantage of the Internet
model and standards for building VoIP networks and applications. In addition to VoIP, SIP is
used for videoconferencing and instant messaging.
As a protocol, SIP defines only how sessions are to be set up and torn down. SIP leverages
other Internet Engineering Task Force (IETF) protocols to define other aspects of VoIP and
multimedia sessions, such as session definition protocol (SDP) for capabilities exchange, URLs
for addressing, Domain Name System (DNS) for service location, and Telephony Routing over
IP (TRIP) for call routing.
SIP Connections
Cisco
CallManager
Express
H.323
Cisco
CallManager
Express
PSTN
SIP
WAN
SIP
SIP
Cisco
CallManager
Express
IPTX v2.02-29
It is possible to use SIP to connect calls between Cisco CallManager Express systems.
Cisco CallManager Express Requirements

This topic describes Cisco CallManager Express requirements.
Cisco CallManager Express Requirements

Feature license
Seat license
IOS software platform
Release 12.3(11)T or greater is recommended.
IP Voice feature set must be included.
Cisco CallManager Express software and files
GUI files
Firmware
IPTX v2.02-30
Cisco CallManager Express requires a Cisco CallManager Express feature license. This
license is based on the number of IP Phones that will be deployed. The router itself must have
an IOS release that is Cisco CallManager Expresscapable. Each IP Phone or ATA port also
requires a Cisco CallManager Express seat license, which can be purchased with the IP Phone.
You also need an account on Cisco.com in order to download Cisco CallManager Express files,
such as Phone firmware and GUI files and firmware.
Cisco CallManager Express Restrictions

This topic describes Cisco CallManager Express restrictions.
Cisco CallManager Express Restrictions

TAPI v2.1 is not fully supported.
Cisco JTAPI is not supported.
Cisco IP Softphone is not supported.
MGCP is not supported.
IPTX v2.02-31
There is a subset of TAPI version 2.1 support in Cisco CallManager Express. Cisco Java TAPI
(JTAPI) is not currently supported, which restricts the use of a Cisco IP Softphone. The newer
IP Softphone, the Cisco Communicator Softphone, is also not currently supported, although
future versions may be supported. Currently, only third-party softphones from IP Blue work
with Cisco CallManager Express.
Cisco CallManager Express supports only phones that are local to the Cisco CallManager
Express LAN and does not support remote SCCP phones that are connected across WAN links.
Media Gateway Control Protocol (MGCP) is not supported in Cisco CallManager Express.
TAPI Lite Functionality

Supported:
Operation of multiple independent clients (for example, one
client per phone line)
Windows Phone Dialer
Outlook Contact Dialer
Third-party applications
Not supported:
TAPI-based softphone
Multiple-user or multiple-call handling (required for ACD)
Direct media and voice handling
JTAPI
IPTX v2.02-32
Cisco CallManager Express does not support TAPI v2.1Cisco CallManager Express TAPI
implements only a small subset of TAPI functionality. It does support operation of multiple
independent clients (for example, one client per phone line), but does not fully support
multiple-user or multiple-call handling, which is required for complex features such as
automatic call distribution (ACD).
Applications such as Windows Phone Dialer and Outlook Contact Dialer can use TAPI Lite
to dial, place on hold, transfer, and terminate a call on an associated line on an IP Phone. JTAPI
is not supported, nor are TAPI-based softphones. TAPI Lite allows for the control of a line
on an associated PC, but not for the termination of voice on the PC.
Note
Third-party applications can be developed to control a line that takes advantage of TAPI
Lite.
Summary
Summary
Cisco CallManager Express software provides
call processing for IP Phones using SCCP.
Cisco CallManager Express supports these
Cisco platforms: IAD 243X Series, 1751V, 1760,
2600XM Series, 28XX, 37XX, and 38XX.
Cisco CallManager Express supports all
Cisco IP Phones.
Certain functionalities are not currently supported
in the Cisco CallManager Express software.
IPTX v2.02-33
Lesson 2
Configuring Cisco
CallManager Express Network
Parameters
Overview
This lesson describes the Cisco CallManager Express network parameters and the steps to
configure these parameters.
Objectives
Upon completing this lesson, you will be able to configure Cisco CallManager Express network
parameters. You also will be able to discuss the need for and the configuration of voice
VLANs, DHCP, DHCP relay, Network Time Protocol (NTP), and transcoding between G.729
and G.711. This includes being able to meet these objectives:
Describe voice VLANs
Configure voice VLANs on a Cisco Catalyst switch and an EtherSwitch network module
Identify DHCP service options
Define a DHCP relay server
Configure NTP
Describe and configure transcoding between G.729 and G.711
Voice VLANs
This topic describes voice VLANs.
Voice VLANs
Prevents unnecessary IP address renumbering
Simplifies QoS configurations
Separates voice and data traffic
Requires two VLANs: one for data traffic and one
for voice traffic
Requires only one drop-down Ethernet for the
Cisco CallManager Express IP Phone and the PC
that is plugged into the Phone
IPTX v2.02-2
A Cisco IP Phone can act as a three-port switch. Just like a switch, the Phone can support
trunking between itself and another switch. Thus, more than one VLAN can be supported
between the IP Phone and the access switch into which it is plugged.
The three ports of the IP Phone are the port that connects to the 10/10 Ethernet switch, the
10/100 Ethernet port into which a PC can be plugged, and an internal port from which voice
traffic originates and terminates. The 10/100 Ethernet port, which attaches to a switch, supports
the 802.1q trunking protocol. This enables two VLANs to arrive at the Phone, one for the voice
traffic and the other for the PC data traffic. The VLAN that the voice traffic goes across is
called the auxiliary VLAN, or the voice VLAN.
Note
Inter-Switch Link (ISL) trunking is not supported on Cisco IP Phones.
The benefits of this type of configuration include the following:

This solution allows IP Phones to be deployed onto the network without scalability
problems from an addressing perspective. IP subnets usually have more than 50 percent
often more than 80 percentof their IP addresses allocated. A separate VLAN (separate IP
subnet) to carry the voice traffic allows a large number of new devices, such as IP Phones,
to be introduced into the network without extensive modifications to the IP addressing
scheme.
This solution allows the logical separation of data traffic and voice traffic, which have
different characteristics. This separation allows the network to individually handle each of
these traffic types and apply different QoS policies.
Because the data and voice traffic are separated, they also can be monitored and managed
separately.
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, the PC location, or
both.
IP Addressing Deployment Options

IP Phone + PC on same
switch ports
IP Phone + PC on same
switch ports
Recommended
171.68.249.100
171.68.249.100
171.68.249.101
10.1.1.1
Public IP addresses
IP Phone uses private network
IP Phone + PC on separate switch ports

171.68.249.101
IP Phone + PC on separate switch ports
171.68.249.100
Public IP addresses
10.1.1.1
171.68.249.100
IP Phone uses private network
IPTX v2.02-3
Cisco IP Phones require network IP addresses. Cisco makes the following recommendations for
IP addressing deployment:
Continue to use existing addressing for data devices (PCs, workstations, and so forth).
Add IP Phones using DHCP as the mechanism for obtaining addresses.
Use subnets for IP Phones if they are available in the existing address space.
Use private addressing such as the 10.0.0.0 network (see RFC 1918 for details) if subnets
are not available in the existing address space.
LANs and private IP WANs will carry these routes between both of the address spaces. The
WAN gateway to the Internet should block private addresses, which are currently blocked by
data devices.
Configuring Voice VLANs
This topic describes how to configure voice VLANs on the Catalyst switch and an EtherSwitch
network module.
Voice VLANs
An access port can handle two VLANs.
Native VLAN
Auxiliary, or voice, VLAN
The switch port interface is set to dot1q trunk.
Tagged 802.1q (voice VLAN)
Untagged 802.3 (native VLAN)
IPTX v2.02-4
All data devices typically reside on data VLANs in the traditional switched scenario. You may
need a separate VLAN when you combine the voice network with the data network. For
configuration purposes, the Catalyst software command-line interface (CLI) refers to this new
VLAN as the voice VLAN. You can use the new voice VLAN to house nondata devices, in this
case, IP Phones. The Phones will reside in the voice VLAN if you configure the switch to
support them; data devices reside in the native VLAN (also referred to as the default VLAN) of
the switch.
With IP Phones residing in a separate VLANa voice VLANit is easier for customers to
automate the process of deploying IP Phones. The IP Phone communicates with the switch via
Cisco Discovery Protocol (CDP) when it powers up. The switch provides the Phone with the
appropriate VLAN Identifier (VLAN ID), known as the Voice VLAN ID (VVID). The VVID
is analogous to the data VLAN ID, known as the Port VLAN ID (PVID).
Example Catalyst Switch or EtherSwitch

Network Module
- -
-- -
--
--
--
-- -
802.1q trunking is enabled on the port.

The access VLAN is used for the PC that is plugged
into the IP Phone.
The voice VLAN is used for voice and signaling that
originates and terminates on the IP Phone.
Spanning Tree PortFast enables the port to initialize
quickly.
IPTX v2.02-5
To configure the trunk on a physical interface between the access switch port and the IP Phone,
an 802.1q trunk must be created. In addition, the native, or untagged, VLAN and the voice
VLAN must be defined.
The example shows the configuration of a Catalyst switch and an EtherSwitch network module.
Verifying Voice VLANConfiguration

- -

-

- -
-
-
--

-
-
-
-

-
IPTX v2.02-6
You can verify your voice VLAN configuration on the Catalyst switch by using the
show interface <mod/port>switchport command.
Router Configuration
802.1q Trunk
Trunk on a Router
-
-
VLAN 12
--
-
-
--
VLAN 112
IPTX v2.02-7
Routing between different VLANs requires a Layer 3 router. The router must have an interface
that is local to all of the VLANs for which it will route. The most efficient way to get multiple
VLANs to the router is to connect a trunk between the switch and the router. This configuration
is known as router on a stick.
The router will have one subinterface local to each VLAN, and only one VLAN can be
assigned per subinterface.
DHCP Service Setup
This topic identifies the DHCP service options.
Dynamic Host Configuration Protocol

Assigns an IP addresses and subnet masks for
one or more subnets
Assigns a default gateway
(Optional) Assigns DNS servers
(Optional) Assigns other commonly used servers
Scope must be customized to assign a TFTP
server to the voice VLAN that IP Phones are on
Best practice is to configure a DHCP scope for the
IP Phones
IPTX v2.02-8
DHCP is a very common protocol and familiar to many network administrators. With DHCP,
a scope is defined per subnet and is used to hand out IP addresses, along with a subnet mask,
from a pool of available addresses. If desired, other values, like the default gateway and DNS,
can be assigned to the scope by setting option values. The default gateway option is 003, and
DNS is 006.
These option values can include values specific to an implementation and can be customized by
the administrator. Cisco IP Phones look for an option 150 from their DHCP server, which
contains the IP address of the TFTP server where the IP Phones configuration file resides. The
administrator must configure an option 150 with the IP address of the TFTP server, which, in
the case of Cisco CallManager Express, is the Cisco CallManager Express router.
DHCP can be deployed on any platform that supports customized scope options. This includes
Windows, Linux, Novell, UNIX, and other operating systems.
DHCP Service Options

Single DHCP IP address pool
Separate DHCP IP address pool for each
Cisco IP Phone
DHCP relay server
IPTX v2.02-9
You can set up DHCP service for IP Phones by defining a single DHCP IP address pool, by
defining a separate pool for each Cisco IP Phone, or by defining a DHCP relay server.
Single DHCP IP address pool: Define a single DHCP IP address pool if the
Cisco CallManager Express router is a DHCP server and if you can use a single
shared address pool for all your DHCP clients.
Separate DHCP IP address pool for each Cisco IP Phone: Define a separate pool
for each Cisco IP Phone if the Cisco CallManager Express router is a DHCP server and
you need different settings on nonIP Phones on the same subnet.
Note
Separate DHCP scopes for individual devices should be avoided if possible because of the
added configuration complexity.
DHCP relay server: Define a DHCP relay server if the Cisco CallManager Express router
is not a DHCP server and you want to relay DHCP requests from IP Phones to a DHCP
server on a different subnet.
Phone Bootup
The IP Phone powers on.

The Phone performs a POST.
The Phone boots up.
Through CDP, the IP Phone learns
what the voice VLAN is.
The Phone initializes the IP stack.
A DHCP scope can be configured on

The scope should define the
following:
Range of available IP addresses
Subnet mask
Default gateway
Address of the TFTP server
DNS server(s)
IPTX v2.02-10
After an IP Phone receives power, the following happens:

POST: The Phone performs some basic tests. This is called a power-on self test (POST).
Bootup: The Phone begins the bootup process.
Voice VLAN discovery: Through the Layer 2 CDP, the Phone learns which VLAN
is the voice VLAN.
IP stack initializing: The Phone initializes a basic IP stack.
Phone Bootup (Cont.)
The IP Phone sends

DHCPDISCOVER broadcast
requesting an IP address.
The DHCP server selects a free IP
address from the pool and sends
it, along with the other scope
parameters, as a DHCPOFFER.
The IP Phone initializes, applying
the IP configuration to the IP stack.
The IP Phone requests a
configuration file from
the TFTP server.
IPTX v2.02-11
The process of a Phone bootup continues with the following:

DHCPDISCOVER: By default, the IP Phone (DHCP client) sends a DHCPDISCOVER
request to the 255.255.255.255 broadcast address.
IP address assigned by DHCP server: If this broadcast is heard by a local DHCP server,
the server assigns a free IP address, the subnet mask for the scope, the default gateway
for the scope, the DNS server (optional) for the scope, and a TFTP server (option 150)
for the scope.
DHCPOFFER: The scope setting is sent to the DHCP client (the IP Phone) using the
broadcast address 255.255.255.255.
DHCP settings initialized: The IP Phone takes the values received from the DHCP
response and applies them to the IP stack of the IP Phone.
Configuration requested from TFTP server: The IP Phone uses the value received in
option 150 to attempt to get a configuration file from the TFTP server (the Cisco
CallManager Express router is always the TFTP server in Cisco CallManager Express).
Commands for Manual Configuration
-- -
Sets a range of addresses to be excluded from the

configured scopes
Creates and enters a DHCP configuration mode
- --
Defines the range of addresses that are available for

assignment to DHCP clients
IPTX v2.02-12
Commands for manual configuration are not needed for IP Phones if automated setup is used
because the setup prompts for these settings and configures a DHCP scope automatically.
However, if a DHCP scope is not configured or if the administrator wishes to manually
configure or change the settings, then these commands must be used.
The ip dhcp excluded-address start-IP end-IP command allows the administrator to exclude
static addresses within the scope range that might be statically assigned to a server or router
interface. For Cisco CallManager Express, the exclusions should include the IP address of the
routers interface that may be local to the IP Phones.
The ip dhcp pool pool-name command defines and creates a DHCP pool. After this command
has been executed, the router enters a DHCP configuration mode. The automated setup mode
creates a DHCP pool named ITS (from Cisco IOS Telephony Service, which Cisco
CallManager Express was formerly known as).
Note
The pool name is case sensitive.
Within the DHCP configuration mode under a pool, enter the network subnet subnet-mask
command to assign a range of IP addresses to be available for assignment to DHCP clients.
This will not include any exclusion previously defined. When the addresses are assigned, the
lowest available IP address is used first. In Cisco CallManager Express, this is the subnet that
the IP Phones are on.
Commands for Manual Configuration (Cont.)
--
Sets the default gateway that is handed out to the

DCHP clients
-- -
(Optional) Sets the DNS server(s) that are assigned

to the DHCP clients
--
Defines a custom option and its value

IPTX v2.02-13
The command default-router IP-address sets option 003 on the DHCP scope that is being
defined. This option sends the IP address of the default gateway to the DHCP client. The
default gateway for Cisco CallManager Express is the router interface that is on the same
subnet as the IP Phones.
The optional command dns-server primary-IP [secondary-IP] allows the DNS server to be
sent in option 006 to the DHCP clients. For Cisco CallManager Express, this setting becomes
important if names are used for any of the URL values that can be assigned. Lack of a DNS
server requires use of IP addresses only.
Finally, a critical command is option option-number ip IP-address. This is the custom
option for the TFTP server. It is important that this command be configured correctly:
option 150 ip CallManagerExpress-IP. This IP address must be the IP address on the
Cisco CallManager Express router with which the IP Phones register.
Configuring DHCP on an IOS Router

--

--
Option 150 sets the TFTP server on the IP Phone.

The TFTP server contains the configuration files and
firmware for the IP Phone.
IPTX v2.02-14
In this sample configuration, the DHCP server has a scope defined for the IP phones. This
shows the command option 150 ip 10.90.0.1, where 10.90.0.1 is always set to the IP address
of a local interface on the Cisco CallManager Express router that is listening for the TFTP
protocol.
DHCP Relay Server
This topic defines a DHCP Relay Server.
DHCP Relay Service

CallManager
Express Router
Without DHCP
DHCP Broadcast
DHCP
Server
The routers default

behavior is to not forward
broadcasts; the DHCP
request times out.
This issue can be addressed with a DHCP relay server.
IPTX v2.02-15
When the DHCP server does not have a local interface on the network with the DHCP clients, a
DHCP relay server must be implemented. This is because of the broadcast nature of the DHCP
request and response process. By default, broadcasts do not traverse from one subnet on a
router to another subnet on a router. This is a basic characteristic of a router, and changing this
behavior effectively turns the router into a software bridge. The way around this is to enable
selective types of broadcast to be converted to either a unicast or a directed broadcast. This
allows the selected type of broadcast to traverse several routers to reach the destination server
or subnet.
DHCP Relay Service (Cont.)

Enable DHCP relay on the interface that
will receive the DHCP broadcast.
DHCP
Server
WAN
Unicast or Directed
Broadcast
DHCP Broadcast
The router forwards

the DHCP request to the
DHCP server.
The DHCP broadcast request is forwarded

through either a unicast or a directed broadcast
to the DHCP server.
IPTX v2.02-16
When the Cisco CallManager Express router is not the DHCP server for the IP Phones, there
is a good chance that the DHCP server is not local to the IP Phones. In this case, the Cisco
CallManager Express routeror another devicemust convert the DHCP broadcast to a
unicast or a directed broadcast. The DHCP request must also be modified to include the
originating subnet so that the appropriate scope is selected.
When the DHCP relay server is enabled on a Cisco IOS router, the configuration is done on the
interface that will be receiving the broadcast. This may or may not be the Cisco CallManager
Express router.
DHCP Relay Service Feature
Enables the DHCP server feature on the router

(enabled by default)
-- --
Enables forwarding of select broadcasts to the

specified subnet or host
IPTX v2.02-17
The command service dhcp enables the Cisco IOS DHCP server feature on the router.
This feature is enabled by default, so this step is necessary only if it has previously been
disabled. The command that enables the selective forwarding of certain types of broadcasts
is ip helper-address ip-address. This command must be entered on the router interfaces that
have IP Phones local to them.
Example of DHCP Relay Service

Enables DHCP relay on the interface
that will hear the DHCP broadcast
fa0/0
DHCP
Server
WAN
10.200.0.1
-
-
--
IPTX v2.02-18
This shows the command ip helper-address 10.200.0.1 configured on the FastEthernet 0/0
(fa0/0) interface, which is local to the IP Phone.
This topic describes how to configure NTP.

The IP Phone gets its displayed time from the Cisco
CallManagerExpress router.
The time of the Cisco CallManager Express routers internal
clock should be synchronized with an NTP server.
The local NTP server can have an attached atomic clock or
can synchronize with a more authoritative source.
There are free NTP servers available on the Internet.
The time of the Cisco CallManager Express router can be
used to stamp all syslog and trace messages.
The internal clock of a Cisco IOS router can drift, and a more
authoritative source through NTP is very desirable.
RFC 1305 defines NTP.
IPTX v2.02-19
The heart of the time service is the system clock. The system clock begins to run the moment
the system starts, and it keeps track of the current date and time. The system clock can be set
from a number of sources and, in turn, can be used to distribute the current time through
various mechanisms to other systems. Some routers contain a battery-powered calendar system
that tracks the date and time across system restarts and power outages.
This calendar system is always used to initialize the system clock when the system is restarted.
It can also be considered an authoritative source of time and redistributed through NTP if no
other source is available. Furthermore, if NTP is running, the calendar can be periodically
updated from NTP, compensating for the inherent drift in the calendar time. When a router with
a system calendar is initialized, the system clock is set based on the time in its internal batterypowered calendar. On models without a calendar, the system clock is set to a predetermined
time constant.
NTP allows you to synchronize your Cisco CallManager Express router to a single clock on the
network, which is known as the clock master. Although NTP is disabled on all interfaces by
default, it is essential to Cisco CallManager Express. NTP is designed to synchronize the time
on a network of machines. NTP runs over the User Datagram Protocol (UDP) using port 123 as
both the source and destination, which in turn runs over IP. NTP version 3 (RFC 1305) is used
to synchronize timekeeping among a set of distributed time servers and clients.
An NTP network usually gets its time from an authoritative time source, such as a radio clock
or an atomic clock attached to a time server. NTP then distributes this time across the network.
An NTP client makes a transaction with its server over its polling interval (from 64 to
1024 seconds), which dynamically changes over time depending on the network conditions
between the NTP server and the client. No more than one NTP transaction per minute is needed
to synchronize two machines.
NTP uses the concept of a stratum to describe how many NTP hops away a machine is from an
authoritative time source. For example, a stratum 1 time server has a radio or atomic clock
directly attached to it. The stratum 1 time server then sends its time to a stratum 2 time server
through NTP, and so on. A machine that runs NTP automatically chooses the machine that has
the lowest stratum number with which it is configured to communicate using NTP as its time
source. This strategy effectively builds a self-organizing tree of NTP speakers.
Configuring the Time
--
Sets the local time zone
- -
Specifies daylight-saving time
- --
Allows the clock on this router to be synchronized

with the specified NTP server
IPTX v2.02-20
The command clock timezone zone hours-offset sets the time zone and number of hours that
the time zone is offset from Coordinated Universal Time (UTC) (formerly Greenwich Mean
Time [GMT]). This allows the Cisco CallManager Express router to have its time zone defined.
If daylight-saving time occurs in the area where the Cisco CallManager Express system is
located, then it must be set up using the clock summer-time zone recurring [start-date enddate] command.
The command to allow the Cisco CallManager Express router to synchronize with an NTP
server is ntp server ip-address. This allows the Cisco CallManager Express router to keep the
correct time based on the time of a more authoritative source than its own system time.
The following list of common time zones and what their offsets are from GMT will help you
configure the clock commands.
Europe
GMT Greenwich Mean Time, as UTC
BST British Summer Time, as UTC + 1 hour
IST Irish Summer Time, as UTC + 1 hour
WET Western Europe Time, as UTC
WEST Western Europe Summer Time, as UTC + 1 hour
CET Central Europe Time, as UTC + 1
CEST Central Europe Summer Time, as UTC + 2
EET Eastern Europe Time, as UTC + 2
EEST Eastern Europe Summer Time, as UTC + 3
MSK Moscow Time, as UTC + 3
MSD Moscow Summer Time, as UTC + 4
United States and Canada

AST Atlantic Standard Time, as UTC
4 hours
ADT Atlantic Daylight Time, as UTC
3 hours
ET Eastern Time, either as EST or EDT, depending on place and time of year
EST Eastern Standard Time, as UTC
5 hours
EDT Eastern Daylight Time, as UTC
4 hours
CT Central Time, either as CST or CDT, depending on place and time of year
CST Central Standard Time, as UTC
6 hours
CDT Central Daylight Time, as UTC
5 hours
MT Mountain Time, either as MST or MDT, depending on place and time of

year
MST Mountain Standard Time, as UTC
7 hours
MDT Mountain Daylight Time, as UTC
6 hours
PT Pacific Time, either as PST or PDT, depending on place and time of year
PST Pacific Standard Time, as UTC
8 hours
PDT Pacific Daylight Time, as UTC
7 hours
AKST Alaska Standard Time, as UTC
9 hours
AKDT Alaska Daylight Time, as UTC
8 hours
HST Hawaiian Standard Time, as UTC
10 hours
Australia
WST Western Standard Time, as UTC + 8 hours
CST Central Standard Time, as UTC + 9.5 hours
EST Eastern Standard/Summer Time, as UTC + 10 hours (+ 11 hours during
summer time)
For example, the command clocktimezone pst -8 would set the time zone to Pacific Standard
Time.
Example of Router Set to PST with

Daylight-Saving Time Enabled
NTP
Server
10.1.2.3
IP Phone time comes from the
Cisco CallManagerExpress
router.
router time synchronizes with
the NTP server.
-
- - -
- -
-
IPTX v2.02-21
This shows the Cisco CallManager Express router in the Pacific Standard time zone with
daylight-saving time turned on. The router is also set to synchronize its system time to that
of an NTP server.
Transcoding
This topic describes how to configure transcoding between the G.711 and G.729 coderdecoders (codecs).
Transcoding
Transcoding between G.711 and G.729:
Requires hardware-based DSP farm
Assists Cisco CallManagerExpress software
ad-hoc conferencing when one or more parties
use G.729
Call transfer and forward to an endpoint where one
leg uses G.729 and the other uses G.711
A G.729 call forwarded to voice mail on the CUE
module, which only supports the G.711 codec
Sends G.711 MOH feed to a caller who is
using G.729
IPTX v2.02-22
Versions of Cisco CallManager Express prior to version 3.2 supported G.729 compressed
voice calls for two-party calls only. Transcoding between G.711 and G.729 codecs requires a
hardware-based digital signal processor (DSP) farm. Cisco CallManager Express versions 3.2
and later support transcoding between G.711 and G.729 for the following features:
Ad hoc conferencing: When one or more remote conferencing parties use G.729.
Call transferring and forwarding: When one leg of a Voice over IP (VoIP)-to-VoIP
hairpin call uses G.711 and the other leg uses G.729. (A hairpin call is an incoming call that
is transferred or forwarded over the same interface from which it arrived.)
Cisco Unity Express (CUE): When an H.323 or SIP call using G.729 is forwarded to
CUE. Note that CUE supports only G.711.
Music on Hold (MOH): When the IP Phone receiving MOH is part of a system that uses
G.729 (G.711 MOH is translated to G.729). Because of compression, the MOH that is sent
using G.729 loses the fidelity that the MOH has with G.711.
Transcoding (Cont.)
DSP hardware for transcoding:
NM-HDV (TI-549 DSP)

NM-HDV2 (TI-5510 DSP)
NM-HD-1V (TI-5510 DSP)
NM-HD-2V (TI-5510 DSP)
NM-HD-2VE (TI-5510 DSP)
PVDM2 slots on the 2800 and 3800 (TI-5510 DSP)
IPTX v2.02-23
Transcoding is facilitated through the use of DSP chips. The DSP chips are contained on single
in-line memory modules (SIMMs) or on packet voice/data modules (PVDMs). These SIMMs
or PVDMs are then seated in the appropriate slots that are present on a network module or in
an onboard PVDM slot like those present on the Cisco 2800 Series routers and the Cisco 3800
Series routers.
Note
Deploying both the TI-549 DSP and the TI-5510 DSP in the same chassis is not
recommended.
Transcoding (Cont.)
http://cisco.com/public/support/tac/tools.shtml
IPTX v2.02-24
The DSP calculator that is available at http://cisco.com/public/support/tac/tools.shtml can be

used to calculate the number of calls that can be processed with a specific hardware
configuration.
Configuring the NM-HDV

Overview
Configure the location and settings of the voice card
Configure SCCP parameters on the host router
Enable the DSP farm and set size
IPTX v2.02-25
The configuration of the High Density Voice Network Module (NM-HDV)based DSP farm is
different from the other DSP farms used by Cisco CallManager Express. The NM-HDV
requires that you configure the physical location of the DSP resource and the Skinny Client
Control Protocol (SCCP) and that you enable and set maximums of the DSP farm.
Configuring the NM-HDV (Cont.)
Identifies the slot where the DSP farm is located
- -- -
Enables the DSP farm services
IPTX v2.02-26
The NM-HDV can be used in the Cisco 2600XM, 2800, 3700, and 3800 platforms as a
conferencing resource and a transcoding resource. The NM-HDV as a DSP resource is based on
the TI-529 chip. This section shows the commands that are required to configure the use of
DSP resources in Cisco CallManager Express 3.2 or greater.
The first step to configure the NM-HDV as a DSP farm is to use the voice-card slot command
to identify the slot where the DSP farm resides. This command also enters voice port
configuration mode. After you are in voice port configuration mode, you must enter the
command dsp services dspfarm to allow the resource to be used as a DSP farm.
Sets the local interface that the transcoding

application should use to register with the
- --
Specifies the address and priority where the

DSP farm will register
Enables SCCP and the associated processes

IPTX v2.02-27
Next, use the sccp local interface-type interface-number command to select the interface
that the DSP farm will use to register with the Cisco CallManager Express system. The
sccp ccm ip-address priority priority command defines the address of the Cisco CallManager
Express system on the DSP farm so that it knows where to register. Because there will be
only one Cisco CallManager Express router, set the priority to 1, which makes it the most
preferred. The sccp command needs to be entered in order to enable the SCCP processes on
the DSP farm router.
Note
The term ccm as seen in the sccp ccm command usually refers to Cisco CallManager;
however, in this case the command sccp ccm should point to the Cisco CallManager
Express router because it is the call control device.
- - ----
Specifies the maximum number of sessions

supported by the DSP farm
Enables the DSP farm
IPTX v2.02-28
The dspfarm transcoder maximum sessions number command specifies the maximum
number of transcoding sessions that the DSP farm will support. This number will depend
on the number of DSP resources present as well as the type of DSP resources. The final step
to configure the NM-HDV as a DSP resource to be used for transcoding is the dspfarm
command. This command enables the DSP farm processes on the router.
Example of Configuring an NM-HDV-Based

Remote DSP Farm
NM-HDV
10.1.1.1
G.711Capable
Only
WAN
G.711
DSP
Farm
G.729

- -- -
- -
-
-
- - ----
-
IPTX v2.02-29
In this example, an NM-HDV is installed in a router that is not the Cisco CallManager Express
router. The DSP resources are configured to be available for use in transcoding. A device
located across a low-bandwidth WAN link has been configured to use only the G.729 codec to
conserve bandwidth. This device calls a device that can use only the G.711 codec. The DSP
farm provides the transcoding under the direction of the CallManager Express system.
Note
CUE supports only the G.711 codec. This is the most common reason for needing the
transcoding DSP resources when using Cisco CallManager Express.
Example of Configuring an NM-HDV-Based

Local DSP Farm
NM-HDV
G.711Capable
Only
G.711
WAN
10.1.1.1
DSP
Farm
G.729

- -- -
- -
-
-
- - ----
-
IPTX v2.02-30
In this example, an NM-HDV is installed in the same chassis as the Cisco CallManager Express
router. The DSP resources are configured to be available for use in transcoding. A device
located across a low-bandwidth WAN link has been configured to use only the G.729 codec to
conserve bandwidth. This device calls a device that can use only the G.711 codec. The DSP
farm provides the transcoding under the direction of the Cisco CallManager Express system.
Configuring the NM-HD-xV, NM-HDV2,

and PVDM2 Slots
Overview
Configure the location and settings of the
voice card
Configure SCCP parameters on the host router
Enable the DSP farm and set size
Define a DSP farm profile
Define a Cisco CallManagerExpress group
IPTX v2.02-31
Setting up TI-5510based DSP farms using the NM-HD-1Vs, NM-HD-2Vs, and NM-HDV2s
involves enabling the DSP farms and SCCP on routers. This includes using the voice-card slot
command to define the DSP farm location, using the dsp services dspfarm command to start
the appropriate services on the router, and using the sccp local interface-type interface-number
command to define the local interface to use. The SCCP processes should be started with the
command sccp. These commands are the same as those that are used for configuring the NMHDV and were covered in detail earlier in this lesson.
Configuring the NM-HD-xV, NM-HDV2, and

PVDM2 Slots (Cont.)
- -
Enables a DSP farm profile for transcoding

-
Specifies the codecs supported by the DSP farm
IPTX v2.02-32
The DSP farm profile declares codec usage and the maximum number of transcoding sessions
and associates SCCP with the DSP farm profile. This profile is then associated with a Cisco
CallManager Express group.
The dspfarm profile profile-identifier transcode command creates a profile and enters DSP
farm profile configuration submode. The supported codecs are then defined with the codec
codec-type command.
Note
Cisco CallManager Express is capable of controlling transcoding between the G.729 and
G.711 codecs only.

PVDM2 Slots (Cont.)
----
Specifies the maximum number of sessions

supported by the DSP farm
-
-- -
Associates SCCP to the DSP farm profile
IPTX v2.02-33
While in the DSP farm profile configuration submode, use the maximum sessions number
command to set the maximum number of simultaneous transcoding sessions that the DSP farm
allows. Finally, use theassociate application sccpcommand to associate SCCP with the DSP farm.

PVDM2 Slots (Cont.)
- --
Specifies the IP address of the Cisco CallManager

Express router and an identifying number
Creates a Cisco CallManager Express group

-
--
Associates a Cisco CallManager Express with a

Cisco CallManager Express group
IPTX v2.02-34
Only one Cisco CallManager Express group is required. Under the Cisco CallManager Express
group, assign a priority to an identifier, associate the group with a DSP farm profile, and set the
keepalive, switchback, and switchover parameters.
The command sccp ccm ip-address identifier identifier-number specifies the address of the
Cisco CallManager Express router and assigns an identifying number. This number is then used
in the associate ccm identifier-number priority 1 commandto associate a Cisco CallManager
Express to the Cisco CallManager Express group. A Cisco CallManager Express group is a
naming device under which data for the DSP farms is declared. The Cisco CallManager
Express group is defined by using the sccp ccm group group-number command.
Note
The priority should always be set to 1 in a Cisco CallManager Express configuration

because the DSP farm can only be associated to one Cisco CallManager Express router.

PVDM2 Slots (Cont.)
-- -
Associates a DSP farm profile with a Cisco

CallManager Express group and assigns the
registered name
-
Sets the number of keepalive retries
IPTX v2.02-35
Associate a DSP farm profile to a Cisco CallManager Express group with the command
associate profile profile-identifier register device-name. If the number of keepalive retries
should be set to something other than the default of three, use the keepaliveretries number
command.
Example of Configuring the NM-HD-xV,

NM-HDV2, and PVDM2 slots
NM-HD-1V or
NM-HD-2V or
NM-HDV2
G.711Capable
Only
G.711
10.1.1.1
WAN
G.729
DSP
Farm
OR
NM-HD-1V or
NM-HD-2V or
NM-HDV2
G.711Capable
Only
G.711
WAN
10.1.1.1
DSP
Farm
G.729
IPTX v2.02-36
This is an example of a router with a TI-5510based DSP resource installed. The DSP
resources are configured to be available for use in transcoding. A device located across a lowbandwidth WAN link that has been configured to use only the G.729 codec to conserve
bandwidth calls a device that can use only the G.711 codec. The DSP farm provides the
transcoding under the direction of the Cisco CallManager Express system.
Example of Configuring the NM-HD-xV,

NM-HDV2, and PVDM2 slots

- -- -
- -
-
-
- -
-
-
- ----
--- -
-
---
--- -
- -
IPTX v2.02-37
Configuring the Cisco CallManagerExpress

Telephony Service to Use a DSP Farm
-
-- -
Specifies the maximum number of DSP farms that

are allowed to register (default is 0)
-
-- - ----
Specifies the maximum number of transcode

sessions for G.729 allowed by the Cisco CallManager
Express router
-
--
Permits a DSP farm unit to register to the Cisco

CallManagerExpress router
IPTX v2.02-38
The Cisco CallManager Express router must be configured in telephony-service mode to utilize
the configured DSP farm. The steps are the same regardless of the type of DSP resource that is
configured. The maximum number of DSP farms that may register with the Cisco CallManager
Express router is set with the command sdspfarm units number. The default setting is 0. The
command sdspfarm transcode sessions number sets the maximum number of G.729 sessions
that the Cisco CallManager Express router allows. The range of the command is 0 to 128
sessions and defaults to 0. The command sdspfarm tag number device-name is to enable the
specific DSP farm to register. The number is a number from 1 to 5 and the device-name is the
name that the DSP farm will register with and is the MAC address of the SCCP client with
mtp prepended (for example, mtp00061476aef3).
Example of Configuring the Cisco CallManager

Express Telephony Service to Use a DSP Farm
-
--- -
--- - ----
---
-
IPTX v2.02-39
The figure shows the configuration in telephony-service mode on the Cisco CallManager
Express router that is required to enable the DSP farm to register.
Verifying That the DSP Farm Is Registered

and Running
- - --- -
Displays the SCCP configuration information and

current status
- -- -
Displays the configured and registered DSP farms
- -- ---- -
Displays transcoding sessions

IPTX v2.02-40
There are show commands available to verify that the DSP farms are configured and registered.
The first command, show sccp [statistics | connections], displays the SCCP configuration as
well as information about the past usage of the DSP farm. An example output follows:
- - -- - --
-
-
- - -
- ---
---
---
- ---
--- ---
--- ---
- ---

The command show sdspfarm units displays the configured and registered DSP farms. An
example output follows:
- -- -
- -

- -- -- --
The command show sdspfarm sessions shows the transcoding streams. An example output
follows:
CMERouter# show sdspfarm sessions
Stream-ID:1 mtp:1 10.1.1.1 18404 Local:2000 START
usage:Ip-Ip
codec: G711Ulaw64k duration:20 vad:0 peer Stream-ID:2

usage:Ip-Ip
codec:G729AnnexA duration:20 vad:0 peer Stream-ID:1
Stream-ID:3 mtp:1 0.0.0.0 0 Local:0 IDLE

usage:
codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:0
Stream-ID:4 mtp:1 0.0.0.0 0 Local:0 IDLE

usage:
The variation on the previous command using show sdspfarms sessions summary displays a
more condensed view of all transcoding streams. An example output follows:
CMERouter# show sdspfarm sessions summary
max-mtps:1, max-streams:24, alloc-streams:24, act-streams:2
ID MTP State
CallID confID Usage
Codec/Duration
==== ===== ====== =========== ====== =============================

1
IDLE -1
G711Ulaw64k /20ms
IDLE -1
G711Ulaw64k /20ms
START -1
MoH (DN=3 , CH=1) FE=TRUE G729 /20ms
START -1
MoH (DN=3 , CH=1) FE=FALSE G711Ulaw64k /20ms
IDLE -1
G711Ulaw64k /20ms
IDLE -1
G711Ulaw64k /20ms
The command show sdspfarm sessions active displays the active sessions at any one time. An
example output follows:
CMERouter# show sdspfarm sessions active
usage:Ip-Ip

usage:Ip-Ip
codec:G729AnnexA duration:20 vad:0 peer Stream-ID:1
Summary
Summary
Voice VLANs are used to separate voice traffic from data traffic.
Voice VLANs are configured on the interfaces of the switch into
which the IP Phone is plugged.
A single DHCP IP address pool is a large shared pool of
IP addresses.
Defining a separate pool for each Cisco IP Phone creates a
name for the DHCP server address pool and specifies IP and
MAC addresses for each name.
A DHCP relay server is defined if the Cisco CallManager
Express router is not a DHCP server and the DHCP server is not
on the same subnet as the DHCP clients.
NTP allows you to synchronize your Cisco CallManager
Express router to a single clock on the network.
DSP resources facilitate transcoding between G.729 and G.711.
IPTX v2.02-41
Lesson 3
Understanding the IP Phone

Registration Process
Overview
This lesson details the process of registering IP Phones with the Cisco CallManager Express
router and the files that must be downloaded.
Objectives
Upon completing this lesson, you will be able to describe the process of registering an IP Phone
with a Cisco CallManager Express router. This includes being able to meet these objectives:
Describe IP Phone firmware files and XML configuration files
Describe how Cisco CallManager Express identifies IP Phones
Describe how IP Phones obtain XML configuration files and IP addresses
Files
This topic describes IP Phone firmware files and XML configuration files.
Files Critical to the IP Phone

7960
Firmware
7940
SEP
SEP
SEP
Firmware
XMLDefault.cnf.xml
SEPAAAABBBBCCCC.cnf.xml
XML
XML SEP
XML SEP
XML
XML
Firmware
7920
Firmware
7912
Firmware
7905
Firmware
7902
Firmware
7910
Firmware
TFTP Server
IPTX v2.02-2
Certain files are necessary to the proper operation of the IP Phone or analog device so that it
can register successfully with the Cisco CallManager Express router. These files are as follows:
Firmware: The firmware is loaded into memory on the IP Phone and will survive a reboot.
XMLDefault.cnf.xml: This extensible markup language (XML) configuration file
specifies the proper firmware, address, and port that the new Phone needs to register.
SEPAAAABBBBCCCC.cnf.xml: This XML configuration file is specific to one device
and is based on the MAC address.
Firmware
7905
Firmware
7940
Firmware
7960
Firmware
- -
Installed in flash RAM with the Cisco CallManager Express

software or individually, as needed, on a per-Phone basis
Served up by the TFTP server on the Cisco CallManager Express
router
Uses the command tftp-server flash:firmware-file-name
IPTX v2.02-3
All of the necessary firmware files for IP Phones are stored internally on the Cisco
CallManager Express router flash memory, so an external database or file server is not
required. During registration, IP Phones use TFTP to download firmware files from the router
flash memory. All Cisco CallManager Express configuration and language files are located in
the DRAM of the router under system:/its/. To make the firmware files available through a
TFTP server, use the command tftp-server flash:firmware-file-name. The command load
firmware-file-name is also required to associate the model of IP Phone with the appropriate
firmware file.
The following is a list of firmware files based on Cisco IP Phone model, including the Cisco
Analog Telephone Adaptor (ATA) and the Cisco 7914 Expansion Module. These files are
specific to Cisco CallManager Express 3.2.1. The files that you need will vary depending on
the version of Cisco CallManager Express that is used.
ATA 186 ATA030100SCCP040211A.zup
ATA 188 ATA030100SCCP040211A.zup
7902G CP7902010200SCCP031023A.sbin
7905G CP7905040000SCCP040701A.sbin and CP79050101SCCP030530B31.zup
7910G+SW P00403020214.bin
7912G CP7912040000SCCP040701A.sbin
7914 S00103020002.bin
7920 cmterm_7920.4.0-01-08.bin
7935 P00503010100.bin
7936 P00503010100.bin
7940G P00303020214.bin or P00305000301.sbn
7960G P00303020214.bin or P00305000301.sbn
The firmware names with .sbin extensions are signed phone loads. When a signed phone load is
installed on an IP Phone, that Phone cannot go back to an unsigned phone load. The Phone will
always have to use a signed phone load even if the Phone is used by Cisco CallManager.
Firmware for the 7970G and 7971G-GE

7970
7970
Firmware
7970
Firmware
7970
Firmware
7970
Firmware
Firmware
- -

- -
-
-
Five firmware files required for the 7970 and 7971G-GE

Installed in flash RAM with the Cisco CallManager Express
software or individually, as needed
Served up by the TFTP server on the Cisco CallManager Express
router
Uses the command tftp-server flash:firmware-file-name
Uses the command load firmware-file-name
IPTX v2.02-4
The 7970G and 7971G-GE are supported with Cisco CallManager Express 3.2.1 and require
five fireware files be present in flash RAM of the Cisco CallManager Express router. These
five files are listed below:
TERM70.DEFAULT.loads
TERM70.6-0-2SR1-0-5s.loads
jvm70.602ES1R6.sbn
jar70.2-8-0-104.sbn
cnu70.62-0-1-6.sbn
Device Configuration XML File

SEPAAAABBBBCCCC.cnf.xml*
SEP
XML
*AAAABBBBCCCC = the
MAC address
<device>
<devicePool>
<callManagerGroup>
<members>
<member priority="0">
<callManager>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
</ports>
<processNodeName>10.15.0.1</processNodeName>
</callManager>
</member>
</members>
</callManagerGroup>
</devicePool>
<versionStamp>{Jan 01 2002 00:00:00}</versionStamp>
<loadInformation>P00303020214</loadInformation>
- <userLocale>
<name>English_United_States</name>
<langCode>en</langCode>
</userLocale>
<networkLocale>United_States</networkLocale>
<idleTimeout>0</idleTimeout>
<authenticationURL />
<directoryURL>http://10.15.0.1/localdirectory</directoryURL>
<idleURL />
<informationURL />
<messagesURL />
<proxyServerURL />
<servicesURL />
</device>
IPTX v2.02-5
The XML file SEPAAAABBBBCCCC.cnf.xml(where AAAABBBBCCCC is the MAC address

of the IP Phone) contains the IP address, the port, the firmware, the locale, the directory
URL, and many other pieces of information. Some of this information cannot currently be
used in Cisco CallManager Express. This file is generated during the initialization of the
CiscoCallManager Express software if the command create-cnf-files is in the startup-config
file.
The figure shows a configuration file that contains the IP address and port that represent the
interface with which the Phone will attempt to register on the Cisco CallManager Express
router. The configuration file also defines a language that will be applied to the IP Phone in
question.
Default XML File

XMLDefault.cnf.xml
Default
XML
<Default>
<callManagerGroup>
<members>
<member priority="0">
<callManager>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
</ports>
<processNodeName>10.15.0.1</processNodeName>
</callManager>
</member>
</members>
</callManagerGroup>
<loadInformation6 model="IP Phone 7910">P00403020214</loadInformation6>
<loadInformation124 model="Addon 7914"></loadInformation124>
<loadInformation9 model="IP Phone 7935"></loadInformation9>
</Default>
Notice that there is no ATA or 7914.

IPTX v2.02-6
The file XMLDefault.cnf.xml is used by IP Phones and devices that do not find a more specific
SEPAAAABBBBCCCC.cnf.xml file. IP Phones that download this XML file through TFTP
learn the IP address and port of the Cisco CallManager Express router. The IP Phones also
learn the version of firmware that is required to function properly with Cisco CallManager
Express. The file is generated by the Cisco CallManager Express system when the command
create-cnf is entered in telephony-service mode.
This topic describes how Cisco CallManager Express identifies IP Phones.
There is no 7914 in the
XMLDefault.cnf.xml file.
Default
XML

<loadInformation124 model="Addon 7914"></loadInformation124>
<loadInformation30040 model=ATA"></loadInformation30040>
The 7914 Expansion Module cannot auto-register.

The 7914 Expansion Module requires the use of the
type command, which is entered by the administrator.
All other valid devices are recognized automatically
by the Cisco CallManager Express system.
IPTX v2.02-7
The 7914 Expansion Module cannot auto-register and requires the use of the
type command under
the ephone. None of the other valid IP Phones and ATA devices in Cisco CallManager Express
require the type command; they are automatically recognized by Cisco CallManager Express.
Download and Registration
This topic describes how an IP Phone obtains its XML configuration file and IP address.
Phone Bootup: All Cisco IP Phones Except

7970G and 7971G-GE, In-Line Power
Step 1 -Switch sends an FLP
FLP
Step 2 -Phone returns FLP to switch
because of a completed circuit
FLP
Step 3 -Power is applied
Step 4 -Link is detected on

switch port
Step 5 -IP Phone boots up

Step 6 -Amount of needed power is conveyed
through CDP from IP Phone to switch
CDP
Needed Power
IPTX v2.02-8
The following are the steps that take place during phone bootup for all Cisco IP Phones when
using the Cisco prestandard Power over Ethernet (PoE).
Step 1
The switch sends a special tone, called a Fast Link Pulse (FLP), out the interface.
The FLP goes to the powered device, in this case, an IP Phone.
Step 2
The powered device has a physical link when there is no power between the pin on
which the FLP arrives and a pin that goes back to the switch. This creates a circuit,
and the end result is that the FLP arrives back at the switch. This will never happen
when the attached device is a non-PoE capable device, such as a PC. And if the FLP
does not make it back to the switch, no power is applied.
Step 3
The switch applies power to the line.
Step 4
The link should go up within 5 seconds.
Step 5
The powered device (IP Phone) boots up.
Step 6
Through Cisco Discovery Protocol (CDP), the IP Phone tells the switch specifically
how much power it needs.
Phone Bootup: Cisco IP Phones 7970G and

7971G-GE, Standard-Based PoE
Step 1 Constantly sends DC current
DC
Step 2 25 ohms of resistance
DC
Step 3 25 ohms of resistance
detected
Step 4 Low power mode initiated (6.3W)
Step 5 Cisco IP Phone boots up
Step 6 -Amount of needed power is conveyed
through CDP from IP Phone to switch
CDP
Needed Power
IPTX v2.02-9
The following are the steps that take place during phone bootup for the 7970G Phone and the
7971G-GE Phone. Power is the standards-based PoE.
Step 1
The switch constantly applies DC current to all ports that may have a powered
device attached to them.
Step 2
The powered device is connected and will have a resistance of 25 ohms if it is PoEcompliant.
Step 3
The switch detects that the device is a PoE-capable device.
Step 4
Power is applied to the link in low power mode, which is 6.3 watts.
Step 5
The powered device (the IP Phone) boots up.
Step 6
Through CDP, the IP Phone tells the switch specifically how much power it needs.
Phone Bootup: Cisco IP Phones 7970G and

7971G-GE, Standard-Based PoE(Cont.)
DHCP Server
or
DHCP Relay
Step 7 -Through CDP, the
switch sends voice VLAN
information to the
IP Phone.
CDP
Voice VLAN
DHCPDISCOVER
Step 8 -The IP Phone initializes the

IP stack and sends a
DHCPDISCOVER broadcast
message.
Broadcast
Step 9 -The DHCP server hears the

DHCPDISCOVER message, selects
an IP address from the scope, and
sends a DHCPOFFER.
DHCPOFFER
IP Address, Subnet Mask, Default
Gateway, and TFTP Server (option 150)
IPTX v2.02-10
Step 7
Through CDP, the switch informs the IP Phone of its voice VLAN (auxiliary
VLAN).
Step 8
The IP Phone initializes the IP stack and sends out a DHCPDISCOVER broadcast
requesting an IP address on the voice VLAN scope.
Note
Step 9
It is possible to hardcode the IP address, subnet mask, default gateway, DNS, and TFTP
server on the IP Phone and skip the DHCP steps. However, it is recommended that DHCP be
used in order to minimize the administrative load that is required to hardcode these settings.
The DHCP server hears the broadcast and assigns an IP address from the scope for
the voice VLAN subnet, subnet mask, default gateway, DNS (optional), and address
of the TFTP server (the Cisco CallManager Express router). All settings are then
sent back to the IP Phone in the form of a DHCPOFFER message.
Phone Bootup: Known IP Phone

MAC 000F.2470.AA32
Cisco
CallManager
Express is the
TFTP server.
Step 10 The IP Phone

applies addressing
information that is
obtained through DHCP to
the IP stack.
Step 11 -The IP Phone looks for an alias named
SEPAAAABBBBCCCC.cnf.xml (where AAAABBBBCCCCis the
MAC address). If the alias is found, the IP Phone will register.
SEP
XML
TFTP Request for the SEP000F2470AA32.cnf.xml file

SEP000F2470AA32.cnf.xml file
If no SEP XML file is found, go to Step 14.

IPTX v2.02-11
Step 10
The Phone receives the DHCPOFFER and applies the values obtained.
Step 11
One of the values carried in the DHCPOFFER message is the address of the TFTP
server. The IP Phone uses this information to make a connection to the TFTP server
and attempt to download a file by the name of SEP000F2470AA32.cnf.xml. This
file, if found, contains the information the Phone needs in order to register with
Cisco CallManager Express. This information includes the IP address, port, locale,
and firmware file that should be loaded on the IP Phone.
If the Phone has the correct firmware, it will register and get its configuration. If the
firmware is not correct, then proceed to the next step.
If no SEP XML file is found, go to Step 14.
Note
The extension numbers, speed dials, and other settings are assigned when the IP Phone
registers. They are not contained in the SEP XML file.
Phone Bootup: Out-of-Date IP Phone

Firmware
MAC 000F.2470.AA32
Cisco
CallManager
Express is the
TFTP server.
Step 12 -If the current firmware version is different from the version
specified in the SEPAAAABBBBCCCC.cnf.xml file, firmware is
downloaded from the TFTP server.
7960
Firmware
TFTP Request for Firmware, If Needed

Firmware File
Step 13 The IP Phone reboots if the
firmware was updated.
IPTX v2.02-12
Step 12
If the firmware is out of date or different from the one that is specified, the IP Phone
goes back to the TFTP server and downloads the appropriate firmware.
Step 13
The IP Phone reboots after the firmware is downloaded.
Phone Bootup: Unknown IP Phone

Unknown IP Address with
MAC 000F.2470.AA32
Cisco
CallManager
Express is the
TFTP server.
Step 14 -If no SEP XML file is found, the IP Phone

downloads the XMLDefault.cnf.xmlfile from TFTP server.
Default
XML
TFTP Request for the XMLDefault.cnf.xml file

XMLDefault.cnf.xml file
Step 15 -The Phone will register to Cisco CallManager Express, but without
any assigned extension. No calls can be placed or received, and a SEP file will
be created on the Cisco CallManager Express router.
or
Step 15 -If automatic assignment is enabled or the phone has been configured,
then the new IP Phone registers to Cisco CallManager Express and
is given an extension number.
IPTX v2.02-13
Step 14
If no SEP XML file exists for the specific device, the device is considered new. The
new IP Phone gets a file called XMLDefault.cnf.xml from the TFTP server. The
XMLDefault.cnf.xml file specifies the IP address, port, and firmware file that the
new IP Phone needs in order to register. If the new IP Phone has the correct
firmware, it can register with Cisco CallManager Express. If it does have the correct
firmware, it will download the correct firmware and reboot.
Step 15
The Phone registers with Cisco CallManager Express using SCCP messages. If
automatic assignment is enabled, Cisco CallManager Express assigns an extension
automatically. If it is not enabled, the Phone will have no extension and will not be
able to place or receive any calls.
Summary
Summary
The IP Phone requests the firmware, configuration,
and language files when it boots up.
The IP Phone uses TFTP-DHCP option 150 to
download during registration.
The IP Phone uses its MAC address as part of
a created file name to download firmware and
configurations and uses the obtained IP address to
register with the Cisco CallManager Express router.
IPTX v2.02-14
Lesson 4
Defining Ephone-dn and

Ephone
Overview
This lesson defines ephone-dn (Ethernet phone directory number) and ephone (Ethernet phone)
and describes the different types of ephone-dns.
Objectives
Upon completing this lesson, you will be able to describe an ephone-dn and an ephone and
explain how to utilize the different types of ephone-dns. This includes being able to meet these
objectives:
Define ephone-dn and describe examples
Define ephone and describe examples
Describe different types of ephone-dns
Explain how to determine the quantity of allowable ephone-dns
Ephone and Ephone-dnConcepts

Ephoneand ephone-dnhave modular IOS software
construction.
Ephonerepresents the physical phone and is
limited by license and hardware.
Ephone-dncan be associated with one or more
ephones.
An ephonecan have more than one ephone-dn
associated with it.
The maximum number of extensions is the same
as the maximum number of ephone-dns.
IPTX v2.02-2
The Cisco CallManager Express software was created with modular and flexible configuration
in mind. The composition of the ephone and ephone-dn allows for many different types of
configurations and designs. The ephone represents the physical phone s configuration and
settings. The ephone is associated with a physical device by MAC address. This Layer 2
address is globally unique. The number of supported ephones on a Cisco CallManager Express
system depends on the licensed capacity and the router platform, and currently can be no more
than 240 ephones. Enterprises with more than 240 Phones should consider Cisco CallManager.
An ephone-dn represents a line or channel for voice to connect to the ephone. The ephone-dn
can be tied to the ephone in the configuration of the ephone. The quantity of ephone-dns that
are supported represents the maximum number of extensions that can be supported at any one
time. It is also a function of the licensed capacity and the hardware platform.
When considering the required number of ephones and ephone-dns, this information must be at
hand:
Number of simultaneous calls at each IP Phone
Quantity of directory numbers that is desired
Quantity of physical IP Phones
Ephone-dn
This topic defines ephone-dn and describes examples.
Ephone-dn Features
Directory number and
extension number are
equivalent
Line and voice port are
equivalent
Sequence number, or dn-tag,
is unique (is assigned when
the ephone-dn is created)
Can have one or more
telephone numbers
associated with it
Can have one or two voice
channels
When it is initially configured,
it creates one or more
telephony system POTS dial
peers
Primary extension number

on a single-line ephone-dn
that can make or receive
one call at a time
DN1
Ephone-dn
Primary and secondary

extensions configured on a
single-line ephone-dn in
which the primary is an
internal extension number
and the secondary is an
E.164 number
One phone extension on a

dual-line ephone-dn for
ephone-dns that need call
waiting, consultative
transfer, and conferencing
DN1 and
DN2
Ephone-dn
DN1
DN1
Ephone-dn
IPTX v2.02-3
Ephone-dn is software that represents a line that connects a voice channel to a phone instrument
on which a user can receive and make calls. An ephone-dn has one or more extensions or
telephone numbers associated with it. An ephone-dn is equivalent to a phone line in most cases,
but not always. There are several types of ephone-dns with different characteristics.
Each ephone-dn has a unique dn-tag, or sequence number, that identifies it during
configuration. Ephone-dns are assigned to line buttons on ephones during configuration.
Because each ephone-dn represents a virtual voice port in the router, the number of ephone-dns
that you create corresponds to the number of simultaneous calls that you can have. This means
that if you want multiple calls to the same number to be answered simultaneously, you need
multiple virtual voice ports (ephone-dns) with the same destination pattern (extension or
telephone number).
Ephone-dns can be configured in various ways, including:
Primary directory number on a single-line ephone-dn
Primary and secondary directory numbers on a single-line ephone-dn
Primary directory number on a dual-line ephone-dn (only one line has active voice at any
one time)
Note
When ephone-dn are created the system will constuct traditional dial peers in the
background. These will be discussed in Module 3.
Configuring an Ephone-dn
This command is used to create an extension

(ephone-dn) for a Cisco IP Phone line, an intercom
line, a paging line, a voice-mail port, or an MWI.
This command is used to associate a directory

number with the ephone-dn instance.
IPTX v2.02-4
An ephone-dn is created by the ephone-dn dn-tag command, which builds one virtual voice
port. The dn-tag field must contain a unique number if this is a new ephone-dn or an existing
number if a current ephone-dn is being modified. If the ephone-dn is to be assigned an
extension and assigned to a phone line, it should be able to accept two calls on the same line at
the same time. The ephone-dn should then have the keyword dual-line at the end of the
ephone-dn command. The dual-line keyword must be present in order to use an ephone-dn for
call waiting, consultative transfers, and conferencing with only one line appearance on the
Phone. An ephone-dn without the dual-line keyword is used when the ephone-dn is configured
for paging functions, intercoms, voice mail ports, or Message Waiting Indicators (MWIs).
Note
The dn-tag numbers do not have to be sequential.
The number dn-number command assigns a primary and, optionally, a secondary number to
the ephone-dn and is entered in ephone-dn subconfiguration mode.
The keyword no-reg can be used if either the primary extension or both the primary extension
and the secondary extension should not be registered to either an H.323 gatekeeper or a session
initiation protocol (SIP) proxy server. For example, a service provider that sells Cisco
CallManager Express may not want to have the primary extension number registered because there
may be many clients with the same dial plan. The secondary number, which would most likely be
an E.164 number, would be registered with an H.323 gatekeeper. The
number dn-number
secondary dn-number no-reg primary command would be added to the configuration of the
ephone-dn to accomplish this.
Basic Configuration
One virtual
voice port
One line or
channel
1001
Assigns a primary extension number to an

ephone-dn
IPTX v2.02-5
When an ephone-dn is configured with a single line, one virtual voice port is configured. Only
one call to or from the ephone-dn can be active because only a single line exists. If a second
call arrives while a call is active, the second call will receive whatever is the defined busy
treatment. Configuring an ephone-dn in this fashion mimics typical functionality of a keyswitch
line. An ephone-dn configured in this way lacks some of the more advanced PBX features.
Ephone
This topic describes an ephone and presents examples.
Ephone Features
Software configuration of a physical phone
Assigned a unique phone-tag,or sequence
number (assigned when it is created)
Can be an IP Phone or an analog phone
attached to an ATA
Uses MAC address of the IP Phone or ATA
to tie software configuration to hardware
Hardware automatically detected for all
supported models except the ATA and 7914
Expansion Module
Can have one or more ephone-dns
associated with it
Number of line buttons varies based
on hardware
7960
Button 1 DN
Button 4 DN
Button 2 DN
Button 5 DN
Button 3 DNDN Button 6
MAC 000F.2470.F92A
7912
Button 1 DN
MAC 000F.2470.F92B
ATA 188
Analog 1 DN
MAC 000F.2470.F92D
Analog 2 DN
MAC 000F.2470.F92E
IPTX v2.02-6
An ephone is a single instance of the software configuration of the physical instrument with
which a phone user makes and receives calls in a Cisco CallManager Express system. The
physical instrument is either a Cisco IP Phone or an analog telephone adaptor (ATA) device
that has an attached analog phone or fax.
Note
The Cisco IP Softphone and Cisco Communicator Softphone are not currently supported as
ephones. However, certain third-party vendors have a softphone that works (IP Blue).
Each ephone has a unique phone-tag, or sequence number, to identify it during configuration.
This phone-tag number must be unique and new if configuring a new ephone. If modifying an
already defined ephone, use the previously defined tag number to enter configuration mode for
that ephone. The ephone must be tied to the physical device in the ephone subconfiguration
mode. This is done by using the MAC address. The type of Phone must be defined if one or two
Cisco IP Phone 7914 Expansion Modules are present or if the device is a Cisco ATA 186 or
Cisco ATA 188. All other types of Phones can be automatically detected by the Cisco
CallManager Express system. The ephone-dns then must be assigned to the line buttons of the
ephone or Expansion Module. The number of line buttons varies with the model of IP Phone.
Configuring an Ephone
Creates an ephone instance and enters the ephone

subconfigurationmode
-- --
Associates the physical devices defined MAC

address with the ephone
IPTX v2.02-7
The ephone is created or modified in global configuration mode, using the ephone phone-tag
command. After the command is entered, the interface will be in ephone subconfiguration
mode, and the ephone-specific commands are entered from there. The command
mac-address mac-address is entered with 12 hex characters in groups of four separated
by a period (for example, 0000.0c12.3456). This associates the defined MAC address of the
physical device with the ephone.
Configuring an Ephone (Cont.)
-
-
Associates the ephone-dn(s) with a specific

button(s) on the IP Phone
Sets the ephoneto have either a 7940 or 7960 with

one or two 7914 Expansion Modules assigned
IPTX v2.02-8
The button button-number {separator} dn-tag command allows a line button to have an
ephone-dn assigned to it. The button number is the button on the IP Phone, starting with the top
button being 1. The dn-tag is the ephone-dn tag, or sequence number. The separator is a
single character that defines the properties of the button and the Phone s extension. Separators
include the following:
: (colon): Normal ring. For incoming calls, the Phone produces audible ringing, a flashing
icon on the Phones display, and a flashing red light on the handset. On the 7914 Expansion
Module, a flashing yellow light also accompanies incoming calls.
b: Beep but no ring. Audible ring is suppressed for incoming calls, but call-waiting beeps
are allowed. Visible cues are the same as those described for a normal ring.
f: Feature ring. Differentiates incoming calls on a special line from incoming calls on other
lines. The feature ring cadence is a triple pulse, as opposed to a single pulse for normal
internal calls and a double pulse for normal external calls.
m: Monitor mode for a shared line. A visible line status indicator shows whether the
shared line is in use. A shared line cannot be used on this Phone for incoming calls, but
can be used as a speed dial to the line it is monitoring. This will work only if the target is
in an idle state.
o: Overlay line without call waiting. Multiple ephone-dns share a single button, up to a
maximum of ten on a button. The dn-tag argument can contain up to ten individual dn-tags,
separated by commas.
c: Overlay line with call waiting. Multiple ephone-dns share a single button, up to a
maximum of ten on a button. The dn-tag argument can contain up to ten individual dn-tags,
separated by commas. This feature is available as of Cisco CallManager Express version 3.2.1.
s: Silent ring. An audible ring and the call-waiting beep are suppressed for incoming calls.
Visible cues are the same as those described for a normal ring.
The type {7940 | 7960} addon 1 7914 command sets the ephone to have either a 7940 or 7960
with either one or two 7914 Expansion Modules assigned. This command is required if using
the 7914 Expansion Module.
Example: Basic Configuration

MAC 000F.2470.F8F8
ephone 1
1001
Button 1
ephone-dn 7:
one virtual port
000F.2470.F8F8

--

IPTX v2.02-9
This example shows an ephone-dn 7 being created and assigned to ephone 1. The ephone-dn
is configured to be dual-line and is assigned to line button 1 on the IP Phone at the specified
MAC address.
Multiple Ephone-dns
1008 on Line 1
1009 on Line 2
1010 on Line 1
1011 on Line 6
Two physical phones
Button 1
Button 2
Button 1
Button 6
1008
1008
1009
1009
1010
1010
1011
1011
Four dual-line ephone-dns defined

Two ephones defined
IPTX v2.02-12
When there are multiple physical devices, the same number of ephones needs to be defined.
Then each ephone has one or more ephone-dns assigned to line buttons on the physical device.
The configuration for this follows.
Example: Configuration for Multiple Ephones

--

--

--

--

IPTX v2.02-11
This example shows the configuration of the multiple ephone-dns shown in the previous figure.
Multiple Ephone-dns
1008 on Line 1
1009 on Line 2
1010 on Line 1
1011 on Line 6
Two physical phones
Button 1
Button 2
Button 1
Button 6
1008
1008
1009
1009
1010
1010
1011
1011
Four dual-line ephone-dns defined

Two ephones defined
IPTX v2.02-12
In the figure, multiple ephone-dns are assigned to the ephone. The ephone-dns are assigned to
different buttons on the ephone. The configuration for this follows.
Example: Configuration for Multiple

Ephone-dns

--

--

IPTX v2.02-13
This example shows the configuration of the multiple ephone-dns shown in the previous figure.
Type of Ephone-dns
This topic describes the different types of ephone-dns.
Overview of Ephone-dns
Six types of
ephone-dns:
Single-line
Dual-line
Primary and secondary
extension on a singleor dual-line ephone-dn
Shared single-or
dual-line ephone-dn
Multiple single-or
dual-line ephone-dns
on one or more
ephones
1001
1002
1002
1004 and
1005
1006
1006
1003
1003
1003
1003
Overlay ephone-dn
on an ephone
1007
IPTX v2.02-14
The ephone-dn is the basic building block of a Cisco CallManager Express system. Six
different types of ephone-dns can be combined in different ways for different call coverage
situations. Each type helps with a particular limitation or call coverage need. For example, if
you want to keep the number of ephone-dns low and provide service to a large number of
people, you might use shared ephone-dns. Or if you have a limited number of extension
numbers that you can use, but you need to handle a large number of simultaneous calls, you
might create two or more ephone-dns with the same number. Knowing how each type of
ephone-dn works and what its advantages are will help you design your system.
These are the types of ephone-dns in a Cisco CallManager Express system:
Single-line ephone-dn
Dual-line ephone-dn
Primary and secondary extension on one ephone-dn
Shared ephone-dn
Multiple ephone-dns on one ephone
Multiple ephone-dns on different ephones
Overlay ephone-dn
Single-Line Ephone-dn
One virtual
voice port
One channel
1001
The ephone-dn creates one virtual voice port.

Only one call to or from this ephone-dn can occur at
any one time.
IPTX v2.02-15
A single-line ephone-dn has the following characteristics:

It makes one call connection at a time using one Phone line button. A single-line ephone-dn
has one telephone number associated with it.
It should be used when Phone buttons have a one-to-one correspondence to the public
switched telephone network (PSTN) lines that come into a Cisco CallManager Express
system.
It should be used for lines that are dedicated to intercom, paging, MWI, loopback, and
Music on Hold (MOH) feed sources.
When used with multiple-line features such as call waiting, call transfer, and conferencing,
there must be more than one single-line ephone-dn on a Phone.
It can be combined with dual-line ephone-dns on the same Phone.
A multiple-line button Phone must be used if call waiting, consultative transfer, or
conferencing are needed.
Note
When an ephone-dn is created, you choose to configure it as either a dual-line ephone-dn or

a single-line ephone-dn. If at some point the selection needs to be changed, the ephone-dn
must be deleted and re-created.
Dual-Line Ephone-dn
One virtual
voice port
Two channels
1002
1002

The dual-line keyword indicates two voice channels for calls to
terminate on an ephone-dn extension.
This should be used on ephone-dns that need call waiting,
consultative transfer, and conferencing on one button.
This cannot be used on ephone-dns that are used for intercoms,
paging, MWI, call parking slots, and MOH feeds.
IPTX v2.02-16
A dual-line ephone-dn has the following characteristics:

It can make two call connections at the same time using one Phone line button. A dual-line
ephone-dn has two channels for separate call connections.
It can have one number or two numbers (primary and secondary) associated with it.
It should be used for an ephone-dn that utilizes just a single button for features such as call
waiting, call transfer, and conferencing.
It cannot be used for lines that are dedicated to intercom, paging, MWI, loopback, call
parking slots, and MOH feed sources.
It can be combined with single-line ephone-dns on the same Phone.
Primary and Secondary Extension Number

on One Ephone-dn
One virtual
voice port
One channel
1005 and
2065559005

Two different directory numbers can be dialed to reach this ephone-dn.
One call connection is allowed if configured as a single-line ephone-dn.
Two call connections are allowed if configured as a dual-line ephone-dn.
This ephone-dn type allows two numbers to be configured without using
an extra ephone-dn.
The secondary number is registered to the H.323 gatekeeper or SIP
proxy server.
IPTX v2.02-17
A dual-number ephone-dn has the following characteristics:

It has two telephone numbers: a primary number and a secondary number.
If it is a single-line ephone-dn, it can make one call connection at a time.
If it is a dual-line ephone-dn, it can make two call connections at a time.
It should be used when you want to have two different numbers for the same button without
using more than one ephone-dn.
The secondary number is registered with the H.323 gatekeeper or SIP proxy server.
Shared Ephone-dn
Button 1
1100 on Line 2
1007 on Line 1
1100 on Line 2
One ephone-dn is applied on two different ephones.

Only one Phone can use the ephone-dn at a time.
1006
1006
1006 on Line 1
Button 2
1100
Button 1
1007
1007
Button 2
1100
Both Phones ring when a call arrives at the

ephone-dn.
Only one ephone can pick up the call, ensuring
privacy.
Either ephone can retrieve a call placed on hold.
IPTX v2.02-18
A shared ephone-dn has the following characteristics:

It appears on two different Phones, but uses the same ephone-dn and number.
Only one call can be made at a time on the two Phones, and that call appears on
both phones.
It should be used when you want the capability to answer or pick up a call at more
than one Phone.
Only one Phone can pick up a call, which ensures privacy.
When a call is placed on hold, either Phone can retrieve it.
If the ephone-dn is connected to a call on one Phone, that ephone-dn is unavailable for
other calls on the second Phone because the Phones share the same ephone-dn.
Example: Configuration for Shared

Ephone-dn

-

--

--

IPTX v2.02-19
This example shows the configuration of the shared ephone-dn shown in the previous figure.
Multiple Ephone-dns on One Ephone

On the same ephone:
Used when more than two
calls to the same extension
are needed
On different ephones:
Used when two different
ephones need the same
number
Is not a shared line
Only one ephone will ring at a
time
A call on hold retrievable only
by the ephone that put the call
on hold
Ephone 3
Button 1
Button 2
1003
1003
1003
1003
preference 0
no huntstop
preference 1
huntstop
Ephone 4
Button 2
1004
1004
preference 0
no huntstop
Ephone 5
Button 2
1004
1004
preference 1
huntstop
IPTX v2.02-20
There are two different ways to use multiple ephone-dns with the same extension number. One
way is for multiple ephone-dns to be assigned to the same ephone, but on separate line buttons.
This type of configuration is useful when more than two calls arrive at a destination and need to
be handled simultaneously. For example, if six calls at a time need to be handled, then three
dual-line ephone-dns can all be configured with the same extension number.
The other way that multiple ephone-dns with the same extension number can be configured is
on different ephones. This is used when two or more ephones need to be able to answer the
same number. This also provides some very basic hunting functionality. The characteristics of
this type of configuration are:
Two or more virtual ports have the same extension number.
It is not a shared line.
Two call connections are allowed per ephone-dn if it is a dual-line ephone-dn; one
connection is allowed if it is a single-line ephone-dn.
The preference and huntstop commands are used to configure hunting behavior.
Only one ephone rings at a time.
A call on hold is retrievable only by the ephone that first placed the call on hold.
Multiple Ephone-dns on One Ephone (Cont.)

preference and huntstop Commands
Sets the dial-peer preference order
Discontinues the call hunting behavior

for an extension (ephone-dn) or an extension
line (dual-line)
IPTX v2.02-21
Values assigned in the preference command are passed to the dial peers that are created by the
two ephone-dns. Both dial peers for the ephone-dns are matched when this extension number
is dialed. The call is connected to the ephone-dn that has the highest preference. The default
preference value is 0 (the most preferred); the lowest preference value that can be set is 10
(the least preferred).
Using the huntstop command without the channel keyword affects call hunting behavior that
relates to ephone-dns (lines or extensions). The huntstop command without the channel
keyword is the default setting on all ephone-dns. If the huntstop attribute is set, an incoming
call does not roll over (hunt) to another ephone-dn when the called ephone-dn is busy or does
not answer and a hunting strategy has been established that includes this ephone-dn. For
example, the huntstop attribute prevents hunt-on-busy from redirecting a call from a busy
Phone into a dial-peer setup with a catch-all default destination. Use the no huntstop command
under the ephone-dn to disable huntstop and allow hunting for ephone-dns.
The huntstop channel attribute works in a similar way, but it affects call hunting behavior for
the two channels of a single dual-line ephone-dn. If the huntstop channel command is used,
incoming calls do not hunt to the second channel of an ephone-dn when the first channel is
busy or does not answer. For example, an incoming call might search through the following
ephone-dns and channels:
ephone-dn 10 (channel 1)

huntstop Commands
1020 DN
Preference 0
1020 DN
Preference 1
1020 DN
Preference 2
no huntstop
Channel 1
no huntstop
channel
no huntstop
1020 DN
Preference 3
Busy
Channel 2
Ephone-dn 11
Busy
Channel 1
no huntstop
channel
huntstop
Call arrives at first

ephone-dn
Ephone-dn 10
Busy
Channel 2
Ephone-dn 12
Busy
Channel 1
no huntstop
channel
Channel 2
Ephone-dn 13
Same directory number on

the ephone-dns
Channel 1
Channel 2
Busy
Ring no answer timeout

of 10 seconds set
globally
IPTX v2.02-22
When the no huntstop command is used on the ephone-dn, the call rings on the first ephone-dn
and goes through any hunting defined on the two channels in a dual-line ephone-dn before
being sent to the next most-preferred ephone-dn that has a matching destination pattern. This
will continue until an ephone-dn with huntstop configured is reached or until no more dial peers
(ephone-dns) have matching destinations patterns.

huntstop channel Commands
1020 DN
no huntstop
Ephone-dn 10
huntstop channel
Preference 0
Channel 1
Channel 2
1020 DN
no huntstop
Preference 1
Busy
Ephone-dn 11
huntstop channel
Channel 1
Channel 2
1020 DN
huntstop
Preference 2
1020 DN
Preference 3
no huntstop
channel
Busy
Ephone-dn 12
Channel 1
Busy
Channel 2
Ephone-dn 13
Channel 1
Channel 2
Call arrives at first

ephone-dn
Ring no answer timeout

of 10 seconds set
globally
IPTX v2.02-23
The huntstop channel attribute works in a similar way, but it affects call hunting behavior for
the two channels of a single dual-line ephone-dn. If the huntstop channel command is used,
incoming calls do not hunt to the second channel of an ephone-dn when the first channel is
busy or does not answer.
When the no huntstop channel command is used (the default), a call might ring for 10 seconds
on ephone-dn 10 (channel 1), then after 10 seconds move to ephone-dn 10 (channel 2). This is
not usually desirable in a dual-line Phone.
It is often useful to reserve the second channel of a dual-line ephone-dn for call transfer, call
waiting, or conferencing. The huntstop channel command tells the system that if the first
channel is in use or does not answer, an incoming call should hunt forward to the next ephonedn in the hunt sequence instead of to the next channel on the same ephone-dn.
Example: Two Ephone-dns, One Number,

Same Ephone
1003 on Line Button 1
Ephone 3
Button 1
Button 2
1003
1003
1003
1003
preference 0
no huntstop
preference 1
huntstop
If either of the two voice channels are available, the ephone-dn that is assigned
to line button 1 is used when an incoming call is set up.
When the two voice channels on the ephone-dn are being used on line button 1,
an incoming call rolls to the ephone-dn that is assigned to line button 2.
A fifth call receives busy treatment when both voice channels onboth ephone-dns
are being used on line buttons 1 and 2.
The preference of 0 is more preferred than the preference of 1; the default is 0.
The no huntstop on the line button 1 ephone-dn allows the call to hunt to the
second ephone-dn when the first ephone-dn is busy.
The huntstop on the line button 2 ephone-dn stops the hunting behavior and
applies the busy treatment.
IPTX v2.02-24
When two different ephone-dns with the same number are assigned to different buttons of the
same ephone and a call arrives, the call goes to the ephone-dn that is most preferred based on
the preference setting. If the first ephone-dn is busy or not answered, the call will go to the
second ephone-dn. Because the buttons have different ephone-dns, the calls that are connected
on these buttons are independent of one another.
Example: Configuration for Two Ephone-dns,

One Number, Same Ephone

-

-

--

IPTX v2.02-25
This example shows the configuration for two ephone-dns with one number on the same
ephone.
Multiple Ephone-dns on Different Ephones

Ephone 4
Button 2
1004
preference 0
no huntstop
Ephone 5
Button 2
1004
preference 1
huntstop
Ephone 4 is used first if available.

When the first ephone-dn is being used on ephone 4, an incoming call uses the
ephone-dnthat is assigned to ephone 5.
A third call receives busy treatment when both ephone-dns are being used on
ephones4 and 5.
The preference of 0 is more preferred than the preference of 1; the default is 0.
The no huntstop on the ephone-dn on ephone 4 allows the call to hunt to the second
ephone-dn on ephone 5 when the first ephone-dn is busy.
The huntstop on the ephone-dn on ephone 5 stops the hunting behavior and applies
the busy treatment for the third call.
Unlike a shared line appearance, if a call is placed on hold, only the original phone
is able to retrieve the call.
IPTX v2.02-26
A shared line is an ephone-dn configured on two ephones with a representation of the same
line on each ephone. This is different than two ephones having separate ephone-dns with the
same number.
A shared ephone-dn has the same call connection at all the buttons on which the shared ephone-dn
appears. If a call on a shared ephone-dn is answered on one ephone, then placed on hold, the
call can be retrieved from the second ephone on which the shared ephone-dn appears. But when
there are two separate ephone-dns with the same number, a call connection appears only on the
Phone and button at which the call is made or received. If the call is placed on hold on one
ephone, it cannot be retrieved from the other ephone that has an ephone-dn with the same
number because that is a different virtual voice port.
Example: Configuration for Two Ephone-dns,

One Number, Different Ephones

-

-

--

--

IPTX v2.02-27
This example shows the configuration for two ephone-dns that have one number on
different ephones.
Overlay Ephone-dn
1101 on Line 4
1101 on Line 4
Button 4
1101
Preference 0
no huntstop
Button 4
1101
Preference 1
huntstop
Button 4
1101
Preference 0
no huntstop
Button 4
1101
Preference 1
huntstop
1101 on Line 4
1101 on Line 4
Two or more ephone-dns applied to the same ephone line button
Up to ten ephone-dns per line button on the phone
In overlay set, either all ephone-dns must be single-line or all must
be dual-line
Ephone-dns usually applied on more than one phone
Allows up to ten calls (depending on the number of ephone-dns)
to the same phone number that resides on multiple ephones
Call pickup is not supported
Call placed on hold retrievable only by the phone that placed the call
on hold
IPTX v2.02-28
An overlay ephone-dn has the following characteristics:

It is a member of an overlay set, which includes all the ephone-dns that have been assigned
together to a particular phone button.
It can have the same telephone or extension number as other members of the overlay set or
it can have different numbers.
It can be single-line or dual-line, but single-line and dual-line cannot be mixed in the same
overlay set.
It can be shared on more than one Phone.
Call waiting can be enabled (minimum Cisco CallManager Express version 3.2.1).
An overlay ephone-dn provides call coverage similar to a shared ephone-dn because the same
number can appear on more than one Phone. The advantage of using two ephone-dns in an
overlay arrangement rather than as a simple shared ephone-dn is that a call to the number on
one Phone does not block the use of the same number on the other Phone. That is what would
happen if this were a shared ephone-dn.
You can overlay up to ten lines on a single button and create a 10x10 shared lineten lines
in an overlay set shared by ten Phones. This results in the possibility of ten simultaneous calls
to the same number.
An overlay is configured by use of an overlay separator with the button command. The
separator is o to create an overlay without call waiting or a c to create an overlay with call
waiting. For example, the command button 1o20,21,23,24,25 would configure ephone-dns 21,
22, 23, 24, and 25 on button 1 of the ephone without call waiting.
The behavior of an overlay set of ephone-dns with call waiting and overlay ephone-dns without
call waiting is the same, except for the following:
Calls to numbers included in overlay ephone-dns with call waiting will cause inactive
Phones to ring and active Phones that are connected to other parties to generate auditory
call-waiting notification. The default sound is beeping, but you can configure an ephone-dn
to use a ringing sound. Visual call-waiting notification includes the blinking of handset
indicator lights and the display of caller IDs.
For example, if three of four Phones are engaged in calls to numbers from the same overlay
ephone-dn with call-waiting and another call comes in, the one inactive Phone will ring, and the
three active Phones will issue auditory and visual call-waiting notification.
Two calls to numbers in an overlay ephone-dn set can be announced. For the first call, the
Phone user will hear a ring; for the second, call-waiting notification. Subsequent calls must
wait in line, remaining invisible until one of the two original calls has ended. The callers
who are waiting in the line will hear a ringback tone.
A simple configuration in which one Phone has a call waiting enabled overlay and the
other one has a standard overlay with no call waiting follows.
Example: Configuration for Overlay Ephone-dn

-

--

--

This shows the configuration for an overlay ephone-dn.
IPTX v2.02-29
Number of Ephone-dns
This topic explains how to determine the quantity of allowable ephone-dns.
max-dn Command
This command sets the maximum definable number

of ephone-dns that can be configured in the system.
The maximum number of supported ephone-dnsis a
function of the license and the hardware platform.
The default is 0.
To make the most efficient use of memory, do not
set this parameter higher than needed.
IPTX v2.02-30
The maximum number of ephone-dns that can be configured is based upon the hardware
platform on which the Cisco CallManager Express software is installed. The default of a newly
installed Cisco CallManager Express system is that no ephone-dns can be configured. This is
because the command max-dn is set to 0. To allow the creation of ephone-dns, use the
command max-dn ? to determine the maximum allowable number of ephone-dns the hardware
supports. Set the value within that range to comply with the licensing.
max-dn Command (Cont.)
Attempts to create an
11th ephone-dn will fail.
DN
DN
DN
DN
DN
DN
DN
DN
DN
DN
IPTX v2.02-31
In this graphic, the command max-dn 10 creates ten ephone-dns. If you try to create an 11th
ephone-dn, an error message is sent to the console of the Cisco CallManager Express router.
An 11th ephone-dn will not be allowed until the maximum allowable number of ephone-dns is
increased.
Summary
Summary
Ephone-dnsand ephonesare two key components in the Cisco
CallManager Express system.
An ephone-dn is a single instance of an extension (directory)
number.
An ephone is a single instance of the configuration of the physical
instrument.
There are different types of ephone-dns:
Single-line ephone-dn
Dual-line ephone-dn
Primary and secondary extension on one ephone-dn
Shared ephone-dn
Multiple ephone-dns on one ephone
Multiple ephone-dns on different ephones
Overlay ephone-dn
IPTX v2.02-32
Lesson 5
Describing Cisco CallManager

Express Files
Overview
This lesson describes Cisco CallManager Express files.
Objectives
Upon completing this lesson, you will be able to describe Cisco CallManager Express methods
for downloading files to IP Phones. This includes being able to meet these objectives:
Describe downloading bundled Cisco CallManager Express files
Describe downloading individual Cisco CallManager Express files
Identify Cisco CallManager Express GUI files to enable web access
Identify TSP files for TAPI integration
Describe Music on Hold and xml.template files
Cisco CallManager Express Files

This topic describes Cisco CallManager Express files.
Cisco CallManager Express Files

FLASH
TFTP or
FTP server
GUI Files
Firmware
Music on Hold
IOS
copy tftp flash

or
copy ftp flash
Load firmware for IP Phones and devices

Used to upgrade Cisco CallManager Express
Load Music on Hold files
IPTX v2.02-2
Cisco CallManager Express requires firmware files to be copied to the flash memory on your
router and shared using TFTP or FTP. Download Cisco CallManager Express 3.1 files to a
TFTP or FTP server that is accessible to your Cisco CallManager Express router. To move the
files from the server to the flash memory, use the copy tftp flash command or the copy ftp
flash command. You can download the files in a single bundle or individually.
When the Cisco CallManager Express router is upgraded, the new files, such as firmware, GUI
files, and Cisco IOS software, must be moved to the flash memory on the router. Other files,
such as new firmware versions and Music on Hold (MOH) files, may need to be periodically
updated.
Bundled Cisco CallManager Express Files

This topic describes downloading bundled Cisco CallManager Express files.
IPTX v2.02-3
A bundled file with all of the Cisco CallManager Express files can be downloaded from
Cisco.com. The Cisco CallManager Express bundle comes in either a .tar file or a .zip file.
These files can then be extracted from the FTP or TFTP server.
Tip
The Cisco CallManager Express software can be found at

http://www.cisco.com/kobayashi/sw-center/sw-voice.shtml.

(Cont.)
The extracted
cme-123-11XL.zip
file yields:
* All files are specific to the version of

Cisco CallManagerExpress.
GUI Files
cme-gui-123-11XL.tar
Cisco TAPI file
CiscoIOSTSP1.3.zip
Firmware files
cmterm7920.4.0-01-08.bin
cmterm7936.3-3-5-0.bin
P00303020214.bin
P00403020214.bin
P00503010100.bin
S00103020002.bin
CP7902040000SCCP40701A.sbin
P00305000301.sbn
ATA030100SCCP040211A.zup
CP7050101SCCP030530B31.zup
B-ACD application
cme-b-acd-2.0.0.0.tar
Cisco TAPI file
CiscoIOSTSP1.3.zip
Music on Hold
music-on-hold.au
IPTX v2.02-4
The Cisco CallManager Express bundle contains all of the files that are needed to install and
configure Cisco CallManager Express. The files that are contained in the bundle are listed
in the figure.
The cme-123-11XL.zip file contains all the files needed to run the GUI web interface for
Cisco CallManager Express. These files are also needed for the GUI of Cisco Unity Express (CUE).
The music-on-hold.au file can be used to provide MOH from a file in flash memory. This can
be replaced with a custom .wav or .au file if desired.
Individual Cisco CallManager Express Files

This topic describes downloading individual Cisco CallManager Express files.
Individual Cisco CallManager Express Files

Firmware files
Basic Cisco CallManager Express.tar
GUI.tar
IPTX v2.02-5
The files can be downloaded individually as well as in a bundle.

Note
These files are specific to Cisco CallManager Express version 3.2.1, and they are not
backward compatible.
GUI Files
This topic identifies Cisco CallManager Express GUI files to enable web access.
GUI Files
IPTX v2.02-6
One of the individual files that can be downloaded is the .tar file that contains the GUI
web interface for Cisco CallManager Express. The CUE module GUI is also dependent on
the Cisco CallManager Express GUI.
GUI Files (Cont.)

XML template
xml.template
GUI files
The extracted
cme-gui-123-11XL.tar
yields:
admin_user.html
admin_user.js
CiscoLogo.gif
Delete.gif
dom.js
downarrow.gif
ephone_admin.html
logohome.gif
normal_user.html
normal_user.js
Plus.gif
sxiconad.gif
Tab.gif
telephony_service.html
uparrow.gif
xml-test.htm
IPTX v2.02-7
The contents of the GUI web interface .tar file are shown in this figure. These files need to be
present in the flash memory of the Cisco CallManager Express router.
Cisco CallManager Express TAPI Integration

This topic identifies telephony service provider (TSP) files for Telephony Application
Programming Interface (TAPI) integration.

TAPI Integration
CiscoIOSTSP1.3.zip
CiscoIOSTspLite1.3.exe
Readme.txt
TAPI Lite
Allows third-party software to control an IP
telephony device
Is installed on Windows PC
IPTX v2.02-8
To allow a third-party piece of software to interact with the Cisco CallManager Express system
through TAPI Lite, the files in the Cisco IOS TSP file must be installed on the same
Windows PC where the software is installed.
The content of the IOS TSP file are shown above. Run the CiscoIOSTspLite1.3.exe on the
Windows PC where the TAPI integration is being performed. This file is specific to Cisco
CallManager Express version 3.2.1 and must be upgraded on the PC when Cisco CallManager
Express is upgraded.
Note
This file does not need to reside in flash memory; it will be extracted and installed on a
Windows PC.
Additional Files
This topic describes music-on-hold.au and xml.template files.
Additional Files
music-on-hold.au
Use the music-on-hold.au audio file to provide

music for external callers who are on hold when
you are not using a live feed.
xml.template
Use the xml.template file to allow or restrict the

GUI functions that are available to an optional
customer administrator.
IPTX v2.02-9
Other files that may be of interest include the file needed for MOH. This file must reside in
flash memory on the Cisco CallManager Express router and must be called music-on-hold.au.
The file, which came in the bundle or was downloaded individually, contains an audio file that
is used when a caller is placed on hold. This file can be customized.
A sample file for creating a customer administrator with a limited subset of administrative
privileges is included in the bundle or can be downloaded in an individual file that contains the
basic files. This file, xml.template, can be customized and stored in flash memory for use.
Summary
Summary
Files are moved to flash memory on the Cisco
CallManager Express router using the copy
command.
Files can be downloaded individually or bundled.
The files may be compressed and may have to be
extracted.
Files that are downloaded include the basic files
for Cisco CallManagerExpress, GUI web interface,
TAPI integration, Music on Hold, and the
xml.template file.
IPTX v2.02-10
Lesson 6
Understanding Initial Phone

Setup
Overview
This lesson describes the three ways to create an initial IP Phone setup. It also discusses
optional parameters, the commands for rebooting IP Phones, setup troubleshooting, and the
steps for verifying the Cisco CallManager Express Phone configuration.
Objectives
Upon completing this lesson, you will be able to configure initial IP Phone setup and verify
Cisco CallManager Express configurations. This includes being able to meet these objectives:
Describe the three ways to create an IP Phone setup in a Cisco CallManager Express system
Perform a manual setup using the router CLI
Perform a partially automated setup using the router CLI
Perform an automated setup using the Cisco CallManager Express setup tool
Identify optional IP Phone parameters
Discuss two ways to reboot IP Phones
Describe troubleshooting tips
Describe the steps to verify Cisco CallManager Express configuration
Setting Up Phones in a Cisco CallManager

Express System
This topic describes the three ways to create an initial IP Phone setup in a Cisco CallManager
Express system.
Three Ways to Set Up Phones

Manual
Requires numerous commands from the CLI
Requires knowledge of Cisco CallManager Express
commands
Requires that phones be entered manually in IOS software
Partially automated
Requires numerous commands from the CLI
Requires knowledge of Cisco CallManager Express
commands
Simplifies deployment
Automated
Needs few commands from the CLI
Requires little knowledge of Cisco CallManager Express
commands
Simplifies deployment
IPTX v2.02-2
There are three ways to set up IP Phones in Cisco CallManager Express. You can set up Phones
manually; you can use a combination of manual setup and automated setup, referred to as
partially automated; or you can use the fully automated setup.
Manual Phone Setup
This topic describes how to perform a manual Phone setup in a Cisco CallManager Express
system using the router command-line interface (CLI).
Manual Setup Overview

All commands can be entered from the CLI.
Manual setup is best performed by experienced
administrators.
Administrators leverage their knowledge of IOS
software.
Full functionality is achieved through IOS
commands.
Deployment of IP Phones can be batched or
scripted through a text file.
IPTX v2.02-3
The manual setup of the Cisco CallManager Express system involves using CLI. This type of
setup allows the administrator to leverage existing knowledge of Cisco IOS software and to
implement Cisco CallManager Express functions. The configuration can be viewed, backed up,
and restored through a simple text file. Manual setup can save time and effort when used for
multiple site deployments because it allows only the differences to be changed on a per-site
basis.
Commands Overview
Commands that are needed to configure a basic
telephony service are as follows:
tftp-server flash:filename
telephony-service
max-ephones max-ephones
max-dn max-directory-numbers
load phone-type firmware-file
ip source-address ip-address [port port]
create cnf-files
keepalive seconds
dialplan-pattern tag pattern extension-length length extensionpattern pattern
IPTX v2.02-4
The following commands must be configured in order to deploy a Cisco CallManager Express
system.
tftp-server flash:filename
telephony-service
max-ephones max-ephones
max-dn max-directory-numbers
load phone-type firmware-file
ip source-address ip-address [port port]
create cnf-files
keepalive seconds
dialplan-pattern tag pattern extension-length length extension-pattern pattern
In the addition to these commands, ephones and ephone-dns must be manually configured.
tftp-server Command
- -
Allows a file in flash to be downloadable with TFTP

7940/60
Firmware
Available
7920
Firmware
7910
Firmware
through TFTP
- -
- -
- -
IPTX v2.02-5
The command tftp-server flash:filename allows the specified file that resides in flash memory
to be downloaded via TFTP. In Cisco CallManager Express, the firmware files need to be
configured so that they are available through TFTP. The figure shows firmware for the
7910G+SW, 7920, 7940G, and 7960G IP Phones.
Telephony Service Commands
Enters telephony-service mode

-
Sets the maximum number of ephones that may be

defined in the system (default is 0)
-
Sets the maximum number of ephone-dns that may

be defined in the system (default is 0)
IPTX v2.02-6
The telephony-service command enters the telephony-service mode, from which much of the
configuration for the Cisco CallManager Express system is entered. The first two commands
that you should enter are max-ephones and max-dn. Both of these commands are set to 0,
which has the effect of not allowing any ephones or ephone-dns to be configured.
The number of ephones and ephone-dns is version and platform-specific. The number displayed
in IOS software Help is not always accurate and may reflect an artificially high number.
Consult the information provided with the Cisco CallManager Express router or on the
Cisco.com web site.
Example
This is an example of the IOS software Help that may be displaying maximums higher than
what the platform can handle.

- -
-
- -
Firmware Association
-
Associates a firmware file with the model of IP

Phone
7940/60
Firmware
7940G and 7960G
Filenames are case sensitive.
7920
7920
Firmware
7910
Firmware
7910G+SW
IPTX v2.02-7
To associate a type of Cisco IP Phone with a Phone firmware file, use the load model
firmware-file command in telephony-service configuration mode. The following shows the
supported Phone models for which firmware can be loaded.
Note
No suffix should be used when using the load command for the 7910G+SW, 7940G, and
7960G models of IP Phones.
7902 Selects the firmware load file for the 7902G Phone
7910 Selects the IP Phone firmware load file for the 7910G+SW Phone
7914 Selects the IP Phone firmware load file for the 7914 Expansion Module
7920 Selects the firmware load file for the 7920 Phone
7935 Selects the IP Phone firmware load file for Conference Station 7935
7936 Selects the firmware load file for Conference Station 7936
7960-7940 Selects the IP Phone firmware load file for the 7960G and 7940G Phones
ATA Selects the firmware load file for Analog Telephone Adaptor (ATA) 186
and ATA 188
To see a list of Phone models supported by your router enter the following:
CMERouter1(config-telephony)#load?
Source IP and Port

-
--- --
Identifies the address and port through which IP

Phones communicate with Cisco CallManager Express
Default
XML
10.90.0.1
-
---
IPTX v2.02-8
The Cisco CallManager Express system expects to receive Skinny Client Control Protocol
(SCCP) messages from the IP Phones concerning registrations and call control. The command
ip source-address ip-address [port port] is used to configure the local IP address and the TCP
port from which the Cisco CallManager Express system expects these messages. The port by
default is set to 2000; although this can be changed, it is unusual to do so.
Example
This is an example of the XMLDefault.cnf.xml file. Note the IP address, port, and firmware files.
-
----

Create XML Files

-
Builds the specific XML files that are necessary for

the IP Phones
SEP
SEP000F2473AB14.cnf.xml
XML
000F.2473.AB14
10.90.0.1
-
IPTX v2.02-9
Use the create cnf-files command in telephony-service configuration mode to build the XML
configuration files that the IP Phones require and that are used with Cisco CallManager Express.
When this command is entered, the file XMLDefault.cnf.xml is generated with the appropriate
settings, including the firmware defined by theload command, the IP address that the new
IP Phones will be registered with, and the TCP port the SCCP messages will arrive on.
Example
This is an example of SEP000F2473AB14.cnf.xml. Note the IP address, port, locale
information, and required firmware.
-
----
- -
-
--
-
-

---

--
Keepalive
-
--
Sets the time interval between keepalive messages

from the IP Phones to Cisco CallManager Express
-

Keepalive
Keepalive
Default is 30 seconds, range is 1065535 seconds

If three successive keepalives missed, device must
register again
IPTX v2.02-10
To set the length of the time interval between successive keepalive messages from the Cisco
CallManager Express router to IP Phones, use the keepalive command in telephony-service
configuration mode. The default setting for the keepalives is 30 seconds. If the router fails to
receive three successive keepalive messages, it considers the Phone to be out of service until
the Phone reregisters.
Direct Inward Dial Configuration

Commands
-
-
-
Sets a dial plan pattern that can expand extension

numbers to fully qualified E.164 numbers, which can be
used for DID numbers
Extension
1000
PSTN
ISDN PRI
DID numbers
assigned:
2015559000
through
2015559099
Extension
10XX
Extension
1099
-
- -
IPTX v2.02-11
Directory numbers for the Cisco IP Phones are entered in extension-number format. The
dialplan-pattern command creates a global prefix that can be used to expand the abbreviated
extension numbers into fully qualified E.164 numbers. The dial-plan pattern is also required for
registering Cisco IP Phone lines with a gatekeeper. The dialplan-pattern command can
transform an incoming call that has a full E.164 number to a Cisco IP Phone extension number.
The extension-length keyword enables the system to convert a full E.164 telephone number
back into an extension number for the purposes of caller ID display and received-call and
missed-call lists. For example, a company uses the extension number range 100 to 199 across
several sites and the extensions from 1000 to 1099 are present only on the local router. An
incoming call from 1044 arrives from the companys internal Voice over IP (VoIP) H.323
networkthe calling number for this call is displayed as 4085551044 in its full E.164 format.
By default, the numbers matching the dialplan-pattern command will be registered to an
H.323 gatekeeper if a gatekeeper is configured. Use of the no-reg keyword changes this default
behavior and prevents the numbers that match the pattern from registering with the gatekeeper.
When the called number matches the dial-plan pattern, the call is considered a local call and has
a distinctive ring that identifies the call as internal. Any call that does not match the dial-plan
pattern is considered an external call and has a ring that is different from the internal ring.
The valid dial-plan pattern with the lowest dial-plan tag number is used as a prefix to all local
Cisco IP Phones.
The number of extension-pattern characters must match the extension length that is specified in
the dialplan-pattern command.
Note
This command can be used in place of configuring secondary numbers on ephone-dns.
Example
Example: Manual Setup of Cisco

CallManager Express
- -
- -
-

-

---
- -
See the lesson

Defining
Ephone-dn
and Ephone
for manual
configuration
information.

-
-

--

IPTX v2.02-12
This figure shows the configuration for a basic Cisco CallManager Express system.
Partially Automated Phone Setup
This topic describes how to perform a partially automated IP Phone setup in a

Cisco CallManager Express system using the router CLI.
Overview of Partially Automated Setup

In a partially automated setup, you dont have to
configure ephones.
Deployment of IP Phones is automated.
The auto assign command is used.
All ephone-dns must be the same type
(single-line or dual-line).
IPTX v2.02-13
In a partially automated setup, you dont have to configure ephones. The ephones can be
detected automatically and assigned an ephone-dn from a range of configured ephone-dns (all
ephone-dns must be the same type). This partially automated setup allows for the deployment
of many Phones without the work of configuring every Phone manually. This automatic
assignment is done through the use of the auto assign command.
auto assign Command

-
-- - -
--
The ephone-dns that are configured to new

ephones are automatically assigned.
Phones can take up to five minutes to register.
Wait for all Phones to register before saving the
configuration.
The cfw keyword defines the call forward busy
number and timeout value for Phones that register.
IPTX v2.02-14
To automatically assign ephone-dn tags to Cisco IP Phones as they register for service with
the Cisco CallManager Express router, use the auto assign command in telephony-service
configuration mode.
This command lets you assign ranges of ephone-dn tags according to the physical Phone type.
Multiple auto assign commands can be used to provide discontinuous ranges and to support
multiple types of IP Phones. Overlapping ephone-dn ranges may be assigned so that they map
to more than one type of Phone. If no type is specified, the values in the range are assigned to
Phones of any type, but if a specific range is assigned for a Phone type, the available ephone-dns
in that range are used first. The cfw keyword sets the call forward busy number and timeout
value on all Phones that automatically register.
The auto assign command cannot be used for the 7914 Expansion Module. Phones with one or
more expansion modules must be configured manually.
Automatically assigned ephone-dn tags must belong to normal ephone-dns and cannot belong
to paging ephone-dns, intercom ephone-dns, Music on Hold (MOH) ephone-dns, or Message
Waiting Indicator (MWI) ephone-dns. The ephone-dn tags that are automatically assigned must
have at least a primary number defined.
All the ephone-dns in a single automatic assignment set must be of the same kind (either
single-line or dual-line). Automatic assignment cannot create shared lines.
If there is not a sufficient number of available ephone-dns in the automatic assignment set,
some Phones will not receive ephone-dns.
Reversal of automatic assignment must be performed by manual CLI entry. This reversal
configuration must be followed by a reboot of the Phones that are assigned. If you use the
type keyword with this command, use the reset command to reboot the Phones. If you do not
use the type keyword with this command, use the restart command to perform a quick reboot.
Note
Care should be taken when using the auto assign command because this command grants
telephony service to any IP Phone that attempts to register. If you use the auto assign
command option, make sure that your network is secure from unauthorized access by
unknown IP Phones.
Example: auto assign Command

New Phone Plugs In
When a new IP Phone registers with a Cisco

CallManager Express system, a new ephone is
created with the MAC address of the IP Phone.
A preexisting ephone-dn is assigned to the new
ephone from the range defined for the type of
phone.
The lowest unassigned ephone-dn in the
matching statement range is used.
If all ephone-dns in a range have been assigned,
some Phones may not receive an ephone-dn or
may overflow to the general auto assign without
a type.
-
--
--
--
--
If a new IP Phone does not match any auto

assign with a type, the auto assign without a
type is used.
IPTX v2.02-15
In this example, there are four auto assign commands with a different ephone-dn assigned
to each. Any 7920 IP Phone is assigned the lowest unassigned ephone-dn from 1 through 10.
Any 7940G IP Phone is assigned the lowest unassigned ephone-dn from 11 through 20. Any
7960G IP Phone is assigned the lowest unassigned ephone-dn from 21 through 40. And finally,
any 7920, 7940G, and 7960G IP Phone is assigned an ephone-dn from the generic range of
41 through 50 if it cannot be assigned an ephone-dn in its assigned range. This generic range,
which is not tied to any type, is also used for any other unspecified models of IP Phones.
Note
When all desired IP Phones have been automatically assigned, be sure to save the
configuration.
Automated Phone Setup
This topic describes how to use the setup utility to perform an automated IP Phone setup in a
Cisco CallManager Express system.
Overview of Automated Setup

Is simple to configure
Has a question-and-answer interface
Is designed for inexperienced administrators
Creates IOS commands in the background
Automates deployment
Must be no preexisting telephony service
configuration
IPTX v2.02-16
Automated setup is designed for the administrator who does not have a lot of experience
with Cisco IOS software and who may not feel comfortable manually configuring the
Cisco CallManager Express system. A question-and-answer interface starts the processthe
administrator only has to provide appropriate answers to the questions.
Note
Any existing configuration of the telephony service in Cisco CallManager Express must be
removed prior to starting the setup.
Running the Automated Setup Utility

Configure NTP prior to
running the setup utility.
Load the firmware files
into flash memory prior to
running the setup utility.
Enter the automated setup
mode using the telephonyservice setup command.
A question-and-answer
session starts, asking for
basic parameters.
The CTRL-C keystroke
can be used at any time to
interrupt or exit the setup
utility.
No changes are
committed until the end.
CMERouter1(config)#telephony-service setup
---Cisco IOS Telephony Services Setup --Do you want to setup DHCP service for your IP Phones? [yes/no]: y
Configuring DHCP Pool for Cisco IOS Telephony Services :
IP network for telephony-service DHCP Pool:10.90.0.0
Subnet mask for DHCP network :255.255.255.0
TFTP Server IP address (Option 150) :10.90.0.1
Default Router for DHCP Pool :10.90.0.1
Do you want to start telephony-service setup? [yes/no]: y
Configuring Cisco IOS Telephony Services :
Enter the IP source address for Cisco IOS Telephony Services :10.90.0.1
Enter the Skinny Port for Cisco IOS Telephony Services : [2000]:2000
How many IP phones do you want to configure : [0]: 10
Do you want dual-line extensions assigned to phones? [yes/no]: y
What Language do you want on IP phones :
0 English6 Dutch
1 French7 Norwegian
2 German8 Portuguese
3 Russian9 Danish
4 Spanish10 Swedish
5 Italian
[0]: 0
IPTX v2.02-17
The Cisco CallManager Express setup utility provides a question-and-answer interface that
allows you to set up an entire Cisco CallManager Express system at one time. Use the
telephony-service setup command to start the Cisco CallManager Express setup utility. If you
do not use the setup keyword, you can set up Phones one at a time using router CLI. The setup
keyword is not stored in the router NVRAM.
Note
If you attempt to use the automated setup option for a system whose telephony-service
configuration is not empty, an error message advises you to remove the existing
configuration first by using the no telephony-service command.
Prior to running the automated setup utility, configure the Cisco CallManager Express router
with Network Time Protocol (NTP) and load the appropriate firmware files into flash memory
on the Cisco CallManager Express router.
The actual configuration is created only when the entire question-and-answer dialog has been
completed. You can interrupt the process by pressing CTRL-C at any point prior to the final
question without having any configuration occur.
The first question asked by the automated setup utility deals with DHCP and whether the Cisco
CallManager Express router will be providing this service. If you enter y, you must enter the
parameters of the DHCP scope when the setup utility prompts you to do so. Entering n will
skip the configuration of DHCP. The name of the scope that is automatically created if y is
answered is ITS.
Second, the automated setup configures the telephony service. The setup utility asks if the
telephony service should be started. If you select y, when prompted to do so, the IP address
and port that Cisco CallManager Express runs on will need to be entered. The IP address that
you enter should be the address on the LAN that is local to the IP Phones. This is the address
that the Phones register with. In most cases, the port should be left to the default port of 2000.
Selecting n will stop the configuration of Cisco CallManager Express.
Third, the number of Phones to be configured must be selected. Select no more than the
licensed amount. If less than the licensed amount is selected, more ephones can be manually
added later.
Fourth, you are asked if dual lines are desired. If you select y, the Phones are configured like
PBX phones; if you select n, the Phones are configured similar to a keyswitch phone.
The fifth question deals with the language of the Phones and configures the locale that will be
displayed on the IP Phone. This includes configuration of the SCCP-dictionary.xml and
phonemodel-dictionary.xml files.
Running the Automated Setup Utility (Cont.)

When the
configuration is
committed, the
settings selected will
appear in the running
configuration.
Which Call Progress tone set do you want on IP phones :

0 United States
1 France
2 Germany
3 Russia
4 Spain
5 Italy
6 Netherlands
7 Norway
8 Portugal
9 UK
10 Denmark
11 Switzerland
12 Sweden
13 Austria
14 Canada
[0]: 0
What is the first extension number you want to configure : [0]: 9000
Do you have Direct-Inward-Dial service for all your phones? [yes/no]: y
Enter the full E.164 number for the first phone :2095559000
Do you want to forward calls to a voice message service? [yes/no]: y
Enter extension or pilot number of the voice message service:9999
Call forward No Answer Timeout : [18]: 10
Do you wish to change any of the above information? [yes/no]: n
----Setup completed config ---
IPTX v2.02-18
The next part of the automated setup configures the call progress tones on the IP Phones. The
call progress tones are the sounds a caller hears. These include the dial tone, busy signal,
ringback, and reorder signal. These call progress tones vary from country to country and should
be set according to what the users are accustomed to hearing.
To continue the automated setup, enter the first of the directory numbers that will be assigned.
The directory numbers are assigned in sequential order.
If direct inward dial (DID) needs to be set up, enter yes when prompted. DID numbers are
used when the connection to the public switched telephone network (PSTN) is able to pass the
dialed number. In order for this to happen, the connection should be the ISDN. If the
connections are Foreign Exchange Office (FXO), then a private line, automatic ringdown
(PLAR) on the analog trunk must be set up instead. This configuration must be done
manually it is not included in the automated setup. Setting up DID can be very simple,
especially if there is a relationship between the PSTN number and the internal directory number
(for example, if 209 555-9009 maps to 1009). If there is no common relationship between the
PSTN number and the internal directory number, then manual setup is required (for example, if
209 555-9009 maps to 7691).
The next question asks if calls should be forwarded to a voice message service. Assuming that
there is a voice mail system, the pilot point number must be entered. This sets forward no
answer and forward busy to the pilot point number for all Phones created. The timeout value
for forward no answer also needs to be set; 18 seconds is the default. This value is in seconds
rather than number of rings because the different ring lengths can vary by as much as 2 seconds.
The final question in the setup utility asks if any of the information that was entered needs to be
changed. If you enter y, the setup starts over. If you enter n, the changes are committed to
the running-config.
One more step is required because the configuration is not saved automatically at the end of the
automated setup. Use the copy running-config startup-config command to save your setup
configuration.
Example: Complete Automated Setup

DHCP pool created
Firmware available
to TFTP server
Flash is searched
for firmware; if
found, it will be
loaded
SEP XML files
created at bootup
and loaded to RAM
Firmware is
searched for MOH;
if found, this entry
is made
DID configuration
Firmware is
searched; if MOH is
found this entry is
made
Selected number of
ephone-dns are
configured

- -
- -
-

-

---

--
- -

-

-
-
IPTX v2.02-19
This figure shows the results of an automated setup. Note that the automated setup assumes that
there is only one ephone-dn per ephone.
Note
ITS was the original name of Cisco CallManager Express and still appears in some
configurations.
Optional Parameters
This topic identifies optional IP Phone parameters.
Locale Parameters
Language of Phone
display
Locale for call
progress tones and
cadences
Danish
Italian
Spanish
Swedish
Dutch
Norwegian
French
Portuguese
English
German
Russian
Japanese
IPTX v2.02-20
The Cisco CallManager Express system can be customized to some degree with the local
language on the IP Phone, call progress indicators, and cadence. This customization allows
users to hear and interact with the system using the language and audible cues that are familiar
to them.
The format in which the Phone displays the date and time can be modified to the format that is
typical for the location of the installation.
Router Configuration for Locale Parameters
Specifies the language to be displayed on an

IP Phone
-
Specifies the set of call progress tones and

cadences on the IP Phone
IPTX v2.02-21
On the Cisco IP Phone 7940G and the Cisco IP Phone 7960G, the language that is displayed
and the call progress tones and cadences can be set to one of several ISO-3166 codes that
indicate specific languages and geographic regions.
Note
The 7920 IP Phone supports English, French, German, and Spanish, and this setting is
made on the handset. The user-locale and network-locale commands have no effect on
the 7920 IP Phone.
To see which language codes are supported by the user-locale command on your device, enter
the following command:
CMERouter(config-telephony)#user-locale ?
The following is a list of typical language codes supported:
DE Germany
DK Denmark
ES Spain
FR France
IT Italy
NL Netherlands
NO Norway
PT Portugal
RU Russian Federation
SE Sweden
US United States
JA Japan
To see which language codes are supported by the network-locale command on your device,
enter the following command:
CMERouter(config-telephony)#network-locale ?
The following is a list of typical language codes supported:
AT Austria
CA Canada
CH Switzerland
DE Germany
DK Denmark
ES Spain
FR France
GB United Kingdom
IT Italy
JA Japan
NL Netherlands
NO Norway
PT Portugal
RU Russian Federation
SE Sweden
US United States
Note
Changes to the language or call progress tones require that the Cisco IP Phone be reset.
Date and Time Parameters
Sets the date format for IP Phone displays

-
Selects a 12-hour or 24-hour clock for IP Phone

displays
IPTX v2.02-22
On the Cisco IP Phone 7940G and the Cisco IP Phone 7960G, the date and time format can be
set on a systemwide basis for all IP Phones.
To see which date formats are supported on your device, enter the following command:
CMERouter(config-telephony)#date-format ?
The following is a list of typical date formats supported:
dd-mm-yy Sets date to dd-mm-yy format
mm-dd-yy Sets date to mm-dd-yy format
yy-dd-mm Sets date to yy-dd-mm format
yy-mm-dd Sets date to yy-mm-dd format
To see which time formats are supported on your device, enter the following command:
CMERouter(config-telephony)#time-format ?
The following is a list of typical time formats supported:
12 Sets time to 12-hour (a.m./p.m.) format
24 Sets time to 24-hour format
Rebooting Cisco CallManager Express Phones

This topic discusses rebooting IP Phones.
Rebooting with the reset and restart

Commands
reset Command
restart Command
Hard reboot
Soft reboot
Phone firmware changes
Phone button changes
User locale changes
Phone line changes
Network locale changes
Speed dial number

changes
URL parameter changes

DHCP and TFTP invoked
More time-consuming
than restart
System message changes

DHCP and TFTP not
invoked
IPTX v2.02-23
After you update information for one or more Phones associated with a Cisco CallManager
Express router, the Phone or Phones must be rebooted. There are two commands for rebooting:
reset and restart. The reset command performs a hard reboot that is similar to a power-off,
power-on sequence. It reboots the Phone and contacts the DHCP server and TFTP server to
update from their information as well. The restart command performs a soft reboot by simply
rebooting the Phone without contacting the DHCP and TFTP servers. The reset command takes
significantly longer to process than the restart command when you are updating multiple
Phones, but it must be used after updating firmware, user locale, network locale, or URL
parameters. For simple button, line, or speed dial changes, you can use the restart command.
Use the reset command in ephone configuration mode to perform a complete reboot of a single
IP Phone. This command has the same effect as a reset command in telephony-service mode
that is used to reset one Phone or all Phones.
reset Command Configuration
- --
-
Resets one or all phones
Resets a specific ephone
IPTX v2.02-24
To perform a complete reboot of one or all Phones associated with a Cisco CallManager
Express router, use the reset command in telephony-service configuration mode.
When using the reset command from telephony-service mode, the default time interval
of 15 seconds is recommended for an eight- to ten-Phone office so that the Phones do not
attempt to access TFTP server resources simultaneously. This value should be increased
for larger networks.
When you use the reset sequence-all command, the router waits for one Phone to complete its
reset and reregister before starting to reset the next Phone. The delay provided by this
command prevents multiple Phones from attempting to access the TFTP server simultaneously
and therefore failing to reset properly. Each reset operation can take several minutes when you
use this command. There is a reset timeout of 4 minutes, after which the router stops waiting
for the currently registering Phone to complete registration and starts to reset the next Phone.
If the router configuration is changed so that the XML configuration files for the Phones
are modified (changes are made to user locale, network locale, or Phone firmware), then
whenever the reset all or restart all command is used, the router automatically executes
the reset sequence-all command instead. The reset sequence-all command resets the
Phones one at a time in order to prevent multiple Phones from trying to contact the TFTP
server simultaneously. This one-at-a-time sequencing can take a long time if there are many
Phones. To avoid this automatic behavior, use the reset all time-interval command or the
restart all time-interval command and set a time interval that is not equal to the 15-second
default time interval (for example, set a time interval of 14 seconds). If a reset sequence-all
command has been started in error, use the reset cancel command to interrupt and cancel the
sequence of resets.
To perform a complete reboot of a single Phone associated with a Cisco CallManager Express
router, use the reset command in ephone configuration mode.
restart Command Configuration
- --
Restarts one or all phones
Restarts the ephone
IPTX v2.02-25
The restart command causes the system to quickly perform a Phone reset in which only the
button template, lines, and speed dial numbers are updated. This command is much faster than
the reset command because the Phone does not access the DHCP or TFTP server. For updates
related to Phone firmware, user locale, network locale, or URL parameters, use the reset
command.
To restart a single Phone, use the restart command with the mac-address argument or use it in
ephone configuration mode.
Setup Troubleshooting Tips
This topic identifies IP Phone setup troubleshooting tips.
Setup Troubleshooting Overview

Verify that a correct IP address and scope options
are received on the IP Phone.
Verify that the correct files are in flash memory.
Debug the TFTP server.
Verify the Phones firmware installation.
Verify that the locale is correct.
Verify Phone setup.
Review the configuration.
IPTX v2.02-26
With the automated setup, there are many places to check if problems are encountered. Some of
the more useful places to check and tools to use include the following:
Verify IP addressing: Use the Settings button to check the configuration on the IP Phone.
Verify the files in flash memory: Check and verify that the correct firmware files are
present in flash memory.
Debug the TFTP server: Make sure the firmware and XML files are being served
correctly.
Verify the Phones firmware installation: Use the debug ephone register command to
verify which firmware is being installed.
Verify locale is correct: Use the telephony-service tftp-bindings command to view the
files being served up by the TFTP server.
Verify phone setup: Use the show ephone command to view the status of the ephones and
whether they are registered correctly.
Review configuration: Use the show running-config command to verify the ephone-dn
configuration.
Verifying IP Addressing
Use the Settings button and select Network
Configuration.
Verify that the IP address and subnet mask are
correct.
Verify that the TFTP server is the Cisco
Verify that the default gateway is correct.
IPTX v2.02-27
To verify that the DHCP server is handing out the correct information to the IP Phones, use the
Settings button, then select Network Configuration. Scroll through the settings and verify the
IP address, subnet mask, default gateway, and location of the defined TFTP server. The TFTP
server must be the Cisco CallManager Express router.
Verifying Correct Firmware Files Are in Flash

show flash Command
- -
IPTX v2.02-28
The show flash command displays the contents of flash memory. The flash memory must
contain the firmware files that are necessary for the models of IP Phones that are deployed.
Many other files may be here as well, depending on other configurations.
debug tftp events Command

--

--

--

--

--- -
- ---

--- -
- ---
Can verify if the SEP file for the Phone is found

Can verify that the correct firmware has been
downloaded
IPTX v2.02-30
The debug tftp events command enables the administrator to view output regarding files that
are served up by the TFTP server. The administrator can view files, including firmware, that
are specific to Cisco CallManager Express to see if out-of-date or unsupported files are being
used. The administrator can also view the XML files for configured IP Phones, the XML files
for new IP Phones, and locale files.
If the firmware ends with a .bin extension, then the file is unsigned. If the firmware ends with a
.sbin extension, then the file is signed. If the .sbin extension is used, the IP Phone permanently
requires signed firmware loads and cannot use unsigned firmware loads.
Verifying Phone Firmware Installation

debug ephone register
Mar 2 15:16:57.582: New Skinny socket accepted [1] (2 active)
Mar 2 15:16:57.582: sin_family 2, sin_port 49692, in_addr 10.90.0.11
Mar 2 15:16:57.582: skinny_add_socket 1 10.90.0.11 49692
Mar 2 15:16:57.766: %IPPHONE-6-REG_ALARM: 20: Name=SEP000F2470F8F8 Load=3.2(2.14) Last=Phone-Keypad
Mar 2 15:16:57.766: Skinny StationAlarmMessage on socket [1] 10.90.0.11 SEP000F2470F8F8
Mar 2 15:16:57.766: severityInformational p1=2368 [0x940] p2=184551946 [0xB000A0A]
Mar 2 15:16:57.766: 20: Name=SEP000F2470F8F8 Load=3.2(2.14) Last=Phone-Keypad
Mar 2 15:16:57.766: ephone-(1)[1] StationRegisterMessage (1/2/2) from 10.90.0.11
Mar 2 15:16:57.766: ephone-(1)[1] Register StationIdentifier DeviceName SEP000F2470F8F8
Mar 2 15:16:57.766: ephone-(1)[1] StationIdentifier Instance 1 deviceType 7
Mar 2 15:16:57.766: ephone-1[-1]:stationIpAddr 10.90.0.11
Mar 2 15:16:57.766: ephone-1[1]:phone SEP000F2470F8F8 re-associate OK on socket [1]
Mar 2 15:16:57.766: %IPPHONE-6-REGISTER: ephone-1:SEP000F2470F8F8 IP:10.90.0.11 has registered.
Mar 2 15:16:57.766: Phone 0 socket 1
Mar 2 15:16:57.766: Skinny Local IP address = 10.95.0.1 on port2000
...
Mar 2 15:16:57.766: Skinny Phone IP address = 10.90.0.11 49692
Mar 2 15:16:57.766: ephone-1[1]:Date Format M/D/Y
Mar 2 15:16:57.766: ephone-1[1][SEP000F2470F8F8]:RegisterAck sent to ephone 1: keepalive period 30
IPTX v2.02-31
Verify the correct Phone firmware installation by setting registration debugging with
the debug ephone register command. Then reset the Phones and look at the Skinny
StationAlarmMessage displayed during Phone reregistration. The Load=parameter should
appear in the display, followed by an abbreviated version name that corresponds to the correct
firmware file name.
Verifying Locale-Specific Files
- - - ---
- --- -
- --- -
- ---
- ------ - --
- ----- - --
- ----- - --
- ----- - --
- ----- - --
- --- -
- --- -
IPTX v2.02-32
Use the show telephony-service tftp-bindings command to ensure that the locale-specific
files are correct.
Verifying Cisco IP Phone Setup
-
-
- --
-

-
- --
-

IPTX v2.02-33
Enter the show ephone command to verify the Cisco IP Phone setup after the Phones have
registered with the Cisco CallManager Express router.
Verifying Cisco CallManager Express Phone

Configuration
This topic describes how to verify the Cisco CallManager Express configuration.
Verifying Cisco CallManager Express

Phone Configuration
-
-

-

---
--
- - -

-

--

IPTX v2.02-29
Use the show running-config command to verify the configuration. The primary area of
interest for Cisco CallManager Express functionality is the telephony-service section, the
TFTP configuration, the ephones, and the ephone-dns.
Summary
Summary
Cisco CallManager Express requires firmware files
to be copied to the flash memory on the router and
shared using TFTP.
There are three ways to create a Phone setup in
Cisco CallManager Express: manual, partially
automated, and automated.
After changing the configuration of an IP Phone,
you must reboot the IP Phone for the changes to
take effect.
When troubleshooting, there are many show and
debug commands available.
IPTX v2.02-34
Module Summary
Module Summary
This module defines the Cisco CallManager Express platforms,
licensing, and supported Phone models.
The network configuration and services that are required by Cisco
CallManager Express include proper switch configuration, DHCP,
and NTP.
Transcoding resources need to be configured when a mismatch in
supported codecs is encountered.
This module describes the bootupand registration processes that
occur in the IP Phone when registering to Cisco CallManager Express.
The Cisco CallManager Express system can be configured in various
ways by using ephones and ephone-dns in different ways.
This module describes the files that are needed in order to install and
manage the Cisco CallManager Express system and the forms in which
the files can be downloaded.
The Cisco CallManagerExpress system can be deployed in three ways:
automated, partially automated, and manually.
IPTX v2.02-1
References
For additional information, refer to the following resources:
Cisco Systems, Inc. Cisco CallManager Express data sheet.
http://cisco.com/en/US/products/ps5855/products_data_sheet0900aecd8016c267.html
Configuring DHCP.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt1/1
cfdhcp.htm#xtocid0.
Performing Basic System Management.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/f
cf012.htm#1001075.
Cisco CallManager Express 3.2: Setting Up a Cisco CallManager Express System .
http://cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_feature_guide_chapt
er09186a00802d253f.html.
Public Domain. NTP: The Network Time Protocol. http://ntp.org.
Cisco CallManager Express 3.2.1:Transcoding between G.729 and G.711.
http://cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_feature_guide_chapt
er09186a00802d255d.html
Cisco CallManager Express 3.2.1: Setting up Phones.
http://cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_chapter09186
a00802b8f6a.html.
Cisco Systems, Inc. Voice Software Downloads.
http://www.cisco.com/kobayashi/sw-center/sw-voice.shtml.
Module Self-Check
Q1) Which of the following are three key features of Cisco CallManager Express? (Choose
three.) (Source: Understanding Cisco CallManager Express Features and Functionality)
A) Built-in Auto Attendant with CUE
B) Interoperable with Cisco CallManager 3.3
C) Supports HTML applications on the IP Phones
D) Licensing can be upgraded to SRST
E) Reduces TCO by converging voice, video, and data onto a common network
F) GUI or CLI administration
Q2) CAC functionality is part of which Cisco CallManager Express
supported protocol?
(Source: Understanding Cisco CallManager Express Features and Functionality)
A) cRTP
B) H.323
C) SCCP
D) H.320
Q3) Which three Cisco IP Phones are supported by Cisco CallManager Express? (Choose
three.) (Source: Understanding Cisco CallManager Express Features and Functionality)
A) ATA 188
B) 7920
C) 7970G
D) 7960G
Q4) Which of the following is one of the recommendations that Cisco makes for IP
addressing deployment? (Source: Configuring Cisco CallManager Express Network
Parameters)
A) Statically apply IP addresses to IP Phones to ensure stability.
B) Apply public IP addresses to IP Phones so that they can be reached from
the PSTN.
C) Add IP Phones with DHCP as the mechanism for obtaining addressees.
D) Deploy IP Phones on the same subnet as data devices.
Q5) The most efficient way to get multiple VLANs to the router is: (Source: Configuring
Cisco CallManager Express Network Parameters)
A) by using a high-speed Layer 2 switch
B) by connecting a trunk directly between the IP Phone and the router
C) by using the configuration known as
router on a stick
D) not possible with VLANs connected to IP Phones
Q6) Set up DHCP service for IP Phones by defining a DHCP relay server if: (Source:
Configuring Cisco CallManager Express Network Parameters)
A) the Cisco CallManager Express router is a DHCP server and you need different
settings on nonIP Phones on the same subnet
B) the Cisco CallManager Express router is a DHCP server and if you can use a
single shared address pool for all your DHCP clients
C) the Cisco CallManager Express router is not a DHCP server and you want to
relay DHCP requests from IP Phones to a DHCP server on a different subnet
Q7) router(dhcp-config)#
host ip-address subnet-mask is a command that: (Source:
Configuring Cisco CallManager Express Network Parameters)
A) creates a scope of the entire subnet with the specified IP address in it
B) is followed by assigning a host with a specific MAC address defined by the
client-identifier MAC-address command
C) statically assigns an IP address to a host that would otherwise get it
dynamically
Q8) A DHCP relay server needs to be implemented: (Source: Configuring Cisco
CallManager Express Network Parameters)
A) when the DHCP server does not have a local interface on the network with the
DHCP clients
B) because the DHCP request and response process is not broadcast
C) to relay the IP Phone
s proprietary DHCP request type to the standard DHCP
request type understood by the Cisco IOS software
D) when an IP Phone, a data device, and a DHCP server all reside on the same
subnet
Q9) NTP runs over: (Source: Configuring Cisco CallManager Express Network Parameters)
A) TCP port 123
B) UDP port 123
C) TCP port 213
D) UDP port 213
Q10) During registration, IP Phones download firmware files from the router flash memory
using: (Source: Understanding the IP Phone Registration Process)
A) HTTP
B) DHCP
C) FTP
D) TFTP
Q11) The use of the type command under the ephone phone-type is required to register for:
(Source: Understanding the IP Phone Registration Process)
A) the 7914 Expansion Module
B) all valid IP Phones other than the 7914 Expansion Module
C) all ATA devices other than the 7914 Expansion Module
D) no phones or devices because the ephone can determine any of them
automatically through the Cisco CallManager Express system
Q12) What is the first step in the process of an IP Phone s obtaining its XML configuration
file and IP address? (Source: Understanding the IP Phone Registration Process)
A) The switch applies power to the line.
B) The powered device has a physical link when there is no power between the
pin that the FLP arrives on and a pin that goes back to the switch. This creates
a circuit, and the end result is that the FLP arrives back at the switch. This
never happens when the device attached is not a powered device, like a PC. As
a result, if the FLP does not make it back to the switch, no power is applied.
C) The switch sends a special tone called an FLP out the interface, and this FLP
goes to the powered device, which in this case is an IP Phone.
D) The switch applies power to the line.
Q13) An ephone-dn is created by which command that builds one virtual voice port?
(Source: Defining Ephone-dn and Ephone)
A) router(config-ephone-dn)#
ephone-dn dn-tag
B) router(config-ephone-dn)#
number dn-number
C) router(config)#
ephone-dn dn-tag
D) router(config)#
ephone-dn dn-number
Q14) The first command to create or modify an ephone is: (Source: Defining Ephone-dn and
Ephone)
A) router(config-ephone)#
ephone phone-tag
B)
ephone phone-tag from ephone subconfiguration mode
C)
ephone phone-tag from global configuration mode
Q15) Which of the following are types of ephone-dns that can be found in a Cisco
CallManager Express system? (Source: Defining Ephone-dn and Ephone)
A) single-line ephone-dn
B) primary and secondary extension on one ephone-dn
C) shared ephone-dn
D) multiple ephone-dns on one ephone
E) overlay ephone-dn
F) all of the above
Q16) Cisco CallManager Express firmware files that are copied to the flash memory on your
router are shared using which of the following two? (Choose two.) (Source: Describing
Cisco CallManager Express Files)
A) HTTP
B) TCP
C) FTP
D) TFTP
E) CDP
Q17) Which file bundle contains all the files that are needed to run the GUI web interface for
Cisco CallManager Express and Cisco Unity Express? (Source: Describing Cisco
CallManager Express Files)
A) CiscoIOSTSP.zip
B) cme-b-acd-2.0.0.0.tar
C) cme-gui-123-11XL.tar
D) xml.template
Q18) Which file bundle contains all the files that are needed to allow a third-party piece of
software to interact with the Cisco CallManager Express system through TAPI Lite?
(Source: Describing Cisco CallManager Express Files)
A) CiscoIOSTSP.zip
B) cme-b-acd-2.0.0.0.tar
C) cme-gui-123-11XL.tar
D) xml.template
Q19) A sample file for creating a customer administrator with a limited subset of
administrative privileges is: (Source: Describing Cisco CallManager Express Files)
A) music-on-hold.au
B) cme-gui-123-11XL.tar
C) xml.template
Q20) Before configuring the telephony service, the maximum number of ephone-dns and
ephones supported by the service is: (Source: Understanding Initial Phone Setup)
A) 0
B) 100
C) 288
D) unlimited
Q21) To perform an automated Phone setup in a Cisco CallManager Express system, use the
command: (Source: Understanding Initial Phone Setup)
A) router(config)#
telephony-service setup
B) router(config-telephony-service)#
telephony-service setup
C) router(config)#
auto assign start-dn to stop-dn
D) router(config-telephony-service)#
auto assign start-dn to stop-dn
Q22) Automatically assigned ephone-dn tags can belong to the following ephone-dns:
(Source: Understanding Initial Phone Setup)
A) paging ephone-dns
B) intercom ephone-dns
C) MOH ephone-dns
D) MWI ephone-dns
E) normal ephone-dns
Q23) On which phone is the language setting made on the handset rather than by using the
user-locale and network-locale IOS commands? (Source: Understanding Initial Phone
Setup)
A) Cisco IP Phone 7920
B) Cisco IP Phone 7940G
C) Cisco IP Phone 7960G
Q24) The command to perform a hard reboot, similar to a power-off, power-on sequence, is:
(Source: Understanding Initial Phone Setup)
A)
restart
B)
reset
C) either
restart or reset
Q25) To verify that the DHCP server is handing out the correct information to the IP Phones,
use the: (Source: Understanding Initial Phone Setup)
A)
show running-config command
B)
show flash command
C)
debug ephone register command
D) Settings button, then, from the menu that appears, select the Network
Configuration settings
Q26) To verify the Cisco CallManager Express configuration, use the: (Source:
Understanding Initial Phone Setup)
A)
show running-config command
B)
show flash command
C)
debug ephone register command
D) Settings button, then, from the menu that appears, select the Network
Configuration settings

Q1) A, B, D
Q2) B
Q3) B,C, D
Q4) C
Q5) C
Q6) C
Q7) B
Q8) A
Q9) B
Q10) D
Q11) A
Q12) C
Q13) C
Q14) C
Q15) F
Q16) C, D
Q17) C
Q18) A
Q19) C
Q20) A
Q21) A
Q22) E
Q23) A
Q24) B
Q25) D
Q26) A
Module 3
Configuring PSTN Interfaces

and Voice Dial Peers
Overview
Cisco voice devices must support a wide variety of connection types. This module describes the
function and basic configuration of various analog and digital voice connections. Information
on how to fine-tune voice ports with port-specific configurations is presented. Dial peers and
class of restriction (COR) are discussed. The use of digit manipulation and special-purpose
connections is covered, along with Ciscos implementation of telephony supplementary
services.
Module Objectives
Upon completing this module, you will be able to configure analog voice interfaces, digital
voice interfaces, and dial peers to set up Voice over IP (VoIP) communications.
Describe the different types of analog and digital interfaces and signaling types supported
by Cisco CallManager Express
Configure analog and digital voice interfaces and discuss voice port applications, FXS,
FXO, E&M, BRI timers and timing, digital voice ports, CAS, and CCS/PRI
Describe dial peers and configuration tasks
Describe how call legs relate to inbound and outbound dial peers by defining all the steps in
the call setup process and the proper use of digit manipulation
Describe the application and configuration of class of restriction
Describe call transfer and forwarding using H.450.x series
Lesson 1
Understanding Analog and

Digital Voice Interfaces
Overview
Interfacing Cisco CallManager Express with traditional analog telephony devices requires an
understanding of the various interfaces used in the industry. When additional port density and
features are required, a digital connection can be used. This lesson describes the various analog
and digital interfaces that can be used with Cisco CallManager Express. It also explores analog
and digital signaling between Cisco CallManager Express and the central office (CO), as well
as the various forms of connection. The choice of digital connection can vary based upon
carrier, and not all services may be available in all areas.
Objectives
Upon completing this lesson, you will be able to identify and describe the different digital
interfaces and signaling types supported by Cisco CallManager Express. This includes being
able to meet these objectives:
Identify the components of local-loop connections
Describe FXS, FXO, and E&M interfaces
State the uses and types of CAS systems that are used for T1
State the uses and types of CAS systems that are used for E1
State the uses and types of common channel signaling systems
Describe what PRI and BRI are and how they can be used
This topic describes the parts of a traditional telephony local-loop connection between a
telephone subscriber and the telephone company.
IPTX v2.03-3
A subscriber home telephone connects to the telephone company CO via an electrical

communication path called a local loop, as depicted in the figure. The loop consists of a pair of
twisted wiresone is the tip wire, and the other is the ring wire.
In most arrangements, the ring wire ties to the negative side of a power source, the battery, and
the tip wire connects to the ground. This pair of wires, which represents the local loop, along
with all the other pairs in your neighborhood, connects to the CO in a cable bundle that is either
buried underground or strung on poles. When the analog phone or fax goes into the off-hook
state, an electrical circuit is completed and current flows through the loop. This signals the
switch that the analog phone or fax is off hook. The switch then uses a dial tone generator to
send a signal the dial tone that the switch is ready to receive digits.
Analog Voice Interfaces
This topic defines the three analog interfaces that can be installed in a voice gateway: Foreign
Exchange Station (FXS), Foreign Exchange Office (FXO), and ear and mouth (E&M). It also
discusses how each of these interfaces is used.
FXS Interface
FXS
FXS
FXS
Connects directly to analog phones or faxes
Used to provision local service
Provides power, call progress tones, and dial tone
IPTX v2.03-4
When analog phones or fax machines are used in an IP-based environment, they must have a
connection into this IP network. This connection takes the form of an FXS interface. The FXS
interface provides a direct connection to an analog telephone, a fax machine, or a similar
device. From the analog devices perspective, the FXS interface functions like a switch.
Therefore, it must supply line power, ring voltage, and dial tone.
The FXS interface contains the coder-decoder (codec), which converts the spoken analog voice
wave into a digital format for processing by the voice-enabled device.
Note
Analog phones plugged into an FXS port on the Cisco CallManager Express router cannot
be forwarded to Cisco Unity Express voice mail. If voice mail is needed on the analog
phones, use the Cisco 186 Analog Telephone Adaptor (ATA) or the Cisco 188 ATA to
connect the analog phone to the network.
Copyright 2005, Cisco Systems, Inc. Configuring PSTN Interfaces and Voice Dial Peers 3-5
FXO Interface
FXO
PSTN
FXO
Connects directly to office equipment

Used to make and receive calls from the PSTN
Can be used to connect through the PSTN to
another site
Answers inbound calls
IPTX v2.03-5
In order for standard analog connections from the CO to enter the IP network, they must be
terminated on an interface on a voice gateway. An FXO interface can be used for this. When a
call arrives, the FXO interface answers the call and either presents a second dial tone or is
configured with a private line, automatic ringdown (PLAR). For outbound calls, the FXO
interface provides either pulse digits or dual tone multifrequency (DTMF) digits for outbound
dialing.
E&M Interface
E&M
E&M
Tie-Line
E&M
MOH
Connects two sites together with a leased connection

Allows for the use of non-PSTN numbers
Used to create tie-lines
Commonly used to connect to external Music on Hold
sources
IPTX v2.03-6
Special analog connections called tie-lines can be leased from the carrier. These are typically
used to tie together two or mores sites that have analog connections. This tie-line terminates in
an analog interface on the router so that the analog communication can enter the IP network.
The E&M interface on the router is where these tie-lines can be terminated. E&M signaling is
also referred to as recEive and transMit; it comes from the term earth and magneto. Earth
represents the electrical ground, and magneto represents the electromagnet used to generate
tone.
E&M signaling defines a trunk-circuit side and a signaling-unit side for each connection,
similar to the DCE and DTE reference types. The router is usually the trunk-circuit side, and
the telephone company (telco), a CO, a channel bank, or a Cisco voice-enabled platform is the
signaling-unit side.
Note
Many Music on Hold services provide an analog E&M interface that can be used to connect
to the Cisco CallManager Express router.
Channel Associated Signaling Systems: T1
This topic describes channel associated signaling (CAS) and its uses with T1 transmission.
Channel Associated Signaling Systems
IPTX v2.03-7
Because the signaling occurs within each DS0, it is referred to as in-band. And because the use
of these bits is reserved exclusively for signaling each respective voice channel, it is referred to
as CAS.
Super Frame (SF) has a 12-frame structure and provides A&B bit signaling. Extended
Superframe (ESF) has a 24-frame structure and provides ABCD signaling.
Tones, such as DTMF addressing or call progress, can be carried in the audio path. However,
other CAS signals must be carried via the robbed bits. These robbed bits are the least
significant bits in the audio channel.
Characteristics of a CAS T1
CAS T1
PSTN
Up to 24 channels for voice

Each channel is a DS0
8000 samples per second
1 byte per sample
Partial T1 may be available
Signaling travels in-band
IPTX v2.03-8
Cisco CallManager Express can be connected to the public switched telephone network (PSTN)
through a CAS T1 connection. This provides up to 24 channels for voice. Each channel is a 64kbps DS0.
Channel Associated Signaling Systems: E1

This topic describes the uses of CAS with E1 transmission.
Channel Associated Signaling Systems: E1
IPTX v2.03-9
In E1 framing and signaling, 30 of the 32 available channels, or time slots, are used for voice or
data. Framing information uses time slot 1 (channel 0), whereas time slot 17 (channel 16) is
used for signaling by all the other time slots. This signaling format is also known as CAS
because each bearer channel has specific bits in the 17th time slot that are assigned for
signaling. However, this implementation of CAS is considered out-of-band because the
signaling bits are not carried within the voice channel, as is the case with T1.
Note
Robbed bit signaling is not used in E1 circuits.
Characteristics of a CAS E1
CAS E1
PSTN
Up to 30 channels for voice

Each channel is a DS0
1 byte per sample
Partial E1 may be available
Signaling is carried out-of-band
IPTX v2.03-10
Cisco CallManager Express can be connected to the PSTN and can provide up to 30 channels
for voice.
Common-Channel Signaling Systems

This topic describes common-channel signaling (CCS) systems.
Common-Channel Signaling
IPTX v2.03-11
Whereas CAS uses bit time slots assigned to each specific channel, CCS uses a common
channel and protocol to set up calls for all the bearer channels. For example, when using ISDN
over E1, the signaling protocol Q.931 uses time slot 17 to exchange call-setup messages for any
of the 30 bearer (B) channels.
Examples of CCS are as follows:
Proprietary implementations: Some PBX vendors choose to implement a proprietary
CCS protocol between their PBXs for T1 and E1. In this implementation, Cisco devices are
configured for Transparent Common Channel Signaling (T-CCS) because they do not
understand proprietary signaling information and must simply transport the signaling,
without modification or interpretation.
ISDN: Uses Q.931 signaling protocol in a common channel to signal all other channels.
Digital Private Network Signaling System (DPNSS): An open standard developed by
British Telecom for implementation by any vendor who chooses to use it. DPNSS also uses
a common channel to signal all other channels.
Q Signaling (QSIG): Like ISDN, QSIG uses a common channel to signal all other
channels.
PRI and BRI
This topic describes PRI and BRI and how they can be used to support voice.
ISDN PRI and BRI

Carrier
PRI 23B+D
Carrier
BRI 2B+D
Allows for a multiple services through one connection

Well-adapted for voice
64-kbps channels
Q.931 on the D channel
Supports standards-based functions
Supports proprietary implementations
International utilization
IPTX v2.03-12
ISDN is one form of CCS. PRI and BRI are the two ways of implementing ISDN.
Note
Because ISDN is a digital service, the time required to set up a call is significantly less than
that of an analog call.
PRI supports 23 (for T1) or 30 (for E1) B channels, whereas BRI features two B channels. Each
implementation also supports a single data (D) channel that is used to carry signaling
information.
The following are characteristics of ISDN PRI and BRI:
ISDN channels can carry data, voice, or video.
Each B channel is 64 kbps, and G.711 pulse code modulation (PCM) requires 64 kbps, so
this is a perfect match for voice applications.
The D channel in BRI is 16 kbps and in PRI is 64 kbps.
ISDN has a built-in call-control protocol known as International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) Q.931 that runs on the D channel.
ISDN can support standards-based voice features, such as call forwarding, and standardsbased enhanced dialup capabilities, such as Group IV fax and audio channels.
ISDN can carry vendor-specific PBX features.
ISDN BRI voice is commonly used in Europe; ISDN PRI voice is used worldwide.
Summary
Summary
Analog interfaces can be used to connect analog
devices and to connect to the PSTN.
Cisco CallManager Express can use T1 circuits to
convey voice.
Cisco CallManager Express can use E1 circuits to
convey voice.
Examples of CCS are proprietary implementations,
ISDN, DPNSS, and QSIG.
ISDN can be implemented in two different ways:
BRI and PRI.
IPTX v2.03-13
Lesson 2
Configuring Analog and Digital

Voice Interfaces
Overview
The connections to analog devicesthe PSTN and WAN links between sitesmay take either
an analog or a digital form. The analog interfaces that are commonly found include the FXS,
the FXO, and the E&M interfaces. The FXS is used to connect analog devices like phones and
fax machines. The FXO interfaces are typically used for traditional analog connections to the
PSTN. E&M analog connections are typically used for connections to the PSTN and may be
used for analog tie-line connections to another site or to connect a Music on Hold (MOH)
system.
The digital connections include both CAS and CCS digital connections. The CAS connection
has signaling in-band. This means that the voice and the signaling travel together on the same
circuit. CCS links use out-of-band signaling. The most common form of CCS is the ISDN
services. There are two main offerings in ISDN: BRI and PRI.
To connect to an ISDN network, you must use the correct router interface. BRI requires
specific commands to enable ISDN. ISDN BRI is typically used for remote access at small
branch sites with lower bandwidth requirements. PRI is typically used by larger central sites
with higher bandwidth requirements to aggregate multiple BRIs. Internet service providers also
use ISDN PRI to support large numbers of plain old telephone service (POTS) (analog modem)
and ISDN BRI calls.
Objectives
Upon completing this lesson, you will be able to configure analog and digital voice interfaces.
This discussion includes voice port applications, FXS, FXO, E&M, BRI timers and timing,
digital voice ports, CAS, CCS: BRI, and CCS: PRI. This includes being able to meet these
objectives:
Set the configuration parameters for FXS voice ports
Set the configuration parameters for FXO voice ports
Set the configuration parameters for E&M voice ports
Set timers and timing requirements on ports to adjust the time allowed for specific
functions
Set the configuration parameters for digital voice ports
Set the configuration parameters for CAS voice ports
Set the configuration for BRI voice ports
Set the configuration parameters for PRI voice ports
Foreign Exchange Station Port Configuration
FXS ports connect analog edge devices. This topic identifies the parameters that are
configurable on the FXS port.
FXS Voice Port Configuration Parameters
signal
cptone
description
ring frequency
ring cadence
disconnect-ack
busyout
station id name
station id number
IPTX v2.03-3
In North America, the FXS port connection functions with default settings most of the time.
The same cannot be said for other countries and continents. Remember, FXS ports look like
switches to the edge devices that are connected to them. Therefore, the configuration of the
FXS port should emulate the switch configuration of the local PSTN.
For example, consider the scenario of an international company with offices in the United
States and England. The PSTN of each country provides signaling that is standard for that
country. In the United States, the PSTN provides a dial tone that is different from the tone in
England. And when the telephone rings to signal an incoming call, the ring in the United States
is different from the ring in England. Another instance when the default configuration might be
changed is when the connection is a trunk to a PBX or key system. In that case, the FXS port
must be configured to match the settings of that device.
Configuration Parameters
FXS port configuration allows you to set parameters based on the requirements of the
connection if default settings need to be altered or the parameters need to be set for fine-tuning.
You can set the following configuration parameters:
signal: Sets the signaling type for the FXS port. In most cases, the default signaling of loop
start works well. If the connected device is a PBX or a key system, the preferred signaling
is ground start. Modern PBXs and key systems do not normally use FXS ports as
connections to the network, but older systems may still have these interfaces. When
connecting the FXS port to a PBX or key system, you must check the configuration of the
voice system and set the FXS port to match the system setting.
cptone: Configures the appropriate call-progress tone for the local region. The callprogress tone setting determines the dial tone, busy tone, and ringback tone to the
originating party.
description: Configures a description for the voice port. You must use the description
setting to describe the voice port in show command output. It is always useful to provide
some information about the usage of a port. The description can specify the type of
equipment that is connected to the FXS port.
ring frequency: Configures a specific ring frequency (in Hz) for an FXS voice port. You
must select the ring frequency that matches the connected equipment. If set incorrectly, the
attached telephone might not ring or might buzz. In addition, the ring frequency is usually
country-specific. You should take into account the appropriate ring frequency for your area
before you configure this command.
ring cadence: Configures the ring cadence for an FXS port. The ring cadence defines how
ringing voltage is sent to signal a call. The normal ring cadence in North America is
2 seconds of ringing followed by 4 seconds of silence. In England, normal ring cadence is a
short ring followed by a longer ring. When configured, the cptone setting automatically
sets the ring cadence to match that country. You can manually set the ring cadence if you
want to override the default country value. You may have to shut down and reactivate the
voice port before the configured value takes effect.
disconnect-ack: Configures an FXS voice port to remove line power if the equipment on
an FXS loop-start trunk disconnects first. This removal of line power is not something the
user hears. Instead, it is a method for electrical devices to signal that one side has ended the
call.
busyout: Configures the ability to busy out an analog port.
station id name: Provides the station name associated with the voice port. This parameter
is passed as a calling name to the remote end if the call is originated from this voice port. If
no caller ID is received on an FXO voice port, this parameter will be used as the calling
name. Maximum string length is limited to 15.
station id number: Provides the station number that is to be used as the calling number
associated with the voice port. This parameter is optional. When it is provided, it is used as
the calling number if the call is originated from this voice port. If not specified, the calling
number is used from a reverse dial-peer search. If no caller ID is received on an FXO voice
port, this parameter is used as the calling number. Maximum string length is 15.
Example: FXS Voice Port Configuration

FXS Port
1/0/0
FXS Port
1/0/1

- -

- -

IPTX v2.03-4
Example
Revisit the scenario of an international company with offices in the United States and England.
The figure shows how the British office is configured to enable ground-start signaling on a
Cisco 2600 or 3600 series router on FSX voice port 1/0/0. The call-progress tones are set for
England and the ring cadence is set for pattern 1.
Foreign Exchange Office Port Configuration
FXO ports act like telephones and connect to CO switches or to a station port on a PBX. This
topic identifies the configuration parameters that are specific to FXO ports.
FXO Voice Port Configuration Parameters

signal
ring number
dial-type
description
supervisory disconnect
IPTX v2.03-5
In most instances, the FXO port connection functions with default settings. FXO port
configuration allows you to set parameters based on the requirements of the connection when
default settings need to be altered or parameters set for fine-tuning. You can set the following
configuration parameters:
signal: Sets the signaling type for the FXO port. If the FXO port is connected to the PSTN,
the default settings are adequate. If the FXO port is connected to a PBX, the signal setting
must match the PBX.
ring number: Configures the number of rings before an FXO port answers a call. This is
useful when you have other equipment available on the line to answer incoming calls. The
FXO port answers if the other equipment does not answer the incoming call within the
configured number of rings.
dial-type: Configures the appropriate dial type for outbound dialing. Older PBXs or key
sets may not support DTMF dialing. If you are connecting an FXO port to this type of
device, you may need to set the dial type for pulse-dialing.
description: Configures a description for the voice port. Use the description setting to
describe the voice port in show command output.
supervisory disconnect: Configures supervisory disconnect signaling on the FXO port.

Supervisory disconnect signaling is a power denial from the switch that lasts at least
350 ms. When this condition is detected, the system interprets it as a disconnect indication
from the switch and clears the call. You should disable supervisory disconnect on the voice
port if there is no supervisory disconnect available from the switch. Typically, supervisory
disconnect is available when connecting to the PSTN and is enabled by default. When the
connection extends out to a PBX, you should verify the documentation to ensure that
supervisory disconnect is supported.
Example: FXO Voice Port Configuration

FX0 Port
1/1/0
PSTN

- -

-
IPTX v2.03-6
Example
The configuration in the figure enables loop-start signaling on a Cisco 2600 or 3600 series
router on FXO voice port 1/1/0. The ring-number setting of 3 specifies that the FXO port does
not answer the call until after the third ring. The dial type is set to DTMF.
Ear and Mouth Port Configuration
E&M ports provide signaling that is generally used for switch-to-switch or switch-to-network
trunk connections. This topic identifies the configuration parameters that are specific to the
E&M port.
E&M Voice Port Configuration Parameters

signal
operation
type
auto-cut-through
description
IPTX v2.03-7
Although E&M ports have default parameters, you must usually configure these parameters to
match the device that is connected to the E&M port. You can set the following configuration
parameters:
signal: Configures the signal type for E&M ports and defines the signaling that is used
when notifying a port to send dialed digits. This setting must match that of the PBX to
which the port is connected. You must shut down and reactivate the voice port before the
configured value takes effect. With wink-start signaling, the router listens on the M-lead to
determine when the PBX wants to place a call. When the router detects current on the Mlead, it waits for availability of digit registers, then provides a short wink on the E-lead to
signal the PBX to start sending digits. With delay-start, the router provides current on the
E-lead immediately upon seeing current on the M-lead. When current is stopped for the
duration of the digit sending, the E-lead stays high until digit registers are available. With
immediate-start, the PBX simply waits a short time after raising the M-lead, then sends the
digits without a signal from the router.
operation: Configures the cabling scheme for E&M ports. The operation command affects
the voice path only. The signaling path is independent of two-wire versus four-wire
settings. If the wrong cable scheme is specified, the user may get voice traffic in one
direction only. You must match the settings of the device on the other end of the line. You
must then shut down and reactivate the voice port for the new value to take effect.
type: Configures the E&M interface type for a specific voice port. The type defines the
electrical characteristics for the E-lead and the M-lead. The E-lead and the M-lead are
monitored for on-hook and off-hook conditions. From a PBX perspective, when the PBX
attempts to place a call, it goes high (off hook) on the M-lead. The switch monitors the Mlead and recognizes the request for service. If the switch attempts to pass a call to the PBX,
the switch goes high on the E-lead. The PBX monitors the E-lead and recognizes the
request for service by the switch. To ensure that the settings match, you must verify them
with the PBX configuration.
auto-cut-through: Configures the ability to enable call completion when a PBX does not
provide an M-lead response. For example, when the router is placing a call to the PBX,
even though they may have the same correct signaling configured, not all PBXs provide the
wink with the same duration or voltage. The router may not understand the PBX wink. The
auto-cut-through command allows the router to send digits to the PBX, even when the
expected wink is not detected.
description: Configures a description for the voice port. Use the description setting to
describe the voice port in show command output.
Example: E&M Voice Port Configuration

E&M Port
1/1/0
MOH

-
IPTX v2.03-8
Example
The configuration in the figure enables immediate signaling with automatic cut-through for an
E&M connection to an MOH device. This allows an external device to provide music on hold
to the Cisco CallManager Express system. The type setting matches the E&M port setting on
the MOH device as well as the number of wires used by the operation command.
Timers and Timing
This topic identifies the timing requirements and adjustments that are applicable to voice
interfaces. Under normal use, these timers do not need adjusting. When ports are connected to a
device that does not properly respond to dialed digits or hookflash or when the connected
device provides automated dialing, these timers can be configured to allow more or less time
for a specific function.
Timers and Timing Configuration

Parameters
timeouts initial
timeouts interdigit
timeouts ringing
timing digit
timing interdigit
timing hookflash-in/hookflash-out
IPTX v2.03-9
You can set a number of timers and timing parameters to fine-tune the voice port. Following
are voice port configuration parameters that you can set:
timeouts initial: Configures the initial digit timeout value in seconds. This value controls
how long the dial tone is presented before the first digit is expected. This timer typically
does not need to be changed.
timeouts interdigit: Configures the number of seconds that the system waits for the next
digit after the caller has input the initial digit. If the digits are coming from an automated
device and the dial plan is a variable length dial plan, you can shorten this timer so that the
call proceeds without having to wait the full default of 10 seconds for the interdigit timer to
expire.
timeouts ringing: Configures the length of time that a caller can continue ringing a
telephone when there is no answer. You can configure this setting to be less than the
default of 180 seconds so that you do not tie up the voice port when it is evident that the
call is not going to be answered.
timing digit: Configures the DTMF digit-signal duration for a specified voice port. You
can use this setting to fine-tune a connection to a device that may have trouble recognizing
dialed digits. If a user or device dials too quickly, the digit may not be recognized. By
changing the timing on the digit timer, you can provide a shorter or longer DTMF duration.
timing interdigit: Configures the DTMF interdigit duration for a specified voice port. You
can change this setting to accommodate faster or slower dialing characteristics.
timing hookflash-in and hookflash-out: Configures the maximum duration (in
milliseconds) of a hookflash indication. Hookflash is an indication by a caller that the caller
wishes to do something specific with the call, such as transfer the call or place the call on
hold. For hookflash-in, the FXS interface processes the indication as on hook if the
hookflash lasts longer than the specified limit. If you set the value too low, the hookflash
may be interpreted as a hang-up. If you set the value too high, the handset has to be left
hung up for a longer period to clear the call. For hookflash-out, the setting specifies the
duration (in milliseconds) of the hookflash indication that the gateway generates outbound.
You can configure this to match the requirements of the connected device.
Example: Timers and Timing Configuration

FXS Port
1/0/0

- -

-
-
-
-
IPTX v2.03-10
Example
The installation in the figure is for a facility for elderly residents. Users in such a facility may
need more time to dial digits than is typical. They may also want the telephone to ring
unanswered for only two minutes. The configuration in the figure enables several timing
parameters on a Cisco voice-enabled router voice port 1/0/0. The initial timeout is lengthened
to 15 seconds, the interdigit timeout is lengthened to 15 seconds, and the hookflash-in timer is
set to 500 ms.
Digital Voice Port Configuration
This topic identifies the configuration parameters that are specific to T1 and E1 digital
voice ports.
Basic T1/E1 Controller Configuration
IPTX v2.03-11
When you purchase a T1 or E1 connection, make sure that your service provider gives you the
appropriate settings. Before you configure a T1 or E1 controller to support digital voice ports,
you must enter the following basic configuration parameters to bring up the interface.
framing: Selects the frame type for a T1 or E1 data line. The framing configuration differs
between T1 and E1.
Options for T1: SF or ESF
Options for E1: cyclic redundancy check 4 (CRC4), no-CRC4, or Australia
Default for T1: SF
Default for E1: CRC4
linecode: Configures the line-encoding format for the DS1 link.
Options for T1: alternate mark inversion (AMI) or binary 8-zero substitution
(B8ZS)
Options for E1: AMI or high density binary 3 (HDB3)
Default for T1: AMI
Default for E1: HDB3
clock source: Configures clocking for individual T1 or E1 links.
Options: line or internal
Default: line

(Cont.)
Configures the line code for a T1 line
Configures the line code for an E1 line
IPTX v2.03-12
Use the linecode command to identify the physical layer signaling method to satisfy the 1s
density requirement on the digital facility of the provider. Without a sufficient number of 1s in
the digital bit stream, the switches and multiplexers in a WAN can lose their synchronization
for transmitting signals. The table shows the linecode command.
linecode Command
Command
Description
ami
Alternate mark inversion; used for T1 configurations
b8zs
Binary 8-zero substitution; used for T1 PRI configurations
hdb3
High density binary 3, used for E1 PRI configurations
B8ZS accommodates the 1s density requirements for T1 carrier facilities using special binary
signals encoded over the digital transmission link. It allows 64 kbps (clear channel) for ISDN
channels.
Settings for these two Cisco IOS software controller commands on the router must match the
framing and line-code types used at the T1/E1 WAN CO switch of the provider.
T1 configurations typically require the framing esf command and the linecode b8zs command.
E1 configurations typically require the linecode hdb3 command.

(Cont.)
- -
Configures the framing for a T1 line
Configures the framing for an E1 line
IPTX v2.03-13
Use the framing command to select the frame type used by the PRI service provider. The table
shows framing controller configuration commands that you can use.
framing Command
Command
Description
sf
Super Frame; used for some older T1 configurations
esf
Extended Superframe; used for T1 PRI configurations
crc4 or no-crc4
Cyclic redundancy check 4; used for E1 PRI

configurations
Note
ESF and CRC4 are most common in new T1s or E1s.
Channel Associated Signaling Configuration

This topic describes the commands required to configure a CAS interface.

(Cont.)
- - -- --
-
- -
- - -- -
-
Creates the voice ports of the T1 or E1 and the

signaling that is used
Sets the source of the clocking

IPTX v2.03-14
You must create a digital voice port in the T1 or E1 controller to make the digital voice port
available for specific voice port configuration parameters. You must also assign time slots and
signaling to the logical voice port through configuration. The first step is to create the T1 or E1
digital voice port with the ds0-group ds0-group-no timeslots timeslot-list type signal-type
command.
The ds0-group part of the command automatically creates a logical voice port that is numbered
as ds0-group-no. The dS0-group-no parameter identifies the DS0 group (numbered from 0 to
23 for T1 and from 0 to 30 for E1). This group number is used as part of the logical voice port
numbering scheme.
The timeslots part of the command allows the user to specify which time slots are parts of the
DS0 group. The timeslot-list parameter is a single time-slot number, a single range of numbers,
or multiple ranges of numbers separated by commas.
The type part of the command defines the emulated analog signaling method that the router
uses to connect to the PBX or PSTN. The type depends on whether the interface is T1 or E1.
To delete a DS0 group, you must first shut down the logical voice port. When the port is in
shutdown state, you can remove the DS0 group from the T1 or E1 controller with the no ds0group ds0-group-no command.
Use the clock source {line | internal}command to configure the T1 and E1 clock source on
Cisco routers.
Example: Basic T1/E1 Controller

Configuration
T1 1/0
PSTN

-
- -- -
-

- -- -
-
IPTX v2.03-15
This example configures the T1 controller for ESF, B8ZS line code, and time slots 1 through 24
with FXO ground-start signaling. The resulting logical voice port is 1/0:1, where 1/0 is the
module and slot number and :1 is the ds0-group-no value that was assigned during
configuration.
The E1 configuration uses a line code of HDB3, framing of CRC4, and time slots of 1 through
15 with E&M wink-start signaling. The resulting logical voice port is 1/0:1, where 1/0 is the
module and slot number and:1 is the ds0-group-no value that was assigned during the
configuration.
Common-Channel Signaling: BRI
This topic identifies the most common components and reference points of ISDN BRI, and it
provides an overview of configuration commands required to successfully configure an ISDN
BRI connection, including an overview of the isdn spid command. And finally, because you
may have to configure the Layer 2 B channel encapsulation protocol and authentication when
configuring ISDN BRI, this topic shows you how to do that.
BRI Reference Points
IPTX v2.03-16
There are many ISDN interface abbreviations, such as T, S, U, S/T, and so on. What do all of
these components and reference points look like in practice?
When creating a network, connect the Network Termination 1 (NT-1) to the wall jack with a
standard two-wire connector, then to the ISDN phone, terminal adapter, Cisco ISDN router, and
maybe a fax with a four-wire connector. The S/T interface is implemented using an eight-wire
connector (two pairs for data transmission and two pairs for providing optional power to the
network terminal [NT] and the terminal endpoint [TE]).
Caution should be taken when connecting ISDN devices, since RJ-11 and RJ-45 connectors
look similar.
The S/T reference point is:
Four-wire interface
Point-to-point and multipoint (passive bus), as shown in the figure
Covered by ITU-T I.430 physical layer specification for BRI interface, and American
National Standards Institute (ANSI) T1.601 standard for the United States
The S/T interface defines the interface between a TE1 or a terminal adapter and a network
terminal. A maximum of eight devices can be daisy-chained to the S/T bus.
The U interface defines the two-wire interface between the NT-1 and the ISDN cloud. The U
interface is used in the United States; the rest of the world uses an S/T interface.
The R interface defines the interface between the terminal adapter and an attached non-ISDN
device (TE2).
In North America, the NT-1 function is commonly integrated into the ISDN device (router,
terminal adapter), thus permitting a direct connection from the ISDN device to the telco jack.
An NT-1 and NT-2 combination device is sometimes referred to as an NTU. In most countries,
the NT-1/NT-2 combination is provided by the service provider (telco), and customer access is
only available at the S/T interface.
ISDN Configuration Tasks

ISDN PRI or BRI
PSTN
Select the ISDN switch type either globally or on an

interface.
The interface setting overrides the global setting.
Configure the interface or controller settings.
IPTX v2.03-17
To configure an ISDN BRI interface on a router, global and interface configuration commands
must be specified.
Global configuration tasks include:
Select the switch type that matches the ISDN provider switch at the CO.
Set destination details. Indicate static routes from the router to other ISDN
destinations.
Specify the traffic criteria that initiate an ISDN call to the appropriate destination.
Interface configuration tasks include the following:
Select the ISDN BRI port and configure an IP address and subnet mask.
Although the interface automatically inherits the global switch-type setting, some
configurations may require a specific switch type to be configured on an interface.
Configure optional features, including length of time for the ISDN carrier to wait
before responding to the call and seconds of idle time before the router times out and
drops the call.
ISDN BRI Configuration Commands
- - -
Sets the ISDN switch type globally
Defines a SPID if assigned by the carrier

(found in North America)
- - -
Sets the ISDN switch type on an interface

(overrides the global setting if it exists)
IPTX v2.03-18
At the global level, the administrator must specify the ISDN service provider CO switch type.
There are several types of switches to choose from, and some of these require special
parameters. Standards signaling specifics differ by region. Therefore, the switch type varies
according to its geographical location. For example, the DMS-100 and National ISDN-1
require a service profile identifier (SPID) to be specified. This is optional on some switches (for
example, AT&T 5ESS) or not required at all.
The interface bri interface-number command designates the interface used for ISDN on a
router acting as a TE1 device.
A router without a native BRI interface is a TE2 device. It must connect to an external ISDN
terminal adapter via a serial interface. On a TE2 router, the interface serial interface-number
command must be used.
Use the isdn switch-type command to specify the CO switch to which the router connects. For
BRI ISDN service, the possible switch types and their corresponding commands are shown in
this table.
isdn switch-type Commands
Command
Description
basic-5ess
AT&T basic rate switches (United States)
basic-dms100
NT DMS-100 (North America)
basic-ni
National ISDN-1 (North America)
basic-qsig
PINX (PBX) switches with QSIG signaling per Q.931
basic-net3
NET3 switch type for United Kingdom, Europe, Asia, and Australia
none
No switch defined
Note
Other switch types are available. The list of switch types can differ based on the Cisco IOS
software version used.
When the isdn switch-type command is used in global configuration mode, all ISDN interfaces
on the router are configured for that switch type. Beginning with IOS Release 11.3T, the
interface configuration mode command was introduced to allow different interfaces to be
configured with different switch types. If the command is used in interface configuration mode,
only the interface that is configured assumes that switch type. The interface setting always
overrides the global setting.
ISDN BRI Configuration Commands (Cont.)
- - -
Defines SPID 1 if assigned by the carrier (found in

North America)
- - -
Defines SPID 2 if assigned by the carrier (found in

North America)
IPTX v2.03-19
Several ISDN service providers use CO switches that require SPIDs. SPIDs are used to
authenticate call requests that are within contract specifications. These switches include
National ISDN and DMS-100 ISDN switches, as well as the AT&T 5ESS multipoint switch.
SPIDs are used only in the United States and are typically not required for ISDN data
communications applications. The service provider supplies the local SPID numbers. If
uncertain, contact the service provider to determine if SPIDs need to be configured on your
access routers.
Use the isdn spid1 and isdn spid2 commands to access the ISDN network when your router
makes its call to the local ISDN exchange.
The table shows the isdn spid1 command syntax for the first BRI 64-kbps channel.
isdn spid1 and isdn spid2 Commands
Commands
Description
spid-number
Number identifying the service to which you have

subscribed. This value is usually a ten-digit telephone
number followed by more digits. The ISDN service
provider assigns this value.
ldn
(Optional) Seven-digit local directory number that is

assigned by the ISDN service provider.
If you want the SPID to be automatically detected, you can specify 0 for the spid-number
argument.
The ldn parameter allows you to associate up to three local directory numbers with each SPID.
This number must match the called-party information coming in from the ISDN switch in order
for both B channels to be used on most switches.
ISDN BRI Configuration Example

BRI 0/1
PSTN
- - --
- -
- -
IPTX v2.03-20
Common-Channel Signaling: PRI
This topic identifies the most common components and reference points of ISDN PRI. It also
shows how to use global and interface configuration commands to configure ISDN PRI and
provides an overview of the isdn switch-type command. In addition, the topic lists and
explains the commands required to configure the ISDN PRI channels and D channel.
PRI Reference Points
IPTX v2.03-21
Depending on country implementation, either the ANSI T1.601 or ITU-T I.431 standard
governs the physical layer of the PRI interface.
PRI technology is a bit simpler than BRI technology. The wiring is not multipoint, which refers
to the ability to have multiple ISDN devices connected to the network, all of which have access
to the ISDN network. Arbitration at Layer 1 and Layer 2 allows multiple devices that need to
share the ISDN network to access the network without collisions or interruptions. But because
there are no multiple devices in PRI, it does not require this arbitration. There is only the
straight connection between the channel service unit/data service unit (CSU/DSU) and the PRI
interface.
ISDN PRI Configuration Commands
- - -
Sets the ISDN switch type globally
Defines a SPID if assigned by the carrier

(found in North America)
- - -
Sets the ISDN switch type on an interface

(overrides the global setting if it exists)
IPTX v2.03-22
Use the isdn switch-type command to specify the CO PRI switch to which the router connects.
With Cisco IOS Release 11.3(3)T or later, this command is also available as a controller
command to allow different switch types to be supported on different controllers. If configured
as a global command, the specified switch type applies to all controllers unless one is
specifically configured on a controller.
An incompatible switch selection configuration can result in failure to make ISDN calls. After
changing the switch type, you must reload the router to make the new configuration effective.
Telco isdn switch-type commands are shown in this table.
isdn switch-type Command
Command
Description
primary-4ess
AT&T Primary-4ESS switches (United States)
primary-5ess
AT&T Primary-5ESS switches (United States)
primary-dms100
NT DMS-100 switches (North America)
primary-ni
National ISDN switch type
primary-ntt
NTT ISDN PRI switches (Japan)
primary-net5
European and Australian ISDN PRI switches
primary-qsig
QSIG signaling per Q.931
None
No switch defined
Unlike BRI operation, ISDN PRIs do not use SPIDs. Therefore, there is no requirement to
configure SPIDs, regardless of the ISDN switch type used by the PRI.
Use the controller {t1 | e1} slot/port command in global configuration mode to identify the
controller to be configured. Use a single unit-number to identify the AS5000 Series controller.
controller {t1 | e1} Command
Command
Description
t1
Specifies the controller interface for North America and Japan
e1
Specifies the controller interface for Europe and most other

countries in the world
slot/port or unit-number Specifies the physical slot/port location or unit number of the
controller
ISDN PRI Configuration Commands (Cont.)
--
Sets the PRI group with a range of time slots
- --
Sets the PRI D channel
IPTX v2.03-23
The pri-group command configures the specified interface for PRI operation and specifies
which fixed time slots (channels) are allocated on the digital facility of the provider.
pri-group Command
Command
Description
timeslots range
The range of time slots allocated to this PRI. For T1, use
values in the range of 1 to 24, and for E1, use values
from 1 to 31. The speed of the PRI is the aggregate of
the channels assigned.
If using all 30 B channels on an E1 PRI (30B+D), specify pri-group 1-31.

If only the first eight B channels (512 kbps total data bandwidth) are allocated for a T1 PRI
(23B+D), then specify pri-group 1-8,24. Note that the D channel must be specified.
Note
When provisioning a PRI line with less than 24 time slots (or 30 for E1), include the D
channel for signaling.
Specification of the PRI group automatically creates the corresponding serial interface for the D
channel: interface serial {slot/port | unit}:{23 | 15}. This interface is used to configure the PRI
D channel. The table shows interface serial commands you can use.
interface serial Command
Command
Description
slot/port
The slot/port of the channelized controller
unit
The unit number of the channelized controller on a Cisco 4000 or

AS5000 Series router
23
A T1 interface that designates channelized DS0s 0 to 22 as the B

channels, and DS0 23 as the D channel
15
An E1 interface that designates 30 B channels and time slot 16 as

the D channel
Note
In an E1 or T1 facility, the channels start numbering at 1 (1 to 31 for E1 and 1 to 24 for T1).

Serial interfaces in the Cisco router start numbering at 0. Therefore, channel 16, the E1
signaling channel, is serial port subinterface 15. Channel 24, the T1 signaling channel, is
serial subinterface 23.
Example: ISDN PRI Configuration

PRI 0/1
PSTN
- -

--
-
-
-
IPTX v2.03-24
The table describes the commands found in the figure.

PRI Configuration Commands
Command
Description
isdn switch-type primary-ni
Selects a switch type of National ISDN
controller t1 0/1
Selects the T1 controller 0/1
pri-group timeslots 124
Establishes the interface port to function as PRI with 24

timeslots (including D channel) designated to operate at a
speed of 64 kbps
framing esf
Selects ESF framing, a T1 configuration feature
linecode b8zs
Selects line code B8ZS for T1
clock source line
Specifies the T1 line as the clock source for the router
interface serial 0/0:23
Identifies the D channel on serial interface 0/0
The controller t1 0/1 command configures the T1 controller. In the example, the switch type
that is selected is the national ISDN standard. This example is accurate for some operations in
the United States.
For an E1 example, the time slot argument for the pri-group command would be 131 rather
than 124, as shown for a T1 example, and the interface command would be 0/1:15 instead of
0/1:23.
Summary
Summary
Configurable parameters on FXS ports include signal,
cptone, description, ring frequency, ring cadence,
disconnect-ack, busyout, station id name, and station id
number.
Configurable parameters on FXO ports include signal, ring
number, dial-type, description, and supervisory disconnect.
Configurable parameters on E&M ports include signal,
operation, type, auto-cut-through, and description.
Configurable timer and timing parameters define initial digit
and interdigit timing, digit and interdigit duration, as well as
ringing time.
Digital voice ports are created with the ds0-group command in
the T1/E1 controller.
IPTX v2.03-25
Summary (Cont.)
ISDN can be implemented in two different ways: BRI and PRI.
In most countries, customer access to BRI is available at the S/T
interface.
Enabling ISDN BRI requires global configuration and interface
configuration commands.
Some ISDN switches require the configuration of SPID numbers.
A T1 controller configuration must include the framing type and line
coding.
ISDN PRI configuration requires that the pri-group command specify
the time slots that are used for voice and signaling.
ISDN PRI does not require SPIDs.
The ISDN PRI D channel and B channel are configured separately
from the controller using the interface serialcommand.
ISDN PRI requires that a T1 (or E1) controller be configured.
IPTX v2.03-26
Lesson 3
Configuring Dial Peers

Overview
This lesson describes voice dial peers, digit manipulation, the matching of calls to dial peers,
and COR.
Objectives
Upon completing this lesson, you will be able to describe dial peers and configuration tasks.
This includes being able to meet these objectives:
Describe dial peers and their application
Configure plain old telephone service dial peers
Configure VoIP dial peers
Describe destination-pattern options and the applicable shortcuts
Describe the default dial peer
This topic describes dial peers and their applications.

A dial peer is an addressable call endpoint.
Dial peers establish logical connections, or call
legs, to complete an end-to-end call.
Cisco voice-enabled routers support two types of
dial peers:
POTS dial peers: Connect to a traditional
telephony network
VoIP dial peers: Connect over a packet network
IPTX v2.03-3
When a call is placed, an edge device generates dialed digits as a way of signaling where the
call should terminate. When these digits enter a router voice port, the router must have a way to
decide whether the call can be routed and where the call can be sent. The router does this by
looking through a list of dial peers.
A dial peer is an addressable call endpoint. The address is called a destination pattern and is
configured in every dial peer. Destination patterns can point to one telephone number only or to
a range of telephone numbers. Destination patterns use both explicit digits and wildcard
variables to define a telephone number or range of numbers.
The router uses dial peers to establish logical connections.These logical connections, known as
call legs, are established in either an inbound or outbound direction.
Dial peers define the parameters for the calls that they match. For example, if a call is
originating and terminating at the same site, and is not crossing through slow-speed WAN
links, then the call can cross the local network uncompressed and without special priority. A
call that originates locally and crosses the WAN link to a remote site may require compression
with a specific codec. In addition, this call may require that voice activity detection (VAD) be
turned on, and it will need to receive preferential treatment by specifying a higher priority level.
Cisco Systems voice-enabled routers support two types of dial peers:

POTS dial peers: Connect to a traditional telephony network, such as the PSTN or a PBX,
or to a telephony edge device, such as a telephone or fax machine. POTS dial peers perform
these functions:
Provide an address (telephone number or range of numbers) for the edge network
or device
Point to the specific voice port that connects the edge network or device
VoIP dial peers: Connect over a packet network. VoIP dial peers perform these functions:
Provide a destination address (telephone number or range of numbers) for the edge
device that is located across the network
Associate the destination address with the next hop router or destination router,
depending on the technology used
Dial Peer
IPTX v2.03-4
In the figure, the telephony device connects to the Cisco Systems voice-enabled router POTS
dial peer. The POTS dial peer configuration includes the telephone number of the telephony
device and the voice port to which it is attached. The router knows where to forward incoming
calls for that telephone number.
The Cisco voice-enabled router VoIP dial peer is connected to the packet network. The VoIP
dial peer configuration includes the destination telephone number (or range of numbers) and the
next hop or destination voice-enabled router network address.
Follow the steps in this table to place a VoIP call:
How to Place a VoIP Call
Step
Action
1 Configure the source router with a compatible dial peer that specifies the recipient
destination address.
2 Configure the recipient router with a POTS dial peer that specifies which voice
port the router uses to forward the voice call.
Plain Old Telephone Service Dial Peers

This topic describes how to configure POTS dial peers.
POTS Dial Peers
IPTX v2.03-5
Before the configuration of Cisco IOS dial peers can begin, the user must have a good
understanding of where the edge devices reside, what type of connections need to be made
between these devices, and what telephone numbering scheme is applied to the devices.
Follow the steps in this table to configure POTS dial peers.
How to Configure POTS Dial Peers
Step
Action
1 Configure a POTS dial peer at each router or gateway where edge telephony
devices connect to the network.
2 Use the
destinationpattern command in the dial peer to configure the

telephone number.
3 Use the
port command to specify the physical voice port that the POTS
telephone is connected to.
The dial peer type is specified as POTS because the edge device is directly connected to a voice
port and the signaling must be sent from this port to reach the device. There are two basic
parameters that need to be specified for the device: the telephone number and the voice port.
When a PBX is connecting to the voice port, a range of telephone numbers can be specified.
Example
The figure illustrates proper POTS dial peer configuration on a Cisco voice-enabled router. The
dial-peer voice 1 pots command notifies the router that dial peer 1 is a POTS dial peer with a
tag of 1. The destination-pattern 7777 command notifies the router that the attached telephony
device terminates calls destined for telephone number 7777. The port 1/0/0 command notifies
the router that the telephony device is plugged into module 1, voice interface card (VIC) slot 0,
voice port 0.
VoIP Dial Peers
This topic describes how to configure VoIP dial peers.
VoIP Dial Peers
IPTX v2.03-6
The administrator must know how to identify the far-end voice-enabled device that will
terminate the call. In a small network environment, the device may be the IP address of the
remote device. In a large environment, the device may mean pointing to another router or
gatekeeper for address resolution and Call Admission Control (CAC) to complete the call.
You must follow the steps in this table to configure VoIP dial peers:
How to Configure VoIP Dial Peers
Step
Action
1 Configure the path across the network for voice data.

2 Specify the dial peer as a VoIP dial peer.
3 Use the
destination-pattern command to configure a range of numbers

reachable by the remote router or gateway.
4 Use the
session target command to specify an IP address of the terminating

router or gateway.
5 Use the remote device loopback address as the IP address.
The dial peer is specified as a VoIP dial peer, which alerts the router that it must process a call
according to the various parameters that are specified in the dial peer. The dial peer must then
package it as an IP packet for transport across the network. Specified parameters may include
the codec to be used, whether to use RTP header compression, whether to use VAD, and may
also include marking the packet for priority service.
The destination-pattern parameter configured for this dial peer is typically a range of numbers
that are reachable via the remote router or gateway.
Because this dial peer points to a device across the network, the router needs a destination IP
address to put in the IP packet. The session target parameter allows the administrator to specify
either an IP address of the terminating router or gateway or another device; for example, a
gatekeeper that can return an IP address of that remote terminating device.
To determine which IP address a dial peer should point to, it is recommended that you use a
loopback address. The loopback address is always up on a router as long as the router is
powered on and the interface is not administratively shut down. If an interface IP address is
used instead of the loopback and that interface goes down, the call fails even if there is an
alternate path to the router.
Example
The figure illustrates the proper VoIP dial peer configuration on a Cisco voice-enabled router.
The dial-peer voice 2 voip command notifies the router that dial peer 2 is a VoIP dial peer with
a tag of 2. The destination-pattern 8888 command notifies the router that this dial peer defines
an IP voice path across the network for telephone number 8888. The session target
ipv4:10.18.0.1 command defines the IP address of the router that is connected to the remote
telephony device.
Destination-Pattern Options
This topic describes destination-pattern options and the applicable shortcuts.
Destination-Pattern Options
IPTX v2.03-7
The destination pattern associates a telephone number with a given dial peer. The destination
pattern also determines the dialed digits that the router collects and forwards to the remote
telephony interface, such as a PBX, Cisco CallManager, Cisco CallManager Express router,
IOS router, or the PSTN. You must configure a destination pattern for each POTS and VoIP
dial peer that you define on the router.
The destination pattern can indicate a complete telephone number or a partial telephone number
with wildcard digits; it can also point to a range of numbers defined in a variety of ways.
Destination-pattern options include:
Plus (+): An optional character that indicates an E.164 standard number. E.164 is the ITUT recommendation for the international public telecommunication numbering plan. The
plus sign in front of a destination-pattern string specifies that the string must conform to
Recommendation E.164.
String: A series of digits specifying the E.164 or private dialing-plan telephone number.
The examples below show the use of special characters that are often found in destination
patterns strings:
Asterisk (*) and pound sign (#) appear on standard touch-tone dial pads. These
characters may need to be used when passing a call to an automated application that
requires these characters to signal the use of a special feature. For example, when
calling an interactive voice response (IVR) system that requires a code for access,
the number dialed might be 5551212888#, which would initially dial the
telephone number 5551212 and input a code of 888 followed by the pound key to
terminate the IVR input query.
Comma (,) inserts a one-second pause between digits. The comma can be used, for
example, where a 9 is dialed to signal a PBX that the call should be processed by the
PSTN. The 9 is followed by a comma to give the PBX time to open a call path to the
PSTN, after which the remaining digits will be played out. An example of this string
is 9,5551212.
Period (.) matches any single entered digit (this character is used as a wildcard). The
wildcard is used to specify a group of numbers that may be accessible via a single
destination router, gateway, PBX or Cisco CallManager Express router. Because the
period (commonly referred to as a dot) indicates a single digit of 0 to 9, this limits
how efficiently ranges of numbers are used. A pattern of 200. allows for 10
uniquely addressed devices, whereas a pattern of 20.. can point to 100 devices. If
one site has the numbers 2000 through 2049 and another site has the numbers 2050
through 2099, then the bracket notation would be more efficient.
Brackets ([ ]) indicate a range. A range is a sequence of characters that are enclosed
in the brackets. Only single numeric characters from 0 to 9 are allowed in the range.
Looking at the previous example, the bracket notation could be used to specify
exactly which range of numbers is accessible through each dial peer. For example,
the first site pattern would be 20[0-4]., and the second site pattern would be 20[59]. The bracket notation offers much more flexibility in how numbers can be
assigned.
T: An optional control character indicating that the destination-pattern value is a
variable-length dial string. In cases where callers may be dialing local, national, or
international numbers, the destination pattern must provide for a variable-length dial plan.
If a particular voice gateway has access to the PSTN for local calls and access to a
transatlantic connection for international calls, then calls being routed to that gateway will
have a varying number of dialed digits. A single dial peer with a destination pattern of .T
could support the different call types. The interdigit timeout determines when a string of
dialed digits is complete. The router continues to collect digits until there is an interdigit
pause longer than the configured value, which by default is 10 seconds.
When the calling party finishes entering dialed digits, there is a pause equal to the interdigit
timeout value before the router processes the call. The calling party can immediately terminate
the interdigit timeout by entering the pound (#) character, which is the default termination
character. Because the default interdigit timer is set to 10 seconds, users may experience a long
call setup delay.
Note
Cisco IOS software does not check the validity of the E.164 telephone number; it accepts
any series of digits as a valid number.
Example
Example: Destination-Pattern Options
Destination Pattern
Matching Telephone Numbers
5551234 Matches one telephone number exactly, 5551234.

This is typically used when there is a single device, such as a telephone or
fax, connected to a voice port.
555[1-3] Matches a seven-digit telephone number where the first three digits are 555,
the fourth digit can be 1, 2, or 3, and the last digits can be any valid digits.
This type of destination pattern is used when telephone number ranges are
assigned to specific sites. In this example, the destination pattern is used in a
small site that does not need more than 30 numbers assigned.
.T Matches any telephone number that has at least one digit and can vary in
length from 1 to 32 digits total.
This destination pattern is used for a dial peer that services a variable-length
dial plan, such as local, national, and international calls. It can also be used
as a default destination pattern so that any calls that do not match a more
specific pattern will match this one and can be directed to an operator.
What Is the Default Dial Peer?

This topic describes the default dial peer.
Default Dial Peer 0
IPTX v2.03-8
When a matching inbound dial peer is not found, the router resorts to the default dial peer.
Note
Default dial peers are used for inbound matches only. They are not used to match outbound
calls that do not have a dial peer configured.
The default dial peer is referred to as dial-peer 0.
Example
In the figure, only one-way dialing is configured. The caller at extension 7777 can call
extension 8888 because there is a VoIP dial peer configured on router 1 to route the call across
the network. There is no VoIP dial peer configured on router 2 to point calls across the network
toward router 1. Therefore, there is no dial peer on router 2 that will match the calling number
of extension 7777 on the inbound call leg. If no incoming dial peer matches the calling number,
the inbound call leg automatically matches to a default dial peer (POTS or VoIP).
Note
There is an exception to the previous statement. Cisco voice and dial platforms, such as the
AS53xx and AS5800, require that a configured inbound dial peer be matched for incoming
POTS calls to be accepted as voice calls. If there is no inbound dial peer match, the call is
treated and processed as a dial-up (modem) call.
Dial peer 0 for inbound VoIP peers has the following configuration:
any codec
ip precedence 0
vad enabled
no rsvp support
fax-rate service
Dial peer 0 for inbound POTS peers has the following configuration:
no ivr application
You cannot change the default configuration for dial peer 0. Default dial peer 0 fails to
negotiate nondefault capabilities or services. When the default dial peer is matched on a VoIP
call, the call leg that is set up in the inbound direction uses any supported codec for voice
compression, based on the requested codec capability coming from the source router. When a
default dial peer is matched, the voice path in one direction may have parameters that are
different from the voice in the return direction. This may cause one side of the connection to
report good-quality voice while the other side reports poor-quality voice. For example, the
outbound dial peer has VAD disabled, but the inbound call leg is matched against the default
dial peer, which has VAD enabled. In this example, VAD is on in one direction and off in the
return direction.
When the default dial peer is matched on an inbound POTS call leg, there is no default IVR
application with the port; as a result, the user gets a dial tone and proceeds with dialed digits.
The use of a catch-all dial peer that matches all calls can prevent the use of the default dial peer
and send any matches to a default location like the operator or an automated attendant.
Summary
Summary
A dial peer is an addressable endpoint.
Cisco voice-enabled routers support POTS dial peers and VoIP dial
peers.
Basic POTS dial-peer configuration consists of defining the dial
peer with a tag number and POTS designation, defining the
destination pattern, and defining the voice port to which the device
is connected.
Basic VoIP dial-peer configuration consists of defining the dial peer
with a tag number and VoIP designation, defining the destination
pattern, and defining the remote voice-enabled router through the
session target command.
The destination-pattern on a dial peer can utilize wildcards to
simplify configuration.
The default dial-peer is used when no match in the configured dial
peers is found.
IPTX v2.03-9
Lesson 4
Understanding Call Setup and

Digit Manipulation
Overview
This lesson describes call flows, digit manipulation, digit collection, and digit consumption as
they relate to inbound and outbound dial peers.
Objectives
Upon completing this lesson, you will be able to define what call legs are, describe how call
legs relate to inbound and outbound dial peers by defining all the steps in the call setup process,
and describe the proper use of digit manipulation. This includes being able to meet these
objectives:
Describe call legs and their relationships to other components
Describe how call legs are interpreted by routers to establish end-to-end calls
Describe how the router matches inbound dial peers
Describe how the router matches outbound dial peers
Describe how the router and attached telephony equipment collect and consume digits and
how to apply digit consumption to the dial peer
Describe digit manipulation and the commands that are used to connect to a specified
destination
Describe how the network establishes private line automatic ringdown
What Are Call Legs?
This topic describes call legs and their relationship to other components.
Dial-Peer Call Legs
IPTX v2.03-3
Call legs are logical connections between any two telephony devices, such as gateways, routers,
Cisco CallManager Express routers, CallManagers, or telephony endpoint devices.
Call legs are router-centric. When an inbound call arrives, it is processed separately until the
destination is determined. Then, a second call leg is established that is outbound, and the
inbound call leg is switched to the outbound voice port.
Example
The connections are made when you configure dial peers on each interface. An end-to-end call
consists of four call legs: two from the source router perspective (as shown in the figure), and
two from the destination router perspective. To complete an end-to-end call from either side
and send voice packets back and forth, you must configure all four dial peers.
Dial peers are used only to set up calls. When the call is established, dial peers are no
longer used.
End-to-End Calls
This topic explains how routers interpret call legs to establish end-to-end calls.
End-to-End Calls
IPTX v2.03-4
An end-to-end voice call consists of four call legs: two from the originating router (R1) or
gateway perspective and two from the terminating router (R2) or gateway perspective. An
inbound call leg originates when an incoming call goes into the router or gateway. An outbound
call leg originates when a call is placed from the router or gateway.
A call is segmented into call legs, and a dial peer is associated with each call leg. The process
for call setup is as follows:
1. The POTS call arrives at R1 and an inbound POTS dial peer is matched.
2. After associating the incoming call to an inbound POTS dial peer, R1 creates an inbound
POTS call leg and assigns it a call ID (Call Leg 1).
3. R1 uses the dialed string to match an outbound voice network dial peer.
4. After associating the dialed string with an outbound voice network dial peer, R1 creates an
outbound voice network call leg and assigns it a call ID (Call Leg 2).
5. The voice network call request arrives at R2, and an inbound voice network dial peer is
matched.
6. After R2 associates the incoming call with an inbound voice network dial peer, R2 creates
the inbound voice network call leg and assigns it a call ID (Call Leg 3). At this point, both
R1 and R2 negotiate voice network capabilities and applications, if required.
When the originating router or gateway requests nondefault capabilities or applications, the
terminating router or gateway must match an inbound voice network dial peer that is
configured for such capabilities or applications.
7. R2 uses the dialed string to match an outbound POTS dial peer.
8. After associating the incoming call setup with an outbound POTS dial peer, R2 creates an
outbound POTS call leg, assigns it a call ID, and completes the call (Call Leg 4).
Matching Inbound Dial Peers
This topic describes how the router matches inbound dial peers.
Matching Inbound Dial Peers

Configurable parameters used for matching inbound dial
peers:
incoming called-number
Defines the called number or dialed number identification
service (DNIS) string
answer-address
Defines the originating calling number or automatic number
identification (ANI) string
destination-pattern
Uses the calling number (originating or ANI string) to match the
incoming call leg to an inbound dial peer
port
Attempts to match the configured dial-peer port to the voice port
associated with the incoming call (POTS dial peers only)
IPTX v2.03-5
When determining how inbound dial peers are matched on a router, it is important to note
whether the inbound call leg is matched to a POTS or VoIP dial peer. Matching occurs in the
following manner:
Inbound POTS dial peers are associated with the incoming POTS call legs of the
originating router or gateway.
Inbound VoIP dial peers are associated with the incoming VoIP call legs of the terminating
router or gateway.
Three information elements sent in the call setup message are matched against four
configurable dial-peer command attributes.
The three call setup information elements that are known about calls arriving at the gateway
are:
Call Setup Information Elements
Call Setup Element
Description
Called number Dialed Number

Identification Service (DNIS)
This is the call-destination dial string, and it is derived from the

ISDN setup message or the CAS DNIS.
Calling number automatic number

identification (ANI)
This is a number string that represents the call origin, and it is

derived from the ISDN setup message or the CAS ANI. The ANI
is also referred to as the calling line ID (CLID).
Voice port This represents the POTS physical voice port.
When the Cisco IOS router or gateway receives a call setup request, it makes a dial-peer match
for the incoming call. This is not digit-by-digit matching; instead, the router uses the full digit
string received in the setup request.
The router or gateway matches call setup element parameters in the following order:
How the Router or Gateway Matches Inbound Dial Peers
Step
Action
1 The router or gateway attempts to match the called number of the call setup request
with the configured incoming called-number of each dial peer.
2 If a match is not found, the router or gateway attempts to match the calling number of
the call setup request with the answer-address of each dial peer.
3 If a match is not found, the router or gateway attempts to match the calling number of
the call setup request to the destination-pattern of each dial peer.
4 The voice port uses the voice port number associated with the incoming call setup
request to match the inbound call leg to the configured dial-peer port parameter.
5 If multiple dial peers have the same port configured, then the router or gateway
matches the first dial peer added to the configuration.
6 If a match is not found in the previous steps, then the default is dial peer 0
Because call setups always include DNIS information, it is recommended that you use the
incoming called-number command for inbound dial-peer matching. Configuring the incoming
called-number command is useful for a company that has a central call center that provides
support for a number of different products. Purchasers of each product get a unique 1-800
number to call for support. All support calls are routed to the same trunk group that is destined
for the call center. When a call comes in, the computer telephony system uses the DNIS to flash
the appropriate message on the computer screen of the agent to whom the call is routed. The
agent then knows how to customize the greeting when answering the call.
Configuring the calling number ANI with the answer-address command is useful when you
want to match calls based on the originating calling number. For example, when a company has
international customers who require foreign-language-speaking agents to answer the call, the
call can be routed to the appropriate agent based on the country of call origin.
You must configure the calling number ANI with the destination-pattern command when the
dial peers are set up for two-way calling. In a corporate environment, the head office and the
remote sites must be connected. As long as each site has a VoIP dial peer configured to point to
each site, inbound calls from the remote site match against that dial peer.
Matching Outbound Dial Peers
This topic describes how the router matches outbound dial peers.
Matching Outbound Dial Peers
IPTX v2.03-6
Outbound dial-peer matching is completed on a digit-by-digit basis. Therefore, the router or

gateway checks for dial peer matches after receiving each digit, then routes the call when a full
match is made.
The router or gateway matches outbound dial peers in the following order:
How the Router or Gateway Matches Outbound Dial Peers
Step
Action
1 The router or gateway uses the destination

to determine how to route the call.
2 The
-pattern command under the dial peer
destination-pattern command routes the call in the following manner:

On POTS dial peers, the port command forwards the call.
On VoIP dial peers, the session target command forwards the call.
3 Use the
show dialplannumber string command to determine which dial peer is

matched to a specific dialed string. This command displays all matching dial
peers in the order that they are used.
Example
In the figure, dial peer 1 matches any digit string that has not matched other dial peers more
specifically. Dial peer 2 matches any seven-digit number in the 2000 and 3000 range of
numbers starting with 555. Dial peer 3 matches any seven-digit number in the 1000 range of
numbers starting with 555. Dial peer 4 matches the specific number 5551234 only. When the
number 5551234 is dialed, dial peers 1, 3, and 4 all match that number, but dial peer 4 places
that call because it has the most specific destination pattern.
Digit Collection and Consumption
This topic describes how the router collects and consumes digits and applies them to the dial
peer statements.
Digit Consumption and Forwarding
IPTX v2.03-7
Use the no digit-strip command to disable the automatic digit-stripping function. This allows
the router to match digits and pass them to the telephony interface.
By default, when the terminating router matches a dial string to an outbound POTS dial peer,
the router strips off the left-justified digits that explicitly match the destination pattern. The
remaining digits, or wildcard digits, are forwarded to the telephony interface, which connects
devices such as a PBX or the PSTN.
Digit stripping is the desired action in some situations. There is no need to forward digits out of
a POTS dial peer if it is pointing to an FXS port that connects a telephone or fax machine. If
digit stripping is turned off on this type of port, the user may hear tones after answering the call
because any unconsumed and unmatched digits are passed through the voice path after the call
is answered.
In other situations, when a PBX or the PSTN is connected through the POTS dial peer, digit
stripping is not desired because these devices need additional digits to further direct the call. In
this situation, the administrator must assess the number of digits that need to be forwarded for
the remote device to correctly process the call. With a VoIP dial peer, all digits are passed
across the network to the terminating voice-enabled router.
Digit Collection
IPTX v2.03-8
The table describes the steps that take place when a voice call enters the network.
How the Router Collects Digits
Step
Action
1 The originating router collects dialed digits until it matches an outbound dial peer.
2 The router immediately places the call and forwards the associated dial string.
3 The router collects no additional dialed digits.
Example
The figure demonstrates the impact that overlapping destination patterns have on the callrouting decision. In example 1, the destination pattern in dial peer 1 is a subset of the
destination pattern in dial peer 2. Because the router matches one digit at a time against
available dial peers, an exact match always occurs on dial peer 1, and dial peer 2 is never
matched.
In example 2, the length of the destination patterns in both dial peers is the same. Dial peer 2
has a more specific value than dial peer 1, so it is matched first. If the path to IP address
10.18.0.2 is unavailable, dial-peer 1 is used.
Matching Destination Patterns

Dialed Digits
5551234 5
5551234 555
Destination Pattern
Dialed Digits Collected
5551234
. 5551234
5551234 555 555

5551234 555T 5551234
In the first row of the table, the destination pattern specifies a seven-digit string. The first digit
must be a 5, and the remaining six digits can be any valid digits. All seven digits must be
entered before the destination pattern is matched.
In the second row, the destination pattern specifies a seven-digit string. The first three digits
must be 555, and the remaining four digits can be any valid digits. All seven digits must be
entered before the destination pattern is matched.
In the third row, the destination pattern specifies a three-digit string. The dialed digits must be
exactly 555. When the user begins to dial the seven-digit number, the destination pattern
matches after the first three digits are entered. The router then stops collecting digits and places
the call. If the call is set up quickly, the answering party at the other end may hear the
remaining four digits as the user finishes dialing the string. After a call is set up, any DTMF
tones are sent through the voice path and played at the other end.
In the last row, the destination pattern specifies a variable-length digit string that is at least
three digits long. The first three digits must be exactly 555, and the remaining digits can be any
valid digits. The T tells the router to continue collecting digits until the interdigit timer
expires. The router stops collecting digits when the timer expires or when the user presses the
pound (#) key.
What Is Digit Manipulation?
This topic describes digit manipulation and the commands that are used to connect to a
specified destination.
Digit Manipulation Commands

prefix
Dial-peer command
Adds digits to the front of the dial string before it is forwarded to the
telephony interface
forward-digits
Dial-peer command
Controls the number of digits forwarded to the telephony interface
number expansion table
Global command (num-exp)
Expands an extension into a full telephone number or replaces one
number with another
digit translation
Global and dial-peer command
Digit translation rules used to manipulate the calling number, or ANI,
or the called number, or DNIS, digits for a voice call
IPTX v2.03-9
Digit manipulation is the task of adding or subtracting digits from the original dialed number to
accommodate user-dialing habits or gateway needs. The digits can be manipulated before
matching an inbound or outbound dial peer. The following is a list of digit manipulation
commands and their uses:
prefix: This dial-peer command adds digits to the front of the dial string before it is
forwarded to the telephony interface. This occurs after the outbound dial peer is matched,
but before digits get sent out of the telephony interface. Use the prefix command when the
dialed digits leaving the router must be changed from the dialed digits that had originally
matched the dial peer. For example, a call is dialed using a four-digit extension such as
1234, but the call needs to be routed to the PSTN, which requires ten-digit dialing. If the
four-digit extension matches the last four digits of the actual PSTN telephone number, then
you can use the prefix command, prefix 902555, to prepend the six additional digits
needed for the PSTN to route the call to 9025551234. After the POTS dial peer is matched
with the destination pattern of 1234, the prefix command prepends the additional digits,
and the string 9025551234 is sent out of the voice port to the PSTN.
forward-digits: This dial-peer command specifies the number of digits that must be
forwarded to the telephony interface, whether they are explicitly matched or wildcard
matched. This command occurs after the outbound dial peer is matched, but before the
digits are sent out of the telephony interface. When a specific number of digits is
configured for forwarding, the count is right-justified. For example, if the POTS dial peer
has a destination pattern configured to match all extensions in the 1000 range (destinationpattern 1), by default, only the last three digits are forwarded to the PBX that is
connected to the specified voice port. If the PBX needs all four digits to route the call, you
must use the command forward-digits 4 or forward-digits all so that the appropriate
number of digits is forwarded.
Note
To restore the forward-digits command to its default setting, use the default forwarddigits command. Using the no forward-digits command specifies that no digits are to be
forwarded.
num-exp (number expansion table): This global command expands an extension into a full
telephone number or replaces one number with another. The number expansion table
manipulates the called number. This command occurs before the outbound dial peer is
matched; therefore, you must configure a dial peer with the expanded number in the
destination pattern in order for the call to go through. The number expansion table is useful,
for example, when the PSTN changes the dialing requirements from seven-digit dialing to
ten-digit dialing. In this scenario, you can do one of the following:
Make all the users dial all ten digits to match the new POTS dial peer that is pointing
to the PSTN.
Allow the users to continue dialing the seven-digit number as they have before, but
expand the number to include the area code before the ten-digit outbound dial peer is
matched.
Note
You must use the show num-exp command to view the configured number-expansion
table. You must use the show dialplan number number commandto confirm the presence
of a valid dial peer to match the newly expanded number.
digit translation: Digit translation is a two-step configuration process. First, the translation
rule is defined at the global level. Then, the rule is applied at the dial-peer level either as
inbound or outbound translation on either the called or calling number. Translation rules
manipulate the ANI or DNIS digits for a voice call. Translation rules convert a telephone
number into a different number before the call is matched to an inbound dial peer or before
the outbound dial-peer forwards the call. For example, an employee may dial a five-digit
extension to reach another employee of the same company at another site. If the call is
routed through the PSTN to reach the other site, the originating gateway may use
translation rules to convert the five-digit extension into the ten-digit format that is
recognized by the CO switch.
You can also use translation rules to change the numbering type for a call. For example, some
gateways may tag a number with more than 11 digits as an international number even when the
user must dial 9 to reach an outside line. In this case, the number that is tagged as an
international number needs to be translated into a national numberwithout the 9before it is
sent to the PSTN.
As illustrated in this topic, there are numerous ways to manipulate digits at various stages of
call completion. In many cases, several of these tools provide a workable solution. The
administrator needs to determine which command is most suitable and what the requirements
are that are necessary for manipulation.
Note
To test configured translation rules, you must use the test translation command.
Example
The following is a sample configuration using the prefix command:
-

In the sample configuration using the prefix command, the device attached to port 1/0/0 needs
all seven digits to process the call. On a POTS dial peer, only wildcard-matched digits are
forwarded by default. Use the prefix command to send the prefix numbers of 555 before
forwarding the four wildcard-matched digits.
The following is a sample configuration using the forward-digits command:
-
-

In the sample configuration using the forward-digits command, the device attached to port
1/0/0 needs all seven digits to process the call. On a POTS dial peer, only wildcard-matched
digits are forwarded by default. The forward-digits command allows the user to specify the
total number of digits to forward.
The following is a sample configuration using the number expansion table command:

-

In the sample configuration using the number expansion table command, the extension
number of 2 is expanded to 5552 before an outbound dial peer is matched. For example,
the user dials 2401, but the outbound dial peer 1 is configured to match 5552401.
The following is a sample configuration using the digit translation command:
-

-
In the sample configuration using the translation-rule command, the rule is defined to
translate 2401 into 5552401. The dial peer translate-outgoing called-number 5 command
notifies the router to use the globally defined translation rule 5 to translate the number before
sending the string out the port. It is applied as an outbound translation from the POTS dial peer.
The following example shows a translation rule that converts any called number that starts with
91 and that is tagged as an international number into a national number without the 9 before
sending it to the PSTN.
-

-
-

-
PLAR
This topic describes the use of PLAR connections.
PLAR Connection
IPTX v2.03-10
PLAR is an auto-dial mechanism that permanently associates a voice port with a far-end
voice port, allowing call completion to a specific telephone number or PBX. When the
calling telephone goes off hook, a predefined network dial peer is automatically matched,
which sets up a call to the destination telephone or PBX. The caller does not hear a dial
tone and does not have to dial a number. PLAR connections are widely used in the business
world. One common use is to connect stockbrokers with trading floors. Timing is critical
when dealing with stock transactions; the amount of time it may take to dial a number and
get a connection can be costly in some cases. Another common use is in the travel sector,
directly connecting travelers with services. At places like airports, the traveler often sees
display boards advertising taxi companies, car rental companies and local hotels. These
displays often have telephones that will connect the traveler directly with the service of
choice; the device is preconfigured with the telephone number of the desired service. One
obvious difference between these telephones and a normal telephone is that they do not
have a dial pad.
As shown in the figure, the following actions must occur to establish a PLAR connection:
1. A user at the remote site lifts the handset.
2. A voice port at the remote site router automatically generates digits 5600 for a dial-peer
lookup.
3. The router at the remote site matches digits 5600 to VoIP dial peer 5 and sends the setup
message with the digits 5600 to IP address 10.18.0.1 as designated in the session target
statement.
4. The router at the central site matches received digits 5600 to POTS dial peer 1 and
forwards digits 5600 out voice port 1/0:1. At the same time, it sends a call-complete setup
message to the router at the remote site because both the inbound and outbound call legs on
the central site router were processed correctly.
5. The PBX receives digits 5600 and rings the appropriate telephone.
Summary
Summary
A call is segmented into call legs with a dial peer
associated with each call leg.
A call legis a logical connection between two gateways or
routers or between a gateway or router and a telephony
endpoint.
An end-to-end call comprises four call legs: two from the
voice router perspective and two from the destination
router perspective.
If no matching inbound dial peer is configured for a call,
the default dial peer is used.
Inbound dial-peer matching uses incoming called-number,
answer-address, destination pattern, and portin that
orderto match inbound dial peers.
IPTX v2.03-11
Summary (Cont.)
Outbound dial-peer matching uses the longest number
match in the destination pattern to match an outbound
dial peer.
On POTS dial peers, only wildcard-matched digits are
forwarded by default.
The prefix and forward-digits commands define how digits
are sent out to the voice port.
The num-exp and translation-rule commands define how
one number is replaced with another number.
The connection plar command permanently associates a
voice port with a specific telephone number. The voice
port does not present a dial tone, but automatically
generates the configured number.
IPTX v2.03-12
Lesson 5
Understanding Class of
Restriction
Overview
This lesson describes class of restriction and how it can be used to restrict access to PSTN
destinations as well as destinations local to CallManager Express.
Objectives
Upon completing this lesson, you will be able to describe class of restriction (COR) and
configure COR on the CallManager Express router. This includes being able to meet these
objectives:
Describe class of restriction
Describe steps to configure class of restriction
Describe a typical deployment
Class of Restriction
This topic describes COR
Features of COR
COR provides a way to deny certain calls based upon the
incoming and outgoing settings on dial peers and ephonedns.
Each dial peer and ephone-dncan have one incoming COR
and one outgoing COR.
COR can be used to control access to dialabledestinations
that are internal to the enterprise or external to the
enterprise.
The incoming COR list indicates the capacity of the dial peer
to initiate certain classes of calls.
The outgoing COR list indicates the capacity required for an
incoming dial peer to deliver a call via this outgoing dial peer.
IPTX v2.03-3
COR provides the ability to deny certain call attempts based on the incoming and outgoing
CORs provisioned on the dial peers.
COR is used to specify which incoming dial peer can use which outgoing dial peer to make a
call. Each dial peer can be provisioned with an incoming and an outgoing COR list. The COR
command sets the dial peer COR parameter for dial peers and for the directory numbers that are
created for Cisco IP Phones associated with the Cisco CallManager Express router. COR
functionality provides the ability to deny certain call attempts on the basis of the incoming and
outgoing class of restrictions that are provisioned on the dial peers. This functionality provides
flexibility in network design, allows users to block calls (for example, calls to 900 numbers),
and applies different restrictions to call attempts from different originators.
If the COR that is applied on an incoming dial peer (for incoming calls) is a superset or is equal
to the COR applied to the outgoing dial peer (for outgoing calls), the call goes through.
Incoming and outgoing, as referred to here, are with respect to the voice ports.
Example: Incoming and Outgoing COR Example

If a phone is attached to one of the FXS ports of the router and an attempt is made to place a
call from that phone, it is an incoming call and uses the incoming COR for the routers voice
port. Similarly, if you make a call to that FXS phone, then it is an outgoing call and uses the
outgoing COR for the voice port.
Incoming and Outgoing CORs

Incoming COROutgoing COR
oror
The incoming COR is like having one or more keys.
The lack of an incoming COR is like having a master key
that can unlock all locks.
The outgoing COR is like a lock or locks.
The lack of an outgoing COR is like having no lock.
IPTX v2.03-4
When the incoming COR list is applied to an ephone-dn or a dial peer, the members of the
COR list are similar to keys. These keys are used to unlock the outgoing COR list that is
applied to the ephone-dn or dial peer that matches the digits of the destination pattern. The
outgoing COR list is similar to having a lock or locks on it. In order to use the dial peer or
ephone-dn with an outgoing COR list, the incoming COR list must have all the members (keys)
that the outgoing COR list has.
The lack of an incoming COR list allows that ephone-dn or dial peer to call any other ephonedn or dial peer regardless of the outgoing COR list. This is like having a master key for all
locks. The lack of an outgoing COR list allows any ephone-dn or dial peer to complete calls to
this ephone-dn or dial peer regardless of the incoming COR setting.
Results of Incoming and Outgoing CORs

COR List on
COR List on
Incoming Dial Peer
Outgoing Dial
or Ephone-dn
Peer or Ephone-dn
Result
Reason
COR is not applied
No COR
No COR
Call succeeds
No COR
Outgoing COR
applied
Call succeeds
Incoming COR
applied
No COR
Call succeeds
Outgoing COR
applied
Call succeeds
Incoming COR list is a

superset of outgoing
COR list
Outgoing COR
applied
Call cannot be
completed
TncomingCOR list is
not a superset of
outgoing COR list
Incoming COR
applied is a
superset of
outgoing COR
Incoming COR
applied not a
superset of
outgoing COR
The no (null) incoming

COR condition has
highest COR priority
Incoming COR list is a
superset of the no
(null) outgoing COR
list
IPTX v2.03-5
By default, an incoming call leg has the highest COR priority and the outgoing COR list has the
lowest COR priority. This means that if there is no COR configuration for incoming calls on a
dial peer, then you can make a call from this dial peer (a phone attached to this dial peer) going
out any other dial peer, regardless of the COR configuration on that dial peer.
Steps to Configure Class of Restriction

This topic presents the steps to configure COR.
Configuration COR
Step 1 Configure the class of restriction names.
Step 2 Configure the class of restriction lists and
members.
Step 3 Assign the COR list to the dial peers.
Step 4 -Assign the COR to the ephone-dns.
IPTX v2.03-6
Configuring COR Names

Step 1 Configure the class of restriction names.
Enters COR configuration mode where classes of

restrictions are specified
--
Used to specify a class of restriction
Step 1
IPTX v2.03-7
Before relating a COR to a dial peer, it needs to be named. This is important because
the COR list needs to refer to these names to apply the COR to dial peers and
ephone-dns. Multiple names can be added to represent various COR criteria. The
dial-peer cor custom and name commands define the COR functionality. Possible
names are call1900, call527, and call9. Up to 64 COR names can be defined
under the dial peer cor custom command. This means that a configuration cannot
have more than 64 COR names and that a COR list is limited to 64 members.
Example: Name the COR and Lists

CMERouter(config)#dial-peer cor custom
CMERouter(config-dp-cor)#namelocal_call
CMERouter(config-dp-cor)#name911
Configuring COR Lists and Members

Step 2 Configure the class of restriction lists and
members.
- -
Provides a name for a list of restrictions

-
--
Adds a COR class to this list of restrictions
Step 2
IPTX v2.03-8
Dial peer COR list and member commands set the capabilities of a COR list. A COR
list is used in dial peers to indicate the restriction that a dial peer has as an outgoing
dial peer. The order of entering the members is not important and the list can be
appended or made shorter by removing the members.
Example: Define the COR Lists

CMERouter(config)#dial-peer cor list callLocal
CMERouter(config-dp-corlist)memberlocal_cal l
CMERouter(config)#dial-peer cor listcall911
CMERouter(config-dp-corlist)member911
Assigning COR List to Dial Peers

Step 3 Assign the COR list to the dial peers.
Defines a dial peer and enters dial-peer

configuration mode
Specifies a COR list to be used when the dial peer is

either the incoming or outgoing dial peer
Step 3
IPTX v2.03-9
Apply the incoming or outgoing COR list to the dial peer. The incoming COR list
specifies the capacity of the dial peer to initiate a certain series or class of calls. The
outgoing COR list specifies the destinations to which the dial peer will be able to
place calls.
Example: Apply the COR to the Dial Peer

CMERouter(config)#dial-peer voice1 pots
CMERouter(config-dial-peer)#destination-pattern 1500
CMERouter(config-dial-peer)#port 1/0/0
CMERouter(config-dial-peer)#corlist incoming call911
CMERouter(config)#dial-peer voice 2pots
CMERouter(config-dial-peer)#destination-pattern 1800.......
CMERouter(config-dial-peer)#port 2//1
CMERouter(config-dial-peer)#corlist outgoing call1800
Assigning COR List to Ephone-dns

Step 4 Assign the COR list to the Ephone-dns.
Defines an ephone-dn and enters ephone-dn mode
Specifies a COR list to be used when the ephone-dn

is used as either the incoming or outgoing part of
a call
Step 4
IPTX v2.03-10
Apply the incoming or outgoing COR list to an ephone-dn. The incoming COR list
specifies the capacity of an ephone-dn to initiate a certain series or class of calls.
The outgoing COR list specifies the ability on the ephone-dn to be able to place calls
to a given number range.
Example: Apply the COR to Ephone-dns

CMERouter(config)#ephone-dn 1
CMERouter(config-ephone-dn)#number 1000
CMERouter(config-ephone-dn)#description LobbyPhone
CMERouter(config-ephone-dn)#cor incoming call911
CMERouter(config)#ephone-dn 2
CMERouter(config-ephone-dn)#number 1001
CMERouter(config-ephone-dn)#description ConfRoomPhone
CMERouter(config-ephone-dn)#cor incoming callLocal
Example: COR
-

The executive can call the employee but the

employee cannot call the executive.
The incoming COR employee is not a
superset of the executive, so the call will not
succeed.
-

-

Ephone-dn 1
Employee
Ephone-dn 2
Executive
Ext 1000
Ext 2000
IPTX v2.03-11
Example: COR Used to Restrict Access Internally Within Cisco

CallManager Express
COR can be used to regulate internal calls, including whether they are allowed. This example
shows two IP Phones with an employee and an executive. In this company, the executive
should be able to call anyone, but employees should not be able to call the executive. Notice
that to accomplish the required results, both an incoming COR on the employee must be
configured as well as an outgoing COR on the executive. But there is no outgoing COR on the
employee, so anyone can call the employee phone whether the phone that is calling has an
incoming COR set or not. The lack of an incoming COR on the executive allows the executive
to call any phone regardless of the outgoing COR setting on the phone that is called.
COR Case Study: XYZ Company

The XYZ company wishes to prevent toll fraud by restricting the
destinations on the PSTN that IP Phones and analog phones attached to
the FXS port can call.
XYZ wants no internal restrictions; anyone internal should be able to
call anyone else internal.
All phones must be able to call 911.
Within XYZ, there are lobby phones, employee phones, sales phones,
and executive phones.
The lobby phone should be able to call only 911 on the PSTN.
The employee phones should be able to call 911 and make local calls
on the PSTN.
The sales phones should be able to call 911 and make local callsand
domestic long distance on the PSTN.
The executives should be able to call 911 and make local calls,
domestic long distance calls, and international calls on the PSTN.
No one should be able to call 900 numbers.
IPTX v2.03-12
COR Case Study: XYZ Company (Cont.)

-

-

911
local
long_distance
international
900
Step 1 -Define the classes of restriction.

Step 1
The first step is to define the COR names.
IPTX v2.03-13

-

-

-
-
-

-

-

-

-

-
-

-

Step 2 Define the COR lists and members.

IPTX v2.03-14
Step 2
The second step is to define the COR list and its member or members. Notice that
none of the COR lists contain the member 900.

Step 3 Assign the COR to the
PSTN dial peers.
Dial peer 1 COR out call 911
-

-
-
Dial peer 2 COR out call LD

-
-
Dial peer 3 COR out call

Local

-
-
Dial peer 4 COR out call Int

-
-
Dial peer 5 COR out call 900
Step 3
Note
IPTX v2.03-15
Assign the COR to the dial peers that govern PSTN access. To restrict calls to the
PSTN destinations, the outbound COR setting is defined.
Although not shown here, the inbound COR can be set to regulate where calls that arrive
from the PSTN are allowed to connect internally.

Step 4 Assign the COR to the ephone-dns.

Ephone-dn 1
COR in Lobby
Ext 1001
Ephone-dn 2
COR in Employee
Ext 1002
Ephone-dn 3
COR in Sales
Ext 1003
Ephone-dn 4
COR in Executive
Ext 1004
IPTX v2.03-16
Step 4
Assign the incoming COR to the lobby, employee, sales, and executive ephone-dns.
Notice that no ephone-dn has the ability to call 900 numbers.

Results:
The lobby ephone-dn can call only

911 on the PSTN.
The employee ephone-dn can call
911 and local calls on the PSTN.
The sales ephone-dn can call 911
and make local and domestic long
distance calls on the PSTN.
The executive ephone-dn can call
911 and make local calls, domestic
long distance calls, and
international calls on the PSTN.
No one can call 900 numbers.
Ephone-dn 1
COR in Lobby
Ext 1001
Ephone-dn 2
COR in Employee
Ext 1002
Ephone-dn 3
COR in Sales
Ext 1003
Ephone-dn 4
COR in Executive
Ext 1004
IPTX v2.03-17
The result of the configuration is that the lobby phone is only one able to place 911 calls to the
PSTN and internal destinations. The employee phone can only call 911, local seven-digit
numbers on the PSTN, and internal destinations. The sales phone can call 911, local seven-digit
numbers, long distance with 11 digits on the PSTN, and internal destinations. The executive
phone can call 911, local, long distance, international on the PSTN, and internal destinations.
No one can call 900 numbers on the PSTN.
Summary
Summary
A dial peer is an addressable endpoint.
Cisco voice-enabled routers support POTS dial peers and VoIP dial
peers.
Basic POTS dial-peer configuration consists of defining the dial peer
with a tag number and POTS designation, defining the destination
pattern, and defining the voice port to which the device is connected.
Basic VoIP dial-peer configuration consists of defining the dial peer
with a tag number and VoIP designation, defining the destination
pattern, and defining the remote voice-enabled router through the
session target command.
The destination-pattern on a dial peer can utilize wildcards to simplify
configuration.
The default dial peer is used when no match in the configured dial peers
is found.
Class of restrictions can be used to control the allowable destinations
for either an incoming or outgoing call.
IPTX v2.03-18
Lesson 6
Describing H.450.x Protocols

Overview
This lesson discusses the supported protocols in Cisco CallManager Express 3.2.1. Those
protocols are: H.450.2, which is used for transfers; H.450.3, which is used for forwarding calls;
and H.450.12, which is used to detect if a remote device supports these protocols.
Objectives
Upon completing this lesson, you will be able to describe call transfer and forwarding using
H.450.x series. This includes being able to meet these objectives:
Describe the different protocols in the H.450.x series
Describe H.450.2 call transfer and H.450.3 call forwarding implementation
Describe H.450.2 and H.450.3 deployment issues and possible workarounds
H.450.x Series Protocols
This topic describes the H.450.x protocols supported in Cisco CallManager Express 3.2.1.
Protocols in the H.450.x Series

H.450.1 General
*H.450.2 Transfer
*H.450.3 Forwarding
H.450.4 Call Hold
H.450.5 Call Park
H.450.6 Call Waiting
H.450.7 MWI
H.450.8 Name
Identification
H.450.9 Callback
H.450.10 Camp On
H.450.11 Barge
*H.450.12 Capabilities
* Supported in Cisco CallManager Express 3.1

IPTX v2.03-3
If you work with VoIP networks, ensuring compatibility between all of the equipment is a
constant challenge. Even basic call connections can be challenging because of the variety of
standards-based signaling protocolsH.323, session initiation protocol (SIP), Media Gateway
Control Protocol (MGCP), H.248, and so onand the varying vendor implementations. With
supplementary services, interoperability is even more of an issue.
The ITU currently defines 12 recommendations (H.450.1, H.450.2, H.450.3, and soon through
H.450.12) for supporting various supplementary services in an H.323 network. Cisco
CallManager Express 3.2.1 currently supports these three protocols of the 12 in the H.450.x
series:
H.450.2call transfers
H.450.3call forwarding
H.450.12detection of H.450.x series protocols on a remote device
Call Transfer Using H.450.2
This topic describes the H.450.2 protocol, which is used for call transfers.
H.450.2 Transfer
B
A calls B.
B wants to transfer to C and

places consultation call. B
and C talk.
A
A
A
C
B
B commits transfer. B
requests and receives an
H.450.2 consultation-ID
from C.
B sends transfer request to

A with consultation-ID.
A calls C, including the

consultation-ID in the call
setup message.
As call to C is successful. A
and C disconnect calls to B.
B
A
B
A
B
A
IPTX v2.03-4
H.450.2 protocol defines two ways for a transfer to take place:

Transfer without consultationThe call is transferred without knowing if the destination
to which the call is transferred will answer.
Transfer with consultationThe call is transferred after the person transferring has called
and consulted with the destination to which the call is going to be transferred.
A typical call flow using H.450.2 to transfer a call follows these steps:
Step 1
A calls B.
Step 2
B transfers to C with a consultation call to C.
Step 3
B talks with C, B commits a transfer, B requests, then receives an H.450.2

consultation-ID from C.
Step 4
B sends a transfer request to A with consultation-ID.
Step 5
A calls C, including the consultation-ID in the call setup message.
Step 6
As call to C succeeds; A and C disconnect the call to B.
The consultation-ID mechanism is a central component of H.450.2. It helps route the

transferred call to the right physical line by ensuring that the A-to-C call goes to the correct
destination, and it resolves issues in which multiple phone lines have the same telephone
number.
H.450.2 Transfer Advantages

Final A-to-C call path is optimal, with no hair-pin
media or control path, for example:
New York calls Los Angeles and is transferred to
London. Final call is direct from New York to
London (not via Los Angeles).
Call parameters for A-B, B-C, and A-C can all be
different (e.g., different codecs).
After the transfer is committed, all resources at B
are released; H.450.2 is very scalable.
There is no H.450.2 limit to the number of times a
call can be transferred.
IPTX v2.03-5
When connecting a Cisco CallManager Express system to another Cisco CallManager Express
system or to a voice gateway, the use of H.450.2 is very desirable because of the following
reasons:
Path optimizationThe final path of the data that contains the voice is optimal and does
not have to traverse through the device that performed the transfer.
Flexible settingsThe settings, like codec, VAD, and others, can change from the original
destination to the transferred destination.
ScalableBecause the device that transferred the call is no longer involved in either the
data path or the signaling, the H.450.2 protocol is very scalable, and there is no limit to
how many times the call can be transferred.
H.450.2 Transfer Disadvantages

All voice gateway routers in the network must
support H.450.2.
Calls may drop and transfers will not complete
correctly if participating endpoints do not support
H.450.2.
H.450.2 is used even when the transferee is on the

same Cisco CallManager Express system as the
transferor; the transferee must still support
H.450.2.
IPTX v2.03-6
When H.450.2 is used in the network, all Cisco CallManager Express systems and voice
gateways involved in the voice path must support the H.450.2 protocol. If this is not configured
or supported on all systems and other mechanisms are not employed, then the symptoms
transfers will fail and the caller will be hung up on. The workaround for this problem is to use a
hairpin connection, which can cause latency and bandwidth inefficiencies.
H.450.2 Transfer Commands
Enters voice service mode

-
--
Enables H.450.2 globally for calls transferred to the

system (enabled by default)
--
Enables H.450.2 on a dial peer for calls transferred to

the system (overrides the system level command)
IPTX v2.03-7
H.450.2 Commands
Command
Description
Enters voice service configuration mode to establish

global call transfer and forwarding parameters.
Example:
-
--
Example:
-
--
Example:
--
(Optional) Enables H.450.2 supplementary services

capabilities exchange globally. This is the default. Use
the no form of this command to disable H.450.2
capabilities globally. This command is also used in dialpeer configuration mode to affect a single dial peer.
If this command is enabled globally and enabled on
a dial peer, the functionality is enabled for the dial
peer. This is the default.
If this command is enabled globally and disabled
on a dial peer, the functionality is disabled for the
dial peer.
If this command is disabled globally and either
enabled or disabled on a dial peer, the functionality
is disabled for the dial peer.
H.450.2 Transfer Commands (Cont.)

-
--- -
-
Sets the system transfer mechanism

-
Enables transfers to nonephone-dn destinations
IPTX v2.03-8
H.450.2 Commands (Cont.)

Command
Description
---

Defines the call transfer method to allow call transfer with

consultation for all lines served by the router.
-
-
For SIP networks, use only the full-blind keyword or the

full-consult keyword. For more information about SIP, refer to
Cisco IOS SIP Configuration Guide .
Example:
Router(config-telephonyservice)#
transfer-system full-consult
blindCalls are transferred without consultation with a

single phone line using the Cisco-proprietary method.
full-blindCalls are transferred without consultation using
H.450.2 standard methods.
full-consultCalls are transferred with consultation using
H.450.2 standard methods and a second phone line if
available. The calls fall back to full-blind if the second line is
unavailable.
local-consultCalls are transferred with local consultation
using a second phone line if available. The calls fall back to
blind for nonlocal consultation and nonlocal transfer target.
-
-
Example:
Router(config-telephonyservice)#
transfer-pattern .T
Allows transfer of telephone calls by Cisco IP Phones to

specified phone number patterns. If no transfer pattern is set,
the default is that transfers are permitted only to other local IP
Phones.
transfer-patternString of digits for permitted call transfers.
Wildcards are allowed. A pattern of .T transfers all calling
parties using the H.450.2 standard.
blind(Optional) When H.450.2 consultative call transfer is
configured, it forces transfers that match the pattern
specified in this command to be executed as blind transfers.
It overrides settings that are made using the transfersystem and transfer-mode commands.
Note: When defining transfers to nonlocal numbers, it is
important to note that transfer-pattern digit matching is
performed before translation-rule operations. Therefore, you
should specify in this command a pattern that matches the digits
that are actually entered by phone users before they are
translated.
Example: H.450.2 Transfer

H.450.2 is turned on by default in Cisco CallManager Express 3.1,
for calls transferred to the system.
H.450.2 must be enabled for initiating transfers within the system.
-
--

-
--
---
-
--- -
-
A default setting that enables H.450.2

globally for transferred parties
Dial-peer setting overrides the
global setting for transferred parties
Enables the system to initiate transfers
and specifies the type of transfer
Specifies which nonephone-dn
destinations that calls can be
transferred to
IPTX v2.03-9
This example shows H.450.2 being enabled on the Cisco CallManager Express router for calls
that are transferred to the system through the use of the supplementary-service h.450.2
command. This is enabled by default, so the only reason to use this command is if H.450.2 has
been previously disabled. The supplementary-service h.450.2 command on the dial peer will
override the systemwide setting and disable H.450.2 for that single dial peer.
To enable the use of H.450.2 for call transfers initiated in the Cisco CallManager Express
system, the command transfer-system must be used with either the full-consult or full-blind
keyword. By default, a proprietary non-H.450.2 blind transfer is used until this is entered. For
transfers to be enabled for nonephone-dn destinations in Cisco CallManager Express, the
transfer-pattern command must be entered.
Note
Without the transfer-pattern command, only transfers from one ephone-dn to another will
work. By default, external destinations are not valid transfer targets.
Call Forwarding Using H.450.3
This topic describes call forwarding using the H.450.3 protocol.
H.450.3 Forwarding
A calls B.
B
A
C
B wants to forward As
call to C.
B sends forward request

to A.
B
A
B
A
B
A
C
B
A calls C.
As call to C is
successful. A
disconnects call
attempt to B.
H.450.3 protocol defines a standards-based mechanism to forward a call.

A typical call flow using H.450.3 to forward a call follows these steps:
Step 1
A calls B.
Step 2
B has been configured to forward all calls to C.
Step 3
B sends an H.450.3 forward request to A.
Step 4
A calls C.
Step 5
C answers and is connected to A.
Step 6
As call to C succeeds; B is no longer involved.
IPTX v2.03-10
H.450.3 Advantages
The final A-to-C call path is optimal, with no hair-pin
media or control path, for example:
New York calls Los Angeles and is forwarded to
London. Final call is direct from New York to London
(not via Los Angeles).
Call parameters for A-B and A-C can be different
(e.g., different codecs).
After forwarding is done, all resources at B are
released; H.450.3 is very scalable.
There is no H.450.3 limit to the number of times a call
can be forwarded.
IPTX v2.03-11
When connecting a Cisco CallManager Express system to another Cisco CallManager Express
system or to a voice gateway, the use of H.450.3 is very desirable because of the following
reasons:
Path optimizationThe final path of the data that contains the voice is optimal and does
not have to traverse through the device that performed the transfer.
Flexible settingsThe settings, like codec, VAD, and others, can change from the initial
destination to the forwarded destination.
ScalableBecause the device that forwards the call is not involved in either the data path
or the signaling, the H.450.3 protocol is very scalable, and there is no limit to how many
times the call can be forwarded.
H.450.3 Disadvantages
All voice gateway routers in the network must
support H.450.3.
Calls may drop if participating endpoints do not
support H.450.3.
H.450.3 is used even when the transferee is on the

same Cisco CallManager Express system as the
phone that requests the forwarding. The transferee
must still support H.450.3.
IPTX v2.03-12
The main disadvantage of using H.450.3 is that all Cisco CallManager Express routers and
voice gateways that are involved in the voice path must have the protocol enabled and must
support the H.450.3 protocol. A hairpin must be used if H.450.3 cannot be enabled on all voice
gateways, which can cause inefficient use of bandwidth and increased latency and call setup
problems.
H.450.3 Forward Commands

-
--
Enables H.450.3 globally (enabled by default)
--
Enables H.450.3 on a dial peer

Dial peer setting overrides the global voice service setting
IPTX v2.03-13
H.450.3 Commands
Command
Description
Enters voice service configuration mode to establish

global call transfer and forwarding parameters.
Example:
-
--
Example:
-
--
Example:
--
(Optional) Enables H.450.3 supplementary services

capabilities exchange globally. This is the default. Use
the no form of this command to disable H.450.3
capabilities globally. This command is also used in dialpeer configuration mode to affect a single dial peer.
If this command is enabled globally and enabled on
a dial peer, the functionality is enabled for the dial
peer. This is the default.
If this command is enabled globally and disabled
on a dial peer, the functionality is disabled for the
dial peer.
If this command is disabled globally and either
enabled or disabled on a dial peer, the functionality
is disabled for the dial peer.
H.450.3 Forward Commands (Cont.)

-
Enables forwarding to nonephone-dn destinations
IPTX v2.03-14
H.450.3 Commands (Cont.)

Command
Description
Specifies the H.450.3 standard for call forwarding. Calling-party

numbers that do not match the patterns that are defined with this
command are forwarded using Cisco-proprietary call forwarding
for backward compatibility.
Example:
patternDigits to match for call forwarding using the

H.450.3 standard. If an incoming calling-party number
matches the pattern, it can be forwarded using the H.450.3
standard. A pattern of .T forwards all calling parties using
the H.450.3 standard.
Note: When defining forwards to nonlocal numbers, it is
important to note that pattern digit matching is performed before
translation-rule operations. Therefore, you should specify in this
command a pattern that matches the digits that are actually
entered by phone users before they are translated.
Example: H.450.3 Forwarding

H.450.3 is turned on by default for forwards to the system.
H.450.3 must be enabled for forwards initiated within the
system.
-
--

-
--
---
-

A default setting that enables H.450.3

globally for forwarded parties
Dial-peer setting overrides the global
setting for forwarded parties
Specifies which non-ephone-dn
destinations that calls can be
forwarded to.
IPTX v2.03-15
This example shows H.450.3 being enabled on the Cisco CallManager Express router for calls
that are forwarded to the system through the use of the supplementary-service h.450.3
command. This is enabled by default, so the only reason to use this command is if H.450.3 has
been previously disabled. The supplementary-service h.450.3 command on the dial peer will
override the systemwide setting and disable H.450.3 for that single dial peer.
To enable the use of H.450.3 for call forwarding initiated in the Cisco CallManager Express
system, the command call-forward pattern must be used to define any nonephone-dn
destinations that a call can be forwarded to.
H.450.12
This topic describes the H.450.12 protocol.
H.450.12 Capabilities
Cisco CallManager Express 3.1 adds H.450.12 support.
H.450.12 provides a supplementary services indication capabilities
exchange.
H.450.12 allows dynamic auto detection of
non-H.450.x-capable endpoints.
H.450.12 indications are provided on Setup, Proceeding, Alerting
and Connect messages.
H.450.12 allows the Cisco CallManager Express 3.1 system to
explicitly detect if H.450.2 and H.450.3 are supported on a
call-by-call basis.
If H.450.2 and H.450.3 is not supported, Cisco CallManager Express
3.1 can fall back to providing hairpin VoIP-to-VoIP call routing
(for H.323).
Previous versions of Cisco CallManager Express support H.450.2
and H.450.3 but not H.450.12.
IPTX v2.03-16
The H.450.12 call capabilities standard provides a means to advertise and discover H.450.2 and
H.450.3 capabilities in voice gateway endpoints on a call-by-call basis. When H.450.12 is
enabled, H.450.2 and H.450.3 services are disabled for call transfers and call forwarding unless
a positive H.450.12 indication is received from all the other VoIP endpoints that are involved in
the call. If a positive H.450.12 indication is received, the router uses the H.450.2 standard for
call transfers and the H.450.3 standard for call forwarding. If a positive H.450.12 indication is
not received, the router uses the alternative method that you have configured for call transfers
and forwards, either hairpin call routing or an H.450 tandem gateway.
Note
Cisco CallManager Express 3.0 does not provide H.450.12 indications for calls even though
it supports theH.450.2 and H.450.3 standards.
Using H.450.12
When you turn on the H.450.12 service, H.450.2
and H.450.3 are disabled unless a positive H.450.12
indication is received from all the other VoIP
endpoints involved in the call.
H.450.12 is turned off by default to minimize risk of
compatibility issues with third-party H.323
systems.
IPTX v2.03-17
H.450.12 capabilities are disabled by default to minimize the risk of compatibility issues with
other types of H.323 systems. This optional task allows you to enable H.450.12 capabilities
globally or by individual dial peer.
H.450.12 Commands

-
-- -
Enables H.450.12 (disabled by default)
IPTX v2.03-18
When all Cisco CallManager Express systems are running version 3.2.1, the command
supplementary-service h.450.12 may be used to enable the H.450.12 protocol. This allows the
Cisco CallManager Express systems to detect on a call-by-call basis if the devices that are
involved with a transfer or forward support H.450.x protocols.
The supplementary-service h450.12 command with the advertise-only keyword is intended
for use on Cisco CallManager Express 3.2.1 systems that are mixed in a network with Cisco
CallManager Express 3.0 systems. This scenario is usually found when you are upgrading a
network from Cisco CallManager Express 3.0 to Cisco CallManager Express 3.2.1. When you
use the advertise-only keyword, the Cisco CallManager Express 3.2.1 router sends out
H.450.12 indications for the benefit of remote VoIP endpoints, but does not require H.450.12
responses and has H.450.2 and H.450.3 enabled for all calls (the default). When in advertiseonly mode, Cisco CallManager Express 3.2.1 is still able to automatically detect Cisco
CallManager systems.
Issues and Workarounds for H.450.x Protocols
This topic describes the issues and workarounds commonly found in Cisco CallManager
Express deployments.
Issues and Workarounds

CallManager does not support H.450.x protocols.
VoIP-to-VoIP hairpin call routing can be inefficient
and bandwidth-intensive.
A mixed Cisco CallManager Express mixed 3.0 and
3.1 environment presents special considerations.
Upgrading Cisco CallManager Express 3.0 to 3.1
presents migrating issues.
IPTX v2.03-19
When deploying Cisco CallManager Express 3.2.1 in an enterprise, it is important to

understand some of the common issues that you may encounter. There are often some viable
workarounds that can be implemented to deal with some of these issues. The issues and
workarounds that are discussed in this section include:
CallManagerCisco CallManager does not support the H.450.x protocols.
VoIP-to-VoIPA VoIP-to-VoIP hairpin can allow for transfers and forwards when not all
devices support H.450.x protocols.
Mixed-version environmentIssues in a mixed Cisco CME 3.0 and 3.1 or greater
environment present issues because of a mismatch in supported protocols.
UpgradingUpgrading multiple Cisco CallManager Express routers from 3.0 to 3.1 or
greater can cause a protocol mismatch that must be dealt with.
Detecting CallManager
CallManager does not support H.450.2, H.450.3,
or H.450.12.
A proprietary detection mechanism is used.
CallManager sends a nonstandard identifier in
most of its H.225 messages. This tells you that
H.450.x can not be supported for the call.
This is useful if you have both CallManager and
older Cisco CallManager Express 3.0 systems
in the same network and, therefore, cannot use
H.450.12.
IPTX v2.03-20
Cisco CallManager does not support the H.450.x protocols. This lack of support can be
detected through a proprietary mechanism. This mechanism is an H.225 message within the
H.332 protocol suite. The presence of this nonstandard message is enough to inform the Cisco
CallManager Express router not to use H.450.x protocols with this device. As a result, a VoIPto-VoIP gateway must be configured to allow the transfer and forwarding of calls between the
Cisco CallManager and Cisco CallManager Express systems.
VoIP-to-VoIP Hairpin Calls

When H.450.x protocols are not supported, a VoIP-to-VoIP
hairpin may be used.
This can cause call routing efficiency issues.
Inefficient bandwidth consumption may occur on WAN
links.
This is explicitly enabled and is disabled by default.
Hairpinning, when enabled, will be used if one of the
following conditions are met:
H.450.12 is used to detect that H.450.2/3 is not
supported by remote VoIP system.
H.450.2 and H.450.3 are explicitly disabled.
Cisco CallManager Express 3.1 auto-detects that the
remote system is a CallManager.
IPTX v2.03-21
VoIP-to-VoIP connections permit the termination and reorigination of transferred and

forwarded calls over the VoIP network. VoIP-to-VoIP connections are used for hairpin call
routing and for H.450 tandem gateways. The only types of VoIP-to-VoIP connection that is
supported by Cisco CallManager Express 3.2.1 is H.323-to-H.323 and H.323-to-SIP
connections. The H.323-to-SIP may only be used to connect to the CUE module.
VoIP-to-VoIP connections are disabled on the router by default, and they must be explicitly
enabled to make use of hairpin call routing or an H.450 tandem gateway. In addition, you must
configure a mechanism to direct transferred or forwarded calls to the hairpin or the H.450
tandem gateway. You do this by using one of the following methods:
Enable H.450.12 capabilities globally or on the routes that your transfers and forwards take.
Explicitly disable H.450.2 and H.450.3 capabilities globally or on the routes that your
transfers and forwards take.
Enabling VoIP-to-VoIP Hairpin Calls

-
Enables the VoIP-to-VoIP hairpinningof forwards

and transfers
IPTX v2.03-22
VoIP-to-VoIP Hairpin Commands

Command
Description
Enters voice service configuration mode to establish global call

transfer and forwarding parameters.
Example:
-
-

Enables VoIP-to-VoIP call connections. Use the no form of the

command to disable VoIP-to-VoIP connections.
Example:
Note: This is disabled by default and must be enabled if desired.
-
-
Example: VoIP-to-VoIP Hairpin Call

1000
1000
CallManager
CallManager
Express
Express A
A
Non-H.450
Gateway
Step 1 -Call from

1000 to 2000
2000
2000
CallManager
CallManager
Express
Express B
B
Step 2 -Transfer
or forward to 3000
IP WAN
Step 3 Call is hairpinned
and connected to 3000
3000
3000
-
-
IPTX v2.03-23
In this example, the following steps are happening in the call flow:
Step 1
A call from an IP Phone on Cisco CallManager Express router A is placed to an IP

Phone on Cisco CallManager Express router B.
Step 2
The call is transferred or forwarded to an IP Phone off a Cisco CallManager cluster

(Cisco CallManager does not support H.450.2 or H.450.3).
Step 3
The call is transferred or forwarded through the use of a hairpin on the Cisco
CallManager Express router B (the ability to perform the hairpin must be enabled on
B).
Notice that the bandwidth between Cisco CallManager Express router B and the WAN cloud is
double the amount that is used for a single call. In addition, the latency of the WAN to Cisco
CallManager Express router B is also cumulative. Both of these issues must be taken into
account when deciding to use this workaround.
Using Cisco CallManager Express 3.1

with 3.0
Turn on H.450.12 in advertise-only mode.
The router sends out H.450.12 indications for the benefit of
remote VoIP endpoints.
Cisco CallManager Express does not require a H.450.12 response
and has H.450.2 and H.450.3 enabled for all calls in this mode.
This is intended to assist with Cisco CallManager Express 3.0 to
Cisco CallManager Express 3.1 network upgrades.
Cisco CallManager Express 3.1 can still auto-detect a
CallManager in this mode.
Both the Cisco CallManager Express 3.1 and Cisco CallManager
Express 3.0 assume that H.450.2 and H.450.3 can be used for all
calls.
If detected, CallManager is auto-detected by Cisco CallManager
Express and may use hairpinningif enabled.
IPTX v2.03-24
The supplementary-service h450.12 command with the advertise-only keyword is intended

for use on Cisco CallManager Express 3.1 or greater systems that are mixed in a network with
Cisco CallManager Express 3.0 systems. In this mode, Cisco CallManager Express does not
require a response to an H.450.12 message that the 3.0 version system does not understand.
This allows the system to effectively communicate with other 3.1 or greater systems and still
use H.450.2 and H.450.3 with 3.0 systems.
Note
The auto-detection of Cisco CallManager is still supported in this mode through a proprietary
H.225 message identifier.
Upgrading Cisco CallManager Express

3.0 to 3.1
As each new Cisco CallManager Express 3.1 is
installed, turn on H.450.12 in advertise-only mode.
supplementary-service h.450.12 advertise only
When all Cisco CallManager Express 3.0 systems
in the network have been upgraded to CallManager
Express 3.1:
remove the advertise-only restriction
supplementary-service h.450.12
IPTX v2.03-25
When upgrading, use the command supplementary-service h.450.12 advertise-only on the

new Cisco CallManager 3.1 or greater system. This allows for the coexistence of both Cisco
CallManager 3.0 and 3.1 or greater without loss of supplemental services. When all Cisco
CallManager Express systems are upgraded to 3.1 or greater, remove the advertise-only
keyword from all systems.
Summary
Summary
H.450.2 is used to efficiently transfer calls from one H.450.2 device to
another.
H.450.3 is used to forward calls efficiently from one H.450.3 device to
another.
H.450.12 is used to detect whether a device supports H.450.2 or H.450.3.
Cisco CallManager Express 3.1 supports H.450.2, H.450.3, and H.450.12.
H.450.2 transfer and H.450.3 forward are enabled by default for transferred
and forwarded calls that arrive at Cisco CallManager Express3.1.
Support for initiating an H.450.2 transfer or H.450.3 forward must be enabled
on the Cisco CallManager Express router.
When H.450.x protocols are disabled or not supported, a VoIP-to-VoIP
hairpin may be used. This ability is disabled by default.
CallManager, which does not support H.450.x protocols, can be
automatically detected by Cisco CallManager Express .
When upgrading Cisco CME 3.0 to 3.1, enable H.450.12 with advertise-only
mode until all the Cisco CallManager Expressrouters have been
upgraded to 3.1.
IPTX v2.03-26
Module Summary
Module Summary
This module defined how to configure voice interfaces, dial peers, and VoIP
communications.
As a result of completing this module, learners should have an
understanding of the types of analog interfaces that are supported in Cisco
CallManagerExpress.
As a result of completing this module, learners should have an
understanding of the types of digital interfaces that are supported in Cisco
CallManagerExpress.
In addition, learners should be able to configure voice interfaces with IOS
commands.
Learners should have an understanding of dial peers and how theyare
configured.
Learners should understand how digits are matched to dial peers and how
digits can be manipulated.
As a result of completing this module, the learner should have an
understanding of the H.450.x protocols and the issues that may be
encountered when using the H.450.x protocols.
IPTX v2.03-1
This module dealt with the supported analog and digital voice interfaces that can be used by
Cisco CallManager Express. Analog interfaces can be used for analog phones, faxes, or analog
trunks. Digital connections can be used for digital trunks and are typically used in situations
that require a higher density of connections.
The concept of a dial peer and how they are configured was also covered in this module. The
dial peer is an essential part of the configuration of Cisco CallManager Express, and it is
important to understand how restrictions and manipulation of digits can be applied to it.
The H.450.2 protocol for call transfer was discussed, and the configuration of this protocol was
explained. The H.450.3 protocol for call forwarding was also covered in detail, and the
configuration explained. Finally, the H.450.12 protocol, which is new to Cisco CallManager
Express 3.1, was explained, and various deployment scenarios were covered.
References
Call Routing/Dial Plans: Understanding Inbound and Outbound Dial Peers on Cisco IOS
Platforms.
http://cisco.com/en/US/partner/tech/tk652/tk90/technologies_tech_note09186a0080147524.
shtml.
Call Routing/Dial Plans: Configuring Class of Restriction (COR).
http://cisco.com/en/US/partner/tech/tk652/tk90/technologies_configuration_example09186
a008019d649.shtml.
Module Self-Check
Q1) In most local-loop connections, to what does the ring wire tie? (Source: Identifying
Differences Between Analog and Digital Voice Interfaces)
A) battery
B) ground
C) telephone
D) switch
Q2) What are the three different types of local-loop signaling? (Choose three.) (Source:
Identifying Differences Between Analog and Digital Voice Interfaces)
A) address signaling
B) coding signaling
C) control signaling
D) informational signaling
E) remote signaling
F) supervisory signaling
Q3) Which call progress indicator is used to let you know that the telephone company is
working on completing the call? (Source: Identifying Differences Between Analog and
Digital Voice Interfaces)
A) busy
B) confirmation tone
C) dial tone
D) ringback
Q4) How many bits long is a T1 frame? (Source: Identifying Differences Between Analog
and Digital Voice Interfaces)
A) 128
B) 164
C) 192
D) 193
Q5) What are the two major frame formats for a T1? (Choose two.) (Source: Identifying
A) SF
B) CRC4
C) ESF
D) ESC4
Q6) In E1 framing, how many channels are available for voice or data? (Source: Identifying
A) 29
B) 30
C) 31
D) 32
Q7) Which type of voice port application automatically dials with prespecified digits?
(Source: Configuring Analog and Digital Voice Interfaces)
A) local call
B) on-net
C) off-net
D) PLAR
Q8) Which type of voice port application makes a call within the same city? (Source:
Configuring Analog and Digital Voice Interfaces)
A) local call
B) on-net
C) off-net
D) PLAR
Q9) Which of the following is not an FXS configuration parameter? (Source: Configuring
Analog and Digital Voice Interfaces)
A) signal
B) cptone
C) busyout
D) ring cadence
E) ring number
F) ring frequency
Q10) What command parameter sets an FXO port to answer after a certain number of rings?
(Source: Configuring Analog and Digital Voice Interfaces)
A) loop number
B) ring number
C) dial number
D) answer number
Q11) What two types of dial peers do Cisco routers support? (Choose two.) (Source:
Describing Dial-peers)
A) local
B) POTS
C) VoIP
D) WAN
Q12) When configuring POTS dial peers, which command is used to define the telephone
number? (Source: Describing Dial-peers)
A)
B)
C)
D)
dial number
ring number
session-pattern
destination-pattern
Q13) When configuring VoIP, which command is used to specify the gateway or destination
router? (Source: Describing Dial-peers)
A)
B)
C)
D)
session target
router-IP
gateway-address
IP-address
Q14) You must specify a destination pattern for each dial peer you configure. (Source:
Describing Dial-peers)
A) true
B) false
Q15) When an end-to-end call is established, how many inbound call legs are associated with
the call? (Source: Understanding Call Setup and Digit Manipulation)
A) 1
B) 2
C) 3
D) 4
Q16) What is the default dial-peer configuration for inbound POTS peers? (Source:
Understanding Call Setup and Digit Manipulation)
A) any codec
B) no IVR application
C) VAD-enabled
D) no RSVP support
E) IP precedence 0
Q17) What happens if there is no matching dial peer for an outbound call? (Source:
Understanding Call Setup and Digit Manipulation)
A) The default dial peer is used.
B) Dial peer 0 is used.
C) The POTS dial peer is used.
D) None of the above.
Q18) After the router strips off the left-justified digits, what are the remaining digits called?
(Source: Understanding Call Setup and Digit Manipulation)
A) leftover digits
B) wildcard digits
C) right-justified digits
D) one of the above
Q19) Call Manager Express 3.1 currently supports which three of the following H.450 series
protocols? (Choose three.) (Source: Describing ITU Supplementary Services)
A) H.450.2
B) H.450.3
C) H.450.11
D) H.450.12
Q20) Which of the H.450x series protocols defines transfers? (Source: Describing ITU
Supplementary Services)
A) H.450.2
B) H.450.3
C) H.450.11
D) H.450.12
Q21) In order for a transfer to be successful, at least one Cisco Call Manager Express or
gateway must be configured for H.450.2. (Source: Describing ITU Supplementary
Services)
A) true
B) false
Q22) What must be used if a device does not support H.450.3 protocol? (Source: Describing
ITU Supplementary Services)
A) bobby pin
B) hairpin
C) banana clip
D) hairspray

Q1) A
Q2) A, D, F
Q3) B
Q4) D
Q5) A, C
Q6) B
Q7) D
Q8) C
Q9) E
Q10) B
Q11) B, C
Q12) D
Q13) A
Q14) A
Q15) D
Q16) D
Q17) B
Q18) B
Q19) A, B, D
Q20) A
Q21) B
Q22) B
Module 4
Configuring Additional Cisco

Overview
This module discusses topics dealing with describing, defining, and configuring additional
features for a basic Cisco CallManager Express system.
Many of the features that are presented are necessary for successful deployment of Cisco
CallManager Express. These features include ways for a system administrator, customer
administrator, and user to interact with Cisco CallManager Express in a web-based GUI.
Critical features that need to be configured in many installations include the Auto Attendant,
Music on Hold (MOH), call transfer, and call forwarding features. Optional features include
paging groups, intercom functions, and customizing the rings of the Phones.
The Cisco CallManager Express system provides basic call center functions through a special
script that can be loaded onto the Cisco CallManager Express system. This script provides call
treatment and basic queuing functions.
In certain installations, integration between the IP Phone and software on the PC may be
desired. Integrating the two is possible through a Telephony Application Programming
Interface (TAPI), which can be installed on the PC and which allows the PC to interact with
the Cisco CallManager Express system.
Network management features provide a way for the administrator to monitor, configure, and
collect information regarding the Cisco CallManager Express environment.
Module Objectives
Upon completing this module, you will be able to configure additional Cisco CallManager
Express features. This includes being able to meet these objectives:
Describe and configure Cisco CallManager Express GUI features
Describe and configure IP Phone features
Describe the features that provide basic ACD functionality
Describe TAPI Lite support for Cisco CallManager Express
Describe the setup utility, syslog messages, and billing support
Lesson 1
Configuring Cisco
CallManager Express
GUI Features
Overview
This lesson defines how to set up, configure, and use the Cisco CallManager Express GUI and
the three different access levels.
Objectives
Upon completing this lesson, you will be able to describe and configure Cisco CallManager
Express GUI features. This includes being able to meet these objectives:
Identify the three user classes for the GUI
Identify the tasks for setting up the GUI
Describe how to access the GUI on the Cisco CallManager Express router
Describe and configure administrative user classes
User Classes
This topic describes the three user classes for the Cisco CallManager Express HTTP-based
GUI access.
Three User Classes

Cisco CallManager Express provides three
levels of HTTP-based GUI access:
System administrator
Customer administrator
Phone user
IPTX v2.04-2
The Cisco CallManager Express GUI provides a web-based interface to manage most
systemwide and Phone-based features. In particular, the GUI facilitates the routine additions
and changes associated with employee turnover, allowing these changes to be performed by
nontechnical staff.
The GUI provides three levels of access to support the following user classes:
System administrator: Able to configure all systemwide and Phone-based features. This
person is familiar with Cisco IOS software and Voice over IP (VoIP) network
configuration.
Customer administrator: Able to perform routine Phone additions and changes without
having access to systemwide features. This person does not have to be trained in Cisco IOS
software.
Phone users: Able to program a small set of features on their own Phone and search the
Cisco CallManager Express directory.
Note
The system administrator account must initially be configured through the command-line
interface (CLI).
System and Customer Administrator

Web-Based GUI
http://ip_address/ccme.html
IPTX v2.04-3
By default, the system administrator and the customer administrator have the same level of
access. The customer administrator can be customized to have a subset of the choices in the
menus. The choices in the drop-down menus are:
Configure: settings that deal with ephones, ephone-dns, and system settings
Voice Mail: settings that deal with voice mail settings and integrations
Administration: functions that involve backup and restore, saving changes, and reloading
the router
Reports: running and viewing various reports
Help: links to version information and the Help file
Note
The system administrator username and password can be changed from within the system
administrator GUI.
Copyright 2005, Cisco Systems, Inc. Configuring Additional Cisco CallManager Express Features 4-5
Phone User GUI
IPTX v2.04-4
The Phone user web-based GUI looks similar to the system administrator web-based GUI and
customer administrator web-based GUI. Phone users can make some basic changes to the
configuration of their Phones and can look up entries in the Cisco CallManager Express
directory. The three drop-down menus available to Phone users include very limited options:
Configure: limited settings for the users associated Phone
Search: search of the Cisco CallManager Express directory
Help: links to version information and the Help file for users
Cisco CallManager Express GUI Prerequisites

This topic describes the GUI prerequisite tasks to be completed.
Cisco CallManager Express GUI

Prerequisite Tasks
The following tasks must be completed
before the GUI is available:
Ensure that the proper files for the version of
Cisco CallManagerExpress are in the flash of the
router
Configure and enable the HTTP server on the
router
(Optional) Change the HTTP server authentication
method
Configure system administrator credentials
IPTX v2.04-5
The Cisco CallManager Express GUI uses HTTP to transfer information from the Cisco
CallManager Express router to the PC of an administrator or Phone user. The router must be
configured as an HTTP server and must have the proper web files locally in flash to serve up
to the browser. In addition, an initial system administrator username and password must be
defined from the router CLI. Customer administrators and Phone users can be added from
the Cisco CallManager Express router using CLI commands or from a PC using GUI web
pages. The GUI web page functions that are for customer administrators can be restricted and
customized with support in Cisco CallManager Express for extensible markup language (XML)
cascading style sheets (files with a .css suffix).
Note
In order to access the GUI, IE 6.0 or greater is required.

Prerequisite Tasks (Cont.)
Enables the HTTP server on the router
Sets the HTTP server path to the flash memory
Determines the type of authentication used by the

HTTP server
IPTX v2.04-6
The HTTP server on the Cisco CallManager Express router is disabled by default. In order to
enable it, enter the ip http server command from global configuration mode. This starts the
HTTP service, but does not define where the files are located that will be served up. To configure the
location of the files to be served up by the web server, enter the command ip http path flash:
from global configuration mode. Authentication is set to use the enable password by default. It
is recommended that authentication be configured to use an authentication, authorization, and
accounting (AAA) server or a local username and password pair. The ip http authentication
command is used to configure the authentication method that is desired.
HTTP Server Commands

Command
Description
Enables the Cisco web server on the local Cisco

CallManager Express router
Example:
-
-
Example:
Sets the base HTTP path for HTML files to flash

memory on the router

-

-
Example:

Customer administrators and Phone users
cannot bring about any changes with this
command.
Specifies method of authentication for the system

administrator to use when accessing the HTTP
server; default is the enable keyword
aaa: Indicates that the authentication method
used for the AAA login service should be used
for authentication. The AAA login service
method is specified by the aaa authentication
login command.
enable: Uses the enable password. This is the
default if this command is not used.
local: Uses login user name, password, and
privilege level access combination that is
specified in the local system configuration (by
the username global configuration command).
tacacs: Uses TACACS server.

Enters telephony-service configuration mode

-
-- - -- - -
-
Sets a username and password for the GUI system

administrator
IPTX v2.04-7
To configure the system administrator credentials, enter the telephony-service command from
global configuration mode. Then, from the telephony-service configuration mode, enter the
web admin system name username password string command. This defines an initial
username and password in order for the system administrator to access the GUI. After you have
created this account you can log in to the GUI. While in the GUI as the system administrator,
you can define the customer administrator and Phone users. Alternatively, you can use the
router CLI to create the customer administrator and Phone user credentials.
If the 0 option is used, then the password will not be encrypted and will be clearly visible in the
configuration. If the password is set with the 5 option, then the password will be displayed as a
Message Digest 5 (MD5) hash.
Note
There is only one system administrator set of credentials.
System Administrator Credentials Commands

Command
Purpose
- -
Example:
-
-- -
-- - -
-
Defines a username and password for a system

administrator. The default username is Admin.
There is no default password.
Example:
name username: System administrator

username
-
-- -

password string: String to verify system

administrator identity; default is empty string
secret {0 | 5} string: Password should be
encrypted. The digit specifies state of encryption
of the string that follows, as explained here:
0 Password that follows is not yet encrypted.
5 Password that follows is encrypted using MD5.
Note
The secret 5 keyword pair is used in the output of show commands when encrypted
passwords are displayed, and it indicates that the password that follows is encrypted.

(Optional) Enables the ability to add ephone directory

numbers through the Cisco CallManager Express GUI
-
(Optional) Enables the ability to set the system time

through the Cisco CallManager Express GUI
IPTX v2.04-8
By default, ephone-dns can be created only through the CLI of the Cisco CallManager Express
router. The ability to add ephone-dns through the web-based GUI can be enabled if desired. To
enable this functionality, use the dn-webedit command.
Similarly, the ability to set the system time of the Cisco CallManager Express router in the
web-based GUI is not available by default and must be enabled. This is the setting that
configures the time that appears on the display of the IP Phones. To enable the setting of time
in the web-based GUI, use the time-webedit command.
These settings provide a way for the nontechnical administrator to create new ephone-dns and
to modify the time through the web-based GUI instead of using the CLI, which the
nontechnical administrator may not be comfortable with.
Webedit Commands
Command
Description
(Optional) Enables the ability to add

directory numbers through the web-based
GUI. The no form of this command
disables the ability to create IP Phone
extension telephone numbers. If this
command is not used, the ability to create
directory numbers is disabled by default
through the GUI web interface.
Example:
Example:
(Optional) Enables the ability to set the

Phone time for the Cisco CallManager
Express system through the web-based
GUI.
Cisco discourages this method for
setting network time. The router should be
set up to automatically synchronize its
router clock from a network-based clock
source using Network Time Protocol
(NTP). In the rare case that an NTP clock
source is not available, the time-webedit
command can be used to allow manual
setting and resetting of the router clock
through the GUI.
Accessing the GUI
This topic describes how to access the GUI.
Accessing the GUI

Use IE 6.0 or greater.
Use the URL http://router_ipaddr/ccme.html.
Enter either system administrator, customer
administrator, or Phone user credentials when
prompted.
IPTX v2.04-9
To access the administrative web site to make changes, use the URL
http://router_ipaddr/ccme.html in your IE 6.0 browser. When prompted for credentials, use the
administrative credentials previously defined in the CLI. Based on the credentials that are
presented to the Cisco CallManager Express router, the router displays the appropriate web
page for the system administrator, customer administrator or Phone user.
Configuring Administrative User Classes

This topic describes how to configure a customer administrator.

To configure a customer administrator to
have a subset of the system administrators
level of access, two steps must be taken:
Create and load a custom XML configuration file
Define the customer administrator credentials
IPTX v2.04-10
In the Cisco CallManager Express system, there is a system administrator that has full control
of the system. It may be desirable to create another customized level of access to the system by
configuring what is known as a customer administrator. This customer administrator can have a
subset of the full level of access enjoyed by the default system administrator. The end result is
the existence of two levels of administrators, the system administrator with full access and the
customer administrator with a defined subset of the system administrators full access.
Creating and defining the level of access for the customer administrator to log in to the Cisco
CallManager Express web-based GUI is a two-step process. The first step is to create the XML
file that defines the level of access to objects in the Cisco CallManager Express web-based
GUI. The second step is to create the user credentials that the customer administrator will use.
This can be done by using either the CLI or the system administrator web-based GUI.

(Cont.)
Creating and loading an XML configuration file is
a five-step process:
Step 1 In a text editor, open a copy of the
xml.template file for the version of Cisco CallManager
Express.
Step 2 Edit the file for desired changes to access.
Step 3 Save the file with a desired name.
Step 4 Upload to flash on the Cisco CallManager
Express router via TFTP or FTP.
Step 5 Load the template from flash to the RAM on
IPTX v2.04-11
The xml.template file is included in both the .tar and .zip files with which Cisco CallManager
Express was installed. First open the xml.template file with a text editor. Next delete either
Hide or Show, as well as the pipe symbol and the brackets, leaving only Hide or Show
remaining, whichever level of access is desired for that object. Save the file with a name that
has significance and an .xml extension, then upload this file to the flash of the Cisco
CallManager Express router. The file is loaded into RAM from flash.
Creating and Loading an XML Configuration File

Step
Action
1.
Open a copy of the xml.template file. The xml.template file is included in both the
.tar file and the .zip file that the Cisco
CallManager Express files came in.
2.
Modify the XML file. Leave only
Hide or Show, whichever

action is desired, deleting the other word
and any brackets or pipe symbols.
3.
Save the file with the desired name.
The name of the file can be anything as long

as it is a known value.
Example:
Notes
-
Upload the XML file to flash memory on the
4.
You can use TFTP or FTP to move the new

XML file to flash memory.
-
Load the template from flash to RAM on the
5.
This command will be executed if saved to

the startup-config file at bootup.
Example
Changing a line in the xml.template file controls the ability to add a new Phone from within the
Cisco CallManager Express web-based GUI.
<AddPhone> [Hide | Show] </AddPhone> becomes <AddPhone> Hide </AddPhone> and
prevents the customer administrator from adding a Phone through the web-based GUI.
Configuring Administrative User Classes:

Demonstration
Step 1 Copy of xml.template in text editor
-

- -
- -

-
--

- -

-- --

IPTX v2.04-12
This is an example of the xml.template that comes with Cisco CallManager Express 3.1. Notice
[Hide | Show]. This needs to be edited to leave only the desired action.

Demonstration (Cont.)
Step 2 File edited for desired changes to access
-
- -
- -

-

- -

- -

-
IPTX v2.04-13
This sample XML file shows the proper syntax for an edited XML file. Notice that this
XML file allows the customer administrator to add and delete a Phone but not an extension.
After the desired changes to access have been made, save the file (step 3) and put it on an
FTP or a TFTP server with which the Cisco CallManager Express router can communicate.
Next, in step 4, use the copy ftp flash or copy tftp flash command to move the file to
flash on the Cisco CallManager Express router. And finally, step 5 uses the command
web customize load filename from telephony-service mode to load the file into RAM on the
Cisco CallManager Express router. Any syntax errors that exist cause this step to fail, which
causes the Cisco CallManager Express router to output a syslog message.
Web Customize Load Command
Command
Description
Used to load and parse an XML file in router

flash memory to customize a Cisco CallManager
Express GUI for a customer administrator.
Example:
-
-

Demonstration Results
Default system
administrator
access
Modified XML
template applied
IPTX v2.04-14
This figure shows the results of the previous XML configuration file. The difference in access
to the web-based GUI is a direct result of the <Extension> section in the previous figure.
Configuring the Customer Administrator

Credentials
Define the custom administrator credentials
in one of two ways:
Through the system administrator GUI
From the CLI of Cisco CallManager Express
IPTX v2.04-15
Defining the Customer Administrator Credentials

After the XML file is configured and loaded into RAM, the system administrator can set up the
credentials for the customer administrator. There are two different ways to achieve this. The
first is through the system administrator GUI, and the second is from the CLI.

Credentials (Cont.)
To add a
customer
administrator:
Add a
username
Select
Customer
from Admin
User Type
Set the
password
IPTX v2.04-16
Defining the Custom Administrator Credentials in the GUI

This figure shows the creation of the customer administrator by the system administrator. You
can access this page by selecting System Parameters from the Configure drop-down menu.
Note
Only one set of customer administrator credentials may be defined. Any subsequent
changes overwrite the initial configuration.

Credentials (Cont.)

-
- - -- -
Sets a username and password for the customer

administrator GUI
IPTX v2.04-17
Defining the Custom Administrator Credentials in the CLI

To create the customer administrator from the CLI, first enter the telephony-service
command from global configuration mode. Then enter the web admin customer name
username password string command to create the credentials to be used by the customer
administrator.
Note
Only one set of customer administrator credentials may be defined. Any subsequent
changes overwrite the initial configuration.
Customer Administrator Credentials Commands

Command
Description
- -
Example:
-
- -
-- - -
-
Example:
-
- -
--
Defines a username and password for a

customer administrator. The default username is
Customer. There is no default password.
name username: Username of customer
administrator
password string: String to verify customer
administrator
Configuring Phone User Classes

There are two ways to define Phone users:
Through the system administrator GUI
From the CLI of Cisco CallManager Express
IPTX v2.04-18
Configuring Phone User Classes (Cont.)
Select the Phone of the

user, then set credentials
on the phone.
IPTX v2.04-19
To set Phone user credentials from the Phone user web pages, go to the Configure drop-down
menu and choose Phones. Either add a new Phone or change an existing Phone by selecting it.
Scroll to the bottom of the page, and in the Login Account area, define the username and
password. Click the Change button to commit the changes.
Configuring Phone User Classes (Cont.)
- - -- --
Sets a username and password for the Phone user

GUI (displayed in the configuration in clear text)
IPTX v2.04-20
To configure the Phone user credentials for a Phone using the CLI, enter the ephone
subconfiguration mode by entering the ephone phonetag command from global configuration
mode. Next enter the username username password password command. This is used by the
Phone users to log in to the web-based GUI and for any Telephony Application Programming
Interface (TAPI) Lite connections.
Note
The password shows in clear text in the router configuration.
Command
Description
- -
- -
Example:

- - --
--
Example:
-
--
Assigns a login account name and password to

a Phone user. This allows individual Phone
users to log in to the Cisco CallManager
Express router through a web-based GUI to
change a limited number of personal settings.
Summary
Summary
There are three levels of access to the web-based GUI:
system administrator, customer administrator, and
Phone user.
The GUI is not enabled by default and requires the
HTTP server and credentials to be enabled.
To access the web-based GUI, use the URL
http://router_ipaddr/ccme.html.
The system administrator must be configured from
the CLI.
The customer administrator can be set up from the GUI
or the CLI and can be customized.
The Phone user can be set up from the GUI or the CLI.
IPTX v2.04-21
Lesson 2
Configuring Phone Features

Overview
This lesson defines additional features that can be installed and configured to enhance a basic
Cisco CallManager Express installation.
Objectives
Upon completing this lesson, you will be able to describe and configure IP Phone features. This
includes being able to meet these objectives:
Describe and configure call transfer options
Describe and configure the call forwarding feature
Describe and configure the call waiting properties of an ephone-dn
Describe and configure the call park properties of an ephone-dn
Describe and configure the IP Phone display
Describe and configure the softkey button layout
Describe and configure the calling and directory features
Describe and configure conferencing
Describe and configure the productivity tools
Describe and configure interdigit timeout and ringing timeout
Describe and configure MOH from an audio file and from a live feed
Call Transfer
This topic describes the Cisco CallManager Express transfer commands.
Transferring a Call from an IP Phone

User transfers
a call to
another
directory
number
IPTX v2.04-3
Transferring a caller to another directory number is a very common occurrence. The person on
the IP Phone can initiate a transfer by using the functions that are displayed on the IP Phone
display. To transfer a caller, the user can initiate the transfer by pressing the Trnsfer softkey
button and dialing the number to which the call will be transferred.
Depending on the configuration deployed on the Cisco CallManager Express system, the call is
either blindly transferred or transferred with a consultation first. A blind transfer occurs when
the transferor transfers the call without knowing if the extension that the call was transferred to
will answer the call. In a consultative transfer, the transferor is connected to the transferee,
then, if satisfied, finalizes the transfer that connects the caller to the transferee.
Configuring Call Transfer

Call transfer commands:
Specify system transfer settings
Specify individual IP Phone transfer settings
Specify a transfer pattern
IPTX v2.04-4
Call transfer is a function that can be configured in various ways, depending on the supported
protocols. These call transfer commands include systemwide settings that can be overridden
with Phone-specific settings. The Phone-specific settings can be overridden by settings on the
transfer pattern.
Configuring Call Transfer (Cont.)
--- -
-
Specifies the call transfer method for all Cisco

CallManager Express extensions
----
IPTX v2.04-5
Transfer System
To specify the systemwide call transfer method for IP Phone extensions that use the
International Telecommunication Union Telecommunication Standardization Sector (ITU-T)
H.450.2 standard, use the command transfer-system in telephony-service configuration mode.
To disable the call transfer method, use the no form of this command.
When call transfer is selected using the full-blind keyword, the call is transferred without
consultation using the H.450.2 standard. When a call is transferred using the blind keyword
(the default), the call is blindly transferred using a single line and a Cisco-proprietary method.
When the full-consult keyword is used, the call is transferred with consultation using the
H.450.2 standard. The local-consult keyword uses consultation with local calls and blindly
transfers nonlocal calls. The local-consult keyword uses a proprietary transfer mechanism and
is not commonly used.
Note
Cisco CallManager Express 3.1 provides full call-transfer and call-forwarding interoperability
with call processing systems on the network that support H.450.2, H.450.3, and H.450.12
standards. For call processing systems that do not support H.450 standards, Cisco
CallManager Express 3.1 provides Voice over IP (VoIP) to-VoIP hairpin call routing without
requiring the use of the special Toolkit Command Language (Tcl) script that was needed in
earlier releases of Cisco CallManager Express.
Transfer System Command

Command
Description
---
-
-
Defines the call transfer method to allow call

transfer with consultation for all lines served by
the router.
Example:
-
--- -
blind: Calls are transferred without

consultation with a single phone line using
the Cisco proprietary method.
full-blind: Calls are transferred without
consultation using H.450.2 standard
methods.
full-consult: Calls are transferred with
consultation using H.450.2 standard
methods and a second phone line if
available. The calls fall back to full-blind
if the second line is unavailable.
local-consult: Local calls are transferred
with local consultation using a second phone
line if available. The calls fall back to blind
for nonlocal consultation or nonlocal transfer
target.
- -
Specifies the type of call transfer for an individual IP

Phone extension number
- -
IPTX v2.04-6
Transfer Mode
To specify the type of call transfer for an individual IP Phone extension that uses the
ITU-T H.450.2 standard, use the command transfer-mode in ephone-dn configuration
mode. To remove this specification, use the no form of this command.
The transfer-mode command specifies the type of call transfer for an individual Cisco IP Phone
extension that is using the ITU-T H.450.2 protocol. It allows you to override the default
transfer-system setting (full-consult or full-blind) for that ephone-dn extension. For example,
in a Cisco CallManager Express network that is set up for consultative transfer, a specific
extension with an automated attendant that automatically transfers incoming calls to specific
extension numbers can be set to use blind transfer because automated attendants do not use
consultative transfer.
Transfer Mode Command
Command
Description
- -
This command specifies the type of call

transfer for an individual Cisco IP Phone
extension that is using the ITU-T H.450.2
protocol. It allows you to override the
default transfer-system setting (full-consult
or full-blind) for that extension.
Example:
blind:Transfers calls without

consultation using a single
phone line.
consult:Transfers calls with
consultation using a second
phone line if available.
- -
Allows transfer of telephone calls from Cisco IP

Phones to other phones
--

IPTX v2.04-7
Transfer Pattern
To allow the transfer of telephone calls from Cisco CallManager Express IP Phones to nonlocal
destinations, use the command transfer-pattern in telephony-service configuration mode. To
disable these transfers, use the no form of this command.
The transfer-pattern command allows you to transfer calls to destinations other than local
IP Phones. This includes nonIP phones and external destinations. A call is then established
between the transferred party and the new recipient. By default, all Cisco IP Phone extension
numbers are allowed as transfer targets. The default is that all transfers are consultative in
nature. The optional blind keyword forces calls that are transferred to numbers that match the
transfer pattern to be executed as blind or full-blind transfers, overriding any settings made
using the transfer-system and transfer-mode commands. When defining transfers to nonlocal
numbers, it is important to note that transfer-pattern digit matching is performed before
translation-rule operations. Therefore, you should specify in this command the digits that are
actually entered by Phone users before they are translated.
Transfer Pattern Command

Command
Description
- -
Allows transfer of telephone calls by Cisco

IP Phones to specified phone number patterns.
If no transfer pattern is set, the default is that
transfers are permitted only to other local
IP Phones.
Example:
-
-
transfer-pattern:String of digits for

permitted call transfers. Wildcards are
allowed. A pattern of .T transfers all calling
parties using the H.450.2 standard.
blind:(Optional) When H.450.2
consultative call transfer is configured, it
forces transfers that match the pattern
specified in this command to be executed
as blind transfers. It overrides settings that
are made using the transfer-system and
transfer-mode commands.
Note: When defining transfers to nonlocal
numbers, transfer-pattern digit matching is
performed before translation-rule operations.
Therefore, you should specify in this command
the digits actually entered by Phone users
before they are translated.
Call Forwarding
This topic describes the Cisco CallManager Express call forwarding commands.
Forwarding a Call from an IP Phone

User forwards all
calls to a directory
number
IPTX v2.04-8
There are various call forwarding settings that govern the behaviors of the forwarding of calls.
Call forwarding may occur when the destination is busy, when the Phone rings but no one
answers, or when the Phone user wants all calls to be forwarded to another destination. On a
users Phone, the ring no answer forward setting is usually set by the administrator to go to the
voice mailbox of that user. However, this is not always the case. For example, extensions may
be set to forward on ring no answer to another extension, constructing a hunt group like
environment.
The setting to forward all calls can be configured on the IP Phone by the user. For example, a
user may go on vacation and want all calls to be handled by another employee. This common
situation occurs in many deployments.
To set all calls to forward, press the CFwdAll softkey button on the Phone and enter the
number to which all calls are to be forwarded, then press the pound (#) key to tell the system
you have finished. The forward all destination is displayed on the bottom of the IP Phone
screen. To remove the forward all, press the CFwdAll softkey button again. This turns off the
forward all. The user or administrator can also use the web-based GUI of Cisco CallManager
Express to configure the call forwarding options.
Forwarding a Call from an IP Phone (Cont.)

Forward all, busy, and no
answer all in the Phone
user web pages
IPTX v2.04-9
From the Phone user web interface, the user is able to configure a line on the Phone to forward
all, forward busy, and forward no answer. Users can configure only the Phone on which they
have credentials defined.
Configuring Call Forwarding

Call forwarding commands:
call-forward all
call-forward busy
call-forward noan
call-forward max-length
call-forward pattern
IPTX v2.04-10
There are five call forwarding commands that can be configured from the command-line
interface (CLI) of the Cisco CallManager Express router. These commands are:
call-forward all (CLI, GUI, Phone)
call-forward busy (CLI, GUI)
call-forward noan (CLI, GUI)
call-forward max-length (CLI)
call-forward pattern (CLI)
Configuring Call Forwarding (Cont.)
Forwards all calls to the specified directory number
Forwards incoming calls when the destination directory

number is busy to another directory number
--
Forwards calls that are not answered in the specified time

to another directory number
IPTX v2.04-11
call-forward all, call-forward busy, and call-forward noan

The call-forward all command can be configured from the CLI, the GUI, and the IP Phone.
The call-forward busy command can be configured from the CLI and the GUI. The callforward noan command can be configured from the CLI and the GUI.
Call Forwarding Commands
Command
Purpose
To configure call forwarding so that all

incoming calls to an extension (ephone-dn)
are forwarded to another extension
Example:

-
Example:
-

-Example:
To configure call forwarding so that

incoming calls to a busy extension
(ephone-dn) are forwarded to another
extension
To configure call forwarding so that
incoming calls to an extension (ephone-dn)
that does not answer are forwarded to
another extension
Configuring Call Forwarding (Cont.)
Restricts the number of digits that can be used with

call forwarding
-
Specifies a pattern for calling-party numbers that

support H.450.3
IPTX v2.04-12
call-forward max-length and call-forward pattern

The call-forward max-length command is used to restrict the number of digits that a user can
enter for the forwarding calls. This is important for preventing a user from forwarding calls to
destinations that might incur toll charges. This command can be configured only from the CLI.
If the call-forward max-length 0 is configured, the call forwarding softkey is grayed out and
not available through the IP Phone. Be aware, however, that even when the maximum length is
set to 0, the Phone user can still set the forward setting in the GUI .
The call-forward pattern command uses a pattern to match against the phone number of the
calling party. When an extension number has forwarded its calls and an incoming call is
received that matches the forwarding pattern, the router sends an H.450.3 response back to the
calling party to request that the call be placed again using the forward-to destination. Calling
numbers that do not match the defined patterns are forwarded using Cisco-proprietary call
forwarding for backward compatibility. Configuring this for numbers that do not support
H.450.3 could result in dropped calls, so this command should be configured to match only
calling numbers that support H.450.3 protocol. This command can be configured only from the
CLI.
Call Forwarding Commands

Command
Description
Restricts the number of digits that can be

entered using the CFwdAll softkey on an
IP Phone
Example:

Example:
Specifies a pattern for calling-party

numbers that are able to support the
ITU-T H.450.3 standard for call
forwarding
Call Waiting
This topic describes the Cisco CallManager Express call waiting commands.
Call Waiting
Call waiting customization on the ephone-dn:
Call waiting can be disabled.
A ring notification for call waiting can be
configured instead of a beep notification.
IPTX v2.04-13
For Cisco CallManager Express 3.2 and later, call waiting beeps can be switched on or off for
individual ephone-dns. You can choose to enable or disable the call waiting beeps that are
generated from and accepted by an ephone-dn.
For call waiting notification in Cisco CallManager Express 3.2.1 and later, you can use either a
standard call waiting beep sound through the handset or a short ring.
Configuring a Call Waiting Beep
Allows an ephone-dn to generate call waiting beeps

that can be received by another ephone-dn (default)
Allows an ephone-dn to accept call waiting beeps

that can be received from another ephone-dn
(default)

IPTX v2.04-14
Call waiting beeps are enabled by default. The command for disabling the beep generation on
an ephone-dn is no call-waiting beep generate. The command for disabling an ephone from
accepting call waiting beeps is no call-waiting beep accept.
If the beep generation of an ephone-dn is disabled, the source ephone-dn does not generate call
waiting beeps to the destination ephone-dn. If the beep acceptance of an ephone-dn is disabled,
that ephone-dn does not play the call waiting beep for the active call.
Configuring a Call Waiting Ring
Allows an ephone-dn to use a ring instead of the

standard beep for call waiting notification (Cisco
CallManager Express 3.2.1 and above)
IPTX v2.04-15
You can set up a ring instead of the standard call waiting beep through the configuration of an
ephone-dn. The default is for ephone-dns to accept call interruptions, such as call waiting, and
to issue a beeping sound for notification. To use a ring sound, you must ensure that your
ephone-dns accept call waiting.
After you have ensured that the ephone-dn accepts call waiting, you can configure it to use a
ringing notification with the command call-waiting ring.
Call Park
This topic describes the Cisco CallManager Express call park commands.
Call Park
User can park
a call at a park
ephone-dn by
pressing the
Park softkey
button
IPTX v2.04-16
Call park allows a Phone user to place a call on hold on a special ephone-dn. This ephone-dn is
used as a temporary parking spot from which the call can be retrieved by anyone on the system.
In contrast, a call that is placed on hold using the Hold button or Hold softkey can be retrieved
only from the extension that placed the call on hold. The special ephone-dn at which a call is
parked is known as a call-park slot. A call-park slot is a floating extension, or ephone-dn, that is
not bound to a physical phone.
Multiple call-park slots can be created with the same extension number. This allows more than
one call to be parked for a particular department or group of people at a known extension
number. For example, at a hardware store, calls for the plumbing department can be parked at
extension 101, calls for lighting can be parked at 102, and so forth. Everyone in the plumbing
department knows that calls that are parked at 101 are for them. When multiple calls are parked
at the same call-park slot number, they are picked up in the order in which they were parked;
that is, the call that has been parked the longest is the first call to be picked up from that callpark slot number.
After at least one call-park slot has been defined and Phones have been restarted, Phone users
are able to park calls using the Park softkey. Phone users who attempt to park a call at a busy
call-park slot hear a busy tone. A Phone user who parks a call can retrieve that call using the
PickUp softkey and the asterisk (*). Phone users other than the one who parked the call can
retrieve the call by pressing the PickUp softkey and the extension number of the call-park slot
that is available on their Phone displays.
Note
In addition to using the Park softkey, the call can be parked by transferring it to the number
of the call-park slot directly.
Configuring Call Park
- -- -

Creates a floating extension at which calls can be

temporarily held
-
IPTX v2.04-17
Each call-park slot occupies one ephone-dn. During configuration, any number of ephone-dns
can be designated as call-park slots using the park-slot command. The total number of callpark slots plus the normal extensions cannot exceed the maximum number of allowable
ephone-dns for a system. After an administrator defines at least one call-park slot and restarts
the Phones, the Park softkey is displayed on all the IP Phones that are able to display softkeys.
Each call-park slot can hold one call at a time, so the number of simultaneous calls that can be
parked is equal to the number of slots that have been created in the Cisco CallManager Express
system.
To create a call-park slot that is reserved for use by one extension, assign that slot a number
whose last two digits are the same as the last two digits of the extension. When an extension
starts to park a call, the system searches for a call-park slot that has the same final two digits as
the extension; if no such call-park slot exists, the system chooses an available call-park slot.
A reminder ring can be sent to the extension that parked the call. This can be configured by
using the timeout keyword with the park-slot command. The reminder ring is sent only to the
extension that parked the call unless the notify keyword is also used. The notify keyword is
used to specify an additional extension number to receive a reminder ring. When an additional
extension number is specified, the Phone user at that extension can retrieve a call from this slot
by pressing the PickUp softkey and the asterisk (*). If the timeout keyword is not used with
this command, no reminder ring is sent to the extension that parked the call.
Call Park Command

Command
Description
- -
-
Creates a floating extension (ephone-dn) at which calls

can be temporarily held (parked)
Example:
timeout seconds:(Optional) Sets the call-park

reminder timeout interval, in seconds. Range is
from 0 through 65535. When the interval expires,
the call-park reminder sends a 1-second ring and
displays a message on the LCD panel of the Cisco
IP Phone that parked the call and to any extension
that is specified with the notify keyword. By
default, the reminder ring is sent only to the Phone
that parked the call.
limit count:(Optional) Sets a limit for the number of
reminder timeouts and reminder rings for a parked
call. For example, a limit of 10 sends ten reminder
rings to the Phone at intervals that are specified by
the timeout keyword. When a limit is set, a call
parked at this slot is disconnected after the limit
has been reached. The limit range is from 1
through 65535 reminders.
notify extension-number:(Optional) Sends a
reminder ring to the specified extension in addition
to the reminder ring that is sent to the Phone that
parked the call.
only:(Optional) Sends a reminder ring only to the
extension that is specified with the notify keyword
and does not send a reminder ring to the Phone
that parked the call. This option allows all reminder
rings for parked calls to be sent to a receptionist s
phone or an attendants phone, for example.
IP Phone Display
This topic describes the IP Phone display options.
IP Phone Display
The following features of the IP Phone
display can be customized:
IP Phone header bar
System text message
System display message (idle URL)
IPTX v2.04-18
The display of the IP Phone can be customized to reflect the needs and identity of the enterprise
that is deploying the Cisco CallManager Express system and Phones.
Normally, the IP Phone header bar, or top line, of a Cisco IP Phone 7940G or 7960G replicates
the text that appears next to the first line button. The header bar can, however, contain a userdefinable message instead of the extension number. For example, the header bar can be used to
display a name or the full E.164 number of the Phone. If no description is specified, the header
bar replicates the extension number that appears next to the first button on the Phone.
The system text message replaces the default Cisco CallManager Express message toward
the bottom of the Phone. There is room for about 30 characters to be displayed. The message
appears when the Phone is idle. This occurs under one of the following three conditions:
A busy Phone goes on hook
The Phone receives a keepalive
The Phone restarts
The system display message feature allows you to specify a file to display on 7940G and
7960G Phones when they are not in use. You can use this feature to provide the Phone display
with a system message that is refreshed at configurable intervals, similar to how the system text
message feature provides a message. The difference between the two is that the system text
message feature displays a single line of text at the bottom of the Phone display, whereas the
system display message feature can use the entire display area and can contain graphic images.
The system display message feature requires a back-end web server to serve up the browser
page to the Phone display because the Cisco CallManager Express system only provisions the
URL. The system display message can also provide softkeys for the Phone and thereby take
input from the Phone user for interactive services.
IP Phone Display (Cont.)

Label
IP Phone
Header Bar
System Text Message
System Display
Message
IPTX v2.04-19
This graphic shows the different areas on the display of a Phone controlled by Cisco
CallManager Express. These features can be customized for the current implementation.
Configuring IP Phone Display

IP Phone Header Bar
Enters ephone-dn configuration mode
- -
Enters the header bar for the IP Phone
Configures a label on the line instead of the line

number
IPTX v2.04-20
Use the ephone-dn dn-tag command to enter the ephone-dn configuration mode. Next, use the
description command to change the header bar of an IP Phone. A common use of this
command is to enter the direct inward dial (DID) number (if there is one) of the first line. This
allows users to easily see the number that someone on the public switched telephone network
(PSTN) could dial in order to call them on that Phone. However, any text or numbers could be
displayed here.
To create a text identifier instead of a phone-number display for an extension on an IP Phone
console, use the label command.
Note
The Phone must be reset to have any changes to the header bar appear.
IP Phone Header Bar Commands

Command
Description
Enters ephone-dn configuration mode.
Example:
dn-tag: The unique sequence number that identifies

the ephone-dn for which the description should be
in effect.

- -
Example:
Defines a description for the header bar of Cisco

IP Phones 7940G and 7960G that has the specified
ephone-dn associated with its first line button.
display-text:Alphanumeric character string, up to 40

characters. The string is truncated to 14 characters
in the display.
To create a text identifier instead of a phone-number

display for an extension on an IP Phone console.
The Phone must be rebooted to accept the changes.
Example:
Configuring IP Phone Display (Cont.)

-
-- -- --
Sets the text message that plays when the IP Phone

is idle
-
--
Sets a URL to be displayed on the IP Phone when it

is idle for the set number of seconds
IPTX v2.04-21
The system message command allows a message to be displayed on all Phones in the
Cisco CallManager Express system. This message can be alphanumeric text only, and the
message size that is allowed varies based on the Phone model. A common use of this command
is to display the name of the company on all of the Phones.
The url idle command allows the functionality of the system message command to extend to
more than just a text message. The url idle command allows the Cisco CallManager Express
router to point all of the Phones to a URL that resides on a back-end web server. This web
server can then provide content in the form of text, graphics, and interactive applications that
appear on the IP Phones after a definable period of inactivity. These applications are written
using XML. For more information, go to http://www.cisco.com/go/developersupport.
Note
Because the Cisco CallManager Express router asks for credentials, it should not be the
web server that serves the idle URL.
System Display Message Commands

Command
Description:
- -- --
Sets the message to display when a Phone is

idle. Uses proportional-width font, so the number
of characters that are displayed varies based on
the width of the characters that are used. The
maximum number of displayed characters is
approximately 30.
Example:
-
-- -- - -Example:
-

-
Defines a URL that contains a file to display on

the Phone when the Phone is not in use and
specifies the interval between refreshes of the
display, in seconds.
url:Any URL that conforms to RFC 2396
seconds:Range is from 0 to 300
Configuring IP Phone Display (Cont.)

Provisioning URL for Customized Function Buttons
-
--
Sets the URL that will be used when the

corresponding function button is pressed
--
-
-- --
IPTX v2.04-22
The Cisco IP Phones 7940G and 7960G have customized function buttons that show the phone
call status and activities on the display panels. These customized function buttons also invoke
programmable services that are not related to calls. There are two buttons that are commonly
modified to link to programmable URLs. This allows the administrator to override any default
settings that may be assigned to the function buttons. The Messages button and the Information
button should not be customized and the Settings button cannot be customized.
Specific URLs are provisioned on the Cisco IP Phone to populate these buttons. The URLs
point to XML-based web pages formatted with XML tags that the Phone understands and uses.
When a function button is pressed, the Phone uses the configured URL to access the
appropriate XML web page for instructions. The web page sends instructions to the Phone to
display information on the screen to be navigated. Options can be selected and information
entered by using softkeys and the scroll button.
The Cisco IP Phones 7940G and 7960G can support four URLs in association with the four
programmable feature buttons on an IP Phone. The four feature buttons on an IP Phone are
configured using the url command keywords. The Settings button cannot be modified.
Operation of these services is determined by the IP Phone capabilities and the content of the
referenced URL.
Note
The Cisco CallManager Express router should not be the web server that serves the URL for
customized function buttons.
URL Commands
Command
Description

--- --
Provisions URLs for use by the Cisco IP Phones.

The four keywords (directory, information,
messages, and services)correspond with the
four feature buttons on an IP Phone: Directories,
Information, Messages, and Services. The purpose
of the url command is simply to provision the
URLs through the SEPDEFAULT.cnf configuration
file supplied by the Cisco CallManager Express
router to the Cisco IP Phones during Phone
registration. The maximum character length for
the URL is 128.
Example:
-

--- You can disable the local directory by entering the
url directories none command. You must reset
the Cisco IP Phones before the url command can
take effect.
Note: By default, the router automatically uses the

local directory service. Provisioning the directory
URL to select an external directory resource
disables the Cisco CallManager Express local
directory service.
This topic describes the customization of the softkey layout.
Softkeys are along the bottom of the screen on

7905G, 7912G, 7940G, 7960G, and 7970G Phones
IPTX v2.04-23
For Cisco CallManager Express version 3.2 and later, you can disable and enable IP Phone
softkeys and change the order in which they appear in the displays of individual ephones. This
feature is available on the Cisco IP Phones 7905G, 7912G, 7940G, 7960G, 7970G, and
7971G-GE.
Softkey Customization (Cont.)

Softkey templates can be defined by the
administrator.
Up to five templates can be defined.
Templates may include settings for each of the four call
states:
Alerting
Connected
Idle
Seized
The system default will be used if no template is defined.
A template can be applied to one or more ephones.
IPTX v2.04-24
Up to five softkey templates can be created. Each template can include softkey settings for all
or some of the four call states:
Alerting: when the remote point is being notified of an incoming call and the status of the
remote point is being relayed to the caller as either ringback or busy. The softkey options
and their default order in this calling state are as follows:
Acct: Short for
account code. Provides access to configured accounts.
Callback: Requests callback notification when a busy called line becomes free.
Endcall: Ends the current call.
Connected: when the connection to a remote point has been established. The softkey
options and their default order in this calling state are as follows:
Acct: Short for
Confrn: Short for
account code. Provides access to configured accounts.

conference. Connects callers to a conference call.

Flash: Short for
hookflash. Provides hookflash functionality for PSTN services on
calls connected to the PSTN via a Foreign Exchange Office (FXO) port.
Hold: Places an active call on hold and resumes the call.
Park: Places an active call on hold so it can be retrieved from another Phone in the
system.
Trnsfer: Short for
call transfer. Transfers active calls to another extension.
Idle: before a call is made and after a call is complete. The softkey options and their default
order in this calling state are as follows:
Cfwdall: Short for
Dnd: Short for
call forward all. Forwards all calls.

do not disturb. Enables the do-not-disturb feature.
Gpickup: Short for

group call pickup. Selectively picks up calls coming into a
phone number that is a member of a pickup group.
Login: Provides PIN access to restricted Phone features.
Newcall: Opens a line on a speakerphone to place a new call. Note that the Newcall
soft key must not be disabled for the Cisco IP Phones 7905G and 7912G.
Pickup: Selectively picks up calls coming into another extension.
Redial: Redials the last number dialed.
Seized: when a caller is attempting a call but has not yet been connected. The softkey
options and their default order in this calling state are as follows:
Cfwdall: Short for
call forward all. Forwards all calls.

Gpickup: Short for
group call pickup. Selectively picks up calls coming into a
phone number that is a member of a pickup group.
Pickup: Selectively picks up calls coming into another extension.
Redial: Redials the last number dialed.
Configuring Softkey Customization
Creates the ephone template and enters ephone

template configuration mode
Configures an ephone template for the softkey

template during the alerting state
IPTX v2.04-25
The command ephone-template creates and defines the number of the softkey template. Under
the ephone template the softkey alerting command may be used to change the order of or
delete softkeys that will appear when the Phone is ringing.
Configuring Softkey Customization (Cont.)
- -
-

template during the connected state

template during the idle state
IPTX v2.04-26
The command softkey connected allows the softkeys to be modified when a call is currently
connected. The softkey idle command allows the softkeys to be modified when the handset is
on hook and no calls are taking place.
Configuring Softkey Customization (Cont.)
- -


template during the seized state
IPTX v2.04-27
The command softkey seized is used to modify the order of or delete softkeys when the handset
is off hook and either a dial tone is being played or digits are being entered on the keypad.
Example: SoftkeyCustomization
Default softkey
buttons during
connected state
IPTX v2.04-28
This figure shows the default softkeys during the connected state.
Example: SoftkeyCustomization (Cont.)
Result after ephone

template is applied
to the ephone

- -

IPTX v2.04-29
This example shows the connected state with an ephone template applied that changes the order
of the softkeys and how they are displayed.
Calling and Directory Features

This topic describes calling and directory features.
Accessing the Directory
The directory
can be
accessed by
pressing the
Directory
button.
IPTX v2.04-30
When a user does not know the number of another subscriber or of a commonly used external
number, the corporate directory on the Cisco CallManager Express system can be accessed to
look up the number for you and connect you to it.
The directory of the Cisco CallManager Express is built and stored on the router from the
configuration. By default, Phone users can access the directory by pressing the Directory button
and selecting the local directory. They can be connected by pressing the Dial softkey when the
number they want is highlighted.
Accessing the Directory (Cont.)

http://ip_address/ccme.html
The directory
can be
accessed
through the
Phone user
web page.
IPTX v2.04-31
The Phone user can also access the directory through the Phone user web-based GUI.
Adding a User to the Directory
Adding a user to the

directory of Cisco
CallManager Express
IPTX v2.04-32
To add a user to the directory of Cisco CallManager Express, the name field under the
properties of the ephone-dn must be defined. The first and last names should be entered in the
same order that the Cisco CallManager Express is set to use.
Adding a User to the Directory (Cont.)
IPTX v2.04-33
The system administrator can also add entries to the directory that represent destinations that
are not IP Phones controlled by the Cisco CallManager Express system. If allowed, the
customer administrator can also configure these options.
The directory may have up to 100 entries added with a maximum digit length of 32 each. The
number of characters in the name is limited to a maximum of 24.
Note
This can be used to enter numbers for another site in the company that is not part of this
Cisco CallManager Express installation.
Directory Commands
Directory order and entry
-
-- --
Sets the order in which the directory entries are listed

-
Adds an entry to the Cisco CallManager Express directory
Creates the name that will appear in the telephone

directory entry
IPTX v2.04-34
The system administrator can configure the order by which the names are listed in the Cisco
CallManager Express directory. The directory command is used to set the systemwide setting
for this. The default is first name first. Entries that represent non IP Phones controlled by Cisco
CallManager Express are entered into the directory from the CLI using the directory entry
command. This can also be done by using the GUI.
The name command is how an identity is associated with the ephone-dn in Cisco CallManager
Express. Enter the name in the same order that was defined using the directory command.
These names will appear in the Cisco CallManager Express directory.
Directory Commands
Command
Description
--
--
Defines the local directory naming order. The

actual directory of names and phone numbers is
built using the name command and the number
command in ephone-dn configuration mode.
When the command is set with the first-namefirst keyword, you see the directory information
displayed on the Phone as Jane J. Jones, and
when the command is set with the last-namefirst keyword, you see the directory information
displayed on the Phone as Jones, Jane J.
Example:
-
--
To add an entry to a local phone directory that

can be displayed on IP Phones.
Example:
-

Example:

Example:
Associates a name with an ephone-dn. The

name should follow the order defined in the
directory {first-name-first | first-name-last}
command.
Conferencing
This topic describes conferencing and the commands required for configuration.
Conferencing
Step 1The conference

is started, and the RTP
streams are sent to the
Cisco CallManager
Express router.
Step 3Cisco
CallManagerExpress
sends the mixed
audio result out to the
earpieces of all
attendees of the
conference.
Step 2Cisco CallManager Express mixes the voices of all

three conference attendees using software conferencing and
may invoke transcoding resources if required.
IPTX v2.04-35
Cisco CallManager Express supports three-party conferencing for local and on-net calls. This
feature supports conversion between G.711 mu-law and a-law and between G.711 and G.729.
The maximum number of simultaneous conferences is platform-specific.
For Cisco CallManager Express version 3.2 and later, a person who initiates a conference call
and hangs up can either keep the remaining parties connected or disconnect them.
Note
Hardware-based conferencing is not supported.
Conferencing Configuration
Sets the maximum number of conferences that may

take place at one time on the Cisco CallManager
Express router
Allows the conference originator to leave the call

and either end the conference or let the conference
continue
IPTX v2.04-36
The command max-conferences max-conference-number sets the maximum number of

simultaneous three-party conferences supported by the Cisco CallManager Express router. The
number that is supported depends on the router platform. The Cisco 1700 and 2801 routers
support eight conferences, the Cisco 2600 and 3700 routers support 16 conferences, and the
Cisco 3800 router supports 24 conferences.
The keep-conference and keep-conference endcall commands configure IP Phones to keep
the remaining conference parties connected when the conference initiator hangs up (places the
handset back in the on-hook position). Conference originators can disconnect from their
conference calls by pressing the Confrn (conference) softkey. When the initiator uses the
Confrn key to disconnect from the conference call, the oldest call leg will be put on hold,
leaving the initiator connected to the most recent call leg. The conference initiator can then
navigate between the two parties by pressing either the Hold softkey or the line buttons to
select the desired call.
The keep-conference command causes the remote conference parties to remain connected
when the conference initiator hangs up the Phone and to disconnect the conference parties if the
initiator presses the EndCall softkey. The keep-conference endcall command causes the
remote conference parties to remain connected when the conference initiator hangs up or
presses the EndCall softkey.
Conference initiator drop-off can be configured per ephone. When the conference initiator
hangs up, Cisco CallManager Express executes a call transfer to connect the two remaining
lines. To facilitate call transfer, the transfer-system command is required using the full-blind,
full-conference, or full conference dss keyword. The drop-off control behavior is the same for
all three keywords. When the initiator hangs up, the remaining calls are transferred without
consultation.
Example: Conferencing Configuration
-
---
-

IPTX v2.04-37
The figure shows conferencing that has been configured on the Cisco CallManager Express
router.
Productivity Tools
This topic describes the Cisco CallManager Express productivity tools.
Productivity Tools
Productivity tools for Cisco CallManager
Express include:
Flash softkey for hookflash functionality
Intercom
Paging
IPTX v2.04-38
There are various tools that can aid productivity and give needed functionality to many
deployments.
Flash Softkeyfor HookflashFunctionality
Enables the Flash softkey button on the IP Phones
IPTX v2.04-39
Certain PSTN services, such as three-way calling and call waiting, require hookflash
intervention from a Phone user. A new softkey labeled Flash has been introduced to provide
this functionality on FXO lines attached to the Cisco CallManager Express system. The Flash
softkey is enabled by using the fxo hook-flash command. Once Flash has been enabled and a
reboot of the IP Phone has been performed, the softkey is available to provide hookflash
functionality during all calls except for local IP Phone toIP Phone calls.
Note
The hookflash-controlled services can be activated only if they are supported by the PSTN
connection that is involved in the call. The availability of the Flash softkey does not
guarantee that hookflash-based services are actually accessible to the Phone user.
Hook Flash Command

Command
Description
Enables the flash button on the 7940G and

7960G Phones for hookflash functionality
Example:
-
-
Intercom

---

--

---
---

--
--

Phone A The Boss

Line 1 1100
Line 2 Admin Assistant
Phone B Admin Assistant

Line 1 1199
Line 2 The Boss
IPTX v2.04-40
Many deployments want intercoms. The intercom is commonly used between executives and
administrative assistants. Although this is not the only situation in which an intercom is used, it
is the most common.
Cisco CallManager Express supports intercom functionality for one-way and press-to-answer
voice connections using a dedicated pair of intercom ephone-dns on two Phones that speed-dial
each other. When an intercom speed dial button is pressed, a call is speed-dialed to the ephonedn that is the other half of the dedicated pair. The called ephone-dn automatically answers the
call in speakerphone mode with mute activated. This provides a one-way voice path from the
initiator to the recipient.
A beep is sounded when the call is auto-answered to alert the recipient to the incoming call. To
respond to the intercom call and open a two-way voice path, the recipient deactivates the mute
function by taking one of the following actions:
On a multibutton Phone, pressing the Mute button
On a Cisco IP Phone 7910G+SW, lifting the handset
Intercom lines cannot be used in shared-line configurations. If an ephone-dn is configured for
intercom operation, it must be associated with one IP Phone only. The intercom attribute causes
an IP Phone line (ephone-dn) to operate as an auto-dial line for outbound calls and as an autoanswer-with-mute line for inbound calls. The figure shows an intercom between an
administrative assistant and a manager.
Any user can dial the intercom if the number of the intercom can be dialed with the keys that
are present on the Phones. In order to configure an intercom line that cannot be dialed, you can
assign the intercom ephone-dn a dialing string with an alphabetic character of A, B, C, or D. No
one can dial the alphabetic character from a normal phone, but the Phone at the other end of the
intercom can be configured to dial the alphabetic character number through the Cisco
CallManager Express router. For example, intercom ephone-dns can be assigned numbers with
alphabetic characters so that only the receptionist can call managers on their intercom line, and
only managers can call the receptionist on the receptionists intercom line.
Note
An intercom requires configuration of two ephone-dns, one for each Phone that makes up
the intercom pair.
Intercom Command
-
-
Programs an extension to call another intercom

phone
IPTX v2.04-41
The intercom command is used under the ephone-dn configuration mode; it is used to
configure one half of the intercom pair. There must be another ephone-dn with the intercom
command on it. Then this ephone-dn must be assigned to a line button using the button
command. The IP Phone must be restarted to accept the changes.
Intercom Command
Command
Description
-
- ]
Creates an intercom by programming a pair of

extensions (ephone-dns) to automatically call and
answer each other.
Example:
barge-in: (Optional) Allows inbound intercom

calls to force an existing call into the call-hold
state and allows the intercom call to be
answered immediately
no-auto-answer:(Optional) Disables the
intercom auto-answer feature
label label:(Optional) Defines an alphanumeric
label for the intercom of up to 30 characters
Paging Function
One-way voice path
Unicast or multicast
Single group or combined groups
IPTX v2.04-42
Audio paging provides a one-way voice path to the Phones that have been designated to receive
paging. It does not have a press-to-answer option as the intercom feature does. Pages are
commonly used for locating people who are away from their desk, for emergency situations
such as a fire drill, for overhead pages, and other situations.
The paging mechanism supports audio distribution using IP multicast, replicated unicast, and a
mixture of both (multicast is used where possible, and unicast is used for specific Phones that
cannot be reached using multicast).
Paging groups can be configured for a single group or for a combined group. Several paging
groups can be specified in a Cisco CallManager Express system, and two or more paging
groups can be joined into a combined group.
A paging group is created using a dummy ephone-dn, known as the paging ephone-dn, which
can be associated with any number of local IP Phones. The paging ephone-dn can be dialed
from anywhere, including from an on-net location.
When a caller dials the paging number (ephone-dn), each idle IP Phone that has been
configured with the paging number automatically answers using its speakerphone mode.
Displays on the Phones that answer the page show the caller ID that has been set using the
name command under the paging ephone-dn. When the caller finishes speaking and hangs up,
the Phones return to their idle state.
Single Paging Group

--

--

ephone 1
paging Group 4
Phone dials 4444
ephone 2
paging Group 4
IPTX v2.04-43
The paging feature defines an ephone-dn that sends one-way voice through a unicast or
multicast mechanism to a single group of idle Cisco IP Phones that have been associated
with the paging ephone-dn tag. In this example, when a caller dials 4444, both ephone 1
and ephone 2 receive a page on the speaker of the IP Phone.
Setting Up a Paging Group

Set up paging
directory
number by
adding a new
extension
through
the GUI
Assign the
paging
extension to
the Phone
IPTX v2.04-44
Paging groups can be set up through the GUI by adding a new paging extension and assigning
it to one or more Phones in the Cisco CallManager Express system.
Note
An IP Phone can be assigned to only one paging group at a time.
Single Paging Group Commands
---
Configures the ephone-dn as paging extension using

either unicast or multicast
Creates a paging extension to receive audio pages

on the ephone
IPTX v2.04-45
To configure a paging directory number, first create the ephone-dn with the command ephonedn tag. Next, use the command paging to configure the ephone-dn as a paging extension. The
paging ephone-dn can then be assigned to the target ephones. By default, the paging command
uses unicast for the pages, and this limits the number of target Phones to ten. If the paging ip
ip_multicast address port udp-port is used, then the page uses multicast and can go out to more
than ten Phones. The configurable range of multicast addresses is 225.0.0.0 through
239.255.255.255.
The use of multicast for paging allows many ephones to receive the same page without generating
a separate stream of traffic for each ephone. In fact, all of the IP Phones in the paging group can
use the same stream, thereby conserving bandwidth, increasing the scalability of the page, and
reducing overhead on the Cisco CallManager Express router.
Note
The network must be multicast-enabled in order to support multicast paging.
This assignment to one or more target ephones is done through the use of the paging-dn
command in the ephone configuration mode for one or more ephones. The configuration of
the paging ephone-dn determines whether a page uses a multicast or a unicast mechanism.
Single Paging Group Commands

Command
Description
---
Defines an extension (ephone-dn) as a paging

extension that can be called to broadcast an audio
page to a set of Cisco IP Phones.
ip multicast-address: (Optional) Uses an IP
multicast address to multicast voice packets for
audio paging, for example, 239.0.1.1.
Example of unicast:
Note: IP Phones do not support multicast at

224.x.x.x addresses. Default is that multicast is not
used and IP Phones are paged individually using
IP unicast transmission (up to ten Phones).
Example of multicast:
port udp-port-number: (Optional) Uses this User

Datagram Protocol (UDP) port for the multicast.
Port range is from 2000 to 65535. Default is 2000.
Creates a paging extension (paging ephone-dn) to

receive audio pages on a Cisco IP Phone in a
Cisco CallManager Express system. The unicast
keyword overrides the multicast configuration in the
paging command.
Example:
Combined Paging Group

Phone dials 2000 and Phone 1 and Phone 2 get page
Phone dials 2001 and Phone 3 and Phone 4 get page
Phone dials 2002 and all four Phones get page

-

Ephone1
Paging Group 10
Phone dials 2000,

2001, or 2002
Ephone2
Paging Group 10
Ephone3
Paging Group 20
Ephone4
Paging Group 20
IPTX v2.04-46
By configuring the ability to page combined groups in addition to single groups, Phone users
are provided with the flexibility to page a small local paging group, such as paging two Phones
in a technical support department, or to page a combined set of several paging groups, such as
paging a group that consists of technical support and sales phones.
Combined Paging Group Command
Creates a combined paging group from two or more

previously defined paging directory numbers
IPTX v2.04-47
The paging-group command is configured under a paging ephone-dn. This allows multiple
paging groups to be combined into larger groups. A common use of this is a systemwide
emergency page.
Combined Paging Group Command
Command
Description
Creates a combined paging group from two or

more previously established paging sets

Example:
Custom IP Phone Rings
This topic describes custom IP Phone rings.
Custom IP Phone Rings

To create custom rings for IP Phones, follow
these steps:
Step 1 Create a ring in the form of a raw PCM file.
Step 2 Create a RingList.xml file using a text
editor to point to the various rings that are desired.
Step 3 Load the rings and RingList.xml file to
flash on the Cisco CallManager Express router.
Step 4 Configure the TFTP server to serve up the
rings and RingList.xml.
Step 5 Reboot the Phones.
IPTX v2.04-48
One of the unique features that can be enabled when IP Phones are used is the ability of the
administrator to make custom rings available for the Phone users. Although this is not a critical
feature, it is a commonly requested feature.
The IP Phone rings can be customized by creating your own pulse code modulation (PCM)
audio files and constructing a custom RingList.xml file.
Cisco IP Phones ship with two default ring types that are implemented in hardware: Chirp1 and
Chirp2. Cisco CallManager Express supports custom ring sounds that are implemented in
software as PCM files. The XML file RingList.xml, which describes the ring list options
available at your site, is needed on the flash of the Cisco CallManager Express router.
The following procedure applies only to creating custom phone rings for the Cisco IP Phone
7940G and 7960G models.
Step 1
Create a PCM file for each custom ring (one ring per file). The PCM files for the
rings must meet the following requirements for proper playback on Cisco IP Phones:
Raw PCM (no header)

8 bits per sample
mu-law compression
Maximum ring size 16080 samples
Minimum ring size 240 samples
Number of samples in the ring must be evenly divisible by 240

Ring should start and end at the zero crossing
Step 2
Use an ASCII editor to edit the RingList.xml file.
Step 3
Use TFTP to download the new PCM files and XML file to the flash of the Cisco
Step 4
Use the tftp-server command to allow access to the files, for example:
- --
- -
Step 5
Reboot the IP Phones. When IP Phones are rebooted, the IP Phones get the files and
show the ring types in the Ring Type Option list under the Settings button.
The RingList.xml file defines an XML object that contains a list of phone ring types. Each ring
type contains a pointer to the PCM file that is used for that ring type and to the text that will be
displayed on the Ring Type menu of the Cisco IP Phone for that ring. The
CiscoIPPhoneRingList XML object uses the following simple tag set to describe the
information:
<CiscoIPPhoneRingList>
<Ring>
<DisplayName/>
<FileName/>
</Ring>
</CiscoIPPhoneRingList>
In the above definition:
<Ring> contains two fields, DisplayName and FileName, that are required for each phone ring
type. Up to 50 rings can be listed.
DisplayName defines the name of the custom ring for the associated PCM file that will be
displayed on the Ring Type menu of the Cisco IP Phone.
FileName specifies the name of the PCM file for the custom ring to associate with
DisplayName.
The DisplayName and FileName fields must not exceed 25 characters.
Example: Sample RingList.xml

A sample RingList.xml file that defines two phone ring types is shown here:
<CiscoIPPhoneRingList>
<Ring>
<DisplayName>Piano1</DisplayName>
<FileName>Piano1.raw</FileName>
</Ring>
<Ring>
<DisplayName>Chime</DisplayName>
<FileName>Chime.raw</FileName>
</Ring>
</CiscoIPPhoneRingList>
Caution
Configuring too many custom rings may cause the Cisco CallManager Express router to
hang or crash.
Timer Settings
This topic describes timer settings for the telephony service.
Timer Settings
- --
Sets the interdigit timeout

-
- --
Sets the number of seconds that the Cisco

CallManager Express system allows ringing to
continue if a call is not answered
IPTX v2.04-49
Interdigit Timeouts and Ringing Timeouts

This task configures the interdigit timeout value for all Cisco IP Phones. The interdigit timeout
is the amount of time that can elapse after the dialing of digits before the dialing process times
out and is terminated.
The ringing timeout is the amount of time a Phone can ring with no answer before returning a
disconnect code to the caller. This timeout is used only for extensions that do not have noanswer call forwarding enabled. The ringing timeout prevents orphaned calls that are received
over the interface, such as FXO that do not have forward-disconnect supervision.
Timeout Commands
Command
Description
- --
A systemwide parameter that sets the interdigit

timeout duration for Cisco IP Phones, in
seconds. Range is from 2 to 120. Default is 10.
Example:
-
-
- -Example:
-
-
The number of seconds that the Cisco

CallManager Express system allows ringing to
continue if a call is not answered. Range is from
5 to 60000. Default is 180.
Music on Hold
This topic describes Music on Hold (MOH).
Music on Hold
MOH can be derived from two sources:
Audio file in .wav or .au format
Live audio source via a feed
IPTX v2.04-50
MOH is an audio stream that is played to PSTN and VoIP G.711 callers who are placed on hold
by Phones in a Cisco CallManager Express system. This audio stream is intended to reassure
callers that they are still connected to their call. MOH is not played to local Cisco CallManager
Express Phones that are on hold with other Cisco CallManager Express Phones. These parties
hear a periodic repeating tone instead.
The audio stream that is used for MOH can come from one of two sources: an audio file or a
live feed. If both are configured concurrently on the Cisco CallManager Express router, the
router seeks the live feed first. If the live feed is found, it displaces the audio file source. If the
live feed is not found or fails at any time, the router falls back to the audio file source that was
specified for MOH during configuration.
If the MOH audio stream is also identified as a multicast source, the Cisco CallManager
Express router additionally transmits the stream on the physical IP interfaces of the Cisco
CallManager Express router that is specified during configuration. This permits external
devices to have access to the MOH stream.
An MOH audio stream from an audio file is supplied from a .wav or .au file that is held in
router flash memory. An MOH audio stream from a live feed is supplied from a standard linelevel audio connection that is directly connected to the router through an FXO or ear and mouth
(E&M) analog voice port. The live-feed feature is typically used to connect to a CD jukebox
player. Only one live MOH feed is supported per system.
Caution
Use royalty-free music to avoid potential legal issues.
Configuring MOH from a File
Phone on Hold
Flash:
MyMohfile.wav
Unicastor Multicast
-

-
Phone on Hold
IPTX v2.04-51
This figure shows a file named MyMoHfile.wav in flash of the Cisco CallManager Express
router. The file is configured to be used for MOH by entering the moh MyMoHfile.wav
command in telephony-service mode. It is currently configured to use the multicast address of
239.23.4.10 for transmission of the MOH.
Commands for Configuring MOH

from a File
Configures MOH using the file specified in flash

-
- --
---
(Optional) Specifies that the MOH file should be

multicast using the configured parameters
IPTX v2.04-52
The command moh filename enables MOH from .au and .wav format music files. MOH is
played for G.711 callers and on-net VoIP and PSTN callers who are on hold in a Cisco
CallManager Express system. Local callers within a Cisco CallManager Express system hear a
repeating tone while they are on hold. Audio files that are used for MOH must be copied to the
Cisco CallManager Express router flash memory. An MOH file can be in .au or .wav file
format; however, the file format must contain 8-bit 8-kHz data in a-law or mu-law data format.
To replace or modify the audio file that is currently specified, you must first disable the MOH
capability using the no moh command. The following example shows file1 being replaced with
file2:
Router(config-telephony-service)# moh file1
Router(config-telephony-service)# no moh
Router(config-telephony-service)# moh file2
If a second file is specified without first removing the original file, the MOH mechanism stops
working and may require a router reboot to clear the problem.
Note
IP Phones do not support multicast at 224.x.x.x addresses.
Commands for Configuring MOH from a File

Command
Description
Generates an audio stream from a file for MOH in

a Cisco CallManager Express system.
Example:
-

- --
--
-
Example:
Configures an MOH audio stream as a multicast

source in a Cisco CallManager Express system.
ip-address:Specifies the destination IP address
for multicast.
port port-number:Specifies the media port for
multicast. Port range is from 2000 to 65535.
Port 2000 is recommended because this port is
already used for normal RTP media transmissions
between IP Phones and the Cisco CallManager
Express router.
route ip-address-list: (Optional) Indicates specific
router interfaces over which to transmit the
IP multicast packets. Up to four IP addresses
can be listed, each separated from the other by
a space. The default is that the MOH multicast
stream output is automatically on the interfaces
that correspond to the address that was configured
with the ip source-address command.
Configuring MOH from a Live Source

Phone on Hold
E&M portfour-wire,
immediate start,
auto-cut-through
Unicastor Multicast
E&M Port
1/1/1

-
-

Phone on Hold
IPTX v2.04-53
To configure MOH from a live feed, a voice port and dial peer for the call are established.
A dummy ephone-dn is also created. The dummy ephone-dn must have a Phone or extension
number assigned to it so that it can make and receive calls, but the number is never assigned
to a physical Phone. The recommended interface for live-feed MOH is an analog E&M port
because it requires the minimum number of external components. You connect a line-level
audio feed (standard audio jack) directly to pins 3 and 6 of an E&M RJ-45 connector.
The E&M voice interface card (VIC) has a built-in audio transformer that provides appropriate
electrical isolation for the external audio source. (An audio connection on an E&M port does
not require loop-current.) The signal immediate and auto-cut-through commands disable
E&M signaling on this voice port. A digital signal processor (DSP) on the E&M port generates
a G.711 audio packet stream.
If you are using an FXO voice port instead of an E&M port for live-feed MOH, connect the
MOH source to the FXO voice port. This connection requires an external adaptor to supply
normal telephone company battery voltage with the correct polarity to the tip and ring leads of
the FXO port. The adaptor must also provide transformer-based isolation between the external
audio source and the tip and ring leads of the FXO port.
Music from a live feed is continuously fed into the MOH playout buffer instead of being read
from a flash file, so there is typically a 2-second delay. An outbound call to an MOH live-feed
source is attempted every 30 seconds until the connection is made by the directory number that
has been configured for MOH. If the live-feed source is shut down for any reason, the flash
memory source automatically activates. A live-feed MOH connection is established as an
automatically connected voice call that is made by the Cisco CallManager Express MOH
system itself or by an external source directly calling in to the live-feed MOH port.
Note
MOH is not supported for use in the basic automatic call distribution (B-ACD) script.
Commands for Configuring MOH from a

Live Source
Enters voice-port configuration mode for the E&M port
(Optional) Sets gain on the MOH signal

Enables call completion when no M-lead response is sent

IPTX v2.04-54
If the MOH arrives on an analog port, that FXO or E&M port must be configured. The
command input gain allows the volume of the feed to be tuned up or down on either an FXO
or E&M port. E&M ports require additional configuration. One of these E&M commands is
auto-cut-through, which allows the connection to the feed to be set up even though the source
of the feed will not provide an M-lead response.
Commands for Configuring MOH from a Live Source
Command
Description
Enters voice-port configuration mode.
Example:

Example:
Specifies, in decibels, the amount of gain to be

inserted at the receiver side of the interface.
Acceptable values are integers from 6 to 14.

Example:
(E&M ports only) Enables call completion when

a device does not provide an M-lead response.
MOH requires that you use this command with
E&M ports.
Sets the E&M port to use a four-wire scheme
Directs calling side to seize the E-lead and send

DTMF digits
IPTX v2.04-55
The E&M port that MOH arrives on must be configured in four-wire mode. This is done by
entering the operation 4-wire command. E&M ports also need to be configured to proceed
with connecting the call by seizing the line and sending dual tone multifrequency (DTMF)
digits without waiting for any signal from the other side of the connection. This is done with
the command signal immediate.
Command
Description
(E&M ports only) Selects the four-wire cabling

scheme. MOH requires that you specify four-wire
operation with this command for E&M ports.
Example:
-
-
Example:
(E&M ports only) For E&M tie trunk interfaces,

directs the calling side to seize a line by going off
hook on its E-lead and to send address information
as DTMF digits.

(Cont.)
Creates the dial peer for the MOH connection
Associates the voice port to the dial peer
- -
Specifies the directory number of the MOH source

IPTX v2.04-56
A dial peer is needed to connect the physical E&M or FXO port to the destination pattern that
will be used to connect to the MOH feed. This is created with the dial-peer voice tag pots
command. The physical voice port that is used is associated with the port command, and the
telephone number that is used is defined by the destination-pattern command.
Command
Description
Enters dial-peer configuration mode
Example:
Associates the dial peer with a voice port
Example:

- -
Example:
Specifies either the prefix or the full E.164 telephone

number to be used for a dial peer

(Cont.)
Creates an ephone-dn
Configures a directory number for this ephone-dn

instance
Specifies that this ephone-dn is used for an incoming

or outgoing call that is to be the source for an MOH
stream
IPTX v2.04-57
An ephone-dn must be configured with the ephone-dn command. Next, the number of the
source of the MOH feed must be configured with the number command. This configures a
valid extension number for this ephone-dn instance. This number is not assigned to any phone;
it is only used to make and receive calls that contain an audio stream to be used for MOH. The
ephone-dn needs the moh command to use the specified live-feed audio stream as MOH for a
Cisco CallManager Express system. The connection for the live-feed audio stream is
established as an automatically connected voice call. If the out-call keyword is used, the type
of connection can include VoIP calls if voice activity detection (VAD) is disabled. The typical
operation is for the MOH ephone-dn to establish a call to a local router E&M port.
If the out-call keyword is used, an outbound call to the MOH live-feed source is attempted
every 30 seconds until the call is connected to the ephone-dn (extension) that has been
configured for MOH. Note that this ephone-dn is not associated with any physical phone.
If the moh command under the ephone-dn mode is used without any keywords or arguments,
the ephone-dn accepts an incoming call and uses the audio stream from the call as the source
for the MOH stream, displacing any audio stream that is available from a flash file. To accept
an incoming call, the ephone-dn must have an extension or phone number configured for it. A
typical use would be for an external H.323-based server device to call the ephone-dn to deliver
an audio stream to the Cisco CallManager Express system. Normally, only a single ephone-dn
would be configured like this. If there is more than one ephone configured to accept incoming
calls for MOH, the first ephone-dn that is successfully connected to a call (incoming or
outgoing) is the MOH source for the system.

Command
Description
Enters ephone-dn configuration mode.
Example:
dn-tag: Unique sequence number that identifies

this ephone-dn during configuration tasks. Range
is from 1 to 288.

Example:

]
Example:
Configures a valid extension number for this ephone-dn

instance. This number is not assigned to any Phone; it
is only used to make and receive calls that contain an
audio stream to be used for MOH.
number: String of up to 16 digits that represents a
telephone or extension number to be associated
with this ephone-dn.
Specifies that this ephone-dn is to be used for an
incoming or outgoing call that is to be the source for
an MOH stream. If this command is used without the
out-call keyword, the MOH stream is received from an
incoming call.
out-call outcall-number: (Optional) Indicates that
the router is calling out for a live feed that is to be
used for MOH and specifies the number to be
called. Forces a connection to the local router voice
port that was specified.
Summary
Summary
Call transfer settings can be applied to the system or to the IPPhone.
Call forwarding can be set up for all calls and for busy and ring no answer
situations.
Call waiting can be customized to use the standard beep or a ring or can be
disabled altogether.
Call park may be configured so that a call may be retrieved fromany phone.
The IP Phone display can be customized through labeling the line
in the header, setting an idle text message, or setting an idle URL
to run.
The softkeybuttons on the IP Phone may be customized for the idle, seized,
alerting, and connected states.
The directory can be used to look up Phone users and also to place calls to those
users.
Conferencing settings can be configured so that the originator, when
disconnecting, can either end the conference or let the conference continue.
Productivity tools like hookflash, intercom, and paging add functionality.
Phone rings and timers associated with placing a call can be customized.
MOH is a common feature, critical in most installations, and cancome from a live
feed or a prerecorded sound file.
IPTX v2.04-58
Lesson 3
Understanding Call Center

Features
Overview
This lesson defines the basic automatic call distribution (ACD) features of Cisco CallManager
Express and how to configure those features.
Objectives
Upon completing this lesson, you will be able to describe the basic ACD features that are
possible within Cisco CallManager Express. This includes the ability to do the following:
Describe and configure ephone hunt groups
Describe and configure logging in to and out of a hunt group through the use of the DND
softkey
Describe and configure the automated logout of an ephone-dn from a hunt group
Describe and configure basic ACD functionality through the use of the B-ACD TCL script
Ephone Hunt Groups
This topic describes functions and features of an ephone hunt group.
Ephone Hunt Groups

Hunt groups have a pilot number.
A hunt group is composed of a list of ephone-dns.
Selection behavior of the ephone-dn can be set to
either sequential, peer, or longest idle.
Hunt groups should have a default behavior at the
end of the hunt group, such as going to voice mail
or another hunt group.
IPTX v2.04-2
Ephone hunt groups provide the ability to direct incoming calls for a specific number
(the ephone hunt-group pilot number) to a defined group of ephone-dns. Incoming calls
are redirected based upon sequential, peer, or longest idle selection criteria.
At the end of hunt groups, a last resort behavior can be defined. This can be either an
ephone-dn or the pilot number for another ephone hunt group.
Configuring Ephone Hunt Groups
- -
Enters ephone-hunt configuration mode and defines the

ephone hunt group
Defines the pilot number, which is the number that is

dialed to reach the hunt group
Defines the list of directory numbers that are associated

with the hunt group (range is two to ten numbers)
IPTX v2.04-3
Use the command ephone-hunt to define one of 20 possible hunt groups in Cisco CallManager
Express version 3.2.1 and the method for selecting the destination to which an inbound call will
be sent. The pilot command can be used to define up to two numbers that will activate the hunt
group. To define the set of ephone-dns, use the list command. Up to ten ephone-dns can be put
into the hunt group, and a minimum of two is required.
In a sequential ephone hunt group, ephone-dns ring left to right in the order in which they were
listed when the hunt group was defined. The first number to ring is always the left-most number
in the list.
In a peer ephone hunt group, the first ephone-dn to ring is the number to the right of the
ephone-dn that last rang. Ringing proceeds in a circular manner, left to right, for the number of
hops that was specified when the ephone hunt group was defined.
In a longest-idle hunt group, the first ephone-dn to ring is the number that has been idle for the
longest period of time.
Note
A maximum of ten hunt groups is supported in Cisco CallManager Express version 3.2.
Configuring Ephone Hunt Groups (Cont.)
Defines the last number to which a call to an ephone

hunt group may be directed
--
Sets the number of seconds after which an

unanswered call is sent to the next selection in the
hunt group
IPTX v2.04-4
At the end of the hunt group, if no ephone-dn that is defined in the list has answered the call,
the incoming call is directed to the destination that is defined by the final command. This
destination can be the pilot number of another hunt group or the number of an ephone-dn.
The timeout command sets the amount of time, in seconds, that an incoming call can ring a
member of the hunt group before hopping to the next target in the hunt group. This is done in
ephone-hunt configuration mode and applies only to a specific hunt group.
Note
Call forwarding settings are ignored for calls that originate from the hunt group.
- -
Defines the preference order for the ephone that is

associated with the ephone hunt group (range is zero to
eight)
Specifies that the pilot number for the hunt group will not
register to the H.323 gatekeeper or SIP proxy server
IPTX v2.04-5
To set the preference order for the ephone-dn that is associated with the pilot number of a
Cisco CallManager Express ephone hunt group, use the preference command in ephone-hunt
configuration mode.
To specify that the pilot number for a Cisco CallManager Express peer ephone hunt group
should not register with an H.323 gatekeeper or session initiation protocol (SIP) proxy server,
use the no-reg command in ephone-hunt configuration mode. To return to the default of
registering the pilot number with an H.323 gatekeeper, use the no form of this command.
Note
To delete the no-reg command, enter no no-reg.
Enters telephony-service mode

-
Sets the number of times that a call can be redirected

within the Cisco CallManagerExpress system
Sets the number of hops before a call proceeds to the

final number
IPTX v2.04-6
A redirect, or hop, is the number of times that a call can be sent to the next ephone-dn. The first hop
is considered the movement of the call from the first ephone-dn to the second ephone-dn as defined
in the list command. The last hop always ends at the number configured in the
final command.
The number of maximum hops is configurable from 5 to 20 using the max-redirect number
command. The default is 5. If the maximum number of hops is reached, the call is dropped.
The command max-redirect number sets the maximum number of hops globally. In some
ephone-hunt configurations, the hops command can be used to limit the number of hops within
a specific peer hunt group.
Note
Be aware that busy and unanswered calls are counted as hops.
Example: Sequential Ephone Hunt Group

The Phone dials 1400,
the pilot number of
ephonehunt group 1.
1007
First choice if busy

or no answer: go
to next
1005
Second choice if
busy or no answer:
go to next
1002
Third choice if
busy or no answer:
go to next
1003
Fourth choice if
busy or no answer:
go to destination
defined by final
command
Top Down Selection
Final
IPTX v2.04-7
Sequential hunt groups will use a selection process starting at the left-hand side of the list
command. In this example, the list command has ephone-dns listed in the following order:
1007, 1005, 1002, and 1003. The first call goes to the ephone-dn with extension 1007 if
available. If the timeout expires or 1007 is busy, the call hops to 1005 if it is available. If
ephone-dn 1005 is busy or is not answered within the timeout value, the call hops to 1002 if it
is available. Assuming 1002 is busy or not answered within the timeout value, the call hops to
1003 if available. If 1003 is busy or not answered within the timeout value, the call hops to
whatever destination is defined using the final command. If at any time the max-redirect
setting is exceeded, the call is dropped.
Sequential Ephone Hunt Group

Configuration
-

-

IPTX v2.04-8
This figure shows the configuration for the example that was described on the previous page.
Example: Peer Ephone Hunt Group

the pilot number of
ephonehunt group 2.
1002
1001
The previous call

went to extension
number 1002.
The call will go to
extension number 1001
since the last went to
extension number 1002.
1000
1003
Round Robin
Selection
Final
If hops setting is exceeded.
IPTX v2.04-9
In a peer ephone hunt group, the first ephone-dn to ring is the number to the right of the
ephone-dn that last rang. Ringing proceeds in a round robin, or circular, manner from left to
right for the number of hops that was specified when the ephone hunt group was defined.
In this figure, the list command has been configured so that the ephone-dns are defined in the
following order: 1002, 1001, 1000, 1003.
The first incoming call goes to the ephone-dn with extension 1002 if available. Assuming that
ephone-dn 1002 answers the first call, the second call goes to 1001 if available. If 1001 is busy
or the timeout expires, the second call hops to 1000, the next ephone-dn in the list. This
continues until an ephone-dn in the hunt group answers the second call or the hop command
parameter is exceeded and the call uses the destination defined by the final command. If at any
time the max-redirect setting is exceeded, the call is dropped.
Peer EphoneHunt Group Configuration

-

-
IPTX v2.04-10
This figure shows the configuration for the example that was described on the previous page.
Example: Longest Idle Ephone Hunt Group

1000

the pilot number of
ephonehunt group 3.
2nd
1st
3rd
The next call will go to
extension 1002 because it has
the longest idle time.
The second call will go to
extension 1001 and the third
will go to 1003.
1000 is active.
1001
1001 has been idle

for 1:30 minutes.
1002
1002 has been idle

for 4:46 minutes.
1003
1003 has been idle

for 39 seconds.
IPTX v2.04-11
The longest idle method for distributing calls to hunt group members uses the idle time of
each member to determine where to send the next incoming call. If the ephone that has been
idle the longest does not answer or is busy, the call hops to the ephone with the second-longest
idle time, and so on. If no members of the hunt group are available, then the destination that is
configured with the final command is used. If the max-redirect setting is exceeded at any time,
then the call is dropped.
Longest Idle EphoneHunt Group

Configuration
-

-

-
IPTX v2.04-12
This figure shows the configuration for the example that is described on the previous page.
Dynamic Hunt Group Login and Logout

This topic describes how to log in to and out of an ephone hunt group.
Using DND for Hunt Group Login and

Logout
Idle
Alerting
Use the DND softkey button to toggle the ephone-dn

between available and unavailable for any ephone hunt
groups to which it belongs.
IPTX v2.04-13
A member of a hunt group can log in to or log out of all ephone-dns by toggling the Do Not
Disturb (DND) softkey button on the IP Phone. When the hunt group member is in the DND
state, the specific ephone-dn is not considered for any hunt groups that it belongs to. When the
DND softkey is used to remove the DND state, this puts the ephone-dn back into consideration
for any hunt groups that it belongs to.
Note
DND is supported only on Cisco IP Phones that have softkeys.
dndfeature ring Command
Allows ephone-dns with the feature ring set to sound

even when DND turned on

IPTX v2.04-14
To allow Phone buttons that are configured with the feature-ring option to ring when their
Phones are in DND mode, use the no dnd feature-ring command in ephone configuration
mode. To stop the ringing of calls to feature-ring ephone-dns when an IP Phone is in DND
mode, remove the no dnd feature-ring command from the ephone configuration by entering
dnd feature-ring. DND is supported only on Cisco IP Phones that have softkeys, and the
minimum version of Cisco CallManager Express that is required is version 3.2.1.
Note
Although the opposite might seem more intuitive, no dnd feature-ring is the command
that allows the line to ring while the Phone is in the DND state, and the dnd feature-ring
command suppresses rings to Phones that are in the DND state.
Automatic Logout of a Hunt Group
This topic describes how the Cisco CallManager Express system can be configured to
automatically log out an ephone-dn after an attempt to connect to the hunt group member
has not been answered.
Automatic Logout of a Hunt Group Member

If a call is unanswered for the timeout value of the
ephone hunt group, the ephone-dn is put into the
DND state.
Automatic logout is the same as if the Phone user
had pressed the DND softkey button.
Automatic logout must be enabled on the ephone
hunt group.
There are no shared line appearances.
Automatic logout is supported on Cisco IP Phones
7905G, 7912G, 7940G, 7960G, and 7970G.
IPTX v2.04-15
For Cisco CallManager Express version 3.2.1 and later, an ephone-dn of an ephone hunt group
can be logged out automatically after a call to the ephone-dn is unanswered. A call is considered
unanswered if it rings longer than the period of time configured in the timeout command in
ephone-hunt configuration mode. After an ephone-dn has been logged out, the Phone that is
assigned to it displays the DND indicator.
Configuring Automatic Logout of a Hunt

Group Member
Allows an ephone-dnto be logged out of the hunt

group by the system when it does not answer a hunt
group call
-

-

-

IPTX v2.04-16
Use the command auto logout in the ephone-hunt configuration mode to enable Cisco
CallManager Express to automatically log out a hunt group member if a call from the hunt
group is unanswered.
B-ACD Service
This topic describes the basic automatic call distribution (B-ACD) service and what it provides.
B-ACD Service
Provides automated attendant and call queuing
functions if no agent is available
Has tools for collecting and obtaining call
statistics
Requires two scripts, one for the automated
attendant function and the other the call queuing
function
Uses Cisco Systems TCL scripts
IPTX v2.04-17
Cisco CallManager Express 3.2.1 and later can provide an automated attendant function and a
call queuing function. These functions are enabled through the use of two Toolkit Command
Language (TCL) scripts. The two functions together provide what is known as the B-ACD service.
The automated attendant function can answer incoming calls and present a basic menu of up
to four options. Commonly presented options include enabling the caller to go directly to an
extension by entering the extension number and to go directly to an operator by pressing 0.
Of the four available options presented in the automated attendant menu, three can point to the
pilot number of an ephone hunt group. The automated function is enabled through
configuration of the automated attendant TCL script.
If a member of the hunt group is unavailable, the second function of the B-ACD service, call
queuing, activates. Call queuing allows calls to be placed in a queue in the order of their arrival.
Then, as members of the hunt group become available, the calls are serviced based on their
order in the queue. The call queuing function is enabled through configuration of the call
queuing TCL script.
Configuring B-ACD Service

Configure the B-ACD automated attendant function
Configure the B-ACD call queuing function
Configure the dial peer to use the B-ACD service
Customize the audio files
Configure the system to collect and report B-ACD
statistics
IPTX v2.04-18
Setting up the B-ACD service requires the configuration of both the automated attendant and
call queuing TCL scripts. In addition to configuring various parameters in the scripts within
Cisco CallManager Express, the dial peers must be configured. This configuration involves
associating an application with the dial peer so that when an outside call arrives and matches
the dial peer, the appropriate automated attendant functions are activated.
The default welcome greeting likely will not be sufficient for most installations of the B-ACD
service. The welcome greeting as well as the other prompts within the service can be customized
to fit specific environments.
By default, the Cisco CallManager Express system does not collect statistics such as average
wait time and calls handled by the hunt group and member. The system must be configured to
collect these and other statistics relevant to the B-ACD service.
Configuring the B-ACD Automated

Attendant TCL Script
Defines the name of the application as well as the

location of the TCL script
Specifies the language for the dynamic prompts that

are used by the automated attendant functions
-

Defines the category and location of audio files used

IPTX v2.04-19
The B-ACD automated attendant TCL script must be downloaded from the Cisco.com website,
then loaded into flash using the archive command on the Cisco CallManager Express router.
The needed files are all contained in the file cme-b-acd-2.0.0.0.tar. The command call
application voice application-name flash:tcl-filename is used to define the name of the
automated attendant application as it is referenced in the Cisco IOS configuration, as well as
the name and location of the TCL script in the routers flash RAM to use.
The language of the dynamic prompts that are used by the automated attendant application is
specified with the command call application voice application-name language digit languagecode. The digit parameter can be any number from 0 through 9 and identifies the language that
the audio files are in. The language code parameter can be set to any of the following:
en English
sp Spanish
ch Mandarin
aa all
Note
The default automated attendant prompts are in English only and will need to be customized
for another language
The category and location of the audio files that are used by the application are defined by the
command call application voice application-name set-location language-code category
location. The language code parameter can be set to any of the following:
en English
sp Spanish
ch Mandarin
aa all
The category parameter is a numeric value from 0 through 4, with 0 representing all categories.
For example, audio files representing the days and months could be category 1, audio files
representing units of currency could be category 2, and audio files representing units of time
seconds, minutes, and hourscould be category 3.
The location parameter defines the location of the audio files. Valid locations include local
flash, HTTP servers, FTP servers, TFTP servers, and Real Time Streaming Protocol (RTSP)
servers.

Attendant TCL Script (Cont.)
Assigns a pilot number to the B-ACD service
Declares the maximum number of ephone hunt group

menus that are supported by the B-ACD service
-
-
Associates the B-ACD automated attendant script

with the B-ACD call queuing script
IPTX v2.04-20
When configuring the automated attendant script, the pilot number is defined by using the
command call application voice application-name aa-pilot pilot-number. The pilot number
is the number that activates the B-ACD service when it is dialed by outside callers.
The number of menu items that point to ephone hunt groups is defined by the command
call application voice application-name number-of-hunt-groups number. This setting can
be from 1 to 3. The default is 3.
The automated attendant script must be associated to the call queue script so that they can work
together. To set up this association, use the command call application voice application-name
service-name call-queue-script-name. For call-queue-script-name, enter the name of the call
queue application as referenced by the IOS configuration, not the name of the TCL script.

-
--
Sets the time a call sits in a queue before the second

greeting is played
Enables direct extension access and sets the option

number

--
Sets the amount of time in queue before a call can be

transferred to an ephone hunt group or voice mail
IPTX v2.04-21
The command call application voice application-name second-greeting-time seconds is

used to set the amount of time that a caller sits in a queue before the second greeting is played.
It also sets the time between repeats of the second greeting when the call continues to sit in
the queue.
To define the automated attendant menu option that allows a caller to dial by extension number,
use the command call application voice application-name dial-by-extension-option number.
For example, if callers should press 1 to enable them to dial by extension, then enter 1 for
number.
The command call application voice application-name call-retry-timer seconds sets the
amount of time that a call must wait in a queue before the system automatically attempts to
transfer the call to a hunt group pilot number or voice mail pilot number. The range of valid
entries is from 5 seconds to 30 seconds. The default is 15.


--
Assigns the maximum period of time a call can stay

in a queue
Assigns a pilot number to the B-ACD voice mail
Sets the number of times that calls can attempt to

reach voice mail
IPTX v2.04-22
In order to set the maximum time that a call can remain in a queue, use the command
call application voice application-name max-time-call-retry seconds. When a call in a
queue reaches this setting, the call will be disconnected. The range of valid settings is from
0 to 3600 seconds. The default is 600 seconds (10 minutes).
The command call application voice application-name voice-mail number sets the B-ACD
voice-mail pilot number.
To set the number of times that calls can attempt to redial voice mail if all ports are busy, use
the call application voice application-name max-time-vm-retry number command.
Example: B-ACD Automated Attendant

TCL Script
Configuring B-ACD automated attendant TCL script
and naming the application AutoAtt
-

-

-
-

-

- -
IPTX v2.04-23
This figure shows a configuration of the B-ACD automated attendant TCL script when the
automated attendant application is named AutoAtt.
Configuring the B-ACD Call Queuing

TCL Script
Associates call queuing with automated attendant
Sets the maximum number of hunt groups that the

call queuing function will manage
Sets the menu number and associates it with the pilot

number of an ephone hunt group
IPTX v2.04-24
To associate call queuing with the automated attendant, the call queuing script must be
associated with the name of the automated attendant application. To do this, use the command
call application voice application-name aa-name aa-script-name. For example, if the name of
the call queuing application is Queuing and the name of the automated attendant application is
AutoAtt, then this command would be configured like this: call application voice Queuing aaname AutoAtt.
The command call application voice application-name number-of-hunt-groups number
specifies the number of hunt groups that can be associated with the call queuing function. This
command defines how many queues the call queuing function will manage. The range is 1 to 3.
The default is 3.
To associate the pilot number of an ephone hunt group to a menu option, use the command call
application voice application-name aa-huntmenunumber pilot-number. Repeat this command
for each menu option that will be presented to the caller, up to the maximum of three.
Configuring the B-ACD Call Queuing

TCL Script (Cont.)
Sets the maximum number of calls allowed in the

queue of each ephone hunt group
Enables or disables the collection of call queuing

debug information
IPTX v2.04-25
The command call application voice application-name queue-len number is used to set the
maximum number of calls that are allowed in the queue of each hunt group.
For troubleshooting and to obtain debugging information, you must enable the collection of call
queuing data by using the command call application voice application-name queue-managerdebugs 1. This command enables debugging, but it does not start the debug. Use a value of 0 to
disable the collection of debugging information.
Note
To start the debug, use the command debug voip ivr script.
Example: B-ACD Call Queuing TCL Script

Configuring B-ACD call queuing TCL script for an
application named Queuing

-

-
IPTX v2.04-26
This figure shows a configuration of the B-ACD call queuing TCL script when the call queuing
application is named Queuing.
Configuring the Dial Peer for the B-ACD

Service
Assigns the automated attendant application to the

dial peer

-
---

IPTX v2.04-27
For the B-ACD service to function, the automated attendant application must be associated
with one or more dial peers. To set up this configuration, use the command application
application-name in dial-peer configuration mode for each dial peer that is to be associated
with the automated attendant application. The dial peers can be Voice over IP (VoIP) or plain
old telephone service (POTS). In the figure, the automated attendant application called AutoAtt
will activate when outside calls arrive at either the POTS or the VoIP dial peer.
Customizing B-ACD Audio Files

Customized audio files can be used instead of
the default prompts
There are seven audio files.
File names cannot be changed.

All prompts must be in G.711 with 8-bit, mu-law, and
8kHz encoding.
Save in .au file format using a tool such as Adobe
Audition.
Upload to flash of Cisco CallManagerExpress router.
IPTX v2.04-28
The Cisco CallManager Express B-ACD service uses seven audio files. You can rerecord these
audio files to customize them. However, you cannot change the names of the files and you
cannot determine when the files are played to callers. These seven files must then be loaded
into the flash of the CallManager Express router that is running the B-ACD script.
The following is a list of the seven files and their default messages:
Default B-ACD Audio Files
File Name
Message
en_bacd_welcome.au
Thank you for calling. Includes a 2-second pause after the

message.
en_bacd_options_menu.au
For sales, press 1 (pause); for customer service, press 2 (pause); to

dial by extension, press 3 (pause); to speak to an operator, press
zero. Includes a 4-second pause after the message.
en_bacd_disconnect.au
We are unable to take your call at this time. Please try again at a
later time. Thank you for calling. Includes a 4-second pause after the
message.
en_bacd_invalidoption.au
You have entered an invalid option. Please try again. Includes a 1second pause after the message.
en_bacd_enter_dest.au
Please enter the extension number you want to reach. Includes a 5second pause after the message.
en_bacd_allagentsbusy.au
All agents are currently busy assisting other customers. Continue to

hold for assistance. Someone will be with you shortly. Includes a 2second pause after the message.
en_bacd_music_on_hold.au Music on Hold (MOH) is played to Cisco CallManager Express

B-ACD callers only.
Each of the menu options listed in the en_bacd_options_menu.au file must provide callers with
a number that can pressed. For example, if the following is the automated attendant and call
queuing configuration:
call application queue number-of-hunt-groups 3
call application queue aa-hunt1 1111
call application queue aa-hunt2 2222
call application aa dial-by-extension-option 3
Then the en_bacd_options_menu.au could be recorded to say the following:
Welcome to Company X.
Press 1 to reach department 1. (System dials pilot number 1111.)
Press 2 to reach department 2. (System dials pilot number 2222.)
If you know your partys extension, press 3. (Permits caller to dial an extension directly.)
The Cisco CallManager Express B-ACD prompts require a G.711 audio file (.au) format with
8-bit, mu-law, and 8-kHz encoding. Cisco recommends the following audio tools or others of
similar quality:
Adobe Audition for Microsoft Windows by Adobe Systems Inc. (formerly Cool Edit, by
Syntrillium Software Corp.)
AudioTool for Solaris by Sun Microsystems Inc.
Example: Typical Call to B-ACD Service

Pilot Number
PSTN
1. The B-ACD automated attendant service answers the outside call to the pilot
number.
2.The automated attendant plays the en_bacd_welcome.aufile, then the
en_bacd_options_menu.aufile, which informs callers of their options.
3.The caller selects the option for the sales department.
4.The sales department option points to ephone hunt group 1.
5.If there are available hunt group members, the call is sent to the hunt group
pilot number.
6.If no hunt group members are available (they are all on calls orin the DND
state), the B-ACD call queuing service activates.
7.The en_bacd_allagentsbusy.aufile plays followed by the
en_bacd_music_on_hold.aufile.
8.The call is placed in a queue until a hunt group member becomes available.
IPTX v2.04-29
This figure shows a typical call to the pilot number of the B-ACD service.
Monitoring and Reporting on the B-ADC

Service
Enable collection of statistics.
Use show commands to view the collected statistics.
Collected statistics can be stored on a TFTP server.
IPTX v2.04-30
In order to report on the operation of the B-ACD service, the collection of B-ACD statistics
must be enabled. The statistics can then be displayed using show commands. In addition,
the statistics can be periodically written to a TFTP server, from which an administrator or
third-party applications can access the information.
Configuring Monitoring and Reporting on

the B-ACD Service
---
Enables the collection of B-ACD statistics for this

ephone hunt group

---
IPTX v2.04-31
To enable the collection of call statistics, the command statistics collect must be entered under
all relevant hunt groups. The figure shows statistic collection being enabled for ephone hunt
group 1.

the B-ACD Service (Cont.)
- - --- - - --- - -
Displays ephone hunt group configuration, current

status, and statistics information
- --- -
-
-
-
-
- --
- - --
--
- --
--
---
IPTX v2.04-32
The command show ephone-hunt displays the collected statistics of a hunt group.
The following output is an example of what might be displayed by the show ephone-hunt
statistics last 2 hours command:

-
-
-
-
- --
- - --
--
- --
--
---

- -
--
- --

- -
--
- --

- -
--
- --
---
- -
- - -
-
- --
- - --
-
--
-
- -

-
-
---
- -
- - -
-
- --
- - --
-
--
-
- -

the B-ACD Service (Cont.)
-
--
-
Sets filename parameters and URL path

-
Sets the hourly interval at which the B-ACD call

statistics are collected for the report
-
Delays the report time

IPTX v2.04-33
The commands that govern the automated writing of call statistics to a TFTP server are listed
on this page.
The command hunt-group report url prefix tftp://url-address/directory-name is used to
define the location to which the files will be written and the starting prefix of the name of the
file or files.
Note
The files that are referenced must exist and be able to be written to.
The command hunt-group report url suffix from-number to to-number is used to define a
numeric suffix that must be present on the end of files on the TFTP server. The from-number
must be either 0 or 1 and the to-number can be from 1 through 200.
The combination of the two hunt-group report url commands determines the names of the
files that must be present on the TFTP server. The prefix determines the start of the filename
and the suffix determines the numeric values that reside on the end. The extension of the file is
not mandated by these commands.
To set the hourly interval at which B-ACD statistics will be collected and written to files, use
the command hunt-group report every number hours. The range is from 1 through 84 hours.
To delay data collection for one to ten hours, use the command hunt-group report delay
number hours. Data collection delay might be desirable because calls are counted when they
end. For example, a call is connected from 1:35 p.m. to 3:30 p.m. If the data collection interval
is set to 1 (every hour with no delay), TFTP will write the 1 p.m. to 2 p.m. statistics at 2 p.m.
However, at 2 p.m., the 1:35 p.m. call is still active, so it will not appear in the TFTP report.
When the call finishes at 3:30 p.m., it will then be counted as occurring from 1 p.m. to 2 p.m.
The show hunt-group command will report this, but TFTP will have already sent out its report
for the 1 p.m. to 2 p.m. time slot. To include the 1:35 p.m. call in the TFTP file, the huntgroup report delay number hours command could be used to delay TFTP statistics reporting
for an extra two hours so that the 1 p.m. to 2 p.m. report will be written at 4 p.m. instead of 2
p.m.
Note
The file that is written is a comma separated values (CSV) file and is not user-friendly. There
are third-party applications that can decode the output.
Example: Configuring Monitoring and

Reporting on the B-ACD Service
Statistics collection begins at 18:20.
10.10.0.99

-
-
At 19:00, statistics have been collected for 40 minutes; no statistics have been
sent because it is less than the configured 3 hours.
At 20:00, statistics have been collected for 1:40 hours; no statistics have been
At 21:00, statistics have been collected for 2:40 hours; no statistics have been
At 22:00, statistics have been collected for 3:40 hours; however, because of the
delay command, the statistics will not be written to a file until 23:00.
IPTX v2.04-34
This example sets up the hunt-group report mechanism to use TFTP to send call statistics every
three hours to the files data000 through data200 that are located on the TFTP server at IP
address 10.10.0.99 under a directory that is named dirdata1. A delay of one hour has been
configured.
Before the statistics can be written to a file, statistics collection has to take place for at least
three hours. In addition, a one-hour delay has been inserted. The following is a chronology of
events that take place under the configured parameters if statistics collection begins at 18:20:
At 19:00, statistics collection has been active for 40 minutes; no statistics are written to the
file because it is less than the configured three hours.
At 20:00, statistics collection has been active for one hour and 40 minutes; no statistics are
written to the file because it is less than the configured three hours.
At 21:00, statistics collection has been active for two hours and 40 minutes; no statistics are
written to the file because it is less than the configured three hours.
At 22:00, statistics collection has been active for three hours and 40 minutes; sufficient
time has passed, but because of the configured one-hour delay, the statistics will not be
written to a file on the TFTP server until 23:00.
Summary
Summary
Ephone hunt groups contain members.
The hunt group member can be selected based upon a
sequential, peer, or longest idle criteria.
Members can log in to or log out of a hunt group by using the
DND softkey button.
If a member of a hunt group does not answer the call, the
Cisco CallManagerExpress system can be configured to log
out the member automatically.
The B-ACD service is composed of automated attendant and
call queuing functions.
The B-ACD service can be customized to fit the needs of the
deployment.
Statistics concerning B-ACD service calls can be gathered
and written to a file on a TFTP server.
IPTX v2.04-35
Lesson 4
Defining TAPI Support for

Overview
This lesson defines the productivity tool called the Cisco IOS Telephony Service Provider
(TSP) and how it can be used to interact with Cisco IP Phones.
Objectives
Upon completing this lesson, you will be able to describe Telephony Application Programming
Interface (TAPI) Lite support for Cisco CallManager Express. This includes being able to
meet these objectives:
Describe Cisco IOS TSP functions and software features
Describe tasks to download and set up Cisco IOS TSP
Describe how to view the TAPI integration status of IP Phones
Identify the steps for modifying and removing a TSP configuration on the PC
Describe the function of and tasks needed to configure an integration of Cisco CallManager
Express and Microsoft CRM
Functions and Features
This topic describes functions and features of the Cisco IOS TSP.
Functions and Features

A PC that is running the Cisco IOS TSP
software enables the user to perform some
Phone functions from the PC.
Answers inbound calls
Forwards incoming calls to voice mail

Displays caller ID for inbound calls
Can dial from an address book on the PC
Places calls on hold
Has dial functionality in Outlook
Is available for third parties to build applications to
IPTX v2.04-2
Cisco CallManager Express provides an interface that enables simple one-to-one remote
control of a Cisco IP Phone by an associated PC that is running the Cisco IOS TSP. This
interface is intended to support only basic TAPI services and to enable screen popups of caller
IDs for incoming calls. It also supports simple outgoing call placement using one-click
address bookstyle speed dialing from the PC application.
The Cisco IOS TSP software package works as an interface between the TAPI that is running
on Microsoft Windows and the Cisco CallManager Express router. This software can provide
the following functionality:
Communicates with the TAPI using the TSP interface (TSPI)
Implements a required set of application program interfaces (APIs) and works with TAPI
Enables other TAPI-based applications to provide call control to the Cisco IP Phones that
are connected to the Cisco CallManager Express router
Cisco IOS TSP software increases personal productivity by enabling call handling management
from a PC without the user having to pick up a Phone handset or dial numbers on the Phone keypad.
The following functionalities are available:

Answering incoming calls
Forwarding incoming calls to voice mail
Dialing address book entries (placing outbound calls from an address book)
Displaying caller IDs via screen popups
Placing calls on hold
Note
This software does not add full TAPI support for multiple users or for the multiple call
handling that is required to implement such complex features as automatic call distribution
(ACD) and IP Contact Center (IPCC).
Cisco IOS TSP Configuration on the PC

This topic describes Cisco IOS TSP configuration on the PC.
TSP Configuration on the PC

To install the Cisco IOS TSP software on a
PC, these tasks must be completed:
Obtain the CiscoIOSTSP1.3.zip file from cisco.com.
Run the setup program that was downloaded with
the .zip file.
Enter the user credentials, IP address, port
number, and whether a headset is being used.
Restart the PC.
IPTX v2.04-3
Ensure that there is network connectivity between the PC and the Cisco CallManager Express
router. To verify network connectivity, enter the ping ip-address command on the PC,
specifying the IP address of the Cisco CallManager Express router.
Install CiscoIOSTSP1.3.zip by running the setup program that was downloaded. This program
installs the following dynamic link library (DLL) files in the system directory of the PC:
CiscoIOSTSP.tsp
CiscoIOSTUISP.dll
LogTrace.dll
Note
After the DLL files are installed, the Cisco IOS TSP configuration dialog box appears before
the installation is complete.
TSP Configuration on the PC (Cont.)
Username and password

that match the login of the
Phone user
IP address and port of the
router
Select the timeout value in
seconds
Select if using a headset
Select to enable trace for
troubleshooting
IPTX v2.04-4
When this configuration dialog box appears, the user must enter information into the
required fields.
Step 1
Enter the username and password of the Cisco IP Phone user.
Step 2
Enter the IP address and port number of the Cisco CallManager Express router.
Step 3
The Synchronous Message Timeout response from the Cisco CallManager Express
router may be set (the default is 3 seconds).
Step 4
If you are using a headset, check the Using Headset check box.
Step 5
Check the Trace check box to enable tracing for troubleshooting purposes. It is best
to use the trace feature only temporarily because the trace function slows down the
TAPI application.
When prompted, restart the PC. Once the PC has rebooted, a third-party application may be
implemented to control the Phone and interact with the Cisco IOS TSP.
Cisco IOS TSP Configuration on the Router
This topic describes how to view the Cisco IOS TSP configuration on the router.
TSP Configuration on the Router
- -
Displays ephones that have an active TAPI

integration
- -
- --
-

- -- -

- --
--
IPTX v2.04-5
After the installation of the Cisco IOS TSP is completed and the PC is rebooted, the status
of the TAPI integration can be verified by using the show ephone tapiclients command
from privileged executive mode. The MAC address and ephone are displayed as well as
the credentials used to register with the Cisco CallManager Express router. The status of
the Phone is also shown.
Modifying Cisco IOS TSP Configuration

on the PC
This topic describes how to modify the Cisco IOS TSP configuration on the PC.
Modifying TSP Configuration on the PC

To modify the TSP settings after the
installation process:
Go to the PC Control Panel
Select Phone and Modem Options
Select the Advanced tab
Highlight Cisco IOS Telephony Service Provider
and select Configure
Restart any TAPI applications and reboot if
prompted
IPTX v2.04-6
To modify the Cisco IOS TSP configuration, follow these steps:

Step 1
To modify a TSP configuration, click the Phone and Modem option from the
PC Control Panel. (Note: The name of this option may vary, depending on the
operating system.)
Step 2
Click the Advanced tab in the Phone and Modem Options dialog box. Cisco IOS
Telephony Service Provider is in the Providers list.
Step 3
Choose Cisco IOS Telephony Service Provider and click Configure.
Step 4
Make the changes that are desired in the Cisco IOS Telephony Service Provider
dialog box.
Step 5
Restart TAPI applications and restart the PC if prompted to do so. After changing
the username, password, and IP address or port of the Cisco IOS TSP, close all the
TAPI applications for the changes to take affect. If any services that depend on the
TSPsuch as Remote Access Connection Managerare running, restart the system
for the changes to take affect. There might be a prompt to reboot the system.
Removing the TSP from the PC

To remove the Cisco
IOS TSP:
Go to the PC Control
Panel
Select Phone and Modem
Options
In Phone and Modem
Options, select the
Advanced tab
Highlight Cisco IOS
Telephony Service
Provider and select
Remove
IPTX v2.04-8
To remove the Cisco IOS TSP from the PC, follow these steps:
Step 1
Click the Phone and Modem option from the PC Control Panel. (Note: The name of
this option may vary, depending on the operating system.)
Step 2
Click the Advanced tab in the Phone and Modem Options dialog box. Cisco IOS
Telephony Service Provider is in the Providers list.
Step 3
Choose Cisco IOS Telephony Service Provider and click Remove.
Cisco CallManager Express and Microsoft CRM

Integration
This topic describes the integration of Cisco CallManager Express and the Microsoft Business
Solution Customer Relationship Management (Microsoft CRM) product.
Cisco CallManagerExpress and Microsoft

CRM Integration
IPTX v2.04-9
One of the most compelling applications that can be integrated with Cisco CallManager
Express through the use of the Cisco IOS TSP is the Microsoft CRM. An integrated CRM
solution enables the company to more efficiently and effectively address customer needs and,
by doing so, build profitable customer relationships.
The Cisco CRM Communications Connector (CCC), which was developed with technical
information and feedback from Microsoft, allows the quick and easy integration of Microsoft
CRM and Cisco CallManager Express with no additional hardware required. Additionally, the
full line of Cisco IP Phones is supported, from the entry-level Cisco IP Phone 7902G to the
advanced Cisco IP Phone 7970G. The Cisco CCC uses Microsoft Outlook or IE as the primary
client for managing tasks and contacts.

CRM Integration (Cont.)
CRM integration features:
Screen popup of a new contact record when a call arrives or is

placed
Click to dial from a Microsoft CRM contact record
Call duration tracking and record creation
Call properties are captured for inbound and outbound calls
Calling number
Called number
Start time
End time
Customer record creation when a call arrives from a new

customer
IPTX v2.04-10
The Cisco CCC empowers small- to medium-sized businesses and branch offices to fully tap
the potential of both Microsoft and Cisco to provide a complete CRM solution.

CRM Integration (Cont.)
Cisco CCC for Cisco CallManagerExpress
installation:
Install the Cisco CCC server software on the
Microsoft CRM server
Install the Cisco IOS TSP on the PC associated

with the Cisco IP Phone
Install the Cisco CCC client software on the PC
that is associated with the Cisco IP Phone
IPTX v2.04-11
In order for the integration of Cisco CallManager Express and Microsoft CRM to be complete,
three pieces of software need to be installed. The Cisco CCC server installation file needs to be
installed on the Microsoft CRM server. The other two files need to be installed on the PC of the
CRM client. The Cisco IOS TSP needs to be installed first, then the Cisco CCC client software
can be installed. Supported client PC operating systems include the following:
Window 98 Second Edition
Windows 2000 Server
Windows 2000 Professional
Windows XP Professional
Windows XP Home
The client PC must also meet the following minimum requirements:
Microsoft .NET framework 1.1
IE 5.5 with service pack 2 for web interface
Tip
See the following URL for detailed installation instructions:

http://cisco.com/en/US/products/sw/voicesw/ps4625/products_feature_guide09186a008020
49fe.html
Summary
Summary
The Cisco IOS TSP enables a PC to have a
one-to-one relationship with a Phone.
A Phone can be controlled through the PC.
To install the Cisco IOS TSP, the username and
port must be collected prior to installation.
The status of an IP Phone TAPI integration may be
viewed on the Cisco CallManagerExpress router.
After installation, modifying the Cisco IOS TSP is
accomplished through the Control Panel under
Phone and Modem Options.
IPTX v2.04-12
Lesson 5
Describing Network
Management for Cisco
CallManager Express
Overview
This lesson defines network management features that can be used to monitor, maintain, and
configure the Cisco CallManager Express system.
Objectives
Upon completing this lesson, you will be able to describe setup utility, syslog, and billing. This
includes being able to meet these objectives:
Describe and configure syslog
Describe billing support
Describe CDRs
Describe the Cisco CNS configuration engine
Syslog Messages and MIBs
This topic describes Cisco CallManager Express syslog messages and Management
Information Bases (MIBs).
Cisco CallManager Express Syslog

Messages
%IPPHONE-6-REG_ALARM
%IPPHONE-6-REGISTER
%IPPHONE-6-REGISTER_NEW
%IPPHONE-6-UNREGISTER_ABNORMAL
%IPPHONE-6-UNREGISTER_NORMAL
IPTX v2.04-2
One of the additional network management features that Cisco CallManager Express supports
is the type 6 syslog messages for IP Phone registration and unregistration. These syslog
messages help the central network management systems manage Cisco CallManager Express
and IP Phones. These messages usually go to a remote syslog server for long-term collection
and analysis.
Example: Syslog Messages

These examples show the output generated when a Phone is reset from the command-line
interface (CLI) of the Cisco CallManager Express router.
*Mar 1 13:17:48.815: %IPPHONE-6-UNREGISTER_NORMAL: ephone2:SEP000F2470F8F8 IP:10.0.0.25 Socket:2 DeviceType:Phone has unregistered normally.
*Mar 1 13:18:07.211: %IPPHONE-6-REG_ALARM: 22: Name=SEP000F2470F8F8
Load=3.2(2.14) Last=Reset-Reset
*Mar 1 13:18:07.211: %IPPHONE-6-REGISTER: ephone-2:SEP000F2470F8F8
IP:10.0.0.25 Socket:2 DeviceType:Phone has registered.
Cisco CallManagerExpress MIBs

Cisco-DIAL-CONTROL-MIB (CDR/call history)
Cisco-VOICE-CONTROL-MIB (extends to
telephony and VoIP dial peers and call legs)
Cisco-VOICE-IF-MIB
IPTX v2.04-3
Through the Simple Network Management Protocol (SNMP), a network management

station such as CiscoWorks can collect, monitor, and implement changes to configurations.
The network management station uses the Get, Get Next, Trap, and Set messages to accomplish
this task. The Cisco CallManager Express router stores information regarding the calls that
have taken place in the form of Call Detail Records (CDRs) and the call history information
in these three IOS MIBs: Cisco-DIAL-CONTROL-MIB, Cisco-VOICE-CONTROL-MIB
(extends to telephony and Voice over IP [VoIP] dial peers and call legs), and Cisco-VOICE-IF-MIB.
This process enables a network management station to gather detailed information about a
specific call and summaries of all calls. Account codes are also supported in the CDRs, and this
information can be used for billing purposes.
Billing Support
This topic describes Cisco CallManager Express billing support.
Billing Support
Billing support is through the use of an
account code field in the CDRs.
The account code field is added through the use of
the Acct softkey during the call alerting or
connected state.
The account code field can be used by a RADIUS
server or customer billing server.
The account code is added into the Cisco-VOICEDIAL-CONTROL-MIB.
IPTX v2.04-4
An account code field can be placed into the CDRs, which can then be used by a
RADIUS server or customer billing server for billing processes. The Acct softkey is
added to the Cisco IP Phones 7940G and 7960G so that users can enter account codes
from an IP Phone during call alerting or connected state. This account code is also added
into the Cisco-VOICE-DIAL-CONTROL-MIB.
Example: Viewing the Account Code from the CLI

To view an account code from the CLI, use the show call active voice command. The
following is the output from the command:
-
-
-
-
-
- -
-
Billing Support: AAA and Syslog Servers

- -- -

-- --

service timestamps places a time stamp in any

syslog message.
AAA commands configure the authentication,
authorization, and accounting.
Gateway accounting for H.323 CDRs is sent to
the syslog server.
The syslog server is defined with the logging
command.
IPTX v2.04-5
When configuring network management tools, the ability to perform authentication,

authorization, and accounting (AAA) with an external security server is often desirable.
If this is desired, AAA must be configured on the Cisco CallManager Express router.
The Cisco CallManager Express router can be configured to allow syslog messages to be
sent to an external syslog server, when this is desirable. It is important to put a time stamp
on each message, and the Cisco CallManager Express router should be synchronized with
a Network Time Protocol (NTP) server.
Billing Support: Softkeys

Select the
softkeybutton
named more to
get to the second
page. On the
second page,
select the Acct
softkey button.
IPTX v2.04-6
To enter an account number with the CDR for this call, select the softkey button named more.
On the next screen, select the Acct softkey button, either during call setup or in the connected
state. This places the call on hold until the account code has been entered. With the call on
hold, enter the account number followed by the pound (#) key to tell the system not to wait for
the interdigit timeout. The call is reconnected, and the account code is inserted into the CDR.
Tip
For partner applications that may use the billing information, see the following URL:
http://forums.cisco.com/eforum/servlet/IPCApps?page=Application_Search
CDR
CDR
The call history log is enabled by default on
Cisco CallManager Express and allows CDRs
to be displayed in the GUI.
Use dial-control-mib to log call history to the buffer
Use the logging command to send the call history to
an external syslogserver

-
--

IPTX v2.04-7
CDRs are created by default in the Cisco CallManager Express system, and these records
contain the starts, stops, attempts, failures, and other information regarding all the calls in the
system. These records can be sent to a syslog server.
CNS
Cisco CallManager Express Auto-Provisioning
with CNS Configuration Engine
CNS Configuration
Engine
HTTP
HTTP
WAN
Cisco
CallManager
Express
Cisco
CallManager
Express
Cisco CallManager Express routers with minimal bootstrap configuration

can be provisioned from CNS Configuration Engine at the hub site.
The CNS Configuration Engine is supported with all platforms andversions
of Cisco CallManager Express.
The configuration template for each router is stored in the CNS server; after
the Cisco CallManager Express router is connected to the network, the
configuration is downloaded automatically from the CNS server using HTTP.
IPTX v2.04-8
The Cisco Networking Services (CNS) Configuration Engine is a secure network product that
supports the activation of customer premises equipment (CPE)based network services through
centralized template-based configuration management. The CNS Configuration Engine
provides a scalable infrastructure for managing the large-scale deployment of Cisco Systems
devices. It takes full advantage of the CNS Intelligent Agent technology of Cisco IOS software
and can manage as many as 5000 Cisco CPE products, including Cisco CallManager Express
and Cisco switches.
Using Secure Socket Layer (SSL) to interface with Cisco IOS software devices, the CNS
Configuration Engine provides an end-to-end zero-touch deployment solution for the entire
portfolio of Cisco IOS CPE products. The CNS Configuration Engine offers a programmatic
interface to the operations support systems of the customer using the CNS Software
Development Kit.
CNS Cisco CallManager Express Bootstrap

Configuration
-
--
- - -- - --
-
The MAC address of FastEthernet 0/0 is used as the

ID to send to the CNS server.
The address of the CNS server is specified.
IPTX v2.04-9
To set up the Cisco CallManager Express router to get its configuration from the CNS
Configuration Engine, some minimal configuration is required. This configuration includes
assigning a MAC address that will be matched to a CNS Event ID and a CNS Config ID on the
CNS Configuration Engine. The IP address of the CNS Configuration Engine server is
specified with the cns config command, and this address must be reachable by the router.
CNS Device Configuration
The Cisco CallManager Express router is mapped to a configuration

template in the CNS Configuration Engine database.
CNS Event ID and CNS Config ID should match the MAC address of the
interface that is specified in the bootstrap configuration.
IPTX v2.04-10
The device that is configured is entered into the CNS Configuration Engine server and is
defined by a MAC address. A template or file can then be assigned to configure the device
upon initialization.
CNS Template Configuration
The template can be manually added or uploaded from a text file.Unique variables
such as hostnames, passwords, and extension numbers can also be set for
individual Cisco CallManager Express routers.
The template is defined in XML format. The XML parser that is built into Cisco IOS
software interprets and applies configuration to the Cisco CallManager Express
router.
IPTX v2.04-11
The template that is used with a device can be customized in the Configuration Engine, then
assigned to the device. This is implemented through the use of an XML format that allows for
unique values to be assigned per device, which lets one template be used for multiple devices.
Summary
Summary
There are syslog messages that deal with
registrations of Phones.
The MIBs that are supported provide a way to
collect CDRs, call legs, dial peers, and information
about the system.
Account numbers that are inserted in the CDRs
and MIBsprovide a mechanism by which billing
functions can be performed.
CNS provides a way to bulk-manage and provision
many Cisco CallManager Express systems.
IPTX v2.04-13
Reference
For additional information, refer to Cisco CallManager Express 3.2.1 System Administrators
Guide: Overview at
http://cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_chapter09186a00
802d2476.html
Module Summary
This topic summarizes the key points that are discussed in this module.
Module Summary
This module defines additional features that can be
installed and configured to enhance a basic Cisco
CallManager Express installation.
This module defines how to install, monitor, and
customize the call center features of the B-ACD
service.
This module defines how to install, modify, and
remove the TAPI software.
This module defines the various management
features of Cisco CallManagerExpress.
IPTX v2.04-1
Reference
Cisco CallManager Express 3.2: Overview.
a00802d2476.html.
Cisco CallManager Express 3.2: Configuring Cisco CME PhoneFeatures .
a00802d241a.html.
Cisco CallManager Express 3.2: Configuring an Attendant for Primary Call Coverage .
a00802d23d1.html.
Cisco IOS TCL IVR and VoiceXML Application Guide:Configuring Audio File Properties
for TCL IVR and VoiceXML Applications.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/iv
rapp/ivrapp03.htm.
Cisco CallManager Express 3.2: Configuring Productivity Tools.
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_feature_guide
_chapter09186a00802d2544.html.
Cisco CallManager Express 3.2 System Administrators Guide: Overview.
a00802d2476.html.
Module Self-Check
Q1) What are the three different levels of access to the web-based interface in Cisco
CallManager Express? (Choose three.) (Source: Configuring Cisco CallManager
Express GUI Features)
A) custom administrator
B) system administrator
C) Phone user
D) root administrator
E) end user
F) customer administrator
Q2) Which answer best describes the steps required to configure the web-based GUI?
(Source: Configuring Cisco CallManager Express GUI Features)
A) Enable the administrative credentials by setting the enable password on the
B) Load the proper files into the web directory on the Microsoft IIS server, then
set credentials on the Cisco CallManager Express router.
C) Load the proper files in flash, enable the HTTP server to use flash, and
configure administrative credentials on the Cisco CallManager Express router.
D) Load the HTTP server on the Cisco CallManager Express router, then use the
enable password as credentials.
E) Enable the telephony service on the Cisco CallManager Express router with a
virtual directory to the Apache web server, then configure a valid username
and password on the web server.
Q3) Which of the following best describes access to the GUI web pages? (Source:
Configuring Cisco CallManager Express GUI Features)
A) The system administrator and customer administrator use the ccme.html page,
whereas the Phone users use the ccmeuser.html.
B) All levels of access use the same page URL.
C) The system administrator uses ccme.html, the customer administrator uses
ccmecustomer.html, and the Phone user uses the ccmeuser.html.
D) The GUI is only for the customer administrator and the Phone user.
Q4) Which command is used to load and parse an XML file to customize the customer
administrator web pages? (Source: Configuring Cisco CallManager Express GUI
Features)
A)
B)
C)
D)
web customize load filename

web load filename
customize web load filename
customize load filename
Q5) Which three of the following describes the xml.template file? (Choose three.) (Source:
Configuring Cisco CallManager Express GUI Features)
A) It is the template that can be used to construct a customized customer
administrator.
B) It can be used to customize the Phone user web page.
C) It is modified with a text editor.
D) It cannot be used without editing.
Q6) Which two of the following describe how a Phone user
s credentials can be
configured? (Choose two.) (Source: Configuring Cisco CallManager Express
GUI Features)
A) From the GUI, select the user drop-down menu and configure the username
password pair.
B) Select
Phone in the GUI menu and define a username and password.
C) From the CLI under the ephone, define the username and password.
D) From the CLI in the telephony-service mode, enter a username and password.
Q7) Which answer best describes the transfer commands? (Source: Configuring Phone
Features)
transfer system command overrides the transfer mode command, which
overrides the transfer pattern command.
B) The
transfer command is used only when the Phones do not support the
H.450.2 protocol.
C) The
transfer commands are for Phones that support the H.450.3 protocol.
D) The
transfer pattern command overrides the transfer mode and transfer
system commands.
A) The
Q8) Which answer best describes the blind option with the
(Source: Configuring Phone Features)
transfer mode command?
A) sets the systemwide parameter to use a blind transfer

B) sets the Phone to use a blind transfer
C) sets the dial pattern to use a blind transfer
D) sets the transfer pattern to use the blind transfer for anything matching
the pattern
Q9) Which of the following answers describes the function of the
command? (Source: Configuring Phone Features)
call-forward max-length
A) sets how many digits can be used for a call forward

B) sets the maximum number of minutes that a forwarded call can last
C) sets the maximum number of minutes that a voice mail message can be
D) configures the Phone to support the H.450.3 digit manipulation
Q10) Which answer best describes the system text message? (Source: Configuring
Phone Features)
A) a label that can be placed on the Phones that appears on the top section next
to the line appearance
B) a message that can be set to a rotating message that is implemented after
2 minutes of idle time
C) a message that can be placed on all Phones and appears toward the bottom of
the Phone screen
D) a message that scrolls across the bottom of the screen when the Phone is idle
Q11) Select three different ways to customize the display of the IP Phone. (Choose three.)
(Source: Configuring Phone Features)
A) IP Phone header bar
B) system text message
C) system idle URL
D) system display message
Q12) The ability to have a graphic displayed on the screen during idle period is configured
through which command? (Source: Configuring Phone Features)
A) Router(config-ephone-dn)#
descriptionhttp://10.1.1.1/logo/logo.htmltimeout 10
B) Router(config-ephone-dn)#
system message http://10.1.1.1/logo/logo.html
timeout 10
C) Router(config-telephony-service)#
system display
http://10.1.1.1/logo/logo.html timeout 10
D) Router(config-telephony-service)#
url idle http://10.1.1.1/logo/logo.html
timeout 10
Q13) Select the three statements that are correct regarding the Cisco CallManager Express
directory. (Choose three.) (Source: Configuring Phone Features)
A) can be accessed through the Phone user web page
B) can be accessed through the 7940G and 7960G IP Phones
C) can be customized to display either the first name first or the first name last
D) is stored in an LDAP directory, like Active Directory or DC Directory
E) can be configured with information regarding the physical location of the user
Q14) To configure an entry that does not directly map to an ephone, which command would
be used? (Source: Configuring Phone Features)
A) (config-telephony-service)#
B) (config-telephony-service)#
C) (config-telephony-service)#
D) (config-telephony-service)#
E) (config-telephony-service)#
nameJohn Smith
directory entry nameJohn Smith
directory nameJohn Smith
directory entry7 2065671234 name John Smith
nameSmith John
Q15) When is the Flash softkey button on a Cisco IP Phone used? (Source: Configuring
Phone Features)
A) for call waiting when another IP Phone in the Cisco CallManager Express
system calls
B) to take a screenshot of the Phone
s display and save it in flash of the
Cisco CallManager Express router
C) to enable hookflash functionality when communicating across FXO ports
to the CO
D) to enable hookflash functionality when communicating across FXS ports to
analog devices
E) to view the contents of flash on the Cisco CallManager Express router, which
will show the rings that are available
Q16) Which statement best describes the difference between an intercom and a paging
group? (Source: Configuring Phone Features)
A) The intercom opens a one-way audio conversation with the target muted to
start; by removing the mute, a two-way audio conversation is started, whereas
the paging group is always one-way audio to the speakerphone.
B) The intercom is simply a paging group with only one target.
C) A paging group is supported only through an analog overhead speaker system,
whereas the intercom is implemented on the IP Phone speaker.
D) The intercom always opens a two-way conversation, whereas the paging can be
either one-way or two-way, depending on configuration.
Q17) Paging can be transmitted to the target Phones through which two of the following?
(Choose two.) (Source: Configuring Phone Features)
A) unicast to the IP of the Phone
B) multicast to the 224.0.0.0
224.255.255.255 range
C) multicast to the 225.0.0.0
239.255.255.255 range
D) broadcast to the 255.255.255.255 address
E) special address of 256.0.0.0
F) multicast range of 224.0.0.0
239.255.255.255
Q18) Based on the following scenario, select the best solution: (Source: Configuring
Phone Features)
A customer has Cisco CallManager Express. There are two departments within the
company: sales and customer support. The company wishes to have the ability to page
a salesperson or customer support representative independent of each other. However,
the company also wishes to have the ability to page both sales and customer support
buildingwide for emergency purposes.
A) Configure three paging groups: sales, support, and emergency. On the sales
ephones, use the paging-dn command twice: once for the sales paging group
and once for the emergency paging group. On the support Phone, set two
paging groups: one for the support paging group and one for the emergency
paging group.
B) Configure three paging groups: sales, support, and emergency. On the sales
ephones, use the paging command twice: once for the sales paging group and
once for the emergency paging group. On the support Phone, set two paging
groups: one for the support paging group and one for the emergency paging
group.
C) Configure three paging groups: sales, support, and emergency. For the
emergency ephone-dn, use the paging-group command to have both the sales
and support paging groups under it. On the sales ephones, use the paging-dn
command once for the sales paging group. On the support Phone, set the
support paging group.
D) Configure three paging groups: sales, support, and emergency. For the
emergency ephone-dn, use the page-group command to have both the sales
and support paging groups under it. On the sales ephones, use the paging
command once for the sales paging group. On the support Phone, set the
support paging group.
Q19) Which steps are required to customize the rings on Cisco CallManager Express
controlled IP Phones beyond the two default rings? (Source: Configuring Phone
Features)
A) Create one or more .raw PCM ring files, load the ring file to flash on the
Cisco CallManager Express router, reboot the Phones, and select the new ring
on the Phone.
B) Create one or more .raw PCM ring files, construct a RingList.xml file, upload
both the rings and the RingList.xml to flash on the Cisco CallManager Express
router, configure the TFTP server to serve up the files, reboot the IP Phones,
and select the ring on the Phone.
C) Create one or more .mp3 ring files, load the ring file to flash on the
Cisco CallManager Express router, reboot the Phones, and select the new ring
on the Phone.
D) Create one or more .raw PCM ring files, construct a RingList.xml file, upload
both the rings and the RingList.xml to flash on the Cisco CallManager Express
router, configure the FTP server to serve up the files, reboot the IP Phones, and
select the ring on the Phone.
E) Create an .mp3 less than 2 seconds long, upload the ring to flash, and reload
the router and the Phone.
Q20) Which three statements are correct regarding MOH? (Choose three.) (Source:
Configuring Phone Features)
A) MOH can come from up to five different files stored in flash.
B) MOH files can be in .au, .wav, or .mp3 format.
C) MOH can be unicast or multicast.
D) MOH can come from a live audio source via an E&M interface.
E) MOH can come from a live audio source via an FXO interface.
Q21) Which is the valid command to enable MOH from a file in flash? (Source: Configuring
Phone Features)
A) (config)#
mohMozart.wav
mohMozart.wav
C) (config)#
moh ip multicast224.0.0.1 Mozart.wav
D) (config-telephony-service)#
moh ip multicast225.0.0.1 Mozart.wav
E) (config)#
multicast225.0.0.1mohMozart.wav
F) (config-telephony-service)#
multicast224.0.0.1mohMozart.wav
Q22) Which definition best describes the Cisco IOS TSP? (Source: Defining TAPI Support
for Cisco CallManager Express)
A) a limited implementation of TAPI
B) a full implementation of TAPI
C) the same TAPI that is used in Call Centers that provides for multiple line
appearances
D) installed on the Cisco CallManager Express router and runs in RAM of
the router
Q23) Which three items of information are needed during the installation of the Cisco IOS
TSP? (Choose three.) (Source: Defining TAPI Support for Cisco CallManager Express)
A) the IP address of the Cisco CallManager Express router
B) the port number of the Cisco CallManager Express service on the router
C) the enable password of the Cisco CallManager Express router so that
configuration changes can be applied
D) username and password that match the Phone user
s credentials
Q24) After the initial installation, how is access to the configuration of the Cisco IOS TSP
achieved? (Source: Defining TAPI Support for Cisco CallManager Express)
A) through the Control Panel of Windows
B) through the Control Panel of Windows, then in the Phones and Modem Options
section
C) by going to c:\program files\cisco\setup.exe
D) from the CLI of the Cisco CallManager Express router, which will use Java to
push the changes to the PC
Q25) Which steps are necessary for uninstalling the TSP? (Source: Defining TAPI Support
for Cisco CallManager Express)
A) Run the uninstall.exe in the path where installed, then delete the .dll files in the
system32 file.
B) Remove the TSP from the Phone and Modem Options section of the Control
Panel, then uninstall it using Add or Remove Programs in the Control Panel.
C) Delete the Cisco folder under the program files directory.
D) From the softphone, select
Add or Remove Components, which starts the
installation screen, then select Remove when prompted and reboot the PC.
Q26) Which of the following statements best describe the setup utility in Cisco CallManager
Express? (Source: Describing Network Management for Cisco CallManager Express)
A) inserts Phones automatically in the Cisco CallManager Express router without
having to define the phone numbers
B) allows the Cisco CallManager Express to auto-discover the devices that are
available and to configure them with Cisco best practices
C) a macro of questions, invoked and answered from the system administrator
web pages, that is used to do the initial configuration of a Cisco CallManager
Express router
D) a macro of questions, invoked and answered from the command line
environment, that is used to do the initial configuration of a Cisco CallManager
Express router
Q27) Logging messages specific for IP Phones in Cisco CallManager Express are what type?
(Source: Describing Network Management for Cisco CallManager Express)
A) 4
B) 5
C) 6
D) 7
Q28) Which three types of information specific to a Cisco CallManager Express installation
can the MIBs contain? (Choose three.) (Source: Describing Network Management for
Cisco CallManager Express)
A) CDRs
B) call leg information
C) billing information
D) user credentials
Q29) Which MIB stores the billing information that is entered by the Acct softkey button?
(Source: Describing Network Management for Cisco CallManager Express)
A) Cisco-DIAL-CONTROL-MIB
B) Cisco-VOICE-CONTROL-MIB
C) Cisco-VOICE-IF-MIB
D) not stored in any MIB stored on a RADIUS server
Q30) Which best describes an ephone hunt group? (Source: Understanding Call Center
Features)
A) a group of ephones on which the top line will ring on all members when a call
arrives at the pilot number
B) a group of ephone-dns that will all ring when a call arrives
C) a group of ephones that will ring in a specified order until the call is answered
D) a group of ephone-dns associated with a pilot number
Q31) Which command globally limits the number of times that a call can be redirected from
one ephone-dn to another to 12? (Source: Understanding Call Center Features)
A) (config-telephony-service)#
max-redirect 12
hops 12
C) (config-ephone-hunt)#
max-redirect 12
D) (config-ephone-hunt)#
hops 12
E) (config)#
redirect-limit 12
F) (config-telephony-service)#
redirect-limit 12
Q32) What are the three ways that an ephone hunt group can select which member to send an
incoming call to? (Choose three.) (Source: Understanding Call Center Features)
A) round robin
B) peer
C) incremental
D) sequential
E) longest idle
F) longest wait
Q33) Pressing the DND softkey button results in which of the following? (Source:
Understanding Call Center Features)
A) The ephone is placed in standby mode and no calls can be received.
B) The ephone-dn is placed into the busyout state for outside calls but is available
to inside callers.
C) The ephone-dn is removed from any hunt group memberships.
D) The ephone is removed from any hunt group memberships.
Q34) Which of the following is provided by the B-ACD service? (Understanding Call Center
Features)
A) The Cisco Unity Express provides automated attendant functions and can have
a custom script made to provide the call queuing.
B) Two TCL scripts provide the automated attendant and call queuing functions
that make up the B-ACD service.
C) The B-ACD TCL script and the automated attendant function of Cisco Unity
Express work together to provide the B-ACD service.
D) The B-ACD service is provided by an IPCC Express Windows-based server.
Q35) Which best describes the format for customized audio prompts? (Source:
Understanding Call Center Features)
A) G.711, 32-bit, mu-law, 8 kHz, and wave file format
B) G.711, 16-bit, mu-law, 8 kHz, and wave file format
C) G.711, 16-bit, mu-law, 8 kHz, and .au file format
D) G.711, 8-bit, mu-law, 8 kHz, and wave file format
E) G.711, 8-bit, mu-law, 8 kHz, and .au file format
Q36) Which three of the following are required to write statistics to a file? (Choose three.)
(Understanding Call Center Features)
A) Nothing is required; the statistics will be written to flash automatically.
B) Statistics must be enabled on the ephone hunt group.
C) Statistics must be enabled in the telephony service.
D) The URL of an FTP server must have read/write permissions set.
E) The URL of a TFTP server must have read/write permissions set.
F) A windows share must have read/write permissions set.
G) A prefix and a suffix must be defined.

Q1) B, C, F
Q2) C
Q3) B
Q4) A
Q5) A, C, D
Q6) B, C
Q7) D
Q8) B
Q9) A
Q10) C
Q11) A, B, D
Q12) D
Q13) A, B, C
Q14) D
Q15) C
Q16) A
Q17) A, C
Q18) C
Q19) B
Q20) C, D, E
Q21) B
Q22) A
Q23) A, B, D
Q24) B
Q25) B
Q26) D
Q27) C
Q28) A, B, C
Q29) A
Q30) D
Q31) A
Q32) B, D, E
Q33) C
Q34) B
Q35) E
Q36) B, E, G
Module 5
Configuring Cisco Unity

Express Automated Attendant
and Voice Mail
Overview
Cisco Unity Express (CUE) is an essential component of both the Cisco CallManager and
Cisco CallManager Express solutions. In a Cisco CallManager environment, CUE provides
local storage and processing of voice mail and automated attendant services for the branch
office, thereby alleviating WAN bandwidth and quality of service (QoS) concerns.
The combination of Cisco CallManager Express and CUE provides a solution that enables
small and medium businesses and branch offices to deliver voice, data, and telephony services
integrated on a single, router-based platform. CUE users can easily and conveniently manage
their voice messages and greetings with intuitive telephone prompts and a straightforward GUI
that allows for ease in administration.
In this module, you will learn how to install CUE, integrate the CUE module with Cisco
CallManager Express, and upgrade the software and licenses. You will be introduced to
automated attendant and voice mail features, and you will learn how to configure and
customize the automated attendant script. Customization of automated attendant scripts is
accomplished via the CUE editor.
The web-based GUI of CUE is tightly integrated with the Cisco CallManager Express web
interface and can be used to configure users, mailboxes, groups, and prompts within the CUE
system. Each of these tasks can also be accomplished from the command-line interface (CLI),
which is very useful for scripting purposes. The CLI is required for some tasks, such as
upgrading and reinstalling the CUE system.
Module Objectives
Upon completing this module, you will be able to install and upgrade CUE; configure CUE
Auto Attendant, users, groups, and voice mail; and troubleshoot.
Describe the key features and functionality of CUE
Describe the requirements and tasks for installing and upgrading CUE
Describe the components and tasks for configuring CUE Auto Attendant
Configure users and groups
Describe the components and tasks for configuring voice mail
Describe the CUE troubleshooting guideline and tools
Lesson 1
Understanding Cisco Unity

Express Features and
Functionality
Overview
This lesson describes the features and functions of Cisco Unity Express (CUE).
Objectives
Upon completing this lesson, you will be able to describe the key features and functionality of
CUE. This includes being able to meet these objectives:
Describe voice mail features
Describe CUE Auto Attendant features
Describe management features
Describe system functionality features
Voice Mail Features
This topic describes the features of CUE voice mail.
Voice Mail Features

Up to 100 hours of voice mail storage on the
NM-CUE and 14 hours on the AIM-CUE
Voice mail storage configurable per mailbox
End user tutorial enables self-service mailbox
setup
End-user mailboxes and General Delivery
Mailboxes
Standard and alternate greetings
Subscriber features
Caller features
VPIM networking
IPTX v2.05-3
CUE voice mail is a feature-rich voice mail system designed for the small- to medium-sized
enterprise. CUE provides flexibility and the choice between two form factors. You can choose
the capacity, performance, and price point that meet the specific site requirements. In addition
to the form factor, the storage capacity of both the CUE network module (NM-CUE) and the
CUE advanced integration module (AIM-CUE), 100 hours and 14 hours, respectively, may be
customized on a per-user basis as defined by the system administrator. Alternatively, the
storage capacity can be left at the factory default settings.
One of the useful features in CUE is a complete, yet concise Telephony User Interface (TUI)
tutorial that takes the user through a step-by-step setup of the mailbox. This minimizes the need
for administrator intervention or assistance, saving both time and money. This tutorial runs for
both personal mailboxes and General Delivery Mailboxes (GDMs).
GDMs allow voice mail storage that any designated team member can retrieve. This enables
quicker responses to caller messages, resulting in greater customer satisfaction.
Users can choose from standard and alternate greetings to communicate special messages,
such as telling callers about an extended absence or vacation. Users can also record their
own greetings.
Of course, commonly used voice mail featuressuch as replying to, forwarding, and
saving messages; message tagging for privacy or urgency; alternate greetings; pausing,
fast forwarding, and rewinding; and envelope informationare provided for optimal
management of messages. This set of typical features allows new CUE users to get started
quickly and with little training.
Within the mailbox, there are features for the caller as well. One of them is the ability to zero
out of the mailbox (press 0) to go to the operator. (The destination for zeroing out of a user s
mailbox can be modified and set on a mailbox-by-mailbox basis.) In addition, the caller can
review the message just recorded and rerecord it. The caller can also mark the message as
urgent or private.
In addition, the system has features that are common in voice mail systems in general, such as
Message Waiting Indicator (MWI) functionality and a mailbox full notification that informs
the user that the mailbox has reached its defined capacity.
When multiple CUE systems are present, they may exchange messages through a standardsbased protocol called Voice Profile for Internet Messaging (VPIM). This allows a message to
be recorded on one system and tranferred to another CUE system.
Copyright 2005, Cisco Systems, Inc. Configuring Cisco Unity Express Automated Attendant and Voice Mail 5-5
This topic describes the features of CUE Auto Attendant.

Default CUE Auto Attendant
Fully customizable script-driven menu structure for custom
Auto Attendant
CUEAA Editor
Greeting management system
Emergency alternate greeting
Return to operator
Dial by name and dial by extension
Time of day call treatment
Day of week call treatment
Holiday schedule
Business hours
IPTX v2.05-4
The CUE Auto Attendant is a built-in feature that simplifies self-service for callers by allowing
them to quickly reach the right person without the assistance of an operator 24 hours per day,
seven days per week. The default CUE Auto Attendant gives callers the choice of either dialing
by name or dialing by extension and the option to return to an operator whenever greater
assistance is needed. The CUE Auto Attendant also provides time of day and day of week call
treatment so that the right message is always communicated and available to the caller. This
default Auto Attendant can be replaced by a customized version that can be constructed in a
GUI tool called the CUE Auto Attendant Editor. (CUE AA Editor)
The CUE AA Editor is a Windows GUI-based visual scripting tool that gives administrators a
simple way to create multiple customized Auto Attendant flows. The CUE AA Editor allows
for dragging and dropping of prebuilt steps into a treelike structure. This makes the operation of
building a custom Auto Attendant straightforward and intuitive. The scripts can then be
installed and applied to the CUE system. Multiple Auto Attendant scripts can be active and
running at the same time in CUE.
The greeting management system (GMS) is a custom phone-based interface that allows the
recording of new greetings for use in Auto Attendant. These are added through the CUE GMS
either via the TUI or an offline .wav file recording tool.
The system administrator can record an alternate Auto Attendant greeting for use in case of an
emergency or other unexpected short-term event, such as a snow day. The alternate Auto
Attendant greeting works much like the alternate voice mail greeting. It prompts the system
administrator to either activate or deactivate the greeting based on its current status.
Management Features
This topic describes management features.
Management Through the TUI

TUI for Administrator
Audio-based interface using the phone

Prompt management and recording
Alternate emergency greeting activation
TUI for End Users
Audio-based interface using the phone

Manager phone setting for associated device
Recording of personal greeting
Recording of spoken name
IPTX v2.05-5
Both the system administrator and the end user can use the TUI to perform CUE management.
The system administrator can use the TUI by dialing the pilot number of the GMS. This allows
the administrator to record, review, and delete prompts that may be used in the Auto Attendant.
The system administrator can also use the TUI to record an emergency alternate greeting, then
activate it or deactivate it as desired.
End users reach the TUI by accessing their voice mail. Through a tutorial, end users can use the
TUI to set up their mailbox, to record a personalized greeting, and to record the spoken name
that callers hear. End users can also record an alternate greeting, which can then be activated or
deactivated through the TUI.
Many of these tasks can also be performed from a web browser in a GUI or from the commandline interface (CLI) of the CUE module.
Management Through the GUI and the CLI

GUI for system administrators
User profiles: name, extension, setting and resetting passwords
General Delivery Mailboxes
Mailboxes: maximum recording time, maximum length per message,
resetting MWI
System statistics on storage use and setting system defaults
(disk space, maximum message size)
Manual backup and restore
GUI for end users
Users able to manage associated device and some settings related
to that device
Remote management
HTTP for GUI
Console connection for CLI via IOSsession command across the backplane
Privilege level: depends on credentials that are entered
Users see subset of what administrators see
IOS softwarelike CLI for administering, debugging, and troubleshooting
IPTX v2.05-6
The CUE system can be managed through either a web-based GUI that is integrated with Cisco
CallManager Express or through the CLI on the CUE module. The GUI is feature-rich and
allows an administrator to manage the following:
Logging in and out: Administrators must provide credentials to enter the GUI or the CLI.
Resetting passwords and PINs: Passwords and PINs can be reset from the CLI or the GUI.
Configuring Auto Attendant: Installation and configuration changes can be done through
the GUI or the CLI.
Configuring voice mail: Voice mail configuration can be set through the GUI or the CLI.
Configuring users and groups: Users and groups can be set up and administered through
the GUI or the CLI.
Backing up and restoring: Backing up and restoring the configuration can be done
through the GUI or the CLI.
Saving configuration: Saving the configuration can be done through the GUI or the CLI
Reloading the system: Reloading the system can be done through the GUI or the CLI.
There is an IOS softwarelike CLI that gives the administrator full administrative abilities to
set up, deploy, manage, and troubleshoot the CUE system. Troubleshooting the CUE system is
done only through the CLI. Full troubleshooting tools are present in the GUI and must be used
in the CLI.
Remote management of the CUE module can be accomplished through the CLI or the GUI.
Access the CLI by first using Telnet to connect to the host router for the CUE module, then
start a session across the backplane of the router to the CUE module. To use the GUI remotely,
open IE 6.0 (or greater) and go to the URL for the CUE module.
Example: GUI Screen
IPTX v2.05-7
The figure illustrates the web-based GUI management features.
Network Administration
Site C
Site A
Site B
IP
Systems can be accessed from anywhere on the IP network.

Remote management can be performed through GUI via HTTP
or through the CLI via Telnet to the router, then using the
session command.
Each system is administered individually.
Systems can be bulk provisioned via CLI scripting.
IPTX v2.05-8
An administrator can be sitting anywhere on the network and access the CUE system through
either the CLI or the GUI.
System Functionality
This topic describes system functionality features.
Functions Available Through CLI Only

Some system administration functions are
available only through the CLI:
Installing and upgrading software and licensing
Monitoring CPU and memory use
Troubleshooting
Syslog files
Trace files
IPTX v2.05-9
Some tasks can only be done through the CLI. These include the following:
Installing and upgrading software and licensing
Monitoring CPU and memory usage
Troubleshooting syslog files and trace files
Language Support
GUI and CLI are in English only.
The Cisco CallManager Express language
setting controls the Phone display.
The CUE language setting affects Auto
Attendant and TUI prompts.
CUE release 2.1 supports English, French,
German, and Italian.
Additional language support for CUE is planned.
CUE language
setting controls
TUI and Auto
Attendant only.
Cisco CallManager
Express language
setting controls
Phone display only.
IPTX v2.05-10
The Cisco CallManager Express language setting controls the Phone display, whereas the CUE
language setting controls the Auto Attendant and TUI prompts. CUE currently supports English
only. This will change in an upcoming release when CUE will support the same languages as
Network Management Features

Assistance in bulk configuration
Users imported from Cisco CallManager Express
CLI for scripting of bulk provisioning
SNMP agent provided
Hardware inventory and identification only
MIBs
No application-specific MIBs supported at
this time
IPTX v2.05-11
The CUE module has a CLI environment that may be used to perform all configuration tasks.
This allows for bulk provisioning task to be performed. In addition, when the CUE module is
integrated with Cisco CallManager Express, all users may be imported from the GUI.
SNMP is supported, but only very basic MIBS are currently present that may be used for
hardware inventory and identification only. There are currently no application-specific MIBs.
Summary
Summary
The CUE system is a feature-rich application
that provides all the expected features of a
voice mail system.
The built-in Auto Attendant can be customized
using the CUEAA Editor.
The CUE system can be managed through a webbased GUI or the CLI.
CUE includes many functions for configuring,
monitoring, and administering the system.
IPTX v2.05-12
Lesson 2
Describing Cisco Unity

Express Installation and
Initialization
Overview
This lesson defines the files that are needed in order to install and upgrade Cisco Unity Express
(CUE), the required hardware, the installation process, and the Cisco CallManager Express
router configuration that is required prior to installation. The lesson then explains how to
initialize the CUE module and how to perform an initial configuration. And finally, information
on running the CUE initialization wizard is presented.
Objectives
Upon completing this lesson, you will be able to describe the requirements and perform the
tasks for CUE installation and initialization. This includes being able to meet these objectives:
Describe CUE software files
Describe hardware requirements
Perform the prerequisite configuration of the Cisco IOS router and Cisco CallManager
Express
Describe how to connect to the CUE module
Describe how to restore the factory defaults to a CUE module
Describe the show commands that are useful for viewing the status of the CUE module
Perform the initial configuration steps
Configure the CUE initialization wizard
Describe different ways to restart
Describe the steps for upgrading the version of CUE and the licensed capacity
Cisco Unity Express Software Download

This topic describes the CUE software download.
Cisco Unity Express Software Download

Cisco
Connection
Online Server
Customer FTP/TFTP Server

Large Software
Files
Internet
Small License Files
Enterprise
IP
Branch
Offices
Newly ordered hardware preinstalled with software

Software has to be downloaded only for version upgrade
Software available from Cisco.com or CD
Licensing embedded in the software SKUs
License files downloaded from Cisco.com once, then
distributed and installed via FTP onto each system
License files are generic, not specific to each system
Software is generic; licenses provide operational parameters
IPTX v2.05-3
CUE comes preinstalled from the factory on the CUE network module (NM-CUE), the NMCUE enhanced capacity (NM-CUE-EC), and the CUE advanced integration module (AIMCUE). However, a method does exist for reinstalling the software. This same method is also
used for upgrading the version of CUE software and upgrading licensed capacity. This is
accomplished by obtaining the appropriate files, either CUE software or licensing, from Cisco
Connection Online or a CD set and putting the files on an FTP or TFTP server that is accessible
to the CUE module. After the files are on the FTP or TFTP server, you can begin the
reinstallation or upgrade process.
CUE Software Download:

Files Needed
Files needed on FTP server for installation:
System software
cue-vm.2.1.1.pkg
cue-vm.2.1.1.prt1
Installation utilities
cue-installer.2.1.1
Cisco CallManagerExpress licenses (only which one is used)

cue-vm-12-license.2.1.1.cme.pkg
Language files
cue-vm-lang-pack.2.1.1. pkg
cue-vm-de_DE-lang-pack.2.1.1.prt1
cue-vm-en_US-lang-pack.2.1.1.prt1
cue-vm-es_ES-lang-pack.2.1.1.prt1
cue-vm-fr_FR-lang-pack.2.1.1.prt1
cue-vm-ga-IE-lang-pack.2.1.1.prt1
IPTX v2.05-4
The file cue-installer.2.1.1 and a license file must be present on the TFTP server in order to run
the installation. All of the other files must be served up by the FTP server. Although the TFTP
server and the FTP server do not have to be the same computer, for administrative reasons it is
recommended that they are. The license files can be obtained from Cisco Connection Online.
Note
The license file that is installed must be for either a Cisco CallManager Express integration
or a Cisco CallManager integration. A hybrid approach is not supported. A license file for a
Cisco CallManager integration would have a name similar to cue-vm-50license.1.1.1.ccm.pkg.
Hardware Installation
This topic describes the CUE hardware installation.
Hardware Installation Requirements

Installing the CUE module:
Upgrade router
NM-CUE-EC: Cisco IOS Release 12.3(14)T1 or later
NM-CUE: Cisco IOS Release 12.3(4)T or later
AIM-CUE: Cisco IOS Release 12.3(7)T or later
Power down router
Insert NM-CUE, NM-CUE-EC, or AIM-CUE into appropriate
slot
Power up router
Use show version command on router to verify that module is
recognized
IPTX v2.05-5
In an integration of Cisco CallManager Express with CUE, the CUE module is usually installed
in the same chassis as the Cisco CallManager Express router, although this is not required. The
minimum version of IOS software needed to support the module depends on which type of
module is used. For the NM-CUE-EC, IOS Release 12.3(14)T1 or later is the minimum version
software that is required. For the NM-CUE, the minimum version of software that is required is
IOS Release 12.3(4)T or later. For the AIM-CUE, the minimum version of software that is
required is IOS Release 12.3(7)T or later. If the show version command does not display 1
cisco service engine, verify the version of software that is installed.
NM-CUE-EC Hardware Overview

Only one NM-CUE-EC per router
chassis
Any slot: 2600XM,
2691, 2800 Series, 3700 Series,
3800 Series
Hard drive cannot be replaced
in the field
Up to 16 sessions
12, 25, 50, or 100 mailboxes
OIR supported on the 3745
and 3845
Requires a manual shutdown
of CUE module
IPTX v2.05-6
The NM-CUE-EC can be installed in a Cisco 2600XM, 2691, 2800 Series, 3700 Series, and
3800 Series router. This module uses a hard drive to store the configuration and as a repository
for voice mails. This hard drive cannot be replaced in the field; if it were to fail, the entire
module would have to be sent to Cisco Systems.
Hot swapping is supported on the Cisco 3745 and 3845 routers, although the module must still
be shut down prior to removal. This online insertion and removal (OIR) of the NM-CUE-EC is
a function of the 3745 and 3845 routers, not of the module. Hot swapping is not supported in
the Cisco 2600XM, 2691, 3725, or 3825 routers.
The NM-CUE-EC can scale up to 100 mailboxes and 16 sessions at any one time. The number
of mailboxes supported by this module will increase in future versions.
Note
Proper shutdown of the CUE module before a planned power shutdown is advised to
prevent file corruption issues.
NM-CUE-EC Front Panel

NM-CUE-EC
The front panel Ethernet port and compact flash

(covered) connectors are disabled; they are not
used on the NM-CUE-EC.
When the EN LED is green, the NM-CUE-EC is
recognized and supported by the IOS software. When
the EN LED is off, an older version of IOS software is
loaded, and it does not recognize or support the NMCUE-EC.
When the PWR LED is green, the NM-CUE-EC
is receiving power from the PCI bus.
IPTX v2.05-7
The NM-CUE-EC has two LEDs on the front panel: PWR and EN. If the PWR LED is green,
then the module is seated correctly and receiving power from the protocol control information
(PCI) bus. If the EN LED is green, the module is recognized by the IOS software. An EN LED
that is not green could mean that a version of IOS software is being used that does not support
the CUE module.
Note
A version of IOS software with the IP voice feature set is required.
In addition to the two LEDs, there is a FastEthernet port. This port is disabled and not used.
The flash slot is also nonfunctional and cannot be used.
NM-CUE-EC Hardware Parameters

NM-CUE-EC Module Implementation
Intel x86style platform installed with Linux

Cisco cookie to identify platform as NM-CUE-EC via SNMP
CPU: Low-power 500-MHz Intel Pentium III
SDRAM: 512 MB
Mass storage: 20-GB IDE hard drive
Strataflash: 16 MB
BIOS: 512 KB
CUE hardware access only via PCI bus from IOS router to NM-CUE-EC
Back-to-back Ethernet
Back-to-back console
No external interfaces on the CUE hardware
Flash and Ethernet connectors on the front panel disabled and not
usable
No cabling
Session across the backplane of the host IOS router for management
IPTX v2.05-8
The NM-CUE-EC is actually an Intel-based server that runs Linux. The Linux operating system
is neither accessible nor configurable. The NM-CUE-EC runs a 500-MHz Pentium III CPU
with 512 MB of synchronous dynamic RAM (SDRAM). This allows the CPU of the host router
to be unaffected by activities that occur in the CUE system. The hard drive is preinstalled with
an operating system and the CUE application. The module currently uses a 20-GB Integrated
Drive Electronics (IDE) hard drive, although this may change in the future. This hard drive is
where the configuration and voice mailboxes reside.
The NM-CUE-EC is hardened and secure, with no shell access, no back doors, and an operating
system that is totally locked down. All access to the command-line interface (CLI) of the CUE
module is through a back-to-back console connection across the backplane of the IOS router.
The service-module service-engine mod/port command is used to connect to the CUE module.
Because the FastEthernet interface on the front of the NM-CUE-EC is disabled, communication
with Cisco CallManager Express and subscribers is through a virtual Ethernet port on the
backplane of the router on which the module is installed. This back-to-back Ethernet port is
accessed through the use of Router Blade Configuration Protocol (RBCP). This port needs to be
on the same subnet as the service engine in the Cisco CallManager Express router. Console
access is also accessed across the backplane of the router.
NM-CUE Hardware Overview

Only one NM-CUE per router
chassis
Any slot: 2600XM,
2691, 2800 Series, 3700 Series,
3800 Series
Hard drive cannot be replaced
in the field
Up to eight sessions
12, 25, 50, or 100 mailboxes
OIR supported on the 3745
and 3845
Requires a manual
application shutdown
IPTX v2.05-9
The NM-CUE can be installed in a Cisco 2600XM, 2691, 2800 Series, 3700 Series, and 3800
Series router. This module uses a hard drive for storage of the configuration and as a repository
for voice mails. This hard drive is not able to be replaced in the field; if it were to fail, the entire
module would have to be sent to Cisco.
Hot swapping is supported on the Cisco 3745 and 3845 routers, although the module must still
be shut down prior to removal. This OIR of the NM-CUE is a function of the 3745 and 3845,
not of the module. Hot swapping is not supported in the Cisco 2600XM, 2691, or 3725 routers.
This module can scale up to 100 mailboxes and eight sessions at any one time.
Note
Proper shutdown of the CUE module before a planned power shutdown is advised to
prevent file corruption issues.
NM-CUE Front Panel
The front panel Ethernet port and compact flash

(covered) connectors are disabled; they are not
used on the NM-CUE.
When the EN LED is green, the NM-CUE is recognized and
supported by the IOS software. When the EN LED is off an
older version of IOS software is loaded, and it does not
recognize or support the NM-CUE.
When the PWR LED is green, the NM-CUE
is receiving power from the PCI bus.
IPTX v2.05-10
The NM-CUE has two LEDs on the front panel: PWR and EN. If the PWR LED is green, then
the module is seated correctly and receiving power. If the EN LED is green, the module is
recognized by the IOS software. An EN LED that is not green could mean that a version of IOS
software is being used that does not support the CUE module.
Note
A version of IOS software with the IP Voice feature set is required.
In addition to the two LEDs, there is a FastEthernet port. This port is disabled and not used.
The flash slot is also nonfunctional and cannot be used.
NM-CUE-EC Hardware Parameters

NM-CUE-EC Module Implementation

Cisco cookie to identify platform as NM-CUE-EC via SNMP
CPU: Low-power 500-MHz Intel Pentium III
SDRAM: 512 MB
Mass storage: 20-GB IDE hard drive
Strataflash: 16 MB
BIOS: 512 KB
CUE hardware access only via PCI bus from IOS router to NM-CUE-EC
No external interfaces on the CUE hardware
Flash and Ethernet connectors on the front panel disabled and not
usable
No cabling
Session across the backplane of the host IOS router for management
IPTX v2.05-8
The NM-CUE is an Intel-based server that runs Linux. The Linux operating system is neither
accessible nor configurable. The NM-CUE runs a 500-MHz Pentium III CPU with 512 MB of
SDRAM. This allows the CPU of the host router to be unaffected by activities that occur in the
CUE system. The hard drive is preinstalled with an operating system and the CUE application.
The module currently uses a 20-GB IDE hard drive, although this may change at some point.
This hard drive is where the configuration and voice mailboxes reside.
The NM-CUE is hardened and secure, with no shell access, no back doors, and an operating
system that is totally locked down. All access to the CLI of the CUE module is through a backto-back console connection across the backplane of the IOS router. The service-module
service-engine mod/port command is used to connect to the NM-CUE.
Because the FastEthernet interface on the front of the NM-CUE is disabled, communication
with Cisco CallManager Express and subscribers is through a virtual Ethernet port on the
backplane of the router in which the module is installed. This back-to-back Ethernet port is
accomplished using RBCP. This port needs to be on the same subnet as the service engine in
the Cisco CallManager Express router. Console access is also accomplished across the
backplane of the router.
AIM-CUE Overview
Makes 2600XM a viable platform for Cisco IDS Voice Gateways,
Cisco CallManagerExpress, and CUE
Communicates with router across backplane
Requires IOS Release 12.3 (7)T to recognize hardware
Four or six sessions, depending on the host hardware
12, 25, or 50 mailboxes
1-GB flash card is an FRU
Cannot put AIM-CUE in
3745 router slot 0must use
slot 1 instead
IPTX v2.05-12
The AIM-CUE requires a minimum of CUE version 1.1 and IOS Release 12.3(7)T or later.
This AIM-CUE is an internal card that can be installed in the chassis of a supported router.
Like the NM-CUE, all communication with Cisco CallManager Express and subscribers is
accomplished across the backplane through the virtual Ethernet interface. The AIM-CUE
differs from the NM-CUE in that it does not have a hard drive. Instead, the AIM-CUE uses an
industrial-quality 1-GB flash card for storing the configuration and voice mailboxes. Flash
memory is limited in the number of times that writes can be made to a piece of memory; as a
result, the card has a limited lifetime and may have to be replaced after three to five years of
average use. There is a page in the web-based GUI to track the usage of the flash card. The card
is field replaceable unit (FRU).
The AIM-CUE is intended for smaller installations than those for which the NM-CUE is
intended. It scales up to 50 ports and either four or six sessions, depending on the chassis in
which the module is installed. This makes the 2600XM platform a viable platform for running
Cisco CallManager Express and Cisco Unity Express. The number of sessions is limited by the
speed of the CPU, and in installations with 50 mailboxes, the amount of storage and the fourport maximum can be limiting.
Caution
In the Cisco 3745 router, install the AIM-CUE in slot 1 only. Installation in slot 0 can result in
damage to the module.
AIM-CUE Parameters
AIM-CUE Implementation

Cisco cookie to identify platform as AIM-CUE via SNMP
CPU: Low-power 300-MHz Intel Celeron
Runs at 150 MHz on the 2600XM Series and the 2691
Runs at 300 MHz on the 3700, 2800, and 3800 Series
routers
SDRAM: 256 MB
Mass storage: 1 GB compact flash
Bootflash: 2 MB
BIOS: 512 KB
CUE hardware access only via PCI bus from IOS router to
AIM-CUE
IPTX v2.05-13
The AIM-CUE runs a Linux-based operating system based on the Intel Celeron 300-MHz CPU.
When the AIM-CUE is installed in a Cisco 2800 Series, 3700 Series, or 3800 Series router, the
maximum number of ports is six.
When the AIM-CUE is installed in the Cisco 2600XM Series or 2691 router, the CPU runs at
half the speed because of power limitations on the AIM-CUE port. This results in the number
of supported ports being limited to four. Another consequence is significantly longer bootup
times for the AIM-CUE.
The AIM-CUE has 256 MB of SDRAM and 1 GB of flash to store the operating system,
configuration, and voice mails. The 1-GB model allows for 14 hours of storage.
Connecting to the AIM-CUE is accomplished from the CLI of the host IOS router by using the
command service-module service-engine mod/port from privileged EXEC mode.
Hardware Installation show version Command

-
- -
-

-
- --

- -
- - -
-
-
-
-
- -
-
- -
- -- - -
--

-
- -
-
- -
-
- - -
IPTX v2.05-14
The installation of the CUE module can be checked on the router by using the show version
command. In the output, cisco service engine should be present. If it is not present, ensure
that the CUE module is installed, that it is seated properly, and that the IOS release supports the
module.
IOS Router and Cisco CallManager Express

Prerequisite Configuration
This topic describes the prerequisite configuration necessary on the Cisco CallManager Express
router and the router that hosts the CUE module.

Prerequisite Configuration
IOS Router
Routing and IP addressing setup

IP addressing for CUE hardware module
Static route to the address of the CUE module
GUI files installed in router flash

SIP dial peers for directing calls into CUE
MWI on and off ephone-dns
IPTX v2.05-15
The router that is hosting the CUE module requires some configuration prior to installation of
the module. This includes performing some basic tasks in the IOS software as well as some
Cisco CallManager Express tasks. The Cisco CallManager Express router and the CUE host
router may be separate devices or the same device.
The tasks to perform in the IOS software of the CUE host router include:
Setting up routing and IP addressing on the service module and the interface service engine
The Cisco CallManager Express router configuration tasks include:
Installing the files needed to run the web-based GUI (the same files that are used for the
Cisco CallManager Express GUI)
Configuring a session initiation protocol (SIP) dial peer for connecting calls to the voice
mail and automated attendant features of CUE
Setting up the router if it is the Network Time Protocol (NTP) server

Prerequisite Configuration (Cont.)
After the hardware installation, the CUE module shows up as an
interface Service-Enginex/y
Configure the IP addressing for the CUE hardware:
Configure service engine interface with a static IP address or IP
unnumbered (recommended)
Configure the service-module IP address to be on same subnet as router
Configure CUE IP default gateway to be the service engine address
Session to the CUE module to start software installation (if needed) or
configuration (if newly shipped from the factory)
--

--
Same Subnet

-
- --
-
-
IPTX v2.05-16
After the CUE module is successfully installed in the chassis of the router, it still requires some
configuration to function properly. The interface service engine needs to have an IP address
that is on the same subnet as the service module. These two IP addresses represent the two ends
of the virtual Ethernet connection across the backplane.
The IP address of the service engine may be statically assigned to the interface, but this
necessitates the creation of a new subnet with two hosts on it. This subnet will need to appear in
all the routing tables so that the module is reachable. The IP unnumbered command can be
used to save a subnet and is the recommeded solution. Also, a default gateway must be
assigned to the service module.
If DHCP is used, then the IP addresses that are assigned to the service engine as well as any
other statically configured interfaces must be excluded so that IP addresses are not duplicated.


-
--- -
---
-

The dial peer that points to CUE must have

certain configuration settings:
SIP version 2 must be used.
The DTMF relay option must be set to sip-notify.
G.711 codec must be used.
VAD must be disabled.
IPTX v2.05-17
Cisco CallManager Express uses SIP to communicate with the CUE module. SIP is a protocol
that is used to set up and tear down calls. In this case, it is used to set up the connection
whenever someone calls the automated attendant or a mailbox. The settings on the SIP dial peer
need to be very specific and include the command session protocol sipv2. This command
instructs the router to use the SIP protocol with this dial-peer destination.
The command dtmf-relay sip-notify instructs the dial peer to take all dual tone multifrequency
(DTMF) digits that are pressed and send them out-of-band as an SIP notify message, rather
than in-band in Real-Time Transport Protocol (RTP) packets. Another command that is used is
the coded g711ulaw command. This command sets the coder-decoder (codec) to G.711, which
is the only codec supported in CUE.
The no vad command is used to disable voice activity detection (VAD). VAD is a mechanism
that suppresses packets when no detectable voice is traversing the RTP stream. It provides a
way to reduce the amount of bandwidth that is consumed by typical two-way voice
conversations. VAD should be disabled for communication with CUE.

Sets the number and any wildcards that must be sent

to match this ephone-dn
Assigns ephonednsto turn the MWI light on or off

IPTX v2.05-18
On the Cisco CallManager Express router, two ephone-dns should be configured for the
Message Waiting Indicator (MWI) functions. The number that is assigned to each MWI
ephone-dn with the command number number must have a certain format in order to function
properly with CUE. The defined number will be composed of a numeric value and a string of
periods. The numeric portion should be the same length as the dial plan for the installation and
should not overlap on existing ephone-dns. The string of periods must be equal to the length of
extensions in the dial plan. For example, if the installation uses five digits then the numeric
string must be followed by a string of five periods.
Note
The number of digits used for extension numbers must be consistent on all end devices.


--

-
- --
-
-
-

-
--- -
---
-

Router IP address
CUE hardware
IP addressing
HTTP server
configuration
Static route into CUE
SIP dial peer to route
calls into CUE
MWI on and off

ephone-dn
IPTX v2.05-19
The figure shows the recommended configuration on the Cisco CallManager Express router,
with the following:
IP addressing of the interface service engine and the service module on the same subnet
A static route to get to the service module IP address
An SIP dial peer
An MWI on ephone-dn (Cisco CallManager Express integrations only)
An MWI off ephone-dn (Cisco CallManager Express integrations only)
The IOS router requires certain prerequisite configurations, including IP addressing on the
service engine as well as a default gateway. A host route to the service module is also needed
so that the router knows where the CUE module is located. The CUE module is seen by Cisco
CallManager Express as a separate device even though it shares the same chassis.
To use flash as the location of the Cisco CallManager Express GUI files, which is needed for
the GUI of CUE, the HTTP server must also be configured on the IOS router.
An SIP dial peer must be configured so that the Cisco CallManager Express router is able to
communicate across the backplane to the CUE module. The SIP dial peer must be hardcoded to
G.711, with no VAD, and DTMF relay through the SIP notify message must be turned on.
The MWI configuration that is required on Cisco CallManager Express must have a period
character to represent each digit in the dial plan. For example, in the figure, there are four
periods at the end of the MWI on ephone-dn and the MWI off ephone-dn. These four periods
represent a four-digit dial plan.
Connecting to the CUE Module
This topic describes the startup of the CUE module and how to connect to the module.
Connecting to the CUE Module

The CUE module starts automatically with the
configured host router when power is applied.
OIR is supported on the 3745 and 3845 only.
AIM-CUE can take significantly longer to start up
than the NM-CUE and NM-CUE-EC.
IPTX v2.05-20
In order for the CUE module to have power, the host router in which the module is installed
must be powered on. After the CUE module receives power, it goes through its bootup
procedure. Because the CUE application is Linux-based, the bootup process loads the Linux
operating system, then loads the CUE application that runs on top of the operating system. The
bootup time of the module may be longer than the bootup time of the host router.
Note
OIR of the NM-CUE and NM-CUE-EC is supported by the Cisco 3745 and 3845 routers. The
modules should always be shutdown before removal from the router.
Connecting to the CUE Module (Cont.)

-
- - -
--- - --
Commands used to control, view status, and connect

to the service engine from the host router
-- - ---

- -
-
IPTX v2.05-21
To connect to the CUE module, use the command service-module service-engine module/port
session. This opens a back-to-back terminal connection over the backplane to the CUE module.
It is important to secure the Telnet access to the router, and thereby the CUE module, because
all access to the CUE module is through the router. To disconnect from the CUE module and
go back to the CLI of the host router, enter exit from the CUE module.
Note
For remote access, telnet to the host router, then session to the CUE module.
Restoring the Factory Defaults
This topic describes how to restore factory defaults for the CUE module.
Restoring the Factory Defaults
Restores the configuration of the CUE module to

factory defaults
--
-
-
-
- -
-- - - - -
-
IPTX v2.05-22
To restore factory defaults on the CUE module, use the command restore factory default
while the module is off-line. This allows you to redo the initial configuration and to rerun the
initialization wizard.
Caution
All configurations and voice mails will be lost.
This topic describes the initial configuration process that can be performed on a CUE module.
This process can be run on a CUE module that is new, going through a reinstallation, or being
reconfigured after restoration of factory defaults.
- --
- -
- - --
-
- --
--
- --
- -
- -
Starts the
configuration of
the CUE module
IPTX v2.05-23
The overwrite of the storage proceeds the installation of the operating system and application.
At the end, you are asked if you wish to start the initial configuration.
Initial Configuration (Cont.)
- -- - -
- - -

- - -
- - - -
--- - --- - -
--
-
--
- -
- - - - -
- - -
- -
- -
Choice to ignore
previous
configuration
This output will appear only if a previous configuration existed.

IPTX v2.05-24
This output appears if any configuration was present before this installation process. You are
asked whether you would like to restore the previous configuration. These settings include the
hostname, domain name, Domain Name System (DNS) server, NTP server, and time zone.

-
-
- - -

-
- -
Sets the hostname of

the CUE module

- - -- - -
--- -- -
- -- -
-
-
- - -
---
Determines if DNS is
used by CUE
IPTX v2.05-25
After an installation or upgrade, the system automatically starts a utility that configures some
basic settings of the CUE system. The information that you must provide includes:
hostname
DNS server address
NTP server address
time zone
administrator credentials

--
-- --
Enter IP address
-
of NTP server
--
-- --
- - - -
- -

-

-

Select region

- -

-

- - -

-
-
--

- - --

Select country

IPTX v2.05-26
The NTP server is defined and the continent and are country set.

- - -
-
- - - -
- -
--

- -

-
- -
- -
- - -
-

-

-
-

- -
-

Select time zone
Confirm time zone

IPTX v2.05-27
The time zone is defined.

-- -
- -
- --

- -
-
--
---
--
---
Set username and

password of default
administrator
CUE prompt
The username and password are needed in order to configure

the CUE module from the GUI and to run the initialization wizard.
IPTX v2.05-28
The default administrative credentials are defined at the end of the initial configuration menus.
After you enter all the requested information, the system prompt appears and you can begin
configuration from the CLI. You can also start the initialization wizard by logging into the
GUI of the CUE module.
Viewing CUE Status
- - -
Displays the installed packages

- - - -

- --
-

-
- -
-
- -
- - - -
IPTX v2.05-29
To verify success after a software version upgrade, use the show software packages command
to view the packages that were installed.
Viewing CUE Status (Cont.)
- - -
Displays the version of the installed packages and

the installed languages
- - -
- -

-

- -
-
IPTX v2.05-30
To verify which versions of the software packages were installed, use the show software
version command.
- - -
Displays the licensed capacity of the CUE module

- - -

- -- -

--
-
- -
-
-
- -
-
IPTX v2.05-31
After a license upgrade, use the show software license command to verify success. This
command allows you to see the number of ports, recording capacity, General Delivery
Mailboxes (GDMs), and the number of mailboxes that are currently installed.
Displays the active calls to the CUE system

-
- --

--
--
-

IPTX v2.05-32
To view any current calls to the CUE module, use the command show ccn call application all.
This is a good command to run prior to taking the CUE system off-line.
This topic describes CUE initialization wizard and the steps required to complete it.

Ping the CUE IP address from the PC where the
browser will be launched to ensure connectivity.
Launch a browser to URL http://a.b.c.d/ (where
a.b.c.d is the IP address of the CUE module).
The CUE GUI banner page login screen is
displayed.
You are now ready to enter the CUE initialization
wizard to set up the defaults for the system.
IPTX v2.05-33
In order to run the initialization wizard, the administrator must connect to the GUI web page of
the CUE module. This is done by using the IP address of the CUE module. The address of the
CUE module must be reachable and may be tested through the use of pings. The initialization
wizard will start the first time the GUI is accessed after installation.
Note
The URL is not the same address as the Cisco CallManager Express router.
CUE Initialization Wizard Login Page
This message indicates that the initialization wizard has not

yet been run on this system. If the system is not yet
configured, then run it now. If the system has been configured
via CLI, then you can bypass the wizard on the next screen.
IPTX v2.05-34
The initialization wizard starts with a login page. The credentials that need to be used are
the same as the administrator credentials defined at the CLI of the CUE module during the
postinstallation steps.
You can bypass the initialization wizard on the next screen, the entry page.
CUE Initialization Wizard Entry Page
The wizard can be skipped and the system configured from the
CLI instead of the GUI.
IPTX v2.05-35
After the CUE credentials have been entered, the administrator is presented with the option to
view the current settings, run the initialization wizard, skip the wizard and use the CLI to
configure, or logoff and run the wizard later.
Note
If the wizard is skipped, then the initial configuration must be completed from the CLI and
Cisco CallManager Express will not synchronize with CUE. In this case, all users must be
re-created in CUE manually.
The initialization wizard consists of five steps, which begin after the screen in this figure.

Step 1: Cisco CallManager Express Login
Defines the Cisco CallManager Express router and login that

will be used to log in to the router to get/write information
imported during the initialization wizard process.
This Cisco CallManager Express login must preexist;
the CUE initialization wizard will not create it.
IPTX v2.05-36
Step 1: Cisco CallManager Express Login

The first step of the wizard asks for the credentials of the Cisco CallManager Express
web administrator. These credentials are used by CUE to import the users from the
Cisco CallManager Express system. These credentials are the username and password
defined for the system administrator in Cisco CallManager Express.
Note
The Cisco CallManager Express credentials must be established already because they
cannot be defined here.

Step 2: Import Users
Click here to
create
mailboxes for
all these users.
Lists all the users currently defined on Cisco CallManager Express

All or a subset can be:
Imported into CUE as users
Given mailboxes
Assigned administrator privileges in CUE
IPTX v2.05-37
Step 2: Import Users

The second step in the initialization wizard is to review the users that are imported from the
Cisco CallManager Express system. These users are selected by default; optionally, they can be
marked to have a mailbox created and be designated as an administrator on a user-by-user
basis. When this is completed, move on to the third step.
Note
The users that are imported are a result of the usernames configured on the ephones in

Step 3: System Defaults
IPTX v2.05-38
Step 3: System Defaults

The third step of the initialization wizard is where a number of settings for the system are
defined. The first section is where the language is set. This is the language that the prompts and
system messages are in; currently only English (United States) is supported. The second section
of this page deals with passwords and PINs. These passwords and PINs may be randomly
generated and displayed at the end of the wizard, or they may be set to remain blank. The third
and final section of this page deals with mailbox defaults that will be applied to all new
mailboxes that are created in CUE. These settings may be overridden on a mailbox-by-mailbox
basis after the wizard is completed. The settings in this area deal with mailbox size, maximum
message size, and the expiration period for messages.
The default mailbox size is determined by the license capacity at the time that the initialization
wizard is run. If future growth is expected, it is advisable to lower the default mailbox size to
accommodate that growth.
Note
Passwords and PINs that are randomly generated by the system appear at the end of the
wizard and are visible to the administrator in the GUI after the wizard is run. When the
password or PIN is reset by the end user, the administrator is no longer able to view the
password or PIN. The administrator is able to reset them.

Step 4: Call Handling
IPTX v2.05-39
Step 4: Call Handling

The fourth page in the initialization wizard deals with call handler defaults for the CUE system.
These are the settings.
Voice Mail Number: The telephone number that users dial to retrieve their voice messages
or the number that is automatically dialed when users press the Messages or Envelope Icon
button on the IP Phone.
Voice Mail Operator Extension: The extension that voice mail users reach when they dial
0 for an operator while in voice mail.
Auto Attendant Access Number: The extension that voice mail users dial to reach the
voice mail operator.
Auto Attendant Operator Extension: The telephone extension for the operator. The
automated attendant application transfers callers to this extension when they dial 0 for the
operator.
Administration via Telephone: The telephone number or extension that administrators
dial to access the Administration via Telephone (AVT). This is used to manage prompts
and the Emergency Alternate Greeting (EAG).
MWI on Number: The system uses this extension together with the extension of the user
to turn on the users MWI light. This value is populated with an ephone-dn that is
configured specifically as an MWI on ephone-dn in Cisco CallManager Express. The
periods at the end of the number are mandatory, and there must be one for every digit in the
dial plan.
MWI off Number: The system uses this extension together with the extension of the user
to turn off the users MWI light. This value is populated with an ephone-dn that is
configured specifically as an MWI off ephone-dn in Cisco CallManager Express. The
periods on the end of the number are mandatory, and there must be one for every digit in
the dial plan.
Caution
The Voice Mail Number field, Auto Attendant Access Number field, and Administration via
Telephone Number field must contain different values. If they do not, then a user who tries
to call the operator while in the voice mail system is directed back to the voice mail system
or the GMS. Also, an outside caller trying to get to the operator is connected to the voice
mail system or the GMS.

Step 5: Commit
IPTX v2.05-40
Step 5: Commit
The fifth step of the initialization wizard consists of two confirmation pages that should be
reviewed for errors. The first of the two pages summarizes much of the configuration that was
entered during the wizard.
Note
At this point, no changes have been committed to the configuration or database. If any
changes are needed, simply click the Back button to correct the setting.

Final Screen: Committed Information
IPTX v2.05-41
Final Screen: Committed Information

The final screen in the initialization wizard is the second of two confirmation pages. This page
shows any passwords and PINs that were randomly generated by the wizard. It would be a good
idea to save the passwords and PINs, either by writing them down or using Print Screen. After
this page, the administrator is not able to view the passwords or PINs of users in clear text.
However, the administrator can reset them to a known value at a later point.
Below the passwords and PINs, a status message appears regarding the actions that were
taken. If these status messages indicate Success, then changes have been committed to the
configuration and database.
The administrator must log out at this point, then log back in to see the administrator GUI
web pages.
Restarting the CUE Module
This topic describes the different ways to restart a CUE module.
Restarting the CUE Module

CUE software can be restarted from:
CUE GUI: Administration > Control Panel
CUE CLI
Router CLI
-- -

-
- -
-

-- --
-- --

IPTX v2.05-42
If the CUE module needs to be restarted, there are three ways to do this:
Web-based GUI: Log in to the administrative web site and choose Administration >
Control Panel.
CLI of the host router: From the host router, use the command service-module serviceengine module/port reload from privilege EXEC mode.
CLI of the CUE module: From the CUE module, use the reload command from privilege
EXEC mode.
Caution
Remember to save the configuration by using the copy running-config startup-config

command on the CUE module before initiating the reload.
Upgrading CUE Software and License

This topic describes the CUE upgrade steps.
CUE Upgrade
Upgrade steps:
Load the new software and license files on the TFTP or FTP server.
Backup the configuration voice mails to an FTP server.
Use the software install cleancommand to perform a reinstallation or upgrade
of the CUE application that reformats the hard drive.
A full backup and restore are required to preserve the configuration and
voice mails.
Select language.
Perform the initial configuration.
Run initialization wizard.
Upgrading the licensed capacity does not reformat the hard drive.
Use the software install upgradecommand to perform an incremental upgrade
(point release) without reformatting the hard drive.
A full backup is still recommended.
No language, selection is possible .
Restore the configuration and voice mails from the backup set onthe FTP
server if the software install cleancommand was used.
Reload the CUE module.
IPTX v2.05-43
Performing an upgrade of the software version and the licensed capacity of CUE is a multistep
process. The following is a summary of these steps:
Load files: The correct software files, license files, or both must be on a TFTP or an FTP
server that is reachable by the CUE system.
Backup: The system must be backed up to an FTP server.
Upgrade: Upgrade the CUE software using either a reinstall or an incremental upgrade.
Restore: Restore the system from the backup file on the FTP server if a reinstall was
performed.
Reload: CUE must be reloaded.
CUE Upgrade Scenarios

Upgrade the system software only and keep the same licensed capacity.
When upgrading the system software, the license file will survive.
Upgrade the licensed capacity on the system only and keep the system
software the same.
Upgrade the license file only and the system software will remain
unchanged.
Upgrade both the licensed capacity and system software of CUE.
Load a new license package, then load the new software package.
Change the installed language.
The following capacity upgrades are possible:
12 to 25, 50, or 100 mailboxes
25 to 50 or 100 mailboxes
50 to 100 mailboxes
100 user mailboxes capacities are only available on the NM-CUE and
NM-CUE-EC.
Capacity downgrades are not supported.
IPTX v2.05-44
The software upgrade procedure in CUE is either a reinstall or an incremental upgrade. If only
the software level will change during an upgrade and the capacity (number of mailboxes) of the
system remains unchanged, then no action with regard to license installation needs to be taken.
The existing license survives a software change.
In CUE, a clean software reinstallation overwrites all software information on the hard drive
(NM-CUE, NM-CUE-EC) or flash (AIM-CUE), so no configuration or message data survives a
software installation or upgrade. It is therefore imperative to do a system backup before the
upgrade is started.
For example, if the capacity of the system is changed from a 12-mailbox system to a 25mailbox system, then a new license file must be installed. Assuming only the license
installation is being upgraded and the software level is not changing, then the hard drive or
flash contents survive and the system is operational after the license installation.
Note
It is always good practice to do a backup before any installation, even though it may not be
required. Performing a backup is recommended before a license installation.
A downgrade is defined as going backward in either software release (for example, from
release 2.1.2 to release 2.0.1.) or license level (for example, 25 mailboxes to 12 mailboxes)
while maintaining the system configuration and data on the disk. Downgrading the version of
CUE software is done by performing a clean installation . Certain releases of CUE support
downgrading to the previous version assuming that the previous upgrade was an incremental
upgrade.
Caution
Downgrading of the licensed capacity is not supported and can cause unpredictable results.
CUE Upgrade Backup

FTP
Server
Read and
Write
Access
Backup
IP Network
Restore
Backup and restore using an FTP server as the

storage for backup sets.
IPTX v2.05-45
In order to perform a backup or a restoration, an FTP server must be present and available to
the CUE module. Both the configuration and the messages can be backed up over the network
to the FTP server. The CUE module must have both read permission and write permission to
the FTP directory. When a restoration is necessary (such as during an upgrade of CUE), the
backup sets can be downloaded from the server using FTP. In order to perform either a backup
or a restoration, the CUE module must be put into an off-line state. While in the off-line state,
CUE is not available to subscribers.
Caution
When the CUE module is taken off-line, any subscribers and callers in the automated
attendant are cut off without warning.
CUE Upgrade Backup (Cont.)
Specify the location and path to where the backup will be written.
Specify the username and password used as credentials.
The username must have write permissions on the directory.
IPTX v2.05-46
Configure the URL of the FTP server and the credentials where the backup and restore
functions will take place. Choose Administration > Backup/Restore > Configuration from
the GUI.
Specify a description for the backup set.

Select what to backup in the backup set.
ConfigurationSystem and application settings
DataApplication data and voice mails
IPTX v2.05-47
A backup can be performed either from the GUI or from the CLI. To perform a backup from
the GUI, choose Administration > Backup/Restore > Trigger Backup and select the name of
the backup and what is to be backed up. For upgrading the software version, be sure to select
both the configurations and the data that is to be backed up.
Click Start Backup to start the operation. This operation causes all calls to be dropped and the
system to go off-line. The backup file that is created is stored on an FTP server. Flash and other
types of media cannot be used for backup and restoration.
It is advised to use the show ccn call application all command prior to triggering the backup to
determine if any active calls are currently ongoing.
Note
While off-line, no calls to the automated attendant or to voice mail will work.
The amount of time the backup takes will depend upon the
bandwidth and the size of the backup set.
When the backup is completed, bring the system back online.
IPTX v2.05-48
After starting the backup, the GUI continues to function. A progress bar is displayed that shows
the number of bytes that were transferred. The amount of time that is required to complete the
backup is mainly a function of how many minutes of voice mail are present on the CUE system
because this makes up the bulk of the data.
When the backup is complete, the administrator must bring the system back online. This does
not happen automatically, and it cannot be automated from the GUI.

-- -
-

-
-
- --
- -
- --

- -
-
-
-
- --
-- -

-
---

IPTX v2.05-49
The CLI method of starting a backup comprises three commands:

CUE#offline: This command takes the system offline and disconnects any calls to the
CUE system.
CUE#backup category [all | configuration | data]: This initiates the backup of both data
and configuration, configuration only, or data only.
CUE#continue: This brings the system back online so that it can accept calls again.
In the CUE GUI, the backup must be initiated manually and put back online manually. There is
no mechanism to do scheduled backups from the GUI. A script that runs on another machine
can be used to automate the backing up of data and configuration on the CUE module.
Performing a backup from either the GUI or the CLI requires the system to be off-line, and
taking the system off-line disconnects all calls in progress on the CUE system. Care needs to be
taken to ensure that the backups take place during nonpeak hours. This is usually late at night
or early in the morning, but varies depending on the situation.
Caution
If error messages occur while using a script to back up the CUE system from the CLI, there
may not be an administrator to view the errors.
Upgrading CUE:
Clean Install 2.x to 2.x
TFTP Server
and FTP Server
IP
From the CLI of CUE, enter thesoftware install
clean command to specify the package to
install.
cue-installer.2.1.1
cue-vm.2.1.1.pkg
cue-vm.2.1.1.prt1
cue-vm-xx-license.2.1.1.cme.pkg
The CUE module will restart and the initial

configuration will be invoked.
IPTX v2.05-50
To perform a clean reinstallation of CUE version 2.x, use the installer that is built into the
application. The command to perform a clean installation is software install clean url url.
Upgrading CUE:
Clean Install 2.x to 2.x (Cont.)
- -
- - -- -
- -
- -

-

-
-

-
-
-

-

IPTX v2.05-51
The clean installation process will perform a reformatting of the hard drive and all previous
configuration and voice mail data will be lost. In order to preserve the configuration and voice
mails, a full backup needs to be performed before the clean install, and a full restore needs to be
performed after the clean install.
Upgrading CUE:
Clean Install 2.x to 2.x (Cont.)

-
-
-

-

- - --

- -
IPTX v2.05-52
The language that is installed must be selected through this installation process. After the
language is selected, the module performs the reformatting and the reinstallation, then will
reboot itself. After the reboot is finished, the module comes up and prompts for the initial
configuration.
Upgrading CUE:
Incremental Upgrade 2.x to 2.x
TFTP Server
and FTP Server
IP
From the CLI of CUE, enter thesoftware install
upgrade command to specify the package to
install.
cue-installer.2.1.1
cue-vm.2.1.1.pkg
cue-vm.2.1.1.prt1
Only the files necessary for the upgrade will

need to be rewritten on the hard drive.
IPTX v2.05-53
For point releases in CUE version 2.x, an incremental upgrade may be performed. This does
not perform a hard drive reformat, so no configuration or voice mails are lost. Use the
command software install upgrade url url to initialize the process.
Upgrading CUE:
Incremental Install 2.x to 2.x (Cont.)
- -
- - -- -
-
- -

IPTX v2.05-54
Even though the configuration and voice mails are not deleted during an incremental upgrade,
performing a full backup prior to the upgrade is recommended.
Upgrading CUE:
1.x to 2.x
TFTP Server
and FTP Server
IP
From the CLI of CUE, enter boot loader mode
by restarting the CUE module, and enter ***
within 10 seconds of being prompted for it.
cue-installer.2.1.1
cue-vm.2.1.1.pkg
cue-vm.2.1.1.prt1
Configure the boot helper with a profile that

contains the IP address, subnet mask, default
gateway, TFTP server IP address, and
installer file name. Select internal for the
Ethernet port and primary for the profile.
Run the boot helper, which will boot the
installer environment across the network
from the TFTP server.
IPTX v2.05-55
To upgrade a 1.x version of CUE software to a 2.x version, use the following process. Reload
CUE from the CLI of the CUE module. While CUE is reloading, a lot of output is sent to the
screen. In order to upgrade or reinstall, *** must be entered within 10 seconds of seeing the
prompt Please enter '***' to change boot configuration. After *** is entered, the CUE
module loads a very basic interface called boot loader mode. In the boot loader mode, a
network profile must be configured with the config command. The profile must contain an
IP address, a subnet mask, a default gateway, the location of the TFTP server that contains an
installer file, and the name of the installer file. This profile is then invoked by the boot helper
command. The installer environment loads across the network via TFTP. During this phase,
there is a lot of output to the console. When the prompt reads se-ip-address-installer>, the
process is complete and installation of the CUE system software, upgraded license file, or both
may begin.
Upgrading CUE:
1.x to 2.x (Cont.)

-
- - -

Reload the CUE

software, in this
case from the
CUE CLI.

-
- -
--
Interrupt the load

process within 10
seconds to get to the
boot loader prompt
by entering ***.
-- --
-- --

Boot loader
- -
-
prompt is
where install instructions
are given.
IPTX v2.05-56
The above output shows the process to upgrade a 1.x version of CUE to a 2.x version. In order
to initialize the boot loader, the CUE module must be restarted and given a sequence of keys
that interrupt the normal boot process. To reboot the CUE module, enter the reload command.
To enter boot loader mode, enter *** when prompted. This starts the boot loader. It looks
similar to the normal bootup of the CUE module. The prompt isServiceEngine boot-loader>
if correctly booted. The boot loader must then be configured with a basic network configuration
as well as with the location of the installer file or license file.
Note
There will be large amounts of output, and the boot loader can take several minutes to
initialize.
After you are in boot loader mode, verify the connectivity to the TFTP server where the
cue-installer.2.1.1 file is located.
Upgrading CUE:
1.x to 2.x (Cont.)
-
--
-
-

-

-
-
-
Config starts the

configuration of the
boot helper.
Boot helper
initialized the loading
of the installer
package.
Verify connectivity to the TFTP server by using the ping command.
IPTX v2.05-57
Because the boot loader must go across the network, a profile that contains an IP address, a
subnet mask, a default gateway, the address of the TFTP server, and an installer file name must
be configured. The Ethernet interface must remain at the default of internal, and the default
boot should be disk.
After the configuration is complete, initiate the loading of the installer by using the command
boot helper. This uses the configuration information that was entered to load the installer. This
takes some time, and a large amount of output is generated to the console. When the installer
has been loaded across the network, a reboot occurs automatically, and the prompt changes.
Upgrading CUE:
1.x to 2.x (Cont.)
TFTP Server
and FTP Server
IP
cue-installer.2.1.1
cue-vm.2.1.1.pkg
cue-vm.2.1.1.prt1
cue-vm-en_US-lang-pack.2.1.1.pkg
To upgrade the operating system, specify the

software package name and the URL where it is
located from installer mode.
The license can be installed consecutively with or

independently of software.
IPTX v2.05-58
When you are in the installer mode, you will see commands instructing you to load a package
across the network. To avoid repeating this process twice, load the license package first, then
load the software package.
Caution
Downgrading the licensed capacity is not supported.
Upgrading CUE:
1.x to 2.x (Cont.)
- --
- -
- -

-
-- -
- -

-
The name and

location of the
license or software
package that will be
installed on the CUE
module
-

-
If installing both a license package and a software package,

install the license package first to avoid having to go through
the installation process twice.
IPTX v2.05-59
Select 1 Install software and define the name of the package to install, the URL of the
FTP server, and login credentials.
Upgrading CUE:
1.x to 2.x (Cont.)
TFTP Server
and FTP Server
IP
Select the language or languages to
install.
cue-installer.2.1.1
cue-vm.2.1.1.pkg
cue-vm.2.1.1.prt1
cue-vm-en_US-lang-pack.2.1.1.pkg
The installer overwrites the storage with

the CUE image.
The CUE module will reboot itself and
start the initial configuration.
The license can be installed consecutively with or

independently of software.
IPTX v2.05-60
Select a language to install on the CUE module. The software installation will then proceed.
When the software package is loaded, the hard disk is overwritten and a fresh copy of the
software is installed.
Caution
The reimaging process may take many minutes, depending on the storage media. The
flash-based AIM-CUE may take significantly longer than the hard drive based NM-CUE
and NM-CUE-EC.
Upgrading CUE:
1.x to 2.x (Cont.)

-
-
-

-

Selects English to be
installed on the CUE
installation
Up to two languages may be selected.
IPTX v2.05-61
The language page appears next and allows the user to select up to two different languages
from the supported list. CUE version 2.1 currently supports English US, French France,
German Germany, and Spanish Spain.
Upgrading CUE:
1.x to 2.x (Cont.)

-
-
-

-
Done selecting
languages
- - --

IPTX v2.05-62
When the language has been selected, a * will appear next to that language in the menu.
Enter x to exit the language menu.
The CUE system reboots itself, then prompts the installer to perform the initial configuration of
the CUE module. A hostname, domain name, DNS server address, NTP server address, and
time zone are defined during the initial configuration. The CUE module loads the new software
image and the CUE prompt appears.
CUE Upgrade Restore
Select the backup entry that the restore should use. Click the
Start Restore button to initiate the process.
Reload the module.
IPTX v2.05-63
To restore the data and configuration after an upgrade of the software, either the GUI or the
CLI can be used.
The GUI web page can be reached by choosing
Administration > Backup/Restore > Start Restore
.
From here, the backup to be restored can be selected as well as what to restore: the configuration,
the data, or both. If multiple backup sets exist, only one may be selected to restore.
As is necessary when performing a backup, the system must go off-line to perform a restoration
from backup. This should not be a problem with an upgrade. At the end of the restoration, a
prompt allows the administrator to set the system to go back online.
Note
The amount of time that is required to restore the data depends on the amount of data. The
data that contains the voice mails usually takes the longest.
CUE Upgrade Restore (Cont.)

--
-
-
- -
-

-
-
--

-
To restore, first take the CUE system off-line.

Backup ID will be needed.
IPTX v2.05-64
The restoration can be performed from the CLI as well. The first command that must be
entered viewed using the show backup history command. The backup ID is needed to
activate the backup.
CUE Upgrade Restore (Cont.)

-
---
-
To restore, first take the CUE system off-line.

Backup ID will be needed.
Reload after the restore.
IPTX v2.05-65
After the backup ID is known, the restore id backupID category [all | configuration | data]
command can be entered. This initializes the restore operation. Upon completion, the CUE
system must be reloaded.
Summary
Summary
Performing an upgrade or reinstallation may require
a TFTP server, an FTP server, and files downloaded
from CCO.
Two form factors exist for the CUE module:
an NM-CUE and an AIM-CUE.
Prior to installation, the Cisco CallManager Express
router will require configuration.
The installation or upgrade process involves
loading an installer file, then installing either the
license file or the application from an FTP server.
After installation of the application, a setup utility
will run to set basic parameters.
IPTX v2.05-66
Summary (Cont.)
Prior to installation, the Cisco CallManager Express
router will require configuration.
The CUE module starts automatically and can be
reloaded in various ways.
The CUE initialization wizard is run only after an
installation of software.
The CUE initialization wizard is a macro that sets
commonly used settings on the CUE.
To upgrade an installation, backup the CUE, install
the newer version, or new license, then finally
restore from the backup.
IPTX v2.05-67
Lesson 3

Express Auto Attendant
Overview
This lesson defines the Cisco Unity Express (CUE) Auto Attendant and how it is used in a
production environment. It also defines how to customize additional automated attendant
scripts using the CUE Auto Attendant Editor (CUE AA Editor) and how to install and
configure them with a trigger. Interaction with the system to implement an Emergency
Alternate Greeting (EAG) and Administration Via TUI (AVT) is also discussed.
Objectives
Upon completing this lesson, you will be able to describe the components of and tasks required
to configure CUE Auto Attendant. This includes being able to meet these objectives:
Describe the workflow of CUE Auto Attendant
Describe CUE AA Editor and perform the steps for automated attendant script creation
Describe how to define the holidays
Describe how to define business hours
Describe CUE scripts and prompts
Perform the tasks to set up CUE Auto Attendant
Describe EAG and perform the tasks for configuration
Describe Administration Via TUI and perform the tasks for configuration
CUE Auto Attendant Operation
This topic describes how the CUE Auto Attendant operates.
CUE Auto Attendant Operation Overview

Answers calls and allows callers to
self-direct by entering an extension
or a name or dialing 0 for the
operator
Can have up to five active automated
attendants per system
Created and customized in the
CUEAA Editor
Can be administered via TUI
Record automated attendant
prompts from an IP phone or a
computer with a microphone.
Provides Emergency Alternate
Greeting
Alert callers to temporary
schedule changes owing to bad
weather and other unexpected
events.
IPTX v2.05-3
The automated attendant functionality of CUE plays messages that callers hear when they dial
the companys telephone number, including prompts to guide the callers to specific extensions
or employees.
CUE can currently have up to five automated attendants per system that are active at any one
time. This allows for different numbers that a caller can dial to reach different sets of prompts
and menus. If the system default automated attendant is not desired, customized versions may
be constructed. This allows a customer to use custom prompts and custom call flows in the
automated attendant function.
A custom automated attendant can be constructed in a GUI by using the CUE AA Editor. This
editor allows for the easy construction of scripts by using prebuilt modules called steps. The
steps are logic blocks that can be placed in a specific order. These steps are then saved to a
script that can be uploaded to the CUE module.
Within the automated attendant, it is often desirable to have a message that is set up to play at
the front of the automated attendant script during an emergency. This allows the administrator
to toggle the EAG on and off through the TUI by using an IP Phone and dialing the AVT
number.
Automated Attendant Operation

System Defaults
Uses script file aa.aef
Cannot be downloaded, uploaded, or changed
Can be deactivated
Only customizable parts of this script are:
Welcome greeting
Activation and deactivate the Emergency
Alternate Greeting
IPTX v2.05-4
CUE comes with a default automated attendant. The default automated attendant maps to a
script called aa.aef (.aef is the file extension that all customized scripts need to be saved with).
This aa.aef script cannot be downloaded into the CUE AA Editor or even viewed. However, the
opening greeting wave file can be modified in the GUI web pages, and the EAG can be
activated via the TUI.
Four additional automated attendants can be uploaded and activated on both the CUE network
module (NM-CUE) and the CUE advanced integration module (AIM-CUE).
Example: Automated Attendant Operation
555.1212
PSTN
555.6789
555.2333
Three Different Numbers with an

Application Assigned to Each
General Auto
Attendant:
Welcome to ACME
Publications ...
Specific Auto
Attendant :
Welcome to the
ACME automotive
center
Specific Auto
Attendant :
Welcome to the
ACME graphic
services
IPTX v2.05-5
If additional customization is required, a custom script can be constructed and associated with
a phone number. It is not uncommon for an enterprise to have multiple phone numbers and
want a different automated attendant for each. This allows for an enterprise to customize the
interaction of the caller based on the number dialed. It is also possible to associate multiple
phone numbers to run the same automated attendant.
Example
In the example in the figure, ACME has three different divisions, and each requires a different
automated attendant. If a customer dials the general phone number, then the general automated
attendant plays; if the automotive number is dialed, then the specific automated attendant for
that division plays. A third number for graphic services is tied to the specific automated
attendant for that division.
Note
Scripts can be nested inside of other scripts.
Automated Attendant Configuration Steps

Prepare the script in CUE AA Editor.
Upload the script to CUE.
Create and upload any required prompts.
Add an application on CUE.
Associate the script with the application.
Set the number of ports and the pilot number for
the application.
Test the application by calling the pilot number.
IPTX v2.05-6
Constructing a custom automated attendant requires that the CUE AA Editor is installed on a
Windows PC. This interface is used to construct the script off-line. The script is then uploaded
to CUE. The CUE system allows up to eight stored scripts on the CUE-NMs and four on the
CUE-AIMs. The custom scripts can be very complex there is no realistic limit to the number
of steps involved in customizing a script.
When custom scripts are constructed, they usually require the creation of custom prompts. The
AIM-CUE can have up to 25 prompts with a maximum size of 1 MB each, and the NM-CUE
can have up to 50 prompts with a maximum size of 1 MB each. The prompts themselves can be
recorded off-line and uploaded to the CUE system through the GUI or the command-line
interface (CLI). Prompts can also be recorded through the AVT if desired.
Automated Attendant Concepts

CUE AA Editor
Scripts prepared off-line and uploaded to the CUE system

Up to five automated attendant applications resident on system
One system and four custom active applications
One deactivated system and five custom active applications
Stored scripts: six on the AIM-CUE; eight on the NM-CUE
Large maximum number of steps per automated attendant
No limit on the number of nesting levels within each automated attendant script
Prompt Parameters
Total number of custom prompts that can be uploaded to the system

25 on AIM-CUE 50 on NM-CUE
1-MB file size per prompt (2 minutes)
Record Prompts
Prompts used in script(s) can be recorded off-line and uploaded to the CUE
system
Prompts can also be recorded and managed via the TUI
IPTX v2.05-7
To create, install, and test the automated attendant application involves multiple steps. The first
step is to create a customized script if the default does not meet the needs of the enterprise. This
script creation is accomplished in a software tool called the CUE AA Editor. After the script is
created, it needs to be uploaded to the storage on the CUE module. Usually new prompts will
need to be recorded and uploaded to the storage of the CUE module as well.
After the script and prompts are present on the storage of CUE, the CLI or the GUI can be used
to create the automated attendant application. The automated attendant application connects the
script, pilot number, and the maximum number of ports. The new automated attendant
application invokes the prompts that are present in the storage of CUE.
It is important to test the function of the automated attendant application by calling the pilot
point number, which is also referred to as the pilot number.
Automated Attendant Script Preparation

1. Install CUE AA Editor from Cisco.com onto
a PC or server.
2. Create or edit the automated
attendant script via the
CUE AA Editor.
3b. Alternate recording of

prompts via the TUI.
PSTN
IP
4. Upload the script and prompts
to the CUE system for active call
control.
3a. Record the prompts used by the script.

IPTX v2.05-8
The process of script preparation starts with installation of the CUE AA Editor. This
application can be installed on any modern Windows-based computer. The application itself
can be obtained from Cisco Connection Online or a CUE CD set. After the CUE AA Editor is
installed, it can be used to create a script. This script should be validated before saving it with
an .aef extension. After saving the script, upload it to the CUE system.
Usually when making a new script, new prompts must also be made. These can be recorded
either with the AVT or outside the system. Regardless of how the recording is made, the scripts
must be present on the CUE system. If they were recorded in the AVT, then they are already
present on the system; if recorded in another way, they must be uploaded.
Note
The construction of scripts in the CUE AA Editor is actually a type of visual programming,
and any experience in programming is helpful.
CUE AA Editor
This topic describes the CUE AA Editor.
CUE AA Editor Overview

Offers a subset of steps for automated attendant script
creation
Palette
Folders
of Steps
Variable
Window
Work Area
Debug and
Message
Window
IPTX v2.05-9
The CUE AA Editor is a script editor that offers a visual programming environment for
creating automated attendant application scripts. You can use the CUE AA Editor on any PC
that has one of the following Microsoft Windows operating systems:
Windows NT (workstation or server) with Service Pack 4 or later
Windows 2000 (professional or server)
Windows XP Professional
The CUE AA Editor simplifies script development by providing blocks of contact-processing
logic in easy-to-use Java-based steps. Each step has its own unique capabilities, such as simple
incrementing, generating and playing out prompts, and obtaining user input.
Although the steps are written in Java, you do not need to understand Java programming to
build a CUE automated attendant script. You can assemble a script by dragging step icons from
a palette on the left pane of the workspace to the design area on the right pane of the workspace.
The CUE AA Editor supplies the code required to connect the steps; you provide the variable
definitions and other parameters. You can validate the completed script directly in the editor.
CUE AA Editor:
Constructing a Script
When starting a new
script, the only step
present in the workspace
will be a start step.
Steps are Java Beans.
Drag and drop steps
from the palette to the
workspace.
When dropping the step in
the workspace, it must be
dropped on top of an
existing step. It will then
appear below.
Validate the script, and if
successful, save with an
.aef extension.
IPTX v2.05-10
Example: Constructing a Script

To construct a script, open the CUE AA Editor application, choose the File menu, and choose
New. This brings up a work area with only a Start step in it. You can then begin constructing
the script by dragging and dropping steps from the palette to the work area. To expand the
contents of a palette, click the plus sign (+) to the left of the palette icon in the palette pane.
Each step performs a specific function and creates a portion of the underlying programming.
Each step is known as a Java Bean and is a small piece of Java programming code. (You can
customize most of the steps after you have placed them in the Design pane (the top right hand
pane of the editor) by right-clicking them and choosing Properties.) Your cursor displays the
international sign for prohibited until you move a step into a location that the CUE AA Editor
allows.
Note
A step must be dropped on top of another step it will then appear below the step it was
dropped on. If you try to drag a step to the Design pane when a Step Properties window is
open, the Design pane will not accept the step. Before you drag a step to the Design pane,
close any open Properties windows, one or more of which may be hidden behind the CUE
AA Editor window.
CUE AA Editor:
Variables
To add a variable, click
the Add New Variable
button and define the
variable.
Check the parameter
box to allow this value
to be defined from the
CUE web pages by
the administrator
(top-level script only).
The value of the
variable can be
another variable or
explicitly defined here.
IPTX v2.05-11
Adding Variables
The Variable pane of the CUE AA Editor is where you add and modify the variables used by
the script. Variables store data that a script uses when it executes the steps. Any step in your
script can use variables after you define them in the Variable pane of the CUE AA Editor
window.
You can also map variables that you define for your script to variables that you define in a
subflow, which is a set of steps that function as part of another script, called the primary script.
A subflow can use and manipulate a variable, then return the data that is stored in the variable
to the primary script. Scripts cannot share variables with other scripts except in the case of
default scripts, where the primary script automatically transfers the values of its variables to
a default script. The value of a variable can change during execution.
To define a new variable, click the New Variable icon at the top left corner of the Variable
pane of the CUE AA Editor window. The Edit Variable window appears. In this window, you
can define a name. It is suggested that a naming convention be used so that variables can be
recognized easily. This naming convention simplifies configuration and enables the script
programmer to know by the name of the object if the object is a variable.
The type of variable can also be selected in the Type window. The value of the variable as well
as the parameter option can be defined.
Note
The parameter value field can contain an explicit pointer to a file, can contain another
variable, or can be left blank and populated by the script or populated in the GUI.
If checked, the parameter option allows the value of the variable to be set or overridden in the
CUE GUI. This allows changes to the script without having to open the CUE AA Editor.
Note
The parameter option works only for top-level scripts. It does not work for nested scripts.
Using a naming convention is also beneficial when troubleshooting. There are many possible
naming conventions that can be used the main thing is to be consistent. An example of a
naming convention is to use two words with the letters of the first word all lowercase and the
first letter of the second word uppercase, such as, myVariable and testPrompt.
Variable Types
Boolean
A Boolean variable is either true or false, and it is used primarily by the If step in the General
palette of the CUE AA Editor.
Java Class Name java.lang.Boolean
Variable Input Format:
t, f
true, false
Character
A Character variable consists of characters, such as letters of the alphabet.
Java Class Name java.lang.Character
Variable Input Format:
Lowercase letters a to z
Uppercase letters A to Z,digits 0 to 9
Any escape sequence:
\t, \r, \0, \n, \f, \\, \
\uXXXX can be used to represent any character using the character hexadecimal
Unicode number XXXX
Float
A Float variable consists of decimal numbers.
Java Class Name java.lang.Float
Variable Input Format (examples):
3.14159
2E-12
-100
Integer
An Integer variable consists of whole numbers from 2147483648 to 2147483647 inclusive.
Java Class Name java.lang.Integer
234556789
0
23
String
A String variable consists of a set of Unicode characters from \u0000 to \uffff inclusive.
Java Class Name java.lang.String
Hello, C:\WINNT\win.ini; this format does not support any escape characters or
Unicode characters.
\This is a quoted string\, u\tHello, u\u2222\u0065,

uC:\\WINNT\\win.ini, and so forth. This format supports the same escape
sequences or Unicode characters described for the Character type.
Date
The Date variable contains date information.
Java Class Name java.util.Date
D[12/13/05]
D[Dec 13, 2005]
D[January 20, 2005]
D[Tuesday, April 12, 2005]
D[12/13/05]
D[12/13/05 5:50 PM]
D[April 1, 2005 12:00:00 AM PST]
The parameter specified inside the brackets following D (D[ ]) is parsed based on any
combination of the following two formats:
<date>
<date> <time>
The CUE AA Editor supports four <date> specification formats:
SHORT completely numeric, such as 12/13/05
MEDIUM somewhat longer, such as Jan 12, 2005
LONG longer, such as January 12, 2005
FULL completely specified, such as Tuesday, April 12, 2005
Time
The Time variable contains time information.
Java Class Name java.sql.Time
T[3:39 AM]
T[11:59:58 PM EST]
The parameter specified inside the brackets following T (T[ ]) is parsed based on the format
<time>.
The CUE AA Editor supports three <time> specification formats:
SHORT short, such as 3:30 PM
MEDIUM longer, such as 3:30:32 PM
LONG or FULL (which are identical) more complete, such as 3:30:42 PM PST
BigDecimal
The BigDecimal variable consists of an arbitrary-precision integer, along with a scale in which
the scale is the number of digits to the right of the decimal point.
Java Class Name java.math.BigDecimal
Variable Input Format (examples; same as Float variable):
3.14159
2E-12
-100
BigInteger
The BigInteger variable represents arbitrary-precision integers.
Java Class Name java.lang.BigInteger
Variable Input Format (examples; same as Integer variable):
234556789
0
23
Double
The Double variable represents an expanded Float variable.
Java Class Name java.lang.Double
Variable Input Format (examples; same as Float variable):
3.14159
2E-12
-100
Long
The Long variable is an expanded Integer variable.
Java Class Namejava.lang.Long
Variable Input Format (examples; same as Integer variable):
234556789
0
23
CUE AA Editor:
General Steps
Step
Description
Annotate
Insert comments in the script (similar to C /* */ comments).
Call Subflow
Invoke a subflow.
Day of Week
Cause script execution to branch depending on current day of week.
Decrement
Decrease the value of an integer variable by 1.
Delay
Pause the execution of script for specified number of seconds.
End
Designate end of script and free all allocated resources.
Goto
Cause script execution to branch to specifiedLabel step.
If
Cause script execution to branch based on evaluation of a Boolean

expression.
Increment
Increase the value of an integer variable by 1.
Label
Insert a label into a script as a target forGoto step.
On Exception Clear Remove an exception set by previousOnExceptionGoto step.

On Exception Goto
Catch an exception/problem during script execution and handle it.
Set
Change the value of a variable (assignment operator).
Start
Indicate start of the script.
Switch
Cause script execution to branch to one of a number of cases.
Time of Day
Cause script execution to branch depending on current time of day.
Is Holiday
Check if it is a holiday.
Business Hours
Check if within defined business hours.
IPTX v2.05-12
Step Reference: General Steps

The steps in the Generalpalette of the CUE AA Editor provide basic programming
functionality for scripting.
Annotate
Use the Annotate step to enter comments that explain the function of a script segment.
To annotate a script, enter your comments in the Enter Comments field and click OK. The
Annotatecustomizer window closes and the first words of your annotation appear next to
the Annotateicon in the Design pane of the CUE AA Editor.
Note
This step has no effect on script logic.
Call Subflow
Use the Call Subflow step to execute a subflow, which is analogous to a subroutine or module
in structured programming. Use the CUE AA Editor to create the subflow as an independent
script that you can reuse in other scripts. Subflows can be nested; that is, you can call subflows
from within scripts that are themselves used as subflows. During run time, if an exception
occurs within a subflow and you do not handle the exception within the subflow, the exception
is available to the parent script for processing.
Day of Week
Use the Day of Week step to direct the script to different connection output branches
depending on the current day of the week. When the CUE system clock matches one of the
days associated with a connection, the script executes any steps that you configured for that
days connection branch. Configure all days with output branches and assign each day its own
connection(s). If a day is not assigned to at least one output branch, the CUE AA Editor
displays a warning dialog box when you close the Day of Week customizer window.
Decrement
Use the Decrement step to decrease the value of a chosen Integer variable by one. This step is
a specialized version of the Set step of the General palette, which you use to assign any value to
a variable. To decrease the chosen Integer variable by one, choose the desired variable from the
Variable drop-down menu and click OK. The Decrement customizer window closes. The
variable appears next to the Decrement step icon in the Design pane of the CUE AA Editor.
Delay
Use the Delay step to pause the processing of a script for a specified number of seconds.
End
Use the End step at the end of a script to complete processing and to free all allocated
resources. You can also use the End step at the end of a branch of logic in a script. Any call
still active by the time this step is executed automatically is processed by the system default
logic. This step has no properties and does not require a customizer.
Goto
Use the Goto step to cause the script logic to branch to a specified Label step within the script.
If
Use the If step to cause the script to go to one of two branches based on the evaluation of a
specified Boolean expression.
The If step automatically adds two output branches, Trueand False:
True: Steps following this output branch execute if the expression is true.
False: Steps following this output branch execute if the expression is false.
Increment
Use the Increment step to increase the value of a chosen Integer variable by one. This step is
a specialized version of the Set step of the Generalpalette, which you use to assign any value
to a variable.
Label
Use the Label step to insert a label into a script to serve as a target for a Goto step within the
same script.
On Exception Clear
Use the On Exception Clear step to remove an exception set by a previous On Exception
Goto step. Typically, this step is used in the following sequence:
1. An On Exception Goto step directs the script to a Label step.
2. The Label step is configured with a script to handle the exception.
3. An On Exception Clear step is then used to clear the exception.
You may also use this step when you no longer need to handle the selected exception within
the script.
On Exception Goto
Use the On Exception Goto step to catch problems that may occur during script execution and
allow a graceful exit from the situation. You can include any script steps in the Exception Flow
branch that you want to use to respond to the exception. If you are using subflows and the
subflow does not handle an exception, the exception is returned to the script and the script
can respond to it.
Set
Use the Set step to change the value of a variable. The Set step supports type casting
(with possible loss of precision) from any Number data type (Integer, Float, Long, Double,
BigInteger, BigDecimal) to any other Number data type. You can also use the Set step to
convert a String variable to any Number data type. For String conversions, the system replaces
all * characters with a decimal point (.) before performing the conversion.
Start
The CUE AA Editor automatically adds the Start step when you create a new script by
choosing File > New. This step has no properties and does not require a customizer. It is not
shown in any palette.
Switch
Use the Switch step to cause the program logic to branch to one of a number of cases based on
the evaluation of a specified expression. A case is a method for providing script logic based on
the value of a variable at a point in time. You can assign one case for each value. The Switch
step lets you define any number of case output branches. You can then create separate script
logic for each branch.
The Switch step supports switching based on the following variables:
Integer: Comparison of integers
String: Comparison of string variables (case insensitive)
The type of switching is automatically determined by the type of the specified expression. If the
integer or string expression you specify for a case is equal to the global expression defined in
the Switch Expression field, the script executes the steps configured for that case output branch.
The Defaultbranch of the step allows you to handle cases in which none of the branches
matches the expression.
Time of Day
Use the Time of Day step to cause the script to branch to different connection branches
depending on the current time of day. When the CUE system clock indicates that the time of
day matches the time associated with a connection, the script executes any steps configured for
that output branch. Associate each output branch with a specified range of time. During run
time, if the current time falls out of the configured time range, the script follows the Restoutput
branch of the Time of Day step.
Is Holiday
Use to determine if the day is a defined holiday.
Business Hours
Use to determine if the time of day is within the defined open hours or closed hours.
CUE AA Editor:
User and Prompt Steps
Step
Description
User
Get User Info
Access user attributes.
Prompt
Create
Conditional
Prompt
Create one of two prompts based on the

evaluation of a Boolean expression.
Create Container
Prompt
Combine multiple prompts into a larger

prompt.
Create
Generated
Prompt
Create prompt phrases from intermediate

variables, e.g. number, currency, etc.
IPTX v2.05-13
Step Reference: User and Prompt Steps

The steps in the Userpalette of the CUE AA Editor provide designers with a way to retrieve
user attributes.
Get User Info
Use the Get User Info step to make user attributes available to the script.
The steps in the Promptpalette of the CUE AA Editor provide script designers with a way to
create intelligent prompts.
Create Conditional Prompt
Use the Create Conditional Prompt step to create a prompt based on the result of evaluating
a specified Boolean expression. The prompts that are passed are evaluated immediately as
prompt objects, but they are not resolved until the time of playback. This means that if the
values of any variables that are part of the expression change between the time that this prompt
was created and the time that the prompt is played back, the new value of the variable is used to
evaluate the conditional expression.
Create Container Prompt

Use the Create Container Prompt step to combine multiple prompts into one larger prompt.
You can create three types of container prompts:
Concatenated Prompt: Contains a list of prompt phrases that are played back in a specific
sequence.
Escalating Prompt: Provides an initial question prompt with a minimal amount of
information at first, then adds additional prompt phrases if no response is given. For
example, for a prompt that provides the caller with more information as needed, you can
create an escalating prompt that when passed to a media step such as the Get Digit String
step begins by playing the first concise prompt inside the escalating prompt, such as What
is your account number? If the step fails to collect the account number because of the
callers failure to provide it, a second prompt plays, such as Please provide your account
number by entering the account number using your Touch-Tone phone followed by the
pound key.
Random Prompt: Plays back a series of promotional or informational messages in a
random order while a caller is waiting for an available agent.
Create Generated Prompt
Use the Create Generated Prompt step to create prompt phrases from intermediate variables
whose values are dynamically determined based on run-time script information. For example,
you can create the prompt phrase of account balance is one hundred and sixty-eight dollars
by querying the database of account balances at a particular point in the script and using a
currency generator to generate the number.
CUE AA Editor:
Contact and Call Contact Steps
Step
Contact
Call
Contact
Description
Accept
Answer a call.
Get Contact Info
Extract information from a contact and

store it in script variables.
Set Contact Info
Modify the context information associated

with a contact.
Terminate
Disconnect a call.
Call Redirect
Redirect a call to another extension.
Get Call Contact

Info
Access call-specific information and

store it in script variables.
IPTX v2.05-14
Step Reference: Contact and Call Contact Steps

The steps in the Contactpalette of the CUE AA Editor provide designers with a way to control
contacts. A contact represents a specific interaction with a customer. For CUE, the contact type
is a telephone call.
Accept
Use the Accept step to accept a particular contact. After the Start step, the Accept step is
normally the first step in a CUE script, triggered by an incoming contact. The caller hears
ringing until the script reaches this step.
Get Contact Info
Use the Get Contact Info step to extract information from a particular type of object and
store it in script variables so that this contact information is available to subsequent steps in
the script.
Set Contact Info
Use the Set Contact Info step to modify the context information associated with a contact. The
Set Contact Info step often follows a Redirect step in the script to mark the contact as
Handled. A contact can be marked Handled only while it is active. After a contact becomes
inactive (such as after a successful transfer), the script has a maximum of 5 seconds to mark the
contact as Handled.
Note
You cannot mark a contact as unhandled. After a contact is reported as Handled, it is always
reported with that status.
Terminate
Use the Terminate step to disconnect the call.
The steps in the Call Contact palette of the CUE AA Editor provide script designers with a way
to manage calls.
Call Redirect
Use the Call Redirect step to redirect a call to another extension. The Call Redirect step is
often used in applications to transfer a call after a desired extension has been specified.
The Call Redirect step produces four output branches:
Successful: The call is ringing at the specified extension.
Busy: The specified extension is busy and the call cannot be transferred.
Invalid:The specified extension does not exist.
Unsuccessful:The redirect step fails internally.
Configure script steps after each of the four branches to handle the possible outcomes of a
redirected call.
Get Call Contact Info
Use the Get Call Contact Info step to access call-specific information and to store values in
specified variables. You can use this step to handle a call in a variety of ways depending on the
source of the call and other properties associated with the session. For example, you can use
this step with the Call Redirect step to transfer a call to another extension, or you can use this
step with the Play Prompt step to play a voice prompt.
CUE AA Editor: Media Steps
Step
Description
Explicit Confirmation
Confirm an explicit response to a prompts, DTMF 1 for

yes and 2 for no.
Get Digit String
Collect DTMF digits in response to a prompt.
Implicit Confirmation
Confirm an action without asking a question.
Menu
Provide a menu from which caller can choose a series

of options.
Name To User
Collect DTMF and try to match it to a person s name.
Play Prompt
Play a specified prompt to the caller.
IPTX v2.05-15
Step Reference: Media Steps

The steps in the Mediapalette of the CUE AA Editor provide script designers with a way to
process media interactions with callers. Media interactions can include playing prompts and
acquiring dual tone multifrequency (DTMF) input.
Explicit Confirmation
Use the Explicit Confirmation step to confirm an explicit response to a prompt. The Explicit
Confirmation step is defined with a default grammar that accepts 1 for yes and 2 for no.
Get Digit String
Use the Get Digit String step to capture a DTMF digit string from the caller in response to a
prompt. The Get Digit String step waits for input until the caller does one of the following:
Presses the terminating key (DTMF only)
Exhausts the maximum number of retries
Enters the maximum number of keys (DTMF only)
Does not respond before the timeout length is reached
Implicit Confirmation
Use the Implicit Confirmation step to confirm an action without having to ask a question. A
prompt explaining the action to be taken is played back and the system waits a configured
number of seconds for input from the caller. If the caller presses any DTMF digits before the
configured timeout, the confirmation is considered to have failed, and an Explicit
Confirmation step should be used.
Menu
Use the Menu step to provide a menu from which callers can choose a series of options. The
Menu step receives a single digit entered by a caller and maps this entry to a series of option
output branches. The system executes the steps that you add after each of these option output
branches.
Name To User
The Name To User step is typically used to prompt a caller for the name of the person being
called (using DTMF), then to compare the name entered by the caller with names stored in a
directory. The Name To User step is often used in a script to automatically transfer a caller to
the extension of the person being called.
Another useful function of the Name To User step is to assign a value to a variable that can
later be queried using the Get User Info step to retrieve information such as the extension,
e-mail address, and spoken name of the user selected by the caller.
Play Prompt
Use the Play Prompt step to play back specified prompts to the caller.
CUE AA Editor:
Validate
When done
constructing the
script with steps:
Save the script with an

.aef extension.
Validate the script by
using the Tools >
Validate command.
Upload the Script to
CUE through the GUI
or CLI.
IPTX v2.05-16
Validate the Script

When programming on the script is complete, the next step is to validate the script. From the
Tools drop-down menu, choose Validate. If there are no problems, a message states that the
validation succeeded. If any errors exist, a message appears in the Debug window indicating
the problem. If you double-click this message, the step that has the problem will be highlighted.
Note
Validating checks for construction errors; it does not verify the logic of the script.
The next step after validation is to save the script with an .aef extension, then upload the script
through the administrator GUI web pages.
Note
Failure to validate the script can result in an invalid script being uploaded to the CUE
module, and this script will not be usable.
Holiday List
This topic describes how to define holidays.
Holiday List
Three years of holidays can be configured:
Moving window of the previous, current, and upcoming
year
Up to 26 holidays per year
In the GUI or the CLI, add a holiday by entering a date and an
optional description to identify the holiday.
Holidays can be copied from the current year to the next year
in the GUI.
Holiday lists can be used for Auto Attendant functionality
only.
The system and custom Auto Attendants can use the holiday
lists to branch to special menu items or prompts on these
dates.
IPTX v2.05-17
CUE permits configuration of a holiday list that causes the Auto Attendant to play a
customizable greeting to callers when the company is closed for a holiday. When a caller
reaches the Auto Attendant, the Auto Attendant plays the welcome prompt and checks to see if
the current day is a holiday. If it is a holiday, the Auto Attendant plays the holiday prompt to
the caller.
In the system Auto Attendant script provided with the CUE package, this prompt is called
AAHolidayPrompt.wav and by default says, We are closed today. Please call back later. You
can customize this prompt by recording a more meaningful message, such as We are closed
today for a holiday. If this is an emergency, please call 222 555-0150 for assistance. Otherwise,
please call back later.
By default, no holidays are configured on the CUE system. Up to three holiday lists the
previous year, the current year, and the upcoming year may be configured. If a year has no
configured entries, the system treats that year as having no holidays. Each of these years may
have a maximum of 26 holidays configured. This configuration may be done from either the
GUI or the CLI.
Holiday List (Cont.)

Current and upcoming year:
Holiday list can be added, modified, and deleted
Previous year:
System saves the holiday list, but cannot add or modify; can
only delete
On New Years Day every year, the following

automatically happens:
Current years holiday list becomes previous years list
Upcoming years list becomes current years list
Oldest years list is deleted (e.g., holidays for 2003 are
automatically deleted on January 1, 2005)
IPTX v2.05-18
The administrator can delete entries from a previous years list but cannot add or modify that
list in any other way. The system automatically deletes the previous years list when the list is
more than one year old. For example, the system will delete the 2004 holiday list on January 1, 2006.
Three years of holidays
Each holiday date and

description listed
IPTX v2.05-19
To add a holiday, choose the Holiday Settings object from the Voice Mail drop-down menu,
then choose the Add link.
IPTX v2.05-20
Choose Add and select the date of the holiday that is being added to the year. Choose Add to
commit the changes.
Holiday List CLI Configuration
- -
Sets a holiday day, month, and year
-
-
-
-
-
-
-
-
-
Use the command calendar holiday to configure holidays.
-
-
-
-

--

--
IPTX v2.05-21
Example: Holiday List CLI
Displays configured holidays

-
-

-
--

--
IPTX v2.05-22
From the IOS router CLI, use the show calendar holiday command to display the
configured holidays.
Business Hours Schedule
This topic describes how to define the business hours.
Business Hours Schedule

Configure a business schedule for each of the
seven days in a week.
The 24 hours in each day are divided into half-hour time

slots.
Each time slot can be marked as open or closed (use
in either the GUI or the CLI).
There can be up to four different schedules per

system.
One example schedule ships with the system
(systemschedule).
By default, the schedule is set to open seven days a

week and 24 hours a day.
This system schedule is modifiable and can be deleted.
System Auto Attendant by default refers to the default
schedule.
IPTX v2.05-23
CUE permits configuration of business hours that will cause the Auto Attendant to play a
customizable greeting to callers during off-hours. The system administrator can configure a
business hours schedule with the following properties:
Up to four business schedules may be configured.
Each 24-hour day is divided into half-hour time slots.
The system default is open for 24 hours each day.
The configuration can be done from the GUI or the CLI.
Use the GUI to copy one business schedule to another schedule, which can then be
modified.
Business Hours Schedule (Cont.)

Business schedules can be used for Auto
Attendant functionality only
The system and custom Auto Attendants can use
any of the four schedules to branch to special
menu items and prompts based on the time of day.
System Auto Attendant: Contains a schedule
script parameter that can be changed
Custom Auto Attendant: Uses the Business
Hours script from the CUE AA Editor
IPTX v2.05-24
When a caller reaches the Auto Attendant, the Auto Attendant plays the welcome prompt and
checks if the current day is a holiday. If it is a holiday, the Auto Attendant plays the holiday
greeting to the caller and does not check the business hours schedule.
If the current day is not a holiday, the system checks if the business is open. If it is, the business
open prompt plays. In the system Auto Attendant, this prompt (AABusinessOpen.wav) is
empty. If the business is closed, the system plays the business closed prompt. In the system
Auto Attendant, this prompt (AABusinessClosed.wav) plays We are currently closed. Please
call back later.
IPTX v2.05-25
The CUE system ships with one default schedule, called SystemSchedule. This schedule
treats the business as open 24 hours per day, seven days per week. Use the GUI option
Voice Mail > Business Hours Settings or CLI commands to modify or delete this schedule.
To construct a new business schedule, choose Add and give the schedule a name, and
optionally, use an existing business schedule as a template.
IPTX v2.05-26
On the new schedule, select the half-hour increments to set the system to determine the open or
closed hours of the day.
Business Hours Schedule CLI

Configuration
- -
Specifies the name for business hours schedule and

enters the business configuration mode
---
Sets the day and time that the business is open

---
Sets the day and time that the business is closed

IPTX v2.05-27
At the CLI, use the command calendar biz-schedule to define or enter the configuration of a
definable schedule. After you are in the business subconfiguration mode, enter the open and
closed times using the openclosed command, respectively. When using either the open or
closed command, the day of the week must be specified by entering a numeric value. The
following are the available numeric values and their meaning:
1 Sunday
2 Monday
3 Tuesday
4 Wednesday
5 Thursday
6 Friday
7 Saturday
The range of time also needs to be specified. This is done by entering a 24-hour time value in
the hh:mm format.
Note
Valid time of day values may have an mm value of either :00 or :30.
Example: Business Hours Schedule CLI

- -
- -
--- -
--- -
--- -
--- -
--- -
--- -
--- -
--- -
--- -
--- -
--- -
--- -
--- -
---
IPTX v2.05-28
This example shows a business hour schedule named summerSchedule.
Business Hours Schedule show Command
- -
Displays the configured business hours schedule(s)

- -
---

-
-
-

IPTX v2.05-29
Use the command show calendar biz-schedule to display the configured business schedules.
Scripts and Prompts
This topic describes scripts and prompts.
Scripts and Prompts Overview

CUE Auto Attendant Admin allows the following:
Add or delete a nonsystem script from the GUI or the CLI
Add or delete prompts from the GUI, the CLI, and the TUI
CUE Auto Attendant Admin does not allow viewing

of script contents.
This is done off-line via the CUE AA Editor.
The system automated attendant, the TUI, and

other system scripts are not able to be
downloaded, viewed, or edited.
IPTX v2.05-30
Both custom scripts and custom prompts must be uploaded to the CUE module for them to
function. This may be done through either the GUI or the CLI of the CUE module. In addition
prompts may also be recorded from the TUI of the IP Phone. The CUE module has some
default scripts and a default welcome prompt. The default scripts may not be modified, deleted,
or viewed.
Note
To view the logic of a custom script, use the CUE AA Editor.
Scripts and Prompts

A number of default scripts exist
in the system, including:
aa.aef -The system automated

attendant
aasimple.aef -A simplified automated
attendant to state a small number
of names
checkaltgreet.aef -The script that plays
the EAG before the system automated
attendant
promptmgmt.aef -The script that
controls the PMS
setmwi.aef -The script that controls
MWI
voicebrowser.aef -The script that
controls voice mail interaction
xfermailbox.aef The script used to
transfer a caller to a mailbox
IPTX v2.05-31
This figure shows the system scripts that are present after the installation of CUE. These
scripts are used by the system to perform system functions and include the following seven
default scripts:
aa.aef: the system automated attendant that plays by default
aasimple.aef: a simplified automated attendant to handle alternate, holiday, and business
hour greetings
checkaltgreet.aef: a subflow that checks for the existence of the AltGreeting.wav and
plays it if present; can be invoked by custom scripts
promptmgmt.aef: used by the TUI when it is called
setmwi.aef: used by the system to set the Message Waiting Indicator (MWI) lights on or off
voicebrowser.aef: the script that is used when voice mail is called
xfermailbox.aef: the script that is used to transfer a caller to a mailbox
Scripts and Prompts (Cont.)

Four custom scripts have
been uploaded.
The system scripts cannot
be downloaded, modified,
or deleted.
IPTX v2.05-32
System scripts cannot be deleted or downloaded. Therefore, they are grayed out. Scripts that are
not grayed out are custom scripts that can be deleted or downloaded.
Scripts show Command
- --
Shows the name, date, and size of the scripts that

are installed
- --

-
-
-

-
-

-
-
IPTX v2.05-33
The command show ccn scripts shows the scripts that are currently uploaded to the CUE
system. Also displayed is the date the scripts were created and modified, along with their size.
Example
This shows the default scripts that are on a CUE system after installation.
- --
Name:
xfermailbox.aef
Create Date: Sun Oct 31 06:57:47 PST 2004

Last Modified Date: Sun Oct 31 12:57:47 PST 2004
Length in Bytes: 5599
Name:
setmwi.aef

Name:
voicebrowser.aef

Name:
aa.aef

Name:
promptmgmt.aef

Name:
checkaltgreet.aef

Name:
aasimple

Prompts
Five prompts exist by default.

IPTX v2.05-34
This figure shows the five system default prompts.
Custom Prompts
The bottom four prompts are custom prompts.

IPTX v2.05-35
This figure shows that there have been three prompts uploaded to the CUE system from the
GUI or the CLI and one created through the TUI. The prompt created through the TUI has a
name that includes the time when the prompt was recorded. For example, if the name of the file
is UserPrompt_06252004192506.wav, the name of the file contains the date and time of June
25, 2004, at 7:25:06 p.m.
Scripts and Prompts
Uploaded prompts may be selected from

a drop-down list or uploaded from this
page
1-MB file size limit on any prompt
Maximum of 50 prompts on an NM-CUE;
maximum of 25 prompts on an AIM-CUE
No error checking on file format
during upload
Format for file must be .wav:
G.711 mu-law, 8 kHz, 8 bit, Mono
IPTX v2.05-36
In this figure, the parameters of a new application are being modified through the administrator
GUI web pages. In this case, the AAWelcome.wav prompt is being replaced with a new prompt
that is being uploaded from the administrator PC.
When custom prompts are recorded, the file format requires the following:
1-MB file size limit on any prompt
Maximum of 50 prompts on an NM-CUE
Maximum of 25 prompts on an AIM-CUE
No error checking on file format during upload
Format for file must be .wav
G.711 mu-law
8 kHz
8 bit, Mono
Note
The system does not verify that the prompt is formatted correctly.
Scripts and Prompts Configuration
Allows a prompt to be uploaded to the CUE system

-
IPTX v2.05-37
The command ccn copy url source destination can be used to either upload or download scripts
and prompts to or from the CUE system.
Example
Uploading a prompt called test.wav as newAA.wav to the CUE system:
-
- -
Name:
newAA.wav
Last Modified Date: Fri Mar 08 07:40:53 PST 2004

Scripts and Prompts Configuration (Cont.)
- -
Shows the name, date, and size of the prompts that

are installed
-
-
-
-
-
-
IPTX v2.05-38
The command show ccn prompts displays the prompts that reside on the CUE system.
Example
This shows the system default prompt of AAWelcome.wav and a prompt recorded through the
AVT called UserPrompt_030820040161012.wav.
- -
Name:
AAWelcome.wav
Last Modified Date: Fri Feb 20 03:11:37 PST 2004

Name:
UserPrompt_03082004061012.wav
Last Modified Date: Fri Mar 08 06:10:12 PST 2002

Scripts and Prompts: Changing Filenames

Prompt filenames can be changed on the CUE
system itself
ccn rename prompt command
Procedure to change a prompt file name:

Download prompt file to PC
Change filename on PC, e.g.:
UserPrompt_08182003132334.wav to StoreHours.wav
Upload new prompt file to CUE system
Change script parameter to refer to new prompt
(StoreHours.wav)
Delete old prompt (UserPrompt_08182003132334.wav)
IPTX v2.05-39
Prompt names cannot be changed through the GUI or the CLI. In order to change a prompt
name, the following procedure must be followed:
Download the prompt to a PC using either the GUI or the CLI.
Change the filename on the PC.
Upload the prompt back to CUE.
Change any parameters in applications to point to the new name.
Delete the old prompt.
Example #1
The prompt UserPrompt_03082004061012.wav was created throught the AVT and the
administrator wishes to change the name.
-
-
Example #2
The prompt UserPrompt_03082004061012.wav was created in the TUI and the administrator
wishes to change the name.
Step 1
Get the file name.
-
-
Step 2
Copy the prompt to a PC or server through the GUI or the CLI.

-
-
Step 3
Upload the CustomAAWelcomePrompt.wav file to the CUE system through the

GUI or CLI.
-
-
Step 4
Update any references to the old prompt name with the new prompt name through
either the GUI or the CLI.
-

-
Step 5
Delete the copy of the prompt with the old name.

-
Setting Up an Automated Attendant
This topic describes the steps required to set up an automated attendant.
Setting Up an Automated Attendant
A single automated attendant application exists: the

system default automated attendant
IPTX v2.05-40
There is a system default automated attendant installed on the CUE module. Although this may
not meet the needs of many installations, it does provide basic automated attendant functions. If
the default automated attendant does not meet the needs of the installation, creation of a custom
automated attendant is required.
Setting Up an Automated Attendant (Cont.)

Play Welcome Prompt (AAWelcome.wav by default)
To enter the phone number of the person you are
trying to reach, press 1.
To enter the name of the person you are trying to
reach, press 2.
To transfer to the operator, press 0.
1: Dial by number
2: Dial by name
0: Transfers to the operator extension configured on the system
Welcome Prompt is a .wav file that can be replaced with any
recorded content
IPTX v2.05-41
The automated attendant system that comes with the CUE installation uses the same prompts as
the CUE product. The system default is to play a file called AAWelcome.wav that contains a
verbal menu that presents the following options:
Press 1 to dial by number.
Press 2 to dial by name.
Press 0 to connect to the operator.
Note
If the EAG is enabled, it is played prior to the AAWelcome.wav file.
The AAWelcome.wav file can be changed to use a different greeting wave file. However, the
menu options cannot be changed in the system script. If different options are desired, a custom
script must be constructed.
Shows the applications and how they are configured

-
----
-
--
--
---
---
----
-
---
IPTX v2.05-42
The command show ccn application displays the applications that are active on the
CUE system.
Example
This shows the default applications after the installation of CUE.
-
Name:
ciscomwiapplication
Description:
Script:
setmwi.aef
ID number:
Enabled:
ciscomwiapplication
0
yes
Maximum number of sessions: 8

strMWI_OFF_DN: 2997
strMWI_ON_DN: 2998
CallControlGroupID: 0
Name:
voicemail
Description:
Script:
voicebrowser.aef
ID number:
Enabled:
voicemail
1
yes

logoutUri: http://localhost/voicemail/vxmlscripts/mbxLogout.jsp
uri:
http://localhost/voicemail/vxmlscripts/login.vxml
Name:
autoattendant
Description:
Script:
autoattendant
aa.aef
ID number:
Enabled:
yes

busOpenPrompt AABusinessOpen.wav
holidayPrompt
AAHolidayPrompt.wav
busClosedPrompt AABusinessClosed.wav
allowExternalTransfers false
MaxRetry:
operExtn:
2001
welcomePrompt: AAWelcome.wav
businessSchedule systemschedule
Name:
promptmgmt
Description:
Script:
promptmgmt.aef
ID number:
Enabled:
promptmgmt
3
yes

Custom
Automated
Attendant
Five automated attendant applications have been

defined: four custom and the system default
IPTX v2.05-43
To view an application, choose Voice Mail > Auto Attendant. A list of the installed
automated attendants appears. In the figure, there are five automated attendants configured.
One of the five is the system default, which may be changed to use a nondefault script. Four of
the five automated attendants are custom and have been previously configured.
To configure custom automated attendants, perform the following steps in the series of
windows that appear after adding a new automated attendant:
Step 1
Choose the script and language and assign a name.
Step 2
Set any script variables.
Step 3
Assign the call-in number, language and maximum allowed sessions.

Add a new automated
attendant by clicking
the Add link
Step 1 of 3: Select the script, and language and assign a name

IPTX v2.05-44
To add an application, choose Voice Mail > Auto Attendant. A list of the installed automated
attendants appears. Click the Add link to open the Add a New Automated Attendant window.
The first configuration page appears and allows a previously uploaded script to be associated
with this new application. In addition, on this page a language other than the system default can
be configured and a name can be assigned that will be used for the new application. When
completed, click Next.
Step 2 of 3: Set any script variables

Script variables with the parameter option set will appear in the GUI.
Default values were assigned when the script was created and maybe
overridden in the GUI.
Prompts used by the script may be uploaded from this page or assigned
from a drop-down list.
IPTX v2.05-45
The second configuration page appears and allows the administrator to set any variables that
have the parameter option selected in the script. If the variable was defined to be a prompt type,
then the Upload button appears to the right of the field along with a drop-down menu that
displays the uploaded prompts currently in the system. Other types of variables accept other
types of data as appropriate.
Although the use of variables is not mandatory, the use of variables with the parameter setting
allows customization of the scripts from the GUI or the CLI without using the CUE AA Editor.
The proper use of variables in construction of the script greatly enhances the power and
flexibility of custom scripts. It also makes administration easier whenever a change is needed
by eliminating the need to open a script in the CUE AA Editor, then reupload it.
Note
In most instances, the recorded prompt should accurately reflect the options available in the
menu unless hidden options are desired.
Step 3 of 3: Assign the call-in number, language, and maximum allowed

sessions
Set the language and maximum sessions allowed.
The automated attendant script may be enabled or disabled .
Calls to the call-in number will invoke the automated attendant.
If the call is delivered by the PSTN, it may require digit manipulation by
the gateway before terminating on the automated attendant.
IPTX v2.05-46
The final configuration page is where the phone number that maps to this automated attendant
is defined. This number should be set to what is delivered to CUE because digit manipulation
may happen on the Cisco CallManager Express router. The maximum number of sessions on
which this automated attendant can be simultaneously playing can also be defined. This does
not dedicate ports; it only sets an upper limit to the number of ports that can be in use by this
automated attendant at any one time.
Note
The Cisco recommendation is to configure all ports in one pool and allow both voice mail
and the automated attendant to use any free port in the pool. This is configured by leaving
the maximum sessions at the default setting.
The automated attendant can also be enabled or disabled at this point. Up to five automated
attendants can be enabled at any one time in the CUE system. When the configuration on this
page is complete, click Finish.
Note
The number of maximum sessions possible is solely dependent upon the hardware
platforms and is not a licensed feature.

-

----

----
Calls to 6700 will invoke the Auto Attendant application.

If a PSTN number is to invoke the Auto Attendant application,
digit manipulation by the gateway may be required.
IPTX v2.05-47
The show ccn trigger command allows the display of the entry point and the automated
attendant associated with it from the CLI. Note that in this graphic, when CUE receives a call to
the number 6700, the system activates the automated attendant. Up to five sessions at one time
may be used in this example.
Assigns a phone number to act as a trigger and

enters trigger configuration mode
Assigns an application to a trigger

-

IPTX v2.05-48
To configure an automated attendant from the CLI, the administrator uses the ccn trigger sip
phonenumber number command from the global configuration mode to enter the trigger
subconfiguration mode. From the trigger subconfiguration mode, the desired application can
then be defined with the application application_name command.
Note
Multiple triggers can be defined to point to the same application if desired, but this can only
be done from the CLI.
Example
This example shows the configuration of phone number 6900 to the automated attendant
application.
CUE#configure terminal
CUE(config)#ccn trigger sip phonenumber 6900
CUE(config-trigger)#application AutoAttendant

-
--

Both numbers invoke the application named

AutoAttendant
Delete the old number if desired
IPTX v2.05-49
After the new trigger has been created, the administrator may wish to remove the old trigger.
To delete a trigger, use the no version of the ccn trigger sip phonenumber number command.
This deletes the trigger and any configuration underneath it in trigger subconfiguration mode.
Example
This shows the deletion of the pilot number 6700.
-
Name: 6700
Type: SIP
Application: AutoAttendant
Locale: en_US
Idle Timeout: 5000
Name 6900
Type: SIP
Locale: en_US
Idle Timeout: 5000
-
-
Name: 6900
Type: SIP
Locale: en_US
Idle Timeout: 5000

-
----
-
---
------
---
------
The aa.aef script is associated with the application autoattendant.

The script is currently enabled.
The maximum number of session has been set to 5.
The MaxRetry variable has been set to 3.
The operExtn variable has been set to 2001.
The welcomePromptvariable is set to AAWelcome.wav.
IPTX v2.05-50
In this example, the automated attendant application has three variables with the parameters
option selected. These variables may then be defined through either the GUI or the CLI without
using the CUE AA Editor.
Example
-
Name:
autoattendant
Description:
Script:
autoattendant
aa.aef
ID number:
Enabled:
yes

MaxRetry:
operExtn:
3
2001
The eight variables that can be modified in example script are:
busOpenPrompt
holidayPrompt
busClosedPrompt
allowExternalTransfers
MaxRetry
operExtn
welcomePrompt
businessSchedule
All entries that come after Maximum number of sessions are custom parameters.

-
-

---- ----- -

- -
-
Application setting may be set from the CLI or the GUI.
IPTX v2.05-51
The names of the parameters can be obtained by using the show ccn application command.
Then, after entering the application subconfiguration mode by using the ccn application
application_name command, the parameters can be set. The command to set the parameters is
parameters parameter_name parameter_value.
Example
This example shows setting a parameter from the CLI for the automated attendant application.
-
Name:
autoattendant
Description:
Script:
autoattendant
aa.aef
ID number:
Enabled:
2
yes

MaxRetry:
operExtn:
3
2000
welcomePrompt:
AAWelcome.wav
-
Name:
autoattendant
Description:
Script:
autoattendant
aa.aef
ID number:
Enabled:
yes

MaxRetry:
operExtn:
5
2000
Application setting
and parameters
may be set from
the GUI or the CLI.
Names are case
sensitive.
IPTX v2.05-52
This figure compares equivalent ways of configuring the parameters of an application from the
administrator GUI web page and from the CLI.
Note
When using the CLI, use the show ccn application command to view the parameter
names. Remember that case does matter.
Case Study
Case Study
The ACME company has just purchased Cisco
CallManager Express and CUE for a branch office.
Management wants the automated attendant to
answer the phone and present the caller with a
custom greeting: Welcome to ACME. Please press 1
if you know your partys extension. Please press 2 to
enter the name of the party you wish to reach and 3
to talk to a sales representative. ACME also wishes
to have hidden options of 9 to reach internal
technical support and 0 to reach the operator.
What tasks need to be completed in order to
implement this design?
IPTX v2.05-53
Case Study
The ACME Company has just purchased Cisco CallManager Express and CUE for a branch
office. Management wants local calls to the branch office to go to an automated attendant that
will present the caller with the custom greeting Welcome to ACME. Please press 1 if you
know your partys extension. Please press 2 to enter the name of the party you wish to reach,
and press 3 to talk to a sales representative. ACME also wishes to have hidden options of 9 to
reach internal technical support and 0 to reach the operator. What tasks must be completed to
implement this design?
Case Study (Cont.)

Step 1: Is the system default sufficient?
No, the requirements state that the 3 and the 9 must
be active on the menu, and the aa.aef cannot be
modified or even downloaded.
IPTX v2.05-54
The first question that you should ask is: Does the automated attendant system default support
the needs of ACME?
In this case, menu options of 3 and 9 are needed in addition to the system options of 1, 2, and 0.
Because you cannot download or modify the menu of the aa.aef script that is used by the
automated attendant application, you cannot use this prebuilt application.
Case Study (Cont.)

Step 2: Construct a
customized script in
the CUE AA Editor.
Validate and save
the script as
MyCustomAA.aef.
The instructor will
demonstrate the creation
of an automated
attendant script.
IPTX v2.05-55
A custom application must be constructed for ACME. It will be built using the CUE AA Editor.
After you have built the application, you will validate, save, and upload the script to the CUE
system.
Note
A sample of this script is on the student CD.
Case Study (Cont.)

Step 3a: Upload the script to the CUE system.
IPTX v2.05-56
This figure shows the script being uploaded from the administrators PC, which is where it was
constructed. Remember that no validation is done at this point. The CUE system permits a
script that has not been validated to be uploaded.
Case Study (Cont.)

Step 3b: Script is successfully uploaded.
IPTX v2.05-57
This figure shows that the script casestudy.aef is now present on the CUE system.
Case Study (Cont.)

Step 4a: Add an
application.
IPTX v2.05-58
The next step is to add the application to the system. This is a three-step process. The first step
is shown in this slide. The script is assigned and given an application name. This name does
not have to match the script name, although it is common that it be configured to match. To
proceed to the next step, click Next.
Case Study (Cont.)

Step 4b: Add an application.
Set the variable values and prompts.

IPTX v2.05-59
Step 4b allows the administrator to set the variables of the script. In order for a variable to show
up on this page, it needs to have been marked with the parameter option in the CUE AA Editor
when it was constructed. Notice that some of the variables are prompts and some are extension
numbers in this example. Click Next to continue to the final page.
Case Study (Cont.)

Step 4c: Add an application.
Set the pilot number for the application.

Set the language.
Set the maximum sessions.
Enable the application.
IPTX v2.05-60
In Step 4c, the phone number and the number of allowed sessions are set. The script could be
disabled if desired, but is enabled by default. Choose Finish to complete the addition of an
application to CUE.
Case Study (Cont.)

Step 5: Test the application by dialing the number;
remember to test the failure and problem paths in the
script.
Dial 2500 and test the
application called
casestudy.
IPTX v2.05-61
The last step in this case study would be to test the application by calling the number that was
defined when you set up the application. Remember to test not only a successful call, but also
the failure and problem paths through the script.
Emergency Alternate Greeting

This topic describes the EAG.
Emergency Alternate Greeting Overview

The EAG can be activated and deactivated:
Via the TUI

Via the GUI (based on the existence or absence of the prompt file named
AltGreeting.wav)
The EAG is recorded via the TUI or off-line and uploaded into
the system.
If uploaded, it must have the filename AltGreeting.wav
If active, the EAG is played before the welcome greeting of

the system automated attendant.
If the EAG is desired by custom automated attendant scripts,
a call to a subflow to checkaltgreet.aefmust be inserted in
the script at the desired location.
If the EAG is deactivated via the TUI, the current prompt
(AltGreeting.wav) is deleted.
If the EAG is activated via the TUI, the recorded prompt is
stored as AltGreeting.wav.
IPTX v2.05-62
The EAG allows an administrator to record and turn on a message that plays at the beginning
of an automated attendant. This is useful in situations where the default automated attendant
greeting does not give the caller pertinent information that may be desired. For example, if a
business closed unexpectedly because of heavy snow, the administrator can put a message at
the beginning of the automated attendant that informs the caller that the business is closed
today. When the emergency is over, the message can be deactivated and deleted by using the
AVT.
The aa.aef script, which is the default automated attendant in CUE, has a call subflow step that
uses checkaltgreet.aef to check for the existence of a prompt called AltGreeting.wav. If an
alternate greeting wave file is found, the subflow plays the alternate greeting at the start of the
script. This EAG is usually recorded via the AVT. It is possible to record the greeting off-line
and upload it to the CUE system. However, it must be named AltGreeting.wav for this to
function properly.
For custom scripts, program a call subflow to the checkaltgreet.aef script and place it in the
script where you want the alternate greeting to be heard. The checkaltgreet.aef cannot be
downloaded or changed, only called upon.
The EAG can be recorded, activated, or deactivated from the TUI. Simply dial the TUI number,
enter an administrator extension and PIN, then follow the prompts.
Configuring Cisco Unity Express

Automated Attendant and Voice Mail

IPTX v2.05-1
Administration via TUI
This topic describes administration via the TUI.
Administration via TUI Overview

Recording and Listening
TUI or an offline system, then uploaded to CUE
Format
G.711 mu-law, 8 kHz, 8 bit, Mono
CUE Administrator GUI
View list of prompts on the system

Upload or download prompts
Assign prompts to automated attendant script parameters
TUI Access
Extension and PIN required; administrator privileges

Entry point phone number defined for TUI
System script menu associated with TUI
Call into the TUI number (from IP Phone or PSTN) script walks caller
through managing and recording prompts
Prompts saved with a unique filename: UserPrompt_DateTime.wav, e.g.,
UserPrompt_08182003132334.wav
IPTX v2.05-63
The AVT can be used for recording prompts to use in custom scripts and the default automated
attendant script. To use the TUI for this, the caller must have administrator privileges to log in.
This login is accomplished by entering an extension number and PIN when prompted. In the
TUI, prompts can be recorded, reviewed, and deleted as desired.
When a prompt is created through the TUI, it is given a name that cannot be changed while it is
on the CUE system. The naming convention that is used will have UserPrompt_ with a large
number representing the date and time appended after the underscore. The only way to change
this name is to download the prompt to another machine, change the name, upload it back to
CUE, then delete the original.
Prompts may also be uploaded, downloaded, assigned to variables, deleted, and managed from
the GUI and the CLI.
Note
All prompts need to be recorded in G.711 mu-law, 8 kHz, 8 bits, and in Mono.


IPTX v2.05-1
The figure shows what will be heard by the Administrator when using the AVT. The portion of
the slide in red pertains to the recording prompts.
Note
Prompts cannot be rerecorded in one step. They must be deleted first, and then recorded
again.
Summary
Summary
The automated attendant on CUE has system defaults, but
these can be customized.
The CUEAA Editor is the interface that is used to create a
custom automated attendant.
To install a custom automated attendant, validate, save,
and upload the .aef file.
Use either the GUI or the CLI to upload the script.
The GUI or the CLI can be used to upload and manage
prompts.
Either the GUI or the CLI is used to associate the script
with an application and set application parameters.
The GUI or the CLI can be used to view the configuration.
IPTX v2.05-64
Lesson 4

Express Users and Groups
Overview
This lesson defines how users interact with the Cisco Unity Express (CUE) system and how the
administrator configures those users and groups.
Objectives
Upon completing this lesson, you will be able to configure users and groups. This includes
being able to meet these objectives:
Describe user GUI and CLI interfaces
Perform the tasks for user configuration
Perform the tasks for group configuration
Perform the configuration tasks for group mailboxes
User Interface
This topic describes the user interface.
User Interface Concepts

A user is associated with a mailbox.
Each user can have at most one individual mailbox.
Each user can belong to multiple groups and therefore have
access to multiple General Delivery Mailboxes.
One attribute of the user is the primar1y extension.
The users primary extension as well as one alternate number
can be redirected to voice mail.
MWI behavior varies based on the line.

The MWI light on the top line of the Phone turns on and an
envelope icon on the display flashes.
Other extensions on lower buttons will have the flashing
envelope icon on the display but not the MWI light.
IPTX v2.05-2
In CUE, one of the basic concepts is that each user is associated with one and only one personal
mailbox. This mailbox is associated with the primary extension of the user, and only that line
can be redirected to voice mail. Only the top line of the Cisco IP Phone has the Message
Waiting Indicator (MWI) light function. Other lines on the Phone can have a flashing envelope
appear on the screen of the Phone when a message is present.
Number of Users
Total number of users allowed on the system
as of CUE version 2.1:
Currently two times the number of mailboxes
allowed in the license/package purchased; for
example, a 12-mailbox license CUE system allows
12 mailboxes and 24 users to be defined
A user without a mailbox still appears in the
corporate directory
IPTX v2.05-3
The current version of CUE allows the number of definable users to be up to twice the number
of licensed mailboxes on the system. This allows for users to be defined who do not have a
personal mailbox.
TUI Access
The MWI light is for the top
line appearance only.
The message button is a

speed dial to the TUI for the
voice mailbox.
The TUI can also be

accessed by dialing the
phone number of voice mail
directly.
IPTX v2.05-4
The user can interact with the CUE system by using the Telephony User Interface (TUI). The
TUI is a set of prompts that guide the user who has a personal mailbox through sending and
receiving voice mails as well as recording personal greetings. The TUI can be accessed by
dialing the number of the voice mail directly or by using the Messages or Envelope Icon button
on the IP Phone. The user becomes aware of a new voice mail message by noticing the MWI
light on the Phone.
TUI Operation
Subscriber TUI Functions
Subscriber and caller mailbox features
Caller automated attendant interaction
Administrator TUI Functions
Emergency Alternate Greeting
Greeting Management System
Subscriber TUI functions are not generally accessible via
the GUI or the CLI except for:
Resetting the mailbox PIN
Switching between the standard and alternate greeting
TUI voice mail prompts are the same as Unity 3.5 (ported).
IPTX v2.05-5
Users can manage their personal mailbox or interact with the CUE Auto Attendant using the
TUI. The administrator can manage the Emergency Alternate Greeting (EAG) and record
prompts using the administrator TUI.
GUI
Administrator vs. User
Administrator
End User
IPTX v2.05-6
The menu items that appear in the GUI vary based on the credentials that are entered to log in
to the web site. The administrator has full access over the system. Users have a subset of the
menu items that the administrator has. Users have the following options:
Configure > Phone: Users can view the Phone that is associated to them.
Configure > Users: Users can view and change some information about themselves and
view information about other users.
Configure > Groups: Users can view information about the configured groups.
Configure > My Profile: Users can view information about themselves and reset their
password and PIN.
Voice Mail > Mailboxes: Users can view their mailbox, set the zero out setting, choose
whether the tutorial runs, and choose whether to use the standard or alternate greeting.
Search > Local Directory Search: Users can view the directory of users.
Help > About: Users can view information about the CUE system.
Help > Configuration: This is the link to the online help file for CUE users.
GUI (Cont.)
A subscriber (FPrefect) logged in to the GUI can see

all other users that are configured in the system.
There is not a way to add a user as a subscriber.
IPTX v2.05-7
A subscriber can log in to the GUI and view a list of all other users.
Password and PIN Setting
Subscribers can change their language, password, and PIN through

the GUI.
A randomly generated PIN will appear to the right of the PIN field until the
subscriber changes the PIN through the GUI or the TUI.
A subscriber can view only limited information about another subscriber.
IPTX v2.05-8
Subscribers, when viewing themselves in the Configure > Users page, will be able to reset their
PIN and password. The PIN is used to log in to the TUI and can be changed on the Configure >
My Profile or the Configure > Users web page. Users can also change their PIN from the TUI.
The password is for access to the GUI and can be reset from the GUI only by the user or an
administrator. The password and PIN are not displayed in clear text to the administrator if the
user has changed the password and PIN at least one time. The password and PIN are displayed
to the right of the field if they were randomly generated by the system.
It is very simple for the administrator to reset a forgotten password or PIN. The administrator
simply logs in, chooses the Configure > Users menu, and selects the user. On the user profile
page, the administrator highlights the password, the PIN, or both and enters the new password
and PIN.
Note
The password and PIN cannot be seen by the administrator if the user has changed them at
least once. The administrator can only reset them to a known value.
User Configuration
This topic describes the user configuration.
User Configuration Overview

User configuration is done through one of three
methods:
Imported with the initialization wizard
Can be run only after a new installation
From the GUI by an administrator
Good for nontechnicaladministrator
From the CLI by the administrator
Good for the technical administrator
Useful for batching configuration
Usernames are case sensitive
IPTX v2.05-9
Configuring users can be done in one of three ways:

CUE initialization wizard
GUI after the initial setup
Command-line interface (CLI) by an administrator
The first way to configure users is during the initial setup of the CUE system, using the
initialization wizard. This method imports the existing users on the Cisco CallManager Express
system to be selected by the administrator for importation and mailbox creation.
An administrator can also configure users from the GUI . This method tends to be the method
preferred by the nontechnical administrator.
And finally, an administrator can configure users from the CLI. This method is used by the
more technically knowledgeable administrator. It can be very useful for backing up and
restoring the configuration, as well as batching installations and bulk changes.
Note
When creating users, remember that usernames and passwords are case sensitive.
Adding a User via the GUI
An administrator may add a new user by selecting

the Add link.
IPTX v2.05-10
To add a user, an administrator chooses the Configure > Users web page. The administrator
clicks the Add link, and the Add New User web page appears.
User Profile in the GUI

Define the following:
User ID *
First Name *
Last Name *
Nick Name *
Display Name *
Primary E.164 Number
Associated Phone
Primary Extension
Language
Password settings
PIN settings
Create Mailbox
Forward Setting
* Indicates a mandatory setting

IPTX v2.05-11
This example shows an administrator changing the settings of a user with a username of
ZBeetlebrox. The Phone with a MAC address of 1111.2222.3333 has been associated with this
user account. The primary extension on the Phone is 1002. The primary extension should
always be the top line on the IP Phone because this is the only line that can use the MWI light
when a new message is present in the mailbox. Other lines display a blinking envelope when a
new message is present.
Other settings may also be configured here, such as the first and last name of the user, the
E.164 number of the user, the password, and the PIN.
While on this page, it is possible to create a mailbox by checking the Create Mailbox check
box. If the mailbox is not created here, then it will have to be created manually and associated
with this user at a later time.
Note
The Nick Name field currently has no significance to the system. It will retain whatever is
entered.
Adding a User via the CLI

- -
Creates a user
- -- - -
Shows defined users

-
- -
IPTX v2.05-12
The command username username create is used to add a new user from the CLI.
User Profile Commands in the CLI
-
-
-
-
-
-
-
-
-
-
--

- -
- -
- -
--
Command to define or change user settings in

privilege EXEC mode
- -
- -
Command to define the phone numbers in global

configuration mode
IPTX v2.05-13
From the CLI, the administrator can enter the command username from either the privilege
EXEC mode or global configuration mode. The majority of the username commands are
entered in privilege EXEC mode. However, the username username phonenumber
phonenumber and the username username phonenumberE164 phonenumber commands are
entered in global configuration mode only.
Note
Notice that some commands are entered in privilege EXEC mode and some are entered in
global configuration mode.
User Password and PIN Setting
- - -- --
Sets a user password
- -
Sets a user PIN

- -- -
-
Note
The minimum PIN length is three digits.
IPTX v2.05-14
Example: User Profile

-
- -
- -
- -
- -- -
-

-
-
- - -

-
-
IPTX v2.05-15
The configuration of a user is displayed in this figure.

Example
The following shows a user named John Smith being configured:
-
- -
- -
- -
- -- -
-

-
-
- - -
Full Name: Mr. John Smith CEO

First Name: John
Last Name: Smith
Nickname: JSmith
Phone: 2002
Phone (E.164): 2065551234
Language: en_US
User with No Extension
JDoe has no defined extension and cannot receive voice mails.
IPTX v2.05-16
The act of creating a user does not necessarily associate the user with a Phone or extension.
Within the CUE system, twice as many users as licensed mailboxes can be configured. For
example, a consultant is an administrator of the system but does not have a voice mailbox
configured on the system.
Deleting a User via the GUI
Deleting a user and associated mailbox and voice mails

IPTX v2.05-17
To delete a user through the GUI, an administrator chooses the Configure > Users menu,
chooses the user to be deleted, then clicks the Delete link. This results not only in the deletion
of the credentials of the user but also in the deletion of the users mailbox and all of its
contents.
Caution
Deleted mailbox contents cannot be recovered without restoring the entire system and the
contents of all mailboxes.
Deleting a User via the CLI
- -
Deletes a user but not the voice mailbox

-
- -
IPTX v2.05-18
To delete a user via the CLI, use the username username delete command. However, this
deletes only the username and leaves the user mailbox and all its contents intact for seven days.
At the end of seven days the mailbox will be automatically deleted. Until the mailbox is
deleted, a user with the same name can be reassociated with the orphaned mailbox.
Note
This results in an orphaned mailbox. Use the no voicemail mailbox owner username
command to delete the orphaned mailbox sooner than its automatic deletion at the end of
seven days.
Password and PIN: System Defaults
The new user defaults can be set on this page by the administrator.
IPTX v2.05-19
Default settings can be defined for all newly created user accounts. To access the default
settings for user accounts, choose the Defaults > User menu and select the desired behavior.
Initial passwords and PINs can be randomly generated by the system or left blank. If created
randomly, the generated password and PINs are displayed after the user is created. The
administrator can print out or write down these settings. The administrator can also view these
in the GUI as long as the subscriber has not reset them. After the subscriber has changed the
password and PIN, the administrator cannot see the password or PIN but can reset these values.
Group Configuration
This topic describes group configuration.
Group Configuration Overview

Group names are case sensitive in the CLI.
To make a user an administrator, make the user a
member of the Administrators group.
The owner of a group can modify membership.
A member of a group has the access level of the group.
A group may have a shared mailbox that all members
can access.
A group can be part of another group.
The owner of a group is not, by default, also a member;
the owner has to be added as a member.
IPTX v2.05-20
A group is a collection of users, usually with a common function or purpose, such as sales,
main office, customer service, technicians, and so on. A group has the following characteristics:
Members of a group can be individual users and other groups.
A group is assigned an extension. If the members of a group are configured with the
extension as a shared line, then anyone who calls this extension reaches a member of the
group.
A group usually has a mailbox assigned to it. This mailbox is called a General Delivery
Mailbox (GDM). All members of the group can access the mailbox to retrieve messages
that are stored there.
At least one user must be designated as the owner of a group. The owner adds and deletes
users from the group. The owner is not usually a member of the group.
Members of one group may belong to other groups.
Members can be added to a group from the global configuration mode using the
groupname command or the username command.
Note
Users must exist before being added to a group.
Only members have access to the messages in a groups voice mailbox. The owner is not
automatically considered to be a member of the group. If the owner needs to access the group s
mailbox, add the owner as a member of the group. In that case, the owners name will appear
twice in the group: once as a member and once as the owner.
A group can be assigned a privilege level. The privilege level permits the members of the group
to access all or a restricted set of administrative functions. Use the show privileges command
to display the privilege levels installed on your system.
Adding a New Group via the GUI
IPTX v2.05-21
Groups may be configured from the GUI by choosing the Configure > Groups menu and
clicking the Add link on the page.
On the Add a New Group page, configure the following fields:
Group ID
Full Name
(Optional) Description
(Optional) Primary Extension, if this will have lines configured on Phones or voice mail
(Optional) Primary E.164 Number, if this will be called from the public switched telephone
network (PSTN)
(Optional) Create Mailbox, if a GDM for this group is desired
(Optional) Super Users, to allow any member of the group administrative privileges as well
as access to administration via telephone
(Optional) Administration via Telephone, to allow members of this group to use the basic
functions of administration via telephone
(Optional) Voice Mail Broadcaster, to allow any member of the group to broadcast
messages using administration via telephone
(Optional) Public List Manager, to allow any member of the group to create, delete, or edit
a public distribution list
(Optional) Private List Viewer, to allow any member of the group to view the private
distribution membership list


Express Users and Groups
IPTX v2.05-1
Adding a New Group via the CLI
Adds a new group and configures the group in CUE

-
-
-
- -
- -
-
-
IPTX v2.05-22
Use the groupname groupname commands to configure a group and its properties
from the CLI.
Example
- -
-
-
-
- -
- -
Full Name: Sales

Description:
Phone: 1800
Phone(E.164): 12065552800
Language: en_US
Owners:
Members:
Member Management via the GUI
Adding a user to a group from the Groups page

IPTX v2.05-23
To add a user to a group using the GUI, log on as an administrator or as the owner of the group
and choose Configure > Groups.Select the group, and on the Group Profile page, click the
Owners/Members tab.
Member Management via the GUI (Cont.)
Adding a user to a group from the Groups page (cont.)

IPTX v2.05-24
After clicking the Owners/Members tab, choose the Subscribemember or Subscribeowner

link, whichever is desired. The User Selection window appears. Select the user or users who are
to be added to the group. Finally, click the Select Rows link to commit the changes.
Adding Members via the CLI
Adds a user to the group
-
- -
-
-
IPTX v2.05-25
From the CLI, add a user to a group using the command groupname groupname member
username. The results can be verified with the show group detail groupname groupname
command.
Example
- -
Full Name: Sales

Description:
Phone:
Phone(E.164):
Language: en_US
Owners:
Members:
-
- -
Full Name: Sales

Description:
Phone:
Phone(E.164):
Language: en_US
Owners:
Members: JSmith
Defining an Administrator via the GUI
Adding a user to the Administrators group from the Groups page
IPTX v2.05-26
Configuring an administrator from the GUI is accomplished by first logging in as an

administrator, then choosing the Configure > Groups menu. The Administrators group, which is
a default, is then chosen.
Defining an Administrator via the GUI

(Cont.)
Adding a user to the Administrators group from

the Groups page (cont.)
IPTX v2.05-27
Next, one or more subscribers are added (in the figure, FPrefect is being added to the
Administrators group). This username is then able to log on to the GUI and have the privileges
of an administrator.
Only those usernames that belong to a group with administrative permissions, such as the
Administrators group, are able to perform administrative tasks in CUE.
Note
There is no equivalent of the customer administrator in CUE.
Defining an Administrator via the CLI
Adds a user to a group

--
- - --
-
-
IPTX v2.05-28
The groupname groupname member username command is used to add a user to a group
from the CLI.
Example
This configures the user JSmith as an administrator:
-
Adding a User to a Group via the GUI
Adding a user to a group from the Users page

IPTX v2.05-29
A user can also be added to a group from the Configure > Users menu in the GUI. Select the
user, and on the User Profile page, click the Groups tab to view current members. Click the
Subscribeas member link to add the user to a group.
Adding a User to a Group via the GUI

(Cont.)
Adding a user to a group from the Users page (cont.)

IPTX v2.05-30
After clicking the Subscribe as member link, select the group or groups to which this user is
going to be added, then click the Select row(s) link to commit the changes.
Adding a User to a Group via the CLI
- -
Adds a user to a group

- - -
-
-
IPTX v2.05-31
From the CLI, a user can also be added to a group through the use of the username username
member groupname command.
Note
This command does not appear in the configuration. Instead, the groupname groupname
member username appears.
Example
-
- -
Full Name: Sales

Description:
Phone:
Phone(E.164):
Language: en_US
Owners:
Members: JSmith
-
Deleting a Group via the GUI
Deleting a group and associated voice mails

IPTX v2.05-32
To delete a group through the GUI, choose the Configure > Groups menu, select the group,
and click the Delete link. Click OK to commit.
Caution
Any mailbox and voice mail contents will be deleted with the group.
Group Configuration:
Deleting a Group via the CLI
Deletes a user to a group

-
- -
IPTX v2.05-33
To delete group via the CLI, use the command group groupname delete. Performing the
deletion from the CLI does not delete the mailbox and its voice mail contents. This results in an
orphaned mailbox, which can be deleted manually via the CLI.
Example
- -
-
- -
Group Mailboxes
This topic describes group mailboxes.
Group Mailboxes
A GDM is a mailbox assigned to a group
A group definition contains:
(Mandatory) Group IDthe groups username,
e.g., Sales
(Optional) Member(s)
(Optional) Owner(s)
(Optional) Mailbox
A group without a mailbox and at least one
member is of limited use
IPTX v2.05-34
A GDM can be assigned to a group. That group can have multiple users as members. When
defining a group, the administrator must give the group a name, assign members to the group,
set the owner of the group, and (optionally) create a mailbox for the group. The mailbox that is
defined for the group is a GDM. The GDM is shared by all members of the group. Group
members still have their own personal mailboxes.
It is possible for a user to belong to many groups and potentially have access to many GDMs in
the system. Access to the GDM is through a TUI menu option in the user s personal mailbox.
Note
It is possible to have a group defined with just a name, but this configuration would be of
little value.
Group Owners and Members

Define groups for the functions (not individuals) that need
voice messaging
Example: front desk, sales, support
Owner
Is not by default a member; the owner must be explicitly
added as a member
Is responsible for maintaining membership of the group
Owners GUI display allows group member maintenance
Members
Log in to the GDM via their personal mailbox login
Record and change spoken name and greetings
Can listen to, save, and delete mailbox messages
IPTX v2.05-35
Groups and their GDMs should be defined for functions that are shared by a group of
individuals. This allows any member of that group to have access to the GDM. The group
number is often assigned as a shared line appearance that resides on a line on the Phones of the
group members.
The owner of a group is allowed to add or delete group members. If the owner needs to be a
part of the group, then the owner must be added as a member. If there is no owner, then only
the administrator can modify the group membership.
When a caller leaves a message in a GDM, no MWI is turned on. Instead, when members log in
to their personal mailbox, the mailbox menu allows members to access the messages in each
GDM. Only one person can access the GDM at a time. After the first person saves or deletes a
message in the GDM, the message is no longer played as new for subsequent members who
access the GDM.
Add a GDM to an Existing Group

via the GUI
Not necessary if Create Mailbox was selected when the group was
created
No difference in Add screen of a personal mailbox vs. that of a GDM
A GDM is defined by the owner of the group
IPTX v2.05-36
In the GUI, the following two-step process creates a GDM:

Step 1
Create the group.
Step 2
Create the GDM.
As an administrator, choose the Voice Mail > Mailboxes menu to add a GDM. Click the Add
link and define the mailbox in the Add a New Mailbox window. In the Owner field, enter the
name of a group that has already been created. The mailbox settings of the GDM are the system
defaults and can be changed here.
Add New Group and GDM Simultaneously
Adding a GDM when creating the group

Creates the group and the GDM at the same time
The group is the owner of the GDM; members of the group can manage
the GDM
IPTX v2.05-37
A GDM can be set up when a new group is created. Choose the Configure > Groups menu
and click the Add link. In the Add a New Group window, configure the group. To
automatically create a GDM when the group is created, be sure to check the Create Mailbox
check box.
Group Mailbox Settings via the CLI
Creates a group
Assigns a member to the group
Sets the phone number of the group

IPTX v2.05-38
To create a group from the CLI, use the command group name create. Members are added to
the group using the command group name member username.
Example
Create a group called Sales, then add two members and a phone number:
-
-
-
-
Group Mailbox Settings via the CLI (Cont.)
Assigns the group to be the owner of the GDM
IPTX v2.05-39
The command voicemail mailbox owner groupname is used to create a GDM for the Sales
group.
Display Groups and Mailboxes in the GUI
List groups and GDMs:

From Groups page
From Mailboxes page
IPTX v2.05-40
The GUI can be used to view Groups by choosing the Configure > Groups menu. The GDMs
can be viewed by choosing the Voice Mail > Mailboxes menu. The type of mailbox is
displayed in the Mailbox Type column.
Display Groups and Mailboxes in the CLI
Displays the groups that are configured
Displays a detailed view of a group

-
-
-

-

-
-
-
IPTX v2.05-41
From the CLI, the show group command can be used to view the groups defined in the
CUE system.
If more detailed information (such as group membership) is required, then use the command
show group detail groupname groupname.
Display Groups and Mailboxes in the CLI

(Cont.)
Displays a mailbox and its settings

- --

-
-
- -
--
-- --

-
- --
--
--
--
-

- --

IPTX v2.05-42
The show voicemail detail mailbox ownername command can be used to display a detailed
view of a specific mailbox, whether a personal mailbox or a GDM.
User Profile in the GUI Showing Group

Memberships and GDM Access
View the GDMsto which a user has access

IPTX v2.05-43
The group membership of a user can also be viewed from the user configuration pages within
the GUI. The Configure > Users menu can be used to go to a specific user. To view GDM
membership, click the Mailboxes tab to access the General Delivery Mailbox(es) section.
Summary
Summary
The users interface is either the TUI or the GUI.
Users can reset their password from the GUI and
their PIN from either the TUI or the GUI.
The administrator can configure new users from
either the GUI or the CLI.
Groups can be configured by the administrator
from the GUI or the CLI.
Defining a GDM is very similar to defining a
personal mailbox.
Members of a group access the GDM through their
personal mailbox.
IPTX v2.05-44
Lesson 5

Express Voice Mail
Overview
This lesson defines how to set up, configure, and manage voice mail settings.
Objectives
Upon completing this lesson, you will be able to describe the components of and perform the
tasks for configuring voice mail. This includes being able to meet these objectives:
Describe the concept of voice mail entry point and port
Perform the tasks for MWI configuration
Describe the properties of broadcast messages
Describe mailbox and message sizes and defaults
Perform the configuration tasks for personal mailboxes
Describe and configure VPIM networking with CUE and Cisco Unity
Perform the configuration tasks for public and private distribution lists
Voice Mail Entry Point and Port
This topic describes the voice mail entry point and port.
Voice Mail Entry Point and Port Concepts

There is no administrator control over the maximum
number of ports allowed on the system. It is
determined by:
The CUE hardware type
(NM-CUE, NM-CUE-EC, or AIM-CUE)
The chassis in which the module is installed
By default, ports are shared between the automated
attendant and voice mail.
Cannot be dedicated
May be partitioned
Keeping ports in shared mode is recommended.
Changing this assignment may cause inefficient
handling of calls.
IPTX v2.05-2
In Cisco Unity Express (CUE), a port does not represent a physical port as it does in a
traditional telephony device. A port in CUE represents one call terminating on the system. The
number of ports in the system is dependent on the hardware and the license. The CUE network
module (NM-CUE) has four ports for the 12- and 25-mailbox license and eight ports for the 50and 100-mailbox license. The CUE advanced integration module (AIM-CUE) has a maximum
of four ports for the 12-, 25-, and 50-mailbox licenses. The AIM-CUE cannot have more than
50 mailboxes.
Note
For the purposes of this lesson, a port and a session are equivalent.
CUE, by default, has voice mail and automated attendant applications, which share all of the
ports on the system. Ports cannot be dedicated in CUE, but they can be partitioned.
One of the parameters that you can configure for the voice mail and automated attendant
applications is the maximum number of callers who can access the application concurrently
at any given time. The maximum sessions parameter is limited by the number of ports on the
CUE module.
Consider your expected call traffic when assigning the number of ports to an application. One
application may need more available ports than another, but each application should have at
least one port available for incoming calls. In most cases, the default configuration, which is all
ports in one pool of ports that can be used by any application, is the most efficient.
Suppose, for example, that your CUE module has four ports and you assign a maximum
sessions parameter of 4 to the voice mail application and 4 to the automated attendant
application. In this case, if four callers access voice mail simultaneously, no ports will be
available for automated attendant callers. Only when zero, one, two, or three callers access
voice mail simultaneously will at least one port be available for the automated attendant.
Suppose, instead, that you assign a maximum sessions parameter of 3 to voice mail and 3 to
automated attendant. At no time will one application use up all the ports. If voice mail has three
active calls, then one caller can access the automated attendant. In this case, a second call to the
automated attendant will not go through at that moment. Also in this case, if four callers try to
call voice mail and no one is using the automated attendant, only three will be able to connect;
the fourth port is unused.
You must also assign themaximum sessions parameter to each application trigger, or pilot
number, which is the telephone number that activates the applications script. The triggers
maximum sessions parameter must not exceed that of the application.
Note
The Cisco best practice is to leave all ports using a common shared pool of ports. This
results in voice mail and the automated attendant efficiently sharing the ports in CUE.
Setting Up the Pilot Number via the GUI

Calls to this number
(1999) enter voice mail.
The voice mail operator
number is, by default,
the automated
attendant number that
was set up during the
initialization wizard, but
can be set to any
extension number.
IPTX v2.05-3
The voice mail pilot number (sometimes called the pilot point number) and the voice mail
operator number can be configured in the GUI by choosing the Voicemail > Call Handling
menu.
Setting Up the Pilot Number via the CLI
Enters the configuration mode for the specified

phone number
Assigns an application to run when a call arrives at

the specified phone number
IPTX v2.05-4
To configure the voice mail pilot number from the command-line interface (CLI), the command
ccn trigger sip phonenumber phonenumber is entered from global configuration mode. This
has the effect of entering a subconfiguration mode. The command application voicemail can
then be used to tie the trigger to invoke the voice mail application.
Setting Up Maximum Sessions via the CLI
----
Defines the maximum ports that the trigger is allowed to

use, eight on the NM-CUE and 4/6 on the AIM-CUE
-

----
-

----
IPTX v2.05-5
The command maxsessions configured in the trigger mode defines the maximum allowable
number of sessions that can arrive at this trigger (number).
Note
Multiple triggers can use the same application.

-

----
----
Setting Up Maximum Sessions via the GUI
The system default will be used for both the voice mail
application and any other applications.
The number of maximum sessions can be lowered per
application to partition the usage of the ports.
IPTX v2.05-6
The GUI can also be used to configure the maximum sessions allowed for a trigger. This can be
done either under Voicemail > Call Handling for the voice mail trigger or when you are
adding a new automated attendant, which is done on the third and final screen of the process.
The maximum sessions setting cannot be more than the number of licensed ports on the
CUE system.
Setting Up Maximum Sessions via the CLI

(Cont.)

----

-
----
----
---
IPTX v2.05-7
The maxsessions command can also be used in application mode. In this configuration, the
maxsessions command defines the maximum sessions that can be used by this application
regardless of which trigger they arrived at. This setting cannot be set to more than the licensed
number of ports.
Message Waiting Indicator Configuration

This topic describes the Message Waiting Indicator (MWI) configuration.
MWI Configuration Overview

The MWI is turned on and off via MWI ephone-dnsin a Cisco
CallManager ExpressCUE integration.
As in Cisco Unity, MWI directory numbers for on, off, or both
must be defined.
A single MWI set is supported in CUE.
2. SIP message sent to turn on MWI
CME
1. Message left
On
3. Message sent
to MWI directory
number
Off
4. SCCP message sent to
turn on MWI
Assume four-digit extension

The periods are very
important. If not
present, the MWI does
not work.
IPTX v2.05-8
CUE uses the MWI on and MWI off extensions with the affected telephone extension to
generate a session initiation protocol (SIP) call to Cisco CallManager Express, which changes
the status of the telephones MWI light. CUE refreshes the MWI lights automatically when new
messages are received, saved, and deleted and when the software is initialized. Use the GUI or
the CLI to refresh the MWI lights for a specific telephone or for all configured telephones.
The MWI display on an IP Phone is controlled by the extension associated with the line 1
button on the Phone.
If a voice message is left for an extension that is associated with line 1 of a Phone, then the
MWI light on the line 1 button of the Phone comes on and a flashing envelope icon appears
next to the extension appearance on the Phone display.
If a voice message is left for an extension that is associated with any line other than line 1,
then only a flashing envelope icon appears next to the extension appearance on the Phone
display.
The above operation is the same for all extensions, regardless of whether the extension is
associated with a user or a group or whether it is a single or multiappearance extension.
CUE requires that IP Phones with mailboxes all have extensions of the same length. The actual
length does not matter. It can be between 1 and 16 digits, as supported by Cisco CallManager
Express, but all extensions that have mailboxes must be of the same length within a particular
Cisco CallManager Express and CUE system. This restriction is because of MWI support.
CUE supports only a single defined set of MWI directory numbers: one on directory number
and one off directory number. The extension length is embedded within the MWI directory
number definition in the form of the number of periods at the end of the directory numbers. The
number of periods represents the length of the extensions in the Cisco CallManager Express
and CUE system. The CUE system sends the MWI number plus the extension number of the
mailbox that has a message to the Cisco CallManager Express via an SIP call when it wishes to
change the status of the MWI, whether from on to off or from off to on.
Example: Digits Sent from CUE to Turn on the MWI

The configuration of the MWI on the Cisco CallManager Express router is as follows:
-
When a message is left in the mailbox that is associated with directory number 2001, the
following SIP call is received on the Cisco CallManager Express router from the CUE module.
- -
Mar 8 14:58:12.863: //24/BC28C3788023/SIP/Call/sipSPICallInfo:

The call setup information is:
Call Control Block (CCB): 0x64945690
State of the Call: STATE_DEAD
TCP Sockets Used: NO
Calling Number: outbound0
Called Number: 80002001
Source IP Address (Sig): 10.20.0.1
Destn SIP Req Addr:Port: 10.20.0.10:0
Destn SIP Resp Addr:Port: 10.20.0.10:5060
Destination Name: 10.20.0.10
The receipt of this SIP call causes the Cisco CallManager Express system to turn on the MWI
for the directory number 2001 (assuming that number is line 1 on the IP Phone).
MWI Configuration
-

MWI number settings can be viewed and chosen from the GUI.
GUI numbers reflect the Cisco CallManager Express CLI settings.
IPTX v2.05-9
To properly set up the MWIs, you must complete configurations on Cisco CallManager
Express as well as on CUE. This can be done from either the GUI or the CLI.
MWI Configuration via Cisco CallManager

Express CLI
- -
Sets the variable strMWI_ON_DN to an extension

number
- -
Sets the variable strMWI_OFF_DN to an extension

number
-
-
-
IPTX v2.05-10
The MWI configuration at the CLI is accomplished by setting a variable in

ciscomwiapplication. This is a system script and cannot be viewed or downloaded, so the
variables must be changed using the CLI. The variables that must be set are strMWI_ON_DN
and strMWI_OFF_DN. This is done in the application configuration mode with the parameter
command, as shown above. Notice that there are four periods at the end of the directory
number. This indicates that the extension length of the Phone that will have MWI is four digits.
MWI Configuration via the GUI
Configure MWI on and off extensions

IPTX v2.05-11
This shows the configuration from the GUI. Cisco CallManager Express must be configured
with an MWI on extension and an MWI off extension. From the GUI, choose the Configure >
Extensions menu and add two new extensions. Extension Type for both extensions must be set
to Message Waiting Indication (MWI). MWI Mode must be set to On for one extension
and Off for the other.
MWI Configuration via Cisco CallManager

Express CLI
Sets this ephone-dn to be either an MWI on

ephone-dnor an MWI off ephone-dn

IPTX v2.05-12
To create the MWI extensions from the CLI, simply create two ephone-dns and assign the
appropriate number followed by a number of periods equal to the extension length of the
directory numbers that will have MWI functionality. Then use the mwi on and mwi off
command to assign each of the ephone-dns a function. (There is an mwi on-off option that is
intended for integration with other voice mail systems, not for integration with CUE.)
Note
The periods are mandatoryeach represents one digit in the dial plan.
Refresh MWI via the GUI
-
-- -
Current state of lamp cannot be queried or displayed

IPTX v2.05-13
To refresh the MWI using the GUI, choose Voice Mail > Message Waiting Indicators > Refresh
.
This can be useful if the MWI is not accurately reflecting the current voice mailbox state, for
example, if a new voice mail was left, but the MWI did not light. This can be done for
individual users, groups, or all Phones in the system.
Refresh MWI via the CLI
Refreshes all MWIsand updates values
Refreshes a specific number

-
-
IPTX v2.05-14
The CLI can also be used to refresh the MWI of one or all IP Phones in the system.
Broadcast Messages
This topic describes sending broadcast messages to all mailboxes.
Broadcast Messages
Broadcast messages can be sent by authorized users.
To send a broadcast message, a user must belong to a group
with the Voice Mail Broadcaster capability set.
Broadcasts are sent from the TUI by an authorized user.
Broadcast messages will be heard after recipients log in to their
mailbox and can not be skipped or interrupted.
The broadcast can be saved or deleted by the recipient.
Broadcasts can go to local and remote users.
By default, broadcasts expire after 30 days.
Broadcast messages do not count against mailbox size unless
the broadcast message is saved.
By default, broadcast messages are sent to all users with
mailboxes on the system.
Broadcast messages can not go to a GDM.
IPTX v2.05-15
CUE permits users with the broadcast privilege to send local and network broadcast messages.
Users obtain this privilege as members of a group that has the broadcast privilege.
Sending a broadcast message is accomplished through the CUE Telephone User Interface
(TUI).
Senders of a broadcast message have the option to review, rerecord, and readdress the message
before they send it. Senders also have the option to set the number of days the broadcast
message plays before the system deletes it. The maximum life of a broadcast message is 30
days, which is also the default message lifetime.
A sender can include any or all of the remote locations configured on the local system. The
remote addresses can be location numbers or location names. When using the location name,
the number of matches may resolve into several locations. If the number of locations is four or
fewer, the system gives the sender the option to select the exact location. If the number of
matches results in more than four locations, the sender must enter more letters to narrow the
search.
All subscribers at the remote location receive the broadcast message. The recipients hear the
message immediately after logging in to their voice mailboxes. Recipients cannot interrupt a
broadcast message, and they cannot reply to or forward the message. Recipients can save or
delete a broadcast message.
Setting Up Broadcast Message Capability

via the GUI
IPTX v2.05-16
To use the GUI to enable members of a group to send a broadcast message, choose
Configure > Groups. Select the desired group, and on the Group Profile page, check
the Voice Mail Broadcaster check box. All members of the group are now able to send
broadcast messages.
Configuring Broadcast Message Capability

via the CLI
-- -
IPTX v2.05-17
To use the CLI to configure the capability to send broadcast messages, use the command group
groupname privilege broadcast.
Setting Broadcast Message Defaults

via the GUI
IPTX v2.05-18
There are some default settings that apply to broadcast messages. To reach them, choose
Defaults > Voice Mail. The preferences regarding whether the MWI works for broadcasts, the
maximum length of a broadcast, and the default expiration time for the broadcast can be set on
this page.
Configuring Broadcast Message Defaults

via the CLI
- -
Sets the maximum length in seconds of a broadcast

message
- --
Sets the number of days to store broadcast

messages
Enables the MWI when a broadcast is received in a

mailbox
IPTX v2.05-19
You can configure the broadcast message defaults from the CLI. The command voicemail
broadcast recording time broadcast-length sets the maximum length of a broadcast message
in seconds. The command voicemail default broadcast expiration time broadcast-days sets
the maximum number of days that a broadcast message is retained by the CUE system.
The system administrator at each location uses the command voicemail broadcast mwi to set
if or when the MWI lights up. This command affects only the local CUE system and applies
both to local broadcasts and to broadcasts received from a remote system.
Example: Broadcast Message Configuration
-
-
-
Maximum length of a broadcast: 120 seconds

Maximum time that a broadcast will be saved:
10 days
When a broadcast is received: MWI will activate
IPTX v2.05-20
The example in the figure shows the maximum message length set to 2 minutes and the
expiration period set to ten days. Upon receipt of a broadcast message, the MWI will light up.
Confirming Broadcast Messages
- - ---
Displays broadcast messages and message ID

- - ----
-
--

-
-
IPTX v2.05-21
The show voicemail broadcast messages command displays information on currently

recorded broadcast messages. The information includes the sender, message length, start date
and time, and end date and time. The message ID is assigned by the system when the message
is created.
Mailbox and Message Sizes and Defaults

This topic describes voice mailbox and message sizes and defaults.
Mailbox and Message Sizes Overview

A mailbox must be for a phone number that is defined
on the integrated Cisco CallManagerExpress system.
Messages are stored using a G.711 file; compression is
not possible.
A single instance of a message is stored in the system,
but it is included in the count of each mailbox in which
it is present. It can be deleted from the system only
after it has been deleted from all mailboxes in which it
was stored.
Mailbox settings can be customized on a per-user
basis.
Default settings can be modified.
IPTX v2.05-22
In order for a user to have a mailbox on the CUE system, the users directory number must be
under the control of the Cisco CallManager Express system that is integrated with the CUE
module. When messages are stored in CUE, they are stored as a G.711 file. Compression using
G.729 is not currently supported.
Even if a voice mail message is in more than one mailbox, there is only one copy of the voice
mail message on the hard drive (NM-CUE) or flash (AIM-CUE). The voice mail message is
included in the count of each mailbox in which it is present. It will not be deleted until all
mailboxes have deleted it.
Mailbox settings that include time limits for the message store, maximum message size, and
expiration time can all be customized on a per-user basis. This overrides the default settings on
the CUE system.
Setting Message Defaults via the GUI
These settings apply to all

new voice mailboxes that
are created.
These settings are
overridden by individual
user settings.
The maximum minutes of
voice message store for the
system is, by default, set to
the upper limit and cannot
be raised.
IPTX v2.05-23
To set the system parameters in the GUI interface, choose the Default > Voice Mail menu.
The maximum voice message store is the total aggregation of all mailboxes in the system.
This number is a function of the hardware and cannot be raised above 6000 minutes for the
NM-CUE or 480 minutes for the AIM-CUE. Other settings here include the ability to limit the
size of outbound messages sent from within the subscribers mailbox. The last setting is the
prompt language that voice mail will use by default.
Setting Mailbox Defaults via the GUI
Existing mailboxes will not be affected by changes here.

New mailboxes will inherit these settings as defaults.
The total size of all mailboxes cannot exceed the maximum voice
storage size.
IPTX v2.05-24
The default settings on new mailboxes include mailbox size, maximum length of a message,
and amount of time until the message expires. To reach these settings, choose Defaults >
Mailbox.
Note
Changing these settings does not affect the existing mailboxes; only new mailboxes inherit
these settings.
Configuring Mailbox and Message Settings

via the CLI
Sets the capacity of the system in minutes
- - --
--- --
Sets user mailbox defaults
Sets default operator extension for the voice mail

system
IPTX v2.05-25
The voice mail system defaults can be configured from the CLI instead of the GUI. The
commands that govern the voice mail system settings are:
voicemail capacity time minutes Sets the capacity up to the maximum allowed by the
hardware
voicemail default expiration days Sets the number of days that a message is stored in
the mailbox
voicemail default mailboxsize seconds Sets the maximum amount of time that the total
of all messages in a mailbox can consume
voicemail default messagesize seconds Sets the maximum amount of time one message
can consume
voicemail operator telephone number Sets the extension to which callers are sent when
they press 0
voicemail recording time seconds Sets the maximum size of outbound messages sent
from one subscriber mailbox to another mailbox
Example: Configuration of Mailbox and

Message Default Settings

-
---

- --
-- --
--
-- -
- -

IPTX v2.05-26
This figure shows an example of configuring the system voice mail defaults and mailbox
defaults.
Changing a Users Mailbox Settings

via the GUI
Changes here will affect only the selected user.

IPTX v2.05-27
The settings of a mailbox that was created with the default settings can be overridden with
settings specific to that subscriber. To do this in the GUI, go to the subscribers profile, choose
Configure > Users, and select the user mailbox to change. In the User Profile window, click
the Mailboxes tab and make the desired changes.
Change a Users Mailbox and Message

Settings via the CLI
- --
Creates a mailbox and sets the maximum size, in

seconds
- -
- ---- -
Configure mailbox settings
IPTX v2.05-28
To change a users mailbox settings from the CLI, first enter the mailbox for that user by using
the voicemail mailbox owner name command. In the mailbox subconfiguration mode, specific
commands may then be entered to change the settings of that mailbox. They are:
description description text Sets a description for the mailbox
mailbox size seconds Sets the maximum amount of time that all the messages can
consume
messagesize seconds Sets the maximum amount of time one message can consume
expiration time days Sets the number of days that a message is stored in the mailbox
no tutorial Disables the tutorial program that runs the first time a user logs in
enable Enables the mailbox
Example: Configuration of a Users Mailbox

Settings

- -
-
---

---
-
- -
- -
--
-- --

-
- --
--
--
--
-

- --

IPTX v2.05-29
This figure shows an example configuration of the settings on a users mailbox.
Personal Mailboxes
This topic describes personal voice mailboxes.
Personal Mailboxes Overview
Only one personal

mailbox per subscriber
Must be a user defined on
the integrated Cisco
CallManagerExpress
A primary extension must
be selected or no calls
will reach voice mail
IPTX v2.05-30
A personal mailbox is a mailbox that is assigned to a specific user and is accessible only by this
user. When a caller leaves a message in this mailbox, the MWI light turns on.
To configure a user and mailbox from the GUI, choose Configure > Users and click the Add
link. This allows the administrator to add a new user from the GUI. On this page, the option
exists to create a mailbox for that user by check the Create Mailbox check box. This allows
the administrator to set up a mailbox and user in one step.
Viewing Personal Mailboxes via the GUI
All
Managing mailboxes as an administrator:

Bulk operations can be performed by selecting more than one
mailbox.
Mailboxes may be sorted by user or group ID, the primary
extension, the mailbox type, or the description field.
A primary extension must be selected or no calls will reach
voice mail.
IPTX v2.05-31
To view the mailboxes after the initial configuration, choose Voice Mail > Mailboxes. All
configured mailboxes appear on this page and are managed from this page. The percentage of
usage can be viewed by selecting the mailbox.
Viewing Personal Mailboxes via the CLI
- -
Displays the mailboxes configured in the system
-
-
-
-

IPTX v2.05-32
The percentage of usage can be viewed for all mailboxes with one command from the CLI.
From the CLI, use the show voicemail mailboxes command.
Viewing and Changing Personal Mailbox

Settings via the GUI
Individual Mailbox Settings

Mailbox size
Maximum message size
Expiration time
Greeting type
Enable / disable
Usage information
IPTX v2.05-33
To view and change the settings of a specific mailbox, choose Voice Mail > Mailboxes and
select the mailbox. If desired, changes can be made on the Mailbox Profile page.
Displaying Personal Mailbox Settings via

the CLI
- -
Displays the settings on a specific mailbox

- -
----
-
- -
- -
-
--
-- --

- --
--
--
--
-
-

IPTX v2.05-34
To view the mailbox from the CLI, use the show voicemail detail mailbox username
command.
Add a New Personal Mailbox via the GUI
Adding a Mailbox
Not necessary if mailbox created
when user was created
Associate the owner of the
mailbox to the mailbox
System default mailbox values
automatically populated
Tutorial enabled by default
IPTX v2.05-35
To add a mailbox using the GUI, choose Voice Mail > Mailboxes and click the Add link. On
the Add a New Mailbox page, select a user to associate with the mailbox. This user must have
been previously defined.
The mailbox size, maximum caller message size, and message expiration time are populated
with the system mailbox defaults. These settings can be changed to different values if desired.
After the new mailbox settings have been configured, click the Add link to create the mailbox.
The new mailbox appears under the Voice Mail > Mailboxes menu.
Note
Lack of a primary extension on a mailbox results in a nonfunctional mailbox.
Using GUI to Delete a Personal Mailbox
Bulk deletions can be performed by selecting more than one

mailbox.
Deletions will not delete the user account.
IPTX v2.05-36
To delete a mailbox using the GUI, choose Configure > Mailboxes, select the mailbox or
mailboxes to be deleted, and clicks the Delete link.
Using the CLI to Delete a Personal Mailbox
Deletes a personal mailbox
IPTX v2.05-37
To delete a mailbox using the CLI, use the command no voicemail mailbox owner name.
Note
This command must be used to delete any orphaned mailboxes.
Greeting Management
Spoken names and mailbox greetings can only be
recorded over again or listened to via the TUI.
Requires the user to log in to the mailbox
The greeting that is currently chosen, standard or
alternate, can be displayed and changed via either
the GUI or CLI.
IPTX v2.05-38
A tutorial can be set to run when subscribers log in to their voice mail for the first time. This
TUI-based tutorial prompts subscribers to record their name and a standard personal greeting
that will be played for callers leaving a message. Subscribers can also use the TUI at any time
to change their spoken name and personal greeting or to rerecord them. In addition, the TUI can
be used to record an alternate greeting, which can then be activated from the TUI.
Viewing Mailbox Active Greeting
- -
----
-
- -
- -

--
-- --
-
- --
--
--
--
-
-
Standard greeting used during normal operation

Alternate greeting may be used after hours or when user
is on vacation
IPTX v2.05-39
To view which of the two personal greetings is currently active, the administrator can use
the GUI or the CLI. The administrator can go to a users profile and view or set which greeting
is used.
Note
Personal greetings cannot be recorded from the GUI.
Modify Mailbox Active Greeting
The greeting enabled for mailbox

can be changed:
From the GUI by the user or
administrator
From the CLI by the administrator
From the TUI by the user

-
IPTX v2.05-40
From the GUI, the user or administrator can set the greeting type that is played to callers who
leave a message in the users mailbox.
The administrator can also use the CLI to set the greeting that is played to callers who leave a
message. In mailbox configuration mode of the user whose greeting is to be set, use the
command greeting standard or greeting alternate.
VPIM Networking
This topic describes networking using VPIM.
VPIM Networking Overview

VPIM allows server-to-server message exchange:
Allows a message created on one system to be sent to
another
CUE to CUE
CUE to Cisco Unity (versions 4.03 and 4.04)
Cisco Unity (versions 4.03 and 4.04) to CUE
Uses SMTP to transport over TCP/IP network
Voice mail, vCard, and spoken name are sent as MIME types
Nondeliveryrecords generated if the message is
undeliverable after six hours
Delayed delivery records generated if a message is not
delivered in one hour
IPTX v2.05-41
CUE Release 2.1 supports the protocol Voice Profile for Internet Messaging (VPIM) version 2
to permit voice mail message networking between CUE and Cisco Unity voice mail systems
that are not located on the same router or server. Supported networked voice mail
configurations include:
CUE to CUE
CUE to Cisco Unity (versions 4.03 and 4.04)
Cisco Unity (versions 4.03 and 4.04) to CUE
If a message cannot be delivered, after a specified amount of time the sender receives a voice
mail message indicating the reason for nondelivery. If nondelivery is because the recipient s
mailbox is full, does not exist, or is disabled, the nondelivery message includes the sender s
original message. When the sender plays the nondelivery record, the sender can readdress and
send the original message again or delete the message.
If the system cannot deliver a message to a remote site after six hours, the local user receives a
nondelivery message indicating that the message was not sent or that the message was not
delivered to the recipients mailbox. CUE Release 2.1 adds a delayed delivery record, which is
a notification left in the senders mailbox after 60 minutes of trying to deliver the original
message. Unlike the nondelivery record, the delayed delivery record does not contain the
original message as an attachment and does not count against the senders mailbox capacity.
Additionally, the delayed delivery record cannot be saved, only deleted. The system stores only
one copy of a delayed delivery record for a particular message in the sender s mailbox. The
user has to delete the existing delayed delivery record in order to receive an updated delayed
delivery record for the same message.
VPIM Networking
To configure networking, the following may
need to be done:
Define the remote location(s)
Define the local location
Enable the sending of vCards
Enable the sending of the spoken name
Enable the LRU cache
Configure commonly used remote users
IPTX v2.05-42
When configuring VPIM, it is critical to understand the following concept of locations. A

location represents one CUE or Cisco Unity system. Any remote systems to which the local
system will send messages using VPIM must have a location defined. In addition, the local
location must be defined and configured. The remote system also needs to define locations for
networking to function properly.
A vCard may be sent by a location when a message is targeted for a user on a remote system.
This vCard contains information about the sender of the message including the first name, last
name, and extension number. Sending location information allows the remote system to cache
the senders information. This is known as the least recently used (LRU) cache. The cached
information can be referenced to address messages.
Although the LRU cache is useful if the remote userthe target of a message from a local
userhas not recently sent a message to a local user, the cache may not contain information
about the remote user. As a result, the sender may have to use the extension number to address
the message. This is known as blind addressing.
Another solution for commonly used remote users is to have the administrator add an entry in
the directory of the local CUE module.
VPIM Networking: Adding a Location

Adding a
Location
IP
Network
seattle.cisco.com
10.10.0.10
QoS Not
Required
boston.cisco.com
10.20.0.10
IPTX v2.05-43
To add a location, choose the Administrator > Networking Locations menu, and on the
window that opens, click the Add link near the bottom of the page.
VPIM Networking: Defining the Remote

Locations
Defining the
Remote
Location(s)
IP
Network
seattle.cisco.com
10.10.0.10
QoS Not
Required
boston.cisco.com
10.20.0.10
IPTX v2.05-44
On the Add a New Location page, assign a Location ID, which is a numeric value used to
represent the location; the Location ID may be up to seven digits long. A maximum of 500
remote locations can be configured. The Location Name is a descriptive name to identify the
location. Other settings that may be configured are:
Abbreviation: An abbreviation that is used in the TUI
Domain Name/IP Address: Used to populate the domain part on the e-mail addresses that
are used by VPIM
Phone Prefix: Required if the local dial plan overlaps with this location
VPIM Broadcast ID: Required if domain names are the same between locations
Minimum Extension Length: Sets the minimum number of expected digits
Maximum Extension Length: Sets the maximum number of expected digits
Voicemail Encoding: Determines whether dynamic, G.711, or G.726 coder-decoders
(codecs) will be used
Send Spoken Name: Sends the spoken name of the sender along with any messages
destined for the remote location using VPIM
Send vCard Information: Sends the vCard information of the sender to the remote
location when a message is sent using VPIM
Enabled: Enables networking with the location
Note
The Location ID must be at least three digits in length, and the VPIM Broadcast ID must be
numeric when integrating with Cisco Unity.
VPIM Networking: Defining the Local

Location
Defining the
Local Location
IP
Network
seattle.cisco.com
10.10.0.10
QoS Not
Required
boston.cisco.com
10.20.0.10
IPTX v2.05-45
The previous steps must be repeated in order to configure the local location. The configuration
of a local location is identical to configuring a remote location.
VPIM Networking: Designating Local

Location
Specify the
Local
Location
IP
Network
seattle.cisco.com
10.10.0.10
QoS Not
Required
boston.cisco.com
10.20.0.10
IPTX v2.05-46
To designate which of the configured locations is the local location, choose the
Administration> Networking Locations menu, enter the Location ID, and click the Apply
link. Only one location may be designated as the local location. Failure to perform this step will
result in networking not functioning on the system.
VPIM Networking CLI Commands
Defines a location and number and enters location mode
Names the location (optional)
Sets an abbreviation for the location (optional)

IPTX v2.05-47
Multiple commands are required to configure a remote location from the CUE CLI. To start the
process, use the network location id number command from global configuration mode. This
will enter the location subconfiguration mode, from which settings for the location are entered.
The location should be given a name with the command name location-name. An abbreviated
name is specified with the command abbreviation name.
VPIM Networking CLI Commands (Cont.)
Sets the e-mail domain or IP address for the location
Assigns a prefix to the extension numbers (optional)
Sets the length of the expected extension for the

location
IPTX v2.05-48
While still in location subconfiguration mode, enter the command email domain domain-name
to set the domain or IP address that will be used on the Simple Mail Transfer Protocol (SMTP)
messages going to this location. If the local dial plan overlaps with the location being defined,
then a prefix must be placed in front of the extension numbers. This number is configured with
the command voicemail phone-prefix digit-string. The expected length of extensions is set
with the command voicemail extension-length number.
VPIM Networking CLI Commands (Cont.)
Determines the encoding method used to send the

voice mail messages to this location
Enables sending the spoken name of the originator

as part of the message
Sets which of the defined locations is local

IPTX v2.05-49
The voice message being sent using VPIM can use either the G.711 or G.726 codec. This may
be statically set or negotiated. While still in location subconfiguration mode, the command
voicemail vpim-encoding g711ulaw or voicemail vpim-encoding g726 statically sets the
codec. The command voicemail vpim-encodingdynamic allows the system to negotiate
whether to use G.711 or G.729.
The default is to send the spoken name of a sender, but if this has been disabled, use the
command voicemail spoken-name to reenable it.
To enable networking on the local system, from global configuration mode use the command
network local location id number.
Note
Failure to define a local location will cause networking to be disabled on the local system
Example: VPIM Networking

-
--
-
- --

-

-
--
-
- --

-

Seattle
IP
Network
Seattle
Configuration
Boston
IPTX v2.05-50
The example in this figure shows the CLI configuration required on the Seattle CUE module to
enable networking with the Boston CUE module.
Example: VPIM Networking (Cont.)

Boston
Configuration

-
--
-
- --

-

-
--
-
- --

-

Seattle
IP
Network
Boston
IPTX v2.05-51
The example in this figure shows the CLI configuration required on the Boston CUE module to
enable networking with the Seattle CUE module.
Note
Both Seattle and Boston must be configured before networking will function.
Directory Entries
Directory entries are used to provide spellby-name and spoken-name confirmation.
Entries are added to the directory as follows:
Static entries in directory
Local users automatically in the directory

Remote users manually defined
Dynamic entries in the directory
Remote users may be learned and stored in circular
LRU cache
No entry in the directory
Blind addressing may be used
IPTX v2.05-52
When a subscriber sends a message to another subscriber on the same (local) CUE voice mail
system, the sender can address the recipient using spell-by-name or extension number. The
sender hears a confirmation of the recipients spoken name, if it is recorded, or the recipients
extension number.
In order for spell-by-name and spoken-name confirmation to work, an entry must exist in the
directory of the CUE module. Local users are automatically in this directory, but remote users
are not. Remote users are entered into the local CUE directory in one of two ways: by an
administrator manually configuring the user and recording a spoken name through the TUI or
learned through the LRU cache.
Remote User Directory Entry Considerations

Considerations when configuring remote users:
Administrator configures remote users
Adds a commonly used remote user to the directory of the CUE

module
Enables a remote user to be addressed with spell-by-name
Maximum of 50 on an NM-CUE or NM-CUE-EC
Maximum of 20 on an AIM-CUE
Administrator may record spoken name for remote user
through the TUI
If spoken name is sent by remote system in VPIM message, spoken
name is updated with sent spoken name
If no spoken name is sent or recorded, then location and extension
number are used for confirmations and announcements
Validity of destination is known before sending message, assuming
administrator configured remote user correctly
IPTX v2.05-53
The local CUE directory is enhanced to allow inclusion of frequently addressed remote users.
This capability allows a local voice mail sender to address a remote recipient using dial-byname. Additionally, the system provides the sender with a spoken-name confirmation of the
remote recipient so that the sender can verify that the name and location are correct.
Regardless of the license level, the NM-CUE and NM-CUE-EC support a maximum of 50
remote users. The AIM-CUE supports a maximum of 20 remote users. There is a new menu
option available on the TUI that allows the system administrators to record the spoken name for
the remote users. If a remote user does not have a spoken name recorded, the system uses the
remote extension number and location as confirmation to the local sender.
If the vCard option is configured, the vCard of the remote user updates the local system with
the first name, last name, or extension of the remote user.
The local sender hears the remote users spoken name if it is configured by one of the following
methods:
The spoken name is recorded on the local system.
The local system receives a message from the remote user, whose spoken name is recorded
on the remote system and the remote system is configured to send the spoken name to the
local system.
If the spoken name of the remote sender is not configured either locally or remotely, the local
user hears the remote extension number and remote location name. When a local user plays
back a message from a remote user, the local user hears the spoken name or phone number of
the remote sender, the spoken name of the remote office, the date, and the time the message
was sent. If the local system receives the message more than 30 minutes after the message was
sent, the local user also hears the time when the message was received. If the local user replies
to this message, the local system automatically sets up the appropriate remote address
information.
Remote User Example

Addressed Using a Defined
Remote User
Administrator has
defined in Seattle
the remote users
of ZBeetle and
MProsser and
recorded spoken
names.
VM
from:1001@seattle.cisco.com
to:2001@boston.cisco.com
Spoken name of ADent (optional)
vCard of ADent (optional)
Administrator has
defined in Boston
the remote users
of FPrefect and
ADent and
recorded spoken
names.
IP
Network
seattle.cisco.com
10.10.0.10
FPrefect -1000
ADent -1001
boston.cisco.com
10.20.0.10
ZBeetle -2000
MProsser -2001
IPTX v2.05-54
In the example in this figure, the administrator has defined in Seattle the remote users of
ZBeetle and MProsser, who reside in Boston. This allows users in Seattle to address messages
to those users in Boston using spell-by-name instead of the location and extension numbers. If
the administrator in Seattle has also recorded a spoken name or a message is received from that
user with a spoken name attached, the system plays the spoken name of the sender as a
confirmation.
Configuring Remote Users from the CLI

- -
Creates a remote user
- - - -
Associates a remote user with a display name
- - - -
Associates a first name with the user

IPTX v2.05-55
Configuring remote users from the CLI requires multiple commands. First create the user
by using the command remote user username location location-id. Use the remote user
username fullnamedisplay display-name command to associate a display name to the
user. Use the command remote user username fullname first first-name to assign a first
name to the user.
Configuring Remote Users from the

CLI (Cont.)
- - - -
Associates a last name to the user
- - -
- --
Displays a list of configured remote users

IPTX v2.05-56
The command remote user username fullname last last-name is used to assign a last name
to the user, and from global configuration mode, use the command remote user username
phonenumber extension-number to associate an extension number to the user.
The command show remote users displays all of the remote users configured in the system.
Configuring Remote User Example from the

CLI
- -- - -
Displays details about a specific remote user

- -
- -
- - - - - - - - - - -
- - -
- -
-

- -
IPTX v2.05-57
The example in this figure shows the configuration to add a user named Douglas Adams with
an extension of 3000.
VPIM Networking LRU Cache Considerations

LRU cache considerations:
The LRU cache is not used for defined remote users.

The local system must receive a message from a user on a remote
system before the LRU cache is populated with information about
that user.
Information on the last 50 users is stored on the NM-CUE and
NM-CUE-EC in the LRU cache.
Information on the last 20 users is stored on the AIM-CUE in the
LRU cache.
vCard information, if sent by the remote system, enables the LRU
cache to populate the first name, last name, and extension number.
The spoken name, if sent by the remote system, enables the LRU
cache to store the spoken name of the user entered into the cache.
The validity of the destination is known before the message is sent.
IPTX v2.05-58
The LRU cache is a database of remote users first names, last names, extension numbers, and
spoken names. The LRU cache is enabled by default and permits vCard information about the
remote users to be updated automatically. When a local sender addresses a voice mail message
to a remote user via spell-by-name, the system accesses the LRU cache information to address
and send a confirmation about the remote user to the local sender.
The users contained in the cache are referred to as cached users.
The maximum length of the LRU cache is 50 users on the NM-CUE and NM-CUE-EC. The
AIM-CUE is limited to caching a maximum of 20 of the final users that sent a message to the
system.
VPIM Networking Blind Addressing

Considerations
Blind addressing considerations:
Used when no entry exists in the LRU cache and no remote user for
the destination has been defined.
Requires the use of the location ID and extension number to
address the message.
Spell-by-name is not available, as the destination user is unknown
to the system.
When sending messages, the location and extension number is
used for confirmation.
Messages received will have no spoken name and will state the
location ID or spoken location if an administrator has recorded it
and extension number from which the message was received.
The validity of the destination is not known before sending the
message.
If the destination extension is not valid, a nondeliveryrecord will be
returned to the sender after six hours.
IPTX v2.05-59
When a subscriber sends a message to a remote subscriber, if there is no entry in the LRU
cache and no remote user defined for this remote subscriber, the sender will not hear a
confirmation of the recipients name or extension. This is called blind addressing. The address
of the remote recipient is the location ID of the remote system plus the recipients extension
number at the remote location. The validity of this destination is not known before the user
sends the message. A nondelivery record is generated after six hours if the extension that is
entered is not valid.
Blind Addressing Example

LRU Cache
Does not
contain info
about
ZBeetle, and
a remote
user for
ZBeetle has
not been
defined.
Blind Addressing
VM
LRU Cache
FPrefect
First name
Last name
from:1000@seattle.cisco.com
to:2000@boston.cisco.com
Spoken name of FPrefect (optional)
vCard of FPrefect (optional)
Extension
Spoken name
IP
Network
seattle.cisco.com
10.10.0.10
FPrefect -1000
ADent -1001
boston.cisco.com
10.20.0.10
ZBeetle -2000
MProsser -2001
IPTX v2.05-60
The example in this figure shows blind addressing. A Seattle user named FPrefect with an
extension number of 1000 composes a voice message for ZBeetle in Boston. The spell-by-name
will not find a match because the Seattle system has no knowledge of the user ZBeetle.
FPrefect will have to enter the location and extension number to send the message. This is blind
addressing. The Seattle CUE system will construct an SMTP message with the voice message,
vCard (if enabled), and spoken name of FPrefect and send the message to the address of
2000@boston.cisco.com from 1000@seattle.cisco.com. In this case, ZBeetle is valid, and the
message will appear in the mailbox of ZBeetle in Boston.
Before receiving the message from FPrefect, the Boston CUE module did not know about
FPrefect. After the message from FPrefect to ZBeetle is received, the Boston system learns the
first name, last name, and extension number from the vCard that was sent by Seattle in the
message for ZBeetle. The spoken name of FPrefect is also learned from the message. This
learned information is stored in the LRU cache of the Boston system.
LRU Cache Example

Addressed Using
the LRU Cache
LRU Cache
MProsser
VM
First name
Last name
Extension
Spoken name
LRU Cache
FPrefect
First name
Last name
from:2001@boston.cisco.com
to:1000@seattle.cisco.com
Spoken name of MProsser (optional)
vCard of MProsser (optional)
Extension
Spoken name
IP
Network
seattle.cisco.com
10.10.0.10
FPrefect -1000
ADent -1001
boston.cisco.com
10.20.0.10
ZBeetle -2000
MProsser -2001
IPTX v2.05-61
The example in this figure shows MProsser (2001) creating and sending a message to FPrefect
(1000) from Boston. Because the Boston CUE system has received a message from FPrefect
(1000) that contained a vCard and the spoken name of FPrefect, the LRU cache contains
information about the user. This information is used to allow MProsser to spell out the name of
Ford Prefect and find a match. The spoken name of Ford Prefect is announced as a
confirmation and the message is sent.
The Seattle CUE module receives a message to FPrefect (1000) from MProsser (2001), which
allows the Seattle system to learn information about MProsser. The Seattle system learns the
first name, last name, extension number, and the spoken name of MProsser. This entry can be
used to address messages using spell-by-name for MProsser in Seattle.
Configuring LRU Cache
Enables the LRU cache (enabled by default)

-
- -

- -

IPTX v2.05-62
The LRU cache is enabled by default. However, if it has been disabled, use the command
remote cache enable to enable it. The command show remote cache displays the learned
remote users that currently reside in the LRU cache.
Confirming Network Locations

Configuration
- - -

Shows networking information

-
- --
- - --
- --
-
-
--
-
-

-
-
-
IPTX v2.05-63
The command show network locations is used to display the configured locations on
the CUE module. The command variation that displays details on one specific location is
show network detail location id location-id.
Confirming Network Locations

Configuration (Cont.)
-

-
--
-
-

-
-
--
--
--
--
IPTX v2.05-64
The command show network detail local displays the local location and details on
its configuration.
Note
If no output shows, then a local location has not been designated and networking will be
disabled on this CUE module.
Distribution Lists
This topic describes public and private distribution lists.
Distribution Lists
Distribution lists are lists to which a voice mail can
be addressed.
Distribution lists may contain any combination of the following:
Local users
Remote users
GDMs
Groups
Other distribution lists
Blind addresses
Public distribution lists are available for all users to reference
and are created by the administrator.
Private distribution lists are specific for the user and are
defined by the user.
IPTX v2.05-65
CUE permits configuration of distribution lists that enables users to send a voice mail message
to multiple recipients at one time.
Members of a distribution list can be any combination of:
Local and remote users
A remote user statically configured on the local system
GDMs
Groups
Other distribution lists
Recursive distribution lists are permitted. For example, list A can be a member of
list B and list B can be a member of list A.
Blind addresses
Specify the Location ID and extension of the blind address. The system verifies the
Location ID and the extension length.
Distribution lists may be either publicly available or private to a user.
Public Distribution Lists

Public distribution lists in CUE have the following
properties and limitations:
Maximum number of distribution lists on the system is 15

Can be up to 50 owners of a distribution list
The everyone list cannot have an owner.
The owner can be a user or a group.
If the owner is a group, then any member of the group is
an owner.
Maximum number of distribution list members is 1000 for all
distribution lists on the system
Excludes the everyone list
Maximum number of list owners in the system is 50
Everyone distribution list updates automatically
IPTX v2.05-66
Public distribution lists are always defined by either an administrator or a user in a group with
the Public List Manager permission set. There may be up to 15 public distribution lists defined
in the CUE system. The maximum total number of owners for all distribution lists in the system
is 50. All 50 owners could potentially be assigned to one public distribution list, but that would
not leave any owners for any other public distribution list. The maximum total membership on
the whole system is limited to 1000 memberships in all public lists.
By default, there is one public distribution list that may not be modified and has no owner. This
is the everyone distribution list. As the name implies, all defined users are in this list.
Add a Public Distribution List Using the GUI
Continued on next slide
IPTX v2.05-67
To add a new public distribution list to the CUE system, choose Voice Mail >
Distribution Lists > Public Lists and, on the page, click the Add link. This opens the Add a
Public Distribution List page. On this page, give the distribution list a name, a number, and a
description, then click the Add link. The new distribution list will now appear. Click the new
distribution list name link, choose the Members tab, then click AddMember .
Add a Public Distribution List Using the GUI

(Cont.)
IPTX v2.05-68
The Find page will appear. On this page, enter the search criteria and click the Find link to start
the search. The results will appear in the Find window. Choose one or more members to add to
the distribution list, then click the Select row(s) link. Notice the new member now appears in
the public distribution list.
Configure a Public Distribution List Using

the CLI
- - -
Creates a public distribution list
Assigns an owner to a public distribution list
- -
- -
Assigns a member to the public distribution list

IPTX v2.05-69
To create a public distribution list from the CLI, use the command list name listname number
listnumber create. This creates the public distribution list and assigns a number to it. The
command list number number owner owner-id assigns an owner to the list, and the command
list number number member member-name type type assigns a member to the list.
Configure a Public Distribution List Using

the CLI (Cont.)
- - -
Adds a descriptive field to the distribution list (optional)
- --
Displays all configured distribution lists

-
-
-
-
-
-
-
-- -

-
-
- -

- - -
- --
-
--
IPTX v2.05-70
The optional command list number number description description adds a descriptive field to
the distribution list. The configured distribution lists may be viewed from the CLI with the
command show lists public.
View Public Distribution Lists Using the CLI
- -

Displays details of a distribution list

- -

--

- - -
-
-
-
-

-- -
IPTX v2.05-71
To view detailed information about a distribution list, use the command show list detail public
number number.
Private Distribution Lists

Private distribution lists in CUE have the following
properties and limitations:
The owner is the user who created the private distribution
list.
The maximum number of private distribution lists per
user is five.
Private distribution lists may be created and managed from
the GUI or the TUI.
Administrators and any member of a group with the View
Private List privilege may view private lists.
The sum of all members in all of an individual users private
lists cannot be more than 50.
IPTX v2.05-72
Private distribution lists in CUE are created by the user and are individualized by the user. Each
user can create up to five private distribution lists from the GUI or the TUI. Only administrators
and users in a group with the Private List Viewer permissions set may view another user s
private distribution lists. The number of members in all of a users private lists cannot total
more than 50.
Add a Private Distribution List

Using the GUI
Continued on next slide
IPTX v2.05-73
Users can add a new private distribution list from the GUI by choosing Voice Mail >
Distribution Lists > My Private Lists and clicking Add. This will open the Add a Private
Distribution List page. On this page, enter a name, a number, and a description for the
distribution list, then click Add. The new distribution list will now appear. Click the new
distribution list Name link.
Add a Private Distribution List

Using the GUI (Cont.)
IPTX v2.05-74
On the Private List page, click the Add Member link. The Find page appears. On this page,
enter the search criteria and click the Find link to start the search. The results appear in the
Find window. Choose one or more members to add to the private distribution list, then click the
Select row(s) link. Notice the new member now appears in the private distribution list.
View a Private Distribution List

Using the CLI
- -

--

- - -
-
-
-
-

-- -
IPTX v2.05-75
To view the membership of a private distribution list from the CLI, use the command
show list detail private name name owner owner-id.
Summary
Summary
Voicemail requires the configuration of a pilot number
MWI integration involves the configuration of the CUE
module from either the CLI or the GUI web interface
Broadcast messages may be sent through the AVT by an
administrator
Mailbox setting may be defined globally but can always be
overridenon a mailbox by mailbox basis
Mailboxes may be configured from either CLY or the GUI web
interface
VPIM allows the CUE module to take and transfer messages
to other VPIM compliant CUE modules and Unity
Public and private distribution lists allow many mailboxes to
receive a message
IPTX v2.05-76
Lesson 6
Troubleshooting
Cisco Unity Express
Overview
This lesson defines the commonly used Cisco Unity Express (CUE) troubleshooting tools,
system architecture, system troubleshooting, troubleshooting the GUI, and problems with CUE
voice mail and automated attendant.
Objectives
Upon completing this lesson, you will be able to describe the troubleshooting guidelines and
tools. This includes being able to meet these objectives:
Describe the troubleshooting methodology and tools
Describe the overview architecture of CUE software
Describe the guidelines for system-level troubleshooting
Describe the guidelines for GUI troubleshooting
Describe the guidelines for troubleshooting voice mail and automated attendant
This topic describes troubleshooting methodology and tools.

Problem-Solving Model
Define Problem
Finished
Gather Facts
Document Facts
Consider Possibilities
Problem Resolved
Start
Create Action Plan

Implement Action Plan
Observe Results
Utilize Process
Yes
Do
problem
symptoms
stop?
No
IPTX v2.05-3
A structured approach to troubleshooting has been proven to be the most effective method. The
Cisco approach to troubleshooting is a proven and effective guideline to analyzing problems
and achieving the fastest resolution times.
Gather Facts and Define Problem

Defining the problem is the first step in Ciscos troubleshooting model. Information is analyzed
to define the most likely cause of a problem. This requires knowledge of the systems that are
being diagnosed. You must gather facts before formulating a thesis about the problem. The
diagnosis of the problem or problems is more accurate if this fact-gathering step is done, and
the more accurate the diagnosis, the more quickly you solve the problem.
While still gathering facts but after enough information is collected, a problem statement is
created. The problem statement defines the problem in a specific, concise, and accurate manner.
The fact gathering continues, but a good problem statement makes it easier to focus on the
problem and ignore extraneous information.
Continue Gathering Facts

At this point, the problem needs more definition. More detailed fact gathering involves using
diagnostic tools to collect information specific to the network and to network devices that are
involved in the problem that is defined in the problem statement. Additional information to be
gathered includes data that eliminate other possibilities and help further pinpoint the problem.
To verify that Layer 3 connections work, for example, you would use tools such as ping,
tracing routes, and Telnet, thus systematically eliminating possible causes. It is important to
gain as much information as possible in order to hone in on the definition of the problem
because without a thorough and specific definition, the problem is much harder to isolate and
resolve.
Consider Possibilities
This step is used to contemplate the possible causes of the problem. It is quite easy to create a
very long list of possible causes. That is why it is so important to gather as much relevant
information as you can and to create an accurate problem statement. By defining the problem
and assigning the corresponding boundaries, the resulting list of possible causes diminishes
because the list focuses on the actual problem and not on possible problems.
However, this is just a list of possible causes. You must create an action plan, implement it,
then observe whether the changes that were made were effective. If they were not, you must go
back to the list of possible causes, checking each of the possibilities in the same way (creating a
plan, implementing it, then observing the results) until the cause of the problem is found.
Create and Implement the Action Plan

An action plan is the documentation of steps that will be taken to remedy the cause of a
network problem. The fact gathering should have produced many possibilities for the source
of the problem. Now it is a matter of investigating each possibility.
When an action plan is created and implemented, it is important that the fix for one problem
does not create another problem. Before implementing an action plan, think it through
possibly even discuss it with other engineers. You must ensure that the solution will fix the
problem without doing anything to create adverse side effects.
A good practice when creating and implementing action plans is to change only one thing at a
time. If multiple changes must be made, it is best to make the changes in small sets. This way it
is easier to keep track of what was done, what worked, and what did not. The observation step
is much more effective if only a few changes are made at a time; ideally, only one change
should be made at a time.
Observe Results
Observing results consists of using the exact same methods and commands that were used to
obtain information to define the problem. This enables you to see whether the changes that
were implemented were effective.
It may take more than one change to fix the problem, but you should observe each change
separately to monitor progress and to make sure that the change doesnt create any adverse
effects. After the first change is made, you should be able to gather enough information to
determine whether or not the change was effective, even if it doesnt entirely solve the problem.
After all of the changes from the action plan are implemented and the results are observed, you
can verify whether the action plan solved the problem. If the problem is solved, document the
changes that were made to the network.
If the changes did not work, go back and either gather more information or create a new action
plan. While working through the action plan process, you might get more ideas of possible
causes. Write them down; if the current action plan doesnt work, you will have notes about
other possibilities.
If you feel that all possible causes have been exhausted, you should probably go back and
gather more information that can give insights into more possible causes.
Repeat As Necessary
Iterations, or repetitions, of certain steps within the troubleshooting model, are how you narrow
implementation
down the causes of the problem. With each iteration of the action plan
observation process, you move closer to solving the problem. This is also the time to undo any
changes that had adverse effects or that did not fix the problem. Before you move on to
repeating the action plan
implementation
observation process, you must undo any
changes you made that did not work. Because you document the changes that you make each
time you implement an action plan, it is easy to undo those changes.
Document the Changes

Documentation is an integral part of troubleshooting. When you keep track of the changes that
were made which configurations, routers, switches, or hosts were changed and when the
changes occurred you have valuable information for future reference. It is always possible
that something that was changed affected something else and you did not notice it at the time. If
this happens, you have the documentation to refer to so you can undo the changes. If a similar
problem occurs in the future, you can refer to these documents to resolve the problem based on
what was done the last time.
Historical information is very useful in the case of a network failure. It provides a reference for
seeing what changes were most recently made to the network.
CUE Troubleshooting Philosophy

GUI administrator does a minimum of troubleshooting.
MWI Refresh and system parameters and limits check
Log and Trace commands require CLI access
Show Commands: Verify system parameters and status
IOS/Router/Cisco CallManager Express show commands

CUE CLI show commands can be used to view incrementing error counters
and focus in on the module and entity causing them
Logging: Unsolicited information from the system

Kept by the system at all times
Logged to storage by default; subset logged to flash
Filtering based on attributes like severity level
Tracing: Solicited detailed information from the system
Information on timing and sequences of activities

Messaging and events between system components
Can be enabled from the GUI or the CLI but can only be viewed from the CLI
IPTX v2.05-4
The GUI, although effective for day-to-day additions, moves, and changes, is not an effective
tool for troubleshooting the CUE system. The GUI can be used to reload CUE, view system
configuration, refresh MWI lights if out of sync, and turn on the tracing function. To effectively
troubleshoot, you must use the command-line interface (CLI) tools and functions.
Note
Trace output cannot be viewed from the GUI.
From the CLI of CUE, there are three different categories of tools that can be used. The first
category is the show commands. The many show commands can be used to view the
configuration, settings, and status of the CUE system.
Logging messages are another troubleshooting tool that can be used to diagnose a problem.
These unsolicited messages that come out of the system have a severity level associated with
them. These messages usually go to a syslog server or an internal log in memory.
Tracing is the equivalent of debugging in Cisco IOS software. Summary information to detailed
information is displayed on the screen, sent to a syslog server, or stored in memory. The trace
tools are used to focus on a specific aspect of the system.
Caution
Tracing can severely impact system performance and should be turned on with caution.
High-Level Approach
1. Use the command show errors.
Shows the number of errors found per module
2. Examine the logs.
show logs (shows log file names)
show log (shows content of a log file)
3. Use trace commands.
Selective trace based on Module, Entity, Activity
-

--
--
---
IPTX v2.05-5
To start troubleshooting CUE, use the show errors command. This command shows which
components of the system have errors. Invoke the problem that is occurring if it is repeatable
and notice which of the modules has the errors that are incrementing the counts.
Then use the show logs command to view the logs and the show log name logname command
to view the contents of the log files. This information may further define the problem or
component that is causing the errors.
Note
The log files can have many lines of output

sufficient.
ensure that the buffer of the terminal is
After the component or module that is causing the problems is known, the trace functionality
can be invoked and detailed output on the operation and function of the module can be
generated. This information should help troubleshoot the problem.
Logging
Four Levels of logging messages exist in CUE:
Info: Syslog levels Debug, Info, and Notice
Warning: Syslog level Warning
Error: Syslog level Error
Fatal: Syslog level Critical, Alert, and Emergency
Three possible destinations for logging messages:

Message.log text file on the hard drive or flash of CUE
(default)
Console of CUE
External syslog server
IPTX v2.05-6
Within the logging functions of CUE are four different levels of output. They are listed here
from least significant to most significant:
Info: Informational messages and notices
Warning: Events that may require attention
Error: Significant events that can affect functions
Fatal: Critical alerts and emergencies that can affect the stability of the system
These messages can be directed to three different destinations. They are:
Messages.log: A text file on the hard drive of the CUE network module (NM-CUE or NMCUE_EC) or the flash of the CUE advanced integration module (AIM-CUE). This is the
default action.
Console: Real-time messages or historical logs can be displayed on the console of CUE.
Syslog: The logging messages can be sent to an external syslog server.
Note
The log files in CUE are written as flat text files that can be opened with any text editor.
Message.log
System log on NM-CUE:
Kept locally on the hard disk
(100-MB max size, history of two are kept)
/var/log/Messages.log
/var/log/Messages.log.prev
System log on AIM-CUE:

Kept locally on the flash card
(10-MB max size)
Messages.log
Recommended to use an external syslog server
IPTX v2.05-7
By default, an NM-CUE sends all four categories of logging messages to a file on the
hard drive called /var/log/Messages.log. When this file reaches a set size, it is renamed as
/var/log/Messages.log.prev, and a new Messages.log file is started. When the Messages.log
file once again reaches a predetermined size, the Messages.log.prev is deleted along with the
entries it contained as the current Messages.log file gets renamed, again as Messages.log.prev.
And again, a new Messages.log file is created. This loop continues indefinitely.
The AIM-CUE uses flash instead of a hard drive, and this results in a different logging behavior
than that of the NM-CUE. Using flash can become an issue at this point because of the limited
number of times the data can write to a section of flash before the flash wears out. The consequence
of this is that the AIM-CUE logs only fatal and error messages to the Messages.log file by
default. The information and warning messages are not written to flash unless specifically
configured to do so.
The AIM-CUE uses a flat log, and when the log is full, any additional output is lost. This is to
ensure that the flash card is not overused.
Note
No Messages.log.prev exists on the AIM-CUE.
Viewing the Messages.log file

Step 1: Verify log file name(s).
- -
--
-
Trace output is
stored in this file

-
Logging output is
---
stored in this file
-
IPTX v2.05-8
If no syslog server is present in the network, an alternative way to view the logging messages
stored in the log file is to send the Messages.log file to an FTP server. After it is on the server,
the file can be viewed using any text editor. Using a text editor is much easier than trying to
view the Messages.log file on the console of the CUE system.
In order for a log file to be displayed on the console or downloaded to a server, the administrator
needs to know the name of the log. The show logs command displays the log files on the
system. The logging messages are stored in the Messages.log file. The name can then be used
to copy the file to a URL.
Viewing the Messages.log File

Using Text Editor
Step 2: Copy the file to the FTP server.
--- ----

Step 3: Open the file with a text editor.

----
-
--
- --
-----
-- -
IPTX v2.05-9
The copy log logname url url command is used to copy the logging files to a server, such as an
FTP server. Then the file can be opened with a text editor. Because the amount of information
in the file can be significant, the search features of many text editors can be useful for finding
specific information or time stamps.
Note
This process works for any log file, including trace output stored in the atrace.log file.
Viewing Logging Messages

on the Console
Displays the contents of a log file to the console of

CUE
- --
--

- -- -- -
-
- --
--
-- -
IPTX v2.05-10
The second way to view the contents of the Messages.log file is from the console. This
is accomplished by using the show log name filename command. The drawback to this
command is that because the output to the console can be significant and the console is a
serial connection that typically runs at 9600 baud, the output can take a very long time to
fully display.
Tip
Use the keystroke CTRL-C to break out of this command while output is displaying to the
console or in the event that a CUE module appears unresponsive.
Viewing Logging Messages

on the Console (Cont.)
Sets the system to send logging messages as they

occur to the console
-
-
-
Fatal logging messages always go to the console
IPTX v2.05-11
Logging messages can be sent to the console of CUE if desired. This is enabled by using the
command logging console [info | warning | error]. Any combination of levels of these logging
messages can be sent to display on the console. The fatal level of logging messages is always
set to display on the console port by default.
Caution
Information messages could create a large quantity of output if turned on.
Configure External Syslog Server
- -- --
Sets the system to log to a syslog server
- --
IPTX v2.05-12
Syslog servers are commonly used to centralize logging information in a network. This also
allows for archiving of messages if desired. If a syslog server is present, it is recommended that
CUE be configured to send its logging messages to the syslog server.
The log server address IP_address command is used to enable sending the logging messages
to a syslog server.
Tip
It is advised that the AIM-CUE be configured to use a syslog server to limit flash wear.
Example: Logging Messages

An invalid PIN is entered
multiple times from
extension 2001
---- -
-- - --
----- -- -
When trying to lower the

maximum voice message
storage parameter to less than
currently used space
IPTX v2.05-13
This figure shows an example of warning level messages and their causes.
Example: Logging Messages (Cont.)

When the system
goes from/to
off-line <->
online mode
- - - -
- - - -
- - - -
-- - --
-----
When a value is
set that is more
than that allowed
by license
IPTX v2.05-14
This figure shows further examples of warning level messages and their causes.
Troubleshooting show Commands
Shows the level of logging currently turned on or off

-
IPTX v2.05-15
The show logging command verifies which levels of logging messages are currently enabled to
the console. The default is that only fatal level logging messages are displayed to the console.
Tracing
Equivalent of IOS software command debug
Composed of modules
Modules composed of one or more entities
Entity may have one or more activities under it
Output stored in atrace.log file as plain text
Used as temporary troubleshooting tool
IPTX v2.05-16
Whereas logging consists of unsolicited messages, tracing is something that the administrator
configures. Tracing in CUE is the equivalent of using debug commands in IOS software.
Knowledge of the system architecture is useful for understanding the structures within the trace
settings. Within trace, there are modules, and within the modules, there are entities. Entities
are composed of one or more activities. When configuring trace, all of these entities or any
combination of them can be enabled.
Trace output is stored in a log file as plain text. This file, atrace.log, is stored on the hard drive
(NM-CUE) or flash (AIM-CUE). Although trace may be enabled from either the GUI or the
CLI, it is viewed from the CLI.
Turning on excessive trace can cause performance issues in the CUE system, so trace should be
used as a temporary troubleshooting tool only. Trace should be turned off when the relevant
output has been gathered.
The trace output can be viewed in one of three different ways:
Displaying the log file: The atrace.log file can be output to the console of CUE.
Echoing to the console: Any new messages can be echoed to the console.
Copying the log file: The log file can be copied to a server and viewed with a text editor.
Trace Control in the GUI
Traces can be
turned on and off
via the GUI.
IPTX v2.05-17
In the Administrator > Traces menu, the module is represented by a folder that can be opened
to view the entities. By selecting the folder level, all traces for that module can be enabled. A
more granular approach can be taken by selecting a specific entity to trace or a more specific
activity under the entity. Be sure to click the Apply button to commit the changes.
Note
Tracing is often turned on and collected under the direction of a Cisco Technical Assistance
Center (TAC) and the results sent to the TAC.
Trace Commands
Tracing can be turned on independently for specific modules.
Within each module are a number of entities that can be traced individually.
Within each entity are activities that can be traced individually.
Trace all will override any prior, more granular trace

commands.
Trace on and off settings return to default if software is
rebooted.

-

IPTX v2.05-18
To enable trace from the CLI, use the trace command. The trace command can be used to turn
on a specific entity, a whole module, or all tracing. Turning on tracing for a higher-level object
overrides lower-level objects. Much like debugging in IOS software on a router, tracing does
not survive the reboot of CUE. The trace setting returns to defaults upon a reboot.
Caution
Be careful of the trace all command because it can create a large amount of output and
have a serious impact on the performance of the CUE module.
Trace Commands (Cont.)
Shows the level of trace enabled

-
----
---
-
-

-
--
IPTX v2.05-19
The show trace command can be used to view the levels of trace that are currently configured.
The module, entity, and setting show up in the output. The setting is a 32-bit value that maps to
the activity or activities that have trace enabled in the system.
On the NM-CUE, there is some level of trace enabled by default. These values, displayed here,
are not easily understood in the CLI, but they can also be viewed in the GUI.
Trace Commands (Cont.)

Identify which activity of a particular entity is being
traced:
Look at the trace setting.
Each bit in the 32-bit mask maps to an activity within the entity.

-
Module
Entity
32-bit Mask
IPTX v2.05-20
The setting field of the show trace command represents the level of tracing enabled. A setting
of ffffffff represents that all activities for an entity are enabled under the specified module.
Traces On by Default on the NM-CUE

-

--

--
--
--
-
--

----
---
-
-

--
-
--
On the AIM-CUE, no traces are on by default.

IPTX v2.05-21
The level of trace that is on by default varies depending on the module. The NM-CUE has
some focused low-level tracing turned on by default. The AIM-CUE has no tracing turned on
by default to prevent unnecessary flash wear.
Note
These values may differ from one version to another.
Viewing and Interpreting

Trace Output
Trace output can be viewed through:
The console of CUE
View the buffer history
Send new trace output to the console
View the atrace.log file
The file in a text editor
Traces cannot be viewed from the GUI.
IPTX v2.05-22
To view the trace output on the console of CUE, there are three choices:
Buffer history: The buffer of trace output can be sent to the console.
Output to console: Any new trace output can be sent to the console.
View the atrace.log: The atrace.log file can be sent to the console.
If the administrator wants to view the trace output in a text editor, the file can be copied to
an FTP server. This allows find and search tools to be used to look through large amounts
of output.

Trace Output (Cont.)
Output of trace webinterface initwizard all/init
for an unsuccessful first-time login

-
--

Date/Time Stamp
Module
Entity
Message Text
IPTX v2.05-23
Trace output has structure and logic to the messages that are output to the atrace.log.
Included in the trace messages are:
Time date stamp: The time that the message was generated
Module: The module that the message originated from
Entity: The entity that the message originated from
Message: Text that conveys relevant information

- -
Outputs the contents of the trace buffer to the

console
-
--
- ----
- -
--
----
-
--
-
-
----
IPTX v2.05-24
The output of trace since the last clearing of the buffer using the
clear buffer command or since the
last reboot, whichever was last, can be accomplished using CLI commands. The CLI command
to view the contents of the trace buffer is show trace buffer [long | short | containing]. The
long option does not use abbreviations for the module and entity like the short option does. One
of the most powerful options is the containing option, with which the administrator can search
for output that contains the specified text. This is very useful for finding messages that may
have occurred at a known time in the past.
Note
The contents of the buffer do not survive a reboot.

Outputs the new trace messages to the console

-
--

---
----
----
---

IPTX v2.05-25
To view trace output as it is generated, use the show trace buffer tail command. This
command sends all new trace messages to the console until the keystroke CTRL-C is entered.
Caution
Understand how much output to expect before turning this command on because output
may be generated faster than it can be sent to the console.

Displays the contents of the atrace.log file to the

console

- -
--

-

-
-

IPTX v2.05-26
The entire contents of the atrace.log file can be sent to the console port of the CUE module.
Please be aware that the amount of output can be largeup to 100 MB of text in the NM-CUE
and up to 10 MB in the AIM-CUE. Another option that allows these larger files to be handled
better is a text editor.
Viewing the atrace.log file

with a Text Editor
Copy the file to the FTP server.
-

Open the file with a text editor.

- -
--

-

-
-

IPTX v2.05-27
To copy the atrace.log file to an FTP server, use the copy log atrace.log url url command.
Interpreting a Debug
on Cisco CallManagerExpress
IOS software has built-in debugging tools
that can be used to troubleshoot problems
regarding the Cisco CallManagerExpress
component part of the integration:
Debugging tools may have a detrimental
performance impact on the router.
Debugging tools should be considered temporary
troubleshooting tools.
Output can be significant in volume.
Use the undebugall or no debug all command, when
finished, to disable all debugging.
IPTX v2.05-28
CUE interacts with and depends upon Cisco CallManager Express, and as a result,
troubleshooting tools on Cisco CallManager Express are important. Debug tools
within IOS software can be used selectively to assist in solving problems.
Debugging tools should be used only when necessary. They should be used only temporarily,
turned on to troubleshoot and turned off when done. This is because of performance issues
use of these tools can have an impact on the system. When debugging is no longer needed, any
debugging function should be turned off using either the undebug all command or the no
debug all command. Both commands disable all debugging.
IOS Debug Commands on

Debug ephone is useful for troubleshooting phones.

--

-

- -
- -
--- ---

IPTX v2.05-29
One very useful debugging command is the debug ephone command, which displays output
regarding the Cisco CallManager Expresscontrolled ephones.
Example
The following shows output for a message left, then retrieved and deleted.

- -

-

IOS Debug Commands: SIP and Misc.

-
- -

- -

--- ---
-- --

IPTX v2.05-30
The debug ccsip command and its modifiers are very useful for debugging the session
initiation protocol (SIP). This is the connection between Cisco CallManager Express and CUE.
Other debug commands that can be useful include the following:
debug tftp Assists in troubleshooting Phone registration problems
debug ip http Troubleshoots GUI web page problems
debug voice ccapi inout Displays calls being set up to a Skinny Client Control Protocol
(SCCP) IP Phone
Caution
The debug voice ccapi inout command can cause a lot of output and overhead and should
be used carefully.
Example
The following shows debug ccsip calls output from checking voice mail.
CMERouter2#debug ccsip calls
SIP Call statistics tracing is enabled
Mar 8 13:27:04.455: //17/000000000000/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x6488517C
State of the Call : STATE_ACTIVE
TCP Sockets Used : NO
Calling Number: 2025559000

Called Number: 2999
Destination Name:
Mar 8 13:27:04.45://17/000000000000/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams:
Media Stream:
Negotiated Codec:
g711ulaw
Negotiated Codec Bytes: 160

Negotiated Dtmf-relay: 0
Dtmf-relay Payload: 0
Source IP Address (Media): 10.20.0.1
Source IP Port (Media): 17330
Destn IP Address (Media): 10.20.0.10
Destn IP Port (Media): 16900
Orig Destn IP Address:Port (Media): 0.0.0.0:0
Mar 8 13:27:10.223://17/000000000000/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB): 0x6488517C
State of the Call :
STATE_DEAD
TCP Sockets Used: NO

Calling Number:
2025559000
Called Number: 2999


Destination Name:
Mar 8 13:27:10.223://17/000000000000/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream:
Negotiated Codec:
g711ulaw
Negotiated Codec Bytes: 160

Negotiated Dtmf-relay: 0
Dtmf-relay Payload: 0
Source IP Address (Media): 10.20.0.1
Source IP Port (Media): 17330
Destn IP Address (Media): 10.20.0.10
Destn IP Port (Media): 16900
Orig Destn IP Address:Port (Media): 0.0.0.0:0
Mar 8 13:27:10.223://17/000000000000/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC): 16
Disconnect Cause (SIP): 200
Software Architecture Overview
This topic presents an overview of the architecture of CUE software.
Software Architecture Overview:

Base-Level Software
BIOS
Applications
Bootloader with recovery

mechanisms
Linux
libc
Linux Kernel
TracingSyslogSNMPRBCP
Bootloader
BIOS
Hardware NM/AIM
Hardware and Operating System
Router Blade Configuration

Protocol (RBCP) to Integrate with
Cisco IOS software
Syslog interface for errors; uses
same FTP syslogserver as host
router
Real-time tracing for applications
and kernel traces
SNMP MIB for platform ID
Standard libraries in libc
IPTX v2.05-31
An understanding of the system architecture is useful in gaining a complete understanding of

CUE. This can be especially helpful in the troubleshooting of CUE.
CUE is based on the Linux operating system. Within the kernel of Linux are several important
functions. They are:
libc: This provides standard libraries that are used within the software.
Tracing: This provides the tracing functions that can be enabled in CUE.
Syslog: This is the system that generates the unsolicited logging messages.
SNMP: The Simple Network Management Protocol allows for remote monitoring,
management, and changes to a network device.
RBCP: The Router Blade Configuration Protocol provides console access across the
backplane of the router.
Note
All shell functions have been removed from the kernel.

Generic Application Infrastructure
Java Virtual Machine
sysdbManagement Interface
Authentication
Tomcat
Open LDAP
PostgreSQL
Applications
Data organized using directories,

nodes, and attributes
Provides both consumer and
provider application program
interfaces (APIs) to data
CLI
Startup/Monitor
sysdb
JVM
Hardware and Operating

System
Application Support Infrastructure
Open Source for:
Open LDAP
PostgreSQL
Tomcat
JAAS Authentication
Startup and Shutdown Component

Monitor
IOS-like CLI with Programmable Syntax
IPTX v2.05-32
The application section of the system architecture is where the CUE applications run. The
different infrastructure components that make up the applications section assist the CUE
application in functioning properly. The infrastructure components are:
Authentication: Java Authentication and Authorization Service (JAAS) is used for
authentication.
HTTP server: A tomcat web server is used for the HTTP server.
LDAP directory: Open LDAP is used for the Lightweight Directory Access Protocol
(LDAP) directory and is where the user and administrator are defined.
Database: PostgreSQL is used for the database and is where voice mailboxes are defined
and voice mails are stored.
JVM: Java Virtual Machine is used in CUE to execute the system and custom scripts.
sysdb: Thissystem utility coordinates the different components that are working together.
Startup monitor: This monitors the bootup process of CUE.
CLI: This is the command-line interface of the CUE system.
System-Level Troubleshooting
This topic describes the guidelines for system-level troubleshooting.

Software Architecture
TUI leverages arrival VXML voice browser
Built on the CRS Java framework
Uses CRS engine for call handling for SIP
Voice mail
VXML scripts launch Java Server Pages (JSPs)
via the tomcat HTTP server
JSPs call upon the Open LDAP schema for user
information
JSPs call PostgreSQLto store mailbox
information and messages
IPTX v2.05-33
The true core applications of CUE are the voice mail and the automated attendant. These
leverage the infrastructure applications to accomplish their tasks.
When a call arrives to either the automated attendant or to voice mail, an .aef script is run
within the Customer Response Solution (CRS) engine. This framework allows an instance of a
script to be executed for each call that arrives. When a call reaches the voice mail application,
voicebrowser.aef, the script has voice extensible markup language (VXML) information. This
launches a Java Server Page (JSP), which can be used to perform various functions, such as
retrieving user information from Open LDAP and sending PostgreSQL database calls to
retrieve voice mails.
on Cisco CallManager Express
- - --
Displays the contents of the atrace.log file to the

console
- - - - -
-- ---
- -
-- -
- -
Verify that the service-module status is in

steady state. RBCP configuration messages go
through only when the service-module is in
steady state.
IPTX v2.05-34
To address problems connecting to the CUE module from the host router, a good place to start
is with the status of the CUE module. The RBCP requires that the service module be in a stable
state before communication can take place. The state of the module can be determined by using
the service-module service-engine mod/port status command. If the module is in a nonsteady
state, a reload of the CUE module may be required. The command to reload the CUE module
from the router is service-module service-engine mod/port reload.
on Cisco CallManager Express (Cont.)
- -
- -
-
- -
-
- - -
- - -
-
--

-
----
-
IPTX v2.05-35
To verify that the CUE module is recognized by the system, use the show version command.
The service module should be seen. If it is not seen with the show version command, some
possible causes are:
Invalid hardware platform: Cisco 2600XM, 2691, 2800 Series, 3700 Series, and
3800 Series platforms only
IOS Release: 12.3(4)T or later for the NM-CUE, 12.3(7)T or later for the AIM-CUE, and
12.3(14)T for the NM-CUE-EC
Feature set of IOS software: Minimum of IOS IP Plus or IP Voice
Seating of module: Reseat the module; OIR on 3745 and 3845 only
Verify IP configuration: View the IP configuration and verify that the service engine has
an IP address and is in the up/up state.
The status of the service engine IP address should be in the up/up condition with a valid
IP address that is on the same subnet as the service module address.
System-Level Troubleshooting:
Verifying Current System Parameters
- - -

- -- -

--

-
- -
-
-
- -
-
- - -
- -

-

- -
-
These show commands give general information

about the versions and licensed features that are
currentlyinstalled.
IPTX v2.05-36
To view the licensed capacity that the CUE system currently has, use the show software
licenses command. This command enables the administrator to verify that the correct license
was installed during deployment or upgrade.
To view the current version that is running on the CUE module, use the show software version
command. This command displays the version of installed packages on the system. This also
shows the amount of time that the CUE module has been running since the last reboot. There is
no other location or command that shows this information.
Note
The version of the boot loader file is commonly a different version from the other files.
Verifying Current System Usage
- -
Number of
- -
mailboxes
-
-
-
Capacity and usage

-
information
-- - --
--
-- --
- --
--
- --
- -
IPTX v2.05-37
To view the current utilization of the CUE system, use the show voicemail usage command.
This is useful when troubleshooting problems which are occurring in numerous mailboxes.
Verifying a Mailbox
-
---
-
-

- -
--
Mailbox settings
-- --

-
Mailbox usage
- --
--
information
--
--
IPTX v2.05-38
To view the specific usage and limits of a single mailbox, use the show voicemail detail
mailbox owner command. This is useful when troubleshooting a single user that is having
problems.
Show System Status
- --
-
-
-
--
- ---
--
- --
--
--
To verify the CPU

utilization and to look for
hung processes, use
these show commands.
IPTX v2.05-39
From the CLI of the CUE module, use the show processes command to view the status of the
processes running on the module. If any of the processes show something other than alive,
a reload of the CUE module may be needed.
To view the CPU utilization, use the show processes cpu command. The information from
this command can be used to build a baseline for the CUE system, which can be useful later
for troubleshooting.
Additional Useful show Commands
Additional useful show commands include:
show ccn application Gives a list of all system and user-defined

applications in the system
show ccn prompts Checks all the system and user-defined prompts
in the system
show ccn scripts Checks all the system and user-defined scripts in
the system
show ntp config Displays a list of NTP servers configured in the
system
show users Displays the list of users
show groups Displays the list of groups
show voicemail detail mailbox <ownerid> -Gives details for the
personal/GDM mailbox
show voicemail mailboxes orphaned Displays a list of orphaned
personal/GDM mailboxes
show running Displays the existing running configuration of the
system
IPTX v2.05-40
There are many other show commands that can be helpful in troubleshooting CUE. These
commands are all executed from the CUE CLI.
GUI Troubleshooting
This topic describes troubleshooting the GUI of the CUE module.
GUI Troubleshooting:
IOS Prerequisite Configuration
These fields must exist for the Cisco
CallManager Express and CUE GUI to operate
correctly
-
-
-
-

-

---
-- -- -
IPTX v2.05-41
For the GUI of CUE to work, there are some prerequisite configurations that must exist on the
Cisco CallManager Express router. The GUI of CUE is tightly integrated with the GUI of Cisco
CallManager Express. In fact, the GUI of CUE requires that the GUI of Cisco CallManager
Express be functioning properly. If problems are found in accessing the GUI of CUE, verify the
following on Cisco CallManager Express:
HTTP server: The HTTP server must be enabled.
Web pages loaded: The web pages must be loaded into the flash of Cisco CallManager
Express.
HTTP server path: The HTTP server must use the Cisco CallManager Express flash to
serve up the web pages.
Credentials: A web administrator must be defined in the Cisco CallManager Express
router.
Flash Files Required
- -
- - - --
-
-
-
IPTX v2.05-42
The web pages must be loaded into flash. The contents of flash can be verified with the
show flash command.
Note
The specific files can vary with the version of Cisco CallManager Express.
Applicable CUE Trace Commands

---
-
--
--

-
Trace module
for the GUI is
trace webinterface
IPTX v2.05-43
To troubleshoot the GUI of CUE, tracing can be enabled. This tracing of the GUI can be
configured with the trace webinterface entityactivity command. Assuming some functionality
of the GUI is working, the tracing of the web interface can be enabled from the GUI of CUE.
Caution
The use of trace as a troubleshooting tool can have a detrimental effect on the performance
of the CUE module.
ReviewAdministrators and Users
Two modes (privilege levels) of access
Administrator mode: Provides functions to
completely provision Cisco CallManager Express
as well as CUE
Default: Administrator mode
User mode: Used to manage user-owned profiles
and preferences; limited capabilities
IPTX v2.05-44
The GUI web page has some limitations on the number of users that can be logged on at any
one time. There can be only one administrator logged in at any time. The second administrator
gets the GUI of a user, not the full menus of the administrator.
Users can have a maximum of four sessions. The fifth user will be denied access.
Failed Login
No JDoe user
A login attempt fails because of nondefined credentials defined

---
-
--- - -
-- - -
--- - -
A login attempt fails because of a bad password
User IPTX fails
to log in
---
-
--- -

--
-
---
-
IPTX v2.05-45
When a login to the GUI fails, whether for a user or an administrator, there are some possible
causes that should be checked.
For a user, the most common problems are a forgotten password and the use of incorrect
usernames. To troubleshoot this, use the trace webinterface sessions login command. If the
password needs to be reset, use the GUI as the administrator to override the current password.
If the username is invalid, create the user or correct the user to the appropriate username.
If an administrator has forgotten the password, another administrator can log in and reset the
password. If there is no other administrator account, then a reinstall and restoration must be
performed. This could be problematic because, in order to make a backup, an administrator
must log in.
Tip
Make an alternate administrator account that can be used in case of an emergency or

personnel changes.
Groups
A group ID is unique and cannot be used to log in to the
CUE GUI.
A group can have only one mailbox.
A group ID cannot be used for a user ID and vice versa.
Users can log in to a group mailbox only via their personal
mailbox.
A group need not have any members.
A group can be a member of any number of other groups.
MWI for individual members of a group requires related
configuration on a Cisco CallManager Expressdedicated
Phone or a shared-line appearance on members Phones.
A group can be a member of another group, and a group can
own another group.
IPTX v2.05-47
When troubleshooting groups it is good to remember some key points:

The group ID must be unique and is not valid to log into the GUI
Groups may have only one mailbox that is shared among the groups members
The group ID may not be used as a user ID, therefore the user checks group voicemails by
entering their user ID first and entering their user TUI
A group can exist without members although messages left for the group will not be able to
be checked
A group may be a part of another group
MWI in will function as long as MWI is configured correctly for the system
A group may not only be a member of another group but the group can also be the owner of
another group thereby giving any members ownership.
Voice Mail and Automated Attendant
This topic describes the guidelines for troubleshooting voice mail and automated attendant.
Voice Mail and Automated Attendant:

Subsystem Trace Commands
Voice Mail:

--

-
--
-

Automated Attendant:

IPTX v2.05-51
The trace command governing voice mail can be invoked with the command trace voicemail
entity activity. This command sends output that can be useful in troubleshooting voice mail. For
troubleshooting the automated attendant, the commands trace webinterface autoattendant
and trace webinterface prompt can be useful.

Interpreting TUI Sessions
Use trace voicemail vxml all command for TUI
session debugging
Displays DTMF received and prompt(s) played in
response to DTMF
Use caller ID for differentiating different calls
into voice mail
Displays voice mail TUI position
Different levels of prompts and menus within
the TUI
IPTX v2.05-52
The script voicebrowser.aef provides the functionality of the CUE voice mail application . This
script uses VXML to implement its functionality. These functions can be viewed by using the
trace voicemail vxml all command.
The caller ID of users calling into voice mail is checked. If there is a mailbox associated to that
phone number, users are prompted for the PIN. If there is no matching mailbox, users are
prompted to enter the extension that their mailbox is associated with.

Interpreting TUI Sessions (Cont.)
A caller leaves a message in voice mail for John Smith

-

-
-
-
--
- -- -

- - -- --
- - -- --
- -- --
-- --
--
---

-- - -

Digit 1 pressed
IPTX v2.05-53
With the trace voicemail vxml all command turned on, a call arriving at voice mail and a
message being left for a subscriber can be viewed in the form of trace output. This output can
include the prompts played and any corresponding wave files that are mapped to those prompts.
The input of the caller can also be displayed in the output of the trace command.

Ford Prefect checks the voice mail that is in the mailbox.
FPrefects password

- -

Continued on the next slide

DTMF digit of 1
is entered

-
-
-

--

-
-
-
-

FPrefects spoken name

IPTX v2.05-54
When the subscriber notices the MWI light and checks the voice mail message, the act of
checking the voice mail can also be viewed in the form of trace voicemail vxml all output.
The password and input of the subscriber logging in and selecting to listen to the message is
displayed in the trace output.

Ford Prefect checks the voice mail that is in the mailbox.
The DTMF tone 3

is entered

-

-

-
-
-

--

Various wave
files played
IPTX v2.05-55
A voice mail message is played to a subscriber, then input is received from the subscriber
instructing the system to delete the message. Various wave files are then played to the
subscriber.

Monitoring Database Activity
Triggering a database lookup query
- -
---
-
-

- -
--
-- --

-
- --
--
--
--
IPTX v2.05-56
The specifics of a users mailbox can be viewed with the command show voicemail detail
mailbox owner. This displays the owner, description, state, size, usage statistics, and
expiration.
Example: Monitoring an Auto Attendant

Application
The mygeneral
script is executed
by a user calling in
to the automated
attendant to which
the mygeneral
script is assigned.
IPTX v2.05-57
In the example, a caller dials into a phone number that has an automated attendant assigned to
it. The automated attendant has been defined by the administrator to play an application called
mygeneral. The following pages show how trace can be used to follow and troubleshoot the call
as it travels through the mygeneral application.

Application (Cont.)

-
--

-

--

-
-
-
- -
- - -
IPTX v2.05-58
The trace ccn engine all command can be used to view the execution of an application. When
the call arrives, the system has been configured to use the application named mygeneral. The
settings on the mygeneral application can be viewed. The settings of ID number, description,
and maximum number of ports can be seen in the output from the trace ccn engine all
command.

Application (Cont.)
- -

- -

- -

- -
- -

- -

- -
- -
- -

IPTX v2.05-59
The trace ccn engine all command is still configured, and the output shows the various steps
being executed. If there is a problem with a step, it will show up in this output. In the case in
the figure, the steps all succeed.

Application
- -
- -
- -

- -
- -

- -
- -
- -
IPTX v2.05-60
The mygeneral application executes successfully, and the call is terminated.
Automated Attendant Application Errors

An automated attendant script is
missing a subflow script entry, or
the script referenced has been
removed from CUE.
-
--
-
-

--
- - -
-
--- --
--
-
IPTX v2.05-61
There is no error checking as a script is uploaded to the CUE system. The CUE system will
allow invalid scripts to be uploaded and applied. If this occurs, the tracing output can be used to
diagnose the problem.
If a script calls upon another script, this uses a call subflow step in the CUE Auto Attendant
Editor (CUE AA Editor). This requires that both scripts be uploaded to the CUE system. If the
subflow is not uploaded, then the output shown in the previous figure will be generated in the
trace ccn engine all output.
Automated Attendant
Application Errors (Cont.)

-- --
-----
--
- - -
--- --
--- - -
--- -
-- - -
-
- -- - -
--
--
-
-
IPTX v2.05-62
This figure shows more specific information about the missing script, which is called
MissingScript.aef.
Monitoring LDAP Access

Use trace voicemail ldap XXXX command
Monitor voice mails LDAP access for user
information
Monitor user search and authentication, spoken
name retrieval, etc.
7008
User is calling in via the Message button from extension 7008
IPTX v2.05-63
In the example in this figure, a caller checks the voice mailbox by pressing the Messages or
Envelope icon button.
Monitoring LDAP Access (Cont.)

-
- - ---

---

-----

-----
User is

-----
authenticated
-
---
---

---
Spoken name is fetched

after authentication
IPTX v2.05-64
This figure shows a user logging in to the voice mailbox. Eventually, the spoken name is
retrieved.
Summary
Summary
A structured and methodical approach to troubleshooting
is the most efficient.
Logs, show commands, and tracing are all tools that are
available to assist with troubleshooting.
An understanding of the architecture of the software will
help you understand troubleshooting.
The CLI has various tools and commands that can be
used if problems with the GUI are encountered.
Trace can be enabled in the GUI, but not viewed. This
must be done from the CLI.
Voice mail and automated attendant problems are
resolved from the CLI through logs,show commands, and
trace output.
IPTX v2.05-65
Module Summary
Module Summary
CUE provides voice mail and automated attendant
functionality that can be managed through the GUI or the CLI.
There are many requirements for installing or upgrading
CUE.
The system software, licensed capacity, or both can be
upgraded.
The automated attendant functions can be customized using
the CUEAA Editor.
Users and groups can be managed by the administrator
using the CLI or the GUI.
GDMs can be created and accessed through the user s
personal mailbox.
Logs, show commands, and traces are all valuable tools for
troubleshooting CUE.
IPTX v2.05-1
Reference
Cisco Systems, Inc. Cisco Unity Express Data Sheet .
http://www.cisco.com/en/US/products/hw/modules/ps3115/products_data_sheet09186a008
01c63a3.html.
Introduction to Cisco Unity Express Voice Mail and Auto Attendant.
http://www.cisco.com/univercd/cc/td/doc/product/voice/unityexp/rel1_1_2/cmecligd/ch1int
ro.pdf.
Introduction to Cisco Unity Express Voice Mail and Auto Attendant.
http://www.cisco.com/en/US/products/sw/voicesw/ps5520/products_administration_guide_
chapter09186a00802caaa3.html.
Module Self-Check
Q1) Choose the router platforms that are supported by the Cisco CallManager Express and
CUE platforms. (Choose all that apply.) (Source: Describing Cisco Unity Express
Installation and Initialization)
A) 3600
B) 2600XM
C) 3800
D) 7200
Q2) Name the three modules that are supported for running CUE. (Choose three.) (Source:
Describing Cisco Unity Express Installation and Initialization)
A) AIM-CUE
B) NM-CUE
C) CUE slot module
D) NM2V-CUE
E) NM-CUE-EC
Q3) What are the hardware specifications for the NM-CUE? (Source: Describing Cisco
Unity Express Installation and Initialization)
A) 2.4-GHz processor
B) 2 GIG of DDR RAM
C) Windows 2003 Slim Version
D) 250 GB ATA HDD
E) none of the above
Q4) What are the two main differences between the memory and storage of the NM-CUE
and the AIM-CUE? (Choose two.) (Source: Describing Cisco Unity Express
A) flash-based storage versus hard drive
based storage
B) the size of the hard drives
C) the operating system
D) the installation packages are different for the different modules
Q5) When rebooting a router that contains the CUE module, what effect does the key
sequence of *** have, if initiated? (Source: Describing Cisco Unity Express
A) causes the router to enter the CUE mode
B) initiates the CUE upgrade wizard
C) interrupts the reload and enters boot loader mode
D) starts up the CUE module
Q6) Which file extension is used on all script names created by the CUE AA Editor?
(Source: Configuring Cisco Unity Express Auto Attendant)
A) .aef
B) .txt
C) .vcs
D) .unt
Q7) How many stored scripts will the AIM-CUE support in the CUE system? (Source:
Configuring Cisco Unity Express Auto Attendant)
A) 12
B) 8
C) 6
D) 4
Q8) How many stored scripts will the NM-CUE support in the CUE system? (Source:
A) 20
B) 10
C) 8
D) 12
Q9) Which is a limitation of using a variable to populate information within a script?
A) Scripts cannot share variables.
B) Variables cannot be modified.
C) Variables are limited to ten characters.
D) There are only 20 variable fields that can be populated.
Q10) Which steps are necessary when making a script available to the CUE system? (Choose
all that apply.) (Source: Configuring Cisco Unity Express Auto Attendant)
A) Save the script with an .aef extension.
B) Upload the script in the repository.
C) Refresh the script.
D) Make the script active.
Q11) Which CLI command shows all available prompts in the CUE system? (Source:
A)
B)
C)
D)
show prompt
show ccn prompts
show cue prompts
show all prompts
Q12) Prompt names cannot be changed within the CUE system. Choose the steps that are
necessary to change a prompt name. (Choose all that apply.) (Source: Configuring
Cisco Unity Express Auto Attendant)
A) Download the prompt to a PC.
B) Change the file name on the PC.
C) Upload the prompt back to the CUE system.
D) Change any parameters in applications to point to the new name.
E) Delete the old prompt.
Q13) What is used to trigger an initial script in the CUE system? (Source: Configuring Cisco
Unity Express Auto Attendant)
A) directory number
B) CED
C) ANI
D) call-in number
Q14) What is the maximum number of automated attendants that can be enabled at one time
in a CUE system? (Source: Configuring Cisco Unity Express Auto Attendant)
A) 10
B) 8
C) 5
D) 12
Q15) After a script has been constructed and uploaded to the CUE, how is it activated?
A) by assigning it to a number that will be dialed by a caller
B) from the GUI, checking the box to make it active
C) from the CLI, issuing the command
ccn active
D) nothing has to be done after uploading script
Q16) When you are recording prompts that will be used in the CUE system, which format
must be used? (Source: Configuring Cisco Unity Express Auto Attendant)
A) G.711 mu-law
B) G.711 a-law
C) G.729 mu-law
D) G.729 a-law
Q17) Where can CUE system users be created? (Choose all that apply.) (Source: Configuring
Cisco Unity Express Users and Groups)
A) TUI
B) CLI
C) GUI
D) initialization wizard
Q18) When creating users in CUE, there is a password field and a PIN field. What is the PIN
field used for? (Choose all that apply.) (Source: Configuring Cisco Unity Express
Users and Groups)
A) logging in to the user
s computer
B) logging in to the IP Phone
C) logging in to e-mail
Q19) When setting mailbox and message limits, which of these fields are required? (Choose
all that apply.) (Source: Configuring Cisco Unity Express Voice Mail)
A) mailbox size
B) maximum call message size
C) maximum greeting size
D) message entry point
Q20) Which of the following must be configured for VPIM networking to function? (Choose
A) remote users
B) the remote location(s)
C) the local location
D) the LRU cache
E) blind addressing
F) the local location must be designated
Q21) When addressing a message from the TUI using spell-by-name, which of the following
scenarios will find a valid remote user, assuming an NM-CUE is being used? (Choose
A) A remote user who has never sent a message to the local location before and is
not configured locally as a remote user.
B) A remote user who has never sent a message to the local location before and is
configured as a remote user on the local CUE module.
C) A remote user sent a message last week, and 60 other remote users sent
messages in the interim. The user is not defined locally as a remote user.
D) A remote user sent a message last week, and 40 other remote users sent
messages in the interim. The user is not defined locally as a remote user.
E) The LRU cache is disabled, and the remote user is not defined locally.
Q22) Broadcasts can be sent by which of the following users? (Choose all that apply.)
(Source: Configuring Cisco Unity Express Voice Mail)
A) all users in the Administrator group
B) users with the Broadcast Message check box enabled
C) all users in the broadcast group
D) all users in any group that has the broadcast capability set
E) any user may send a broadcast locally
F) any user that starts with a numeric value
Q23) Which two of the following best describe a distribution list? (Choose two.) (Source:
Configuring Cisco Unity Express Voice Mail)
A) Determines the administrative abilities of any member of the list.
B) Is used to broadcast messages to all members of the list.
C) Public distribution lists are available to all users.
D) Private distribution lists are specific to a user.
E) May only be defined by the administrator.
F) Are constructed through the TUI only.
Q24) When enabling tracing in the CUE system, where can the output be directed? (Choose
all that apply.) (Source: Troubleshooting Cisco Unity Express)
A) TFTP server
B) Messages.log
C) router
s flash
D) syslog server

Q1) B, C
Q2) A, B, E
Q3) E
Q4) A, B
Q5) C
Q6) A
Q7) D
Q8) C
Q9) A
Q10) A, B, C
Q11) B
Q12) A, B, C, D, E
Q13) D
Q14) C
Q15) A
Q16) A
Q17) B, C, D
Q18) B
Q19) A, B, D
Q20) B, C, F
Q21) B, D
Q22) A, C, D
Q23) C, D
Q24) B, D
Module 6
Introducing IP Quality of
Service
Overview
In order to provide a quality user experience in a converged network, voice traffic must be
protected from other types of traffic. The employment and enforcement of quality of service
(QoS) policies within a network plays an essential role in enabling network administrators and
architects to meet the demands of a converged network. QoS is a crucial element of any
administrative policy that mandates how application traffic is to be handled on a network. This
module introduces the concept of quality of service, explains key issues of networked
applications, and describes different methods for implementing QoS.
Module Objectives
Upon completing this module, you will be able to explain the need to implement QoS and
explain methods for implementing and managing QoS using AutoQoS.
Define the terminology of QoS and explain the key steps to implement QoS on a converged
network
Describe the Differentiated Services model and explain how it can be used to implement
QoS in a network
Describe mechanisms for implementing QoS and identify where in a network the different
QoS mechanisms are commonly used
Explain how to implement a QoS policy using MQC
Identify capabilities provided by AutoQoS and successfully configure QoS on a network
using AutoQoS
Lesson 1
Understanding Quality of
Service
Overview
Before QoS can be configured in a network, it is important to understand just what QoS is and
why it is useful in solving different problems that arise when different traffic types are
converged into a single network infrastructure. The basic concepts and key terminology of QoS
are explained in this lesson. Also included in this lesson are the three steps involved in
implementing a QoS policy and special QoS considerations for LANs.
Objectives
Upon completing this lesson, you will be able to define the terminology of QoS and identify
and explain the key steps in implementing QoS on a converged network. This includes being
able to meet these objectives:
Define the term quality of service with respect to traffic in a network
Identify the four key quality issues with converged networks
Explain the QoS requirements of common types of network applications
Define the term QoS policy
List and explain the key steps involved in implementing a QoS policy on a network
Identify QoS considerations of LAN switches
Quality of Service Defined
This topic defines the term quality of service
Quality of Service Defined
IPTX v2.06-3
QoS is the ability of the network to provide better or special service to selected users and/or
applications to the detriment of other users and/or applications.
Cisco IOS QoS features enable network administrators to control and predictably service a
variety of networked applications and traffic types, thus allowing network managers to take
advantage of a new generation of media-rich and mission-critical applications.
The goal of QoS is to provide better and more predictable network service by providing
dedicated bandwidth, controlled jitter and latency, and improved loss characteristics. QoS
achieves these goals by providing tools for managing network congestion, shaping network
traffic, using expensive wide-area links more efficiently, and setting traffic policies across the
network. QoS offers intelligent network services that when correctly applied, help to provide
consistent, predictable performance.
Converged Networks
This topic explains why QoS was not important in nonconverged networks.
Converged Networks:
Network Before Convergence
Traditional data traffic characteristics:

Bursty data flow
First-come, first-served access

Mostly not time sensitive delays OK
Brief outages are survivable
IPTX v2.06-4
Historically, network engineering has been focused on connectivity. Different traffic types
(data, voice, video, and so on) have different network requirements and traffic characteristics.
Not too long ago, few tools existed to handle the differing needs of these traffic types, forcing
network engineers to build separate networks to handle these traffic requirements. Separate
networks mean higher equipment, installation, and operating costs and require a larger support
staff.
For traditional data networks that are supporting applications such as file transfer or email, the
rates at which data comes onto the network resulted in bursty data flows. The data arrives in
packets and tries to grab as much bandwidth as it can at any given time. The access is very
egalitarian its first come, first served, so whoever gets there first gets the bandwidth.
As a result of this somewhat anarchic way of attacking the network, the data rate is adaptive to
network conditions.
The protocols that have been developed for data networks adapt to the bursty nature of data
networks, and brief outages are survivable. Typically, if retrieving e-mail, a delay of a few
seconds is generally not noticeable. A delay of minutes is annoying, but not serious.
Copyright 2005, Cisco Systems, Inc.
Converged Networks:
Network After Convergence
Converged traffic characteristics:
Constant small packet voice flow competes

with with bursty data flow
Critical traffic must get priority
Voice and video are time sensitive
Brief outages not acceptable
IPTX v2.06-5
This figure shows a converged network in which voice, video, and data traffic use the same
network facilities. Merging different traffic streams with dramatically differing requirements
can lead to a number of problems.
Although packets carrying voice traffic are typically very small, they cannot tolerate delay and
delay variation as they traverse the network or voice quality suffers. Voices break up and words
become incomprehensible.
On the other hand, packets carrying file transfer data are typically large and can survive delays
and drops. It is possible to retransmit part of a dropped file, but it is not feasible to retransmit a
part of a conversation.
The constant, but small packet voice flow competes with bursty data flows. Unless some
mechanism mediates the overall flow, voice quality suffers terribly at times of network
congestion. The critical voice traffic must get priority.
Voice traffic and video traffic are very time sensitive. They cannot be delayed or dropped or the
resulting quality of voice and video suffers.
Converged Networks Quality Issues
This topic describes the basic quality issues presented by converged networks.
Converged Networks:
Quality Issues
Phone Call: I cant understand you; your voice is

breaking up
Teleconferencing: The picture is very jerky.
Voice not synchronized.
Brokerage House: I needed that information 2
hours ago. Where is it?
Call Center: Please hold while my screen
refreshes.
IPTX v2.06-6
With inadequate preparation of the network, voice transmission is choppy or unintelligible.

Gaps in speech are particularly troublesome pieces of speech are interspersed with silence,
and speech literally disappears. In voice mail systems, this silence is a problem. For example,
you dial 68614. When the gaps in speech are actually gaps in the tone, 68614 becomes
6688661144 because the gaps in speech are perceived as pauses in the touch tones.
Poor caller interactivity is the consequence of delay. It causes two problemsecho and talker
overlap. Echo is caused by the signal reflections of the speakers voice from the far-end
telephone equipment back into the speakers ear. Talker overlap (or the problem of one talker
stepping on the other talkers speech) becomes significant if the one-way delay becomes greater
than 250 milliseconds. If bad, calls go to walkie-talkie mode.
Disconnected calls are the worst cases. If there are long gaps in speech, people hang up, or if
there are signaling problems, calls are disconnected. Such events are completely unacceptable
in the voice world yet are quite common for an inadequately prepared data network that s
attempting to carry voice.
Multimedia streams, such as those used in IP telephony or video conferencing, may be
extremely sensitive to delivery delays, creating unique QoS demands on the underlying
networks that carry them. When packets are delivered using the best-effort delivery model, they
may not arrive in order, in a timely manner, or at all. The result is unclear pictures, jerky and
slow movement, and sound not synchronized with the image.
Converged Networks:
Quality Issues (Cont.)
Video Lacking
Proper QoS
Lack of bandwidth: multiple flows compete for a

limited amount of bandwidth
End-to-end delay (fixed and variable): packets have
to traverse many network devices and links that
add up to the overall delay
Variation of delay (jitter): sometimes there is a lot
of other traffic which results in more delay
Packet Loss: packets may have to be dropped
when a link is congested
IPTX v2.06-7
The three big problems facing converged enterprise networks are bandwidth capacity, delay
issues, variable delay, variation of delay (also called jitter), and packet loss.
Large graphic files, multimedia uses, and increasing use for voice and video cause bandwidth
capacity problems over data networks.
Delay is the amount of time it takes for a packet to reach the receiving endpoint after being
transmitted from the sending endpoint. This is called end-to-end delay, and it consists of two
components: fixed network delay and variable network delay. Jitter is the delta, or difference,
in the total end-to-end delay values of two voice packets in the voice flow.
Two types of fixed delay are serialization and propagation. Serialization is the process of
placing bits on the circuit. The higher the circuit speed, the less time it takes to place the bits on
the circuit. Therefore, the higher the speed of the link, the less the amount of serialization delay
that is incurred. Propagation delay is the time it takes for frames to transit the physical media.
Processing delay is a type of variable delay and is the time required by a networking device to
look up the route, change the header, and complete other switching tasks. In some cases, the
packet also must be manipulated. For example, the encapsulation type or the hop count must be
changed. Each of these steps can contribute to the processing delay.
Queuing delay is another type of variable delay and is the time a packet spends in a queue, or
buffer, before being processed. Packets may be queued by routers or switches on an ingress
interface, an egress interface, or both. Queuing delay can be significant if a rate change occurs
or if many interfaces are aggregated into a single uplink.
Loss of packets is usually caused by congestion in the WAN, resulting in speech dropouts or a
stutter effect if the play-out side tries to accommodate by repeating previous packets.
Lack of Bandwidth
This topic explains how a lack of bandwidth can adversely impact QoS in a network and
describes ways to effectively increase bandwidth on a link.
Lack of Bandwidth
Bad Voice Due to

Lack of BW
BWmax = min(10M, 256k, 512k, 100M)=256kbps

BWavail = BW max /Flows
Maximum available bandwidth equals the bandwidth of the
weakest link
Multiple flows are competing for the same bandwidth resulting in
much less bandwidth being available to one single application
IPTX v2.06-8
Bandwidth must be considered on the entire communication path between source and
destination. The example in the figure illustrates an empty network with four hops between a
server and a client. Each hop is using different media with a different bandwidth. The
maximum available bandwidth is equal to the bandwidth of the slowest link. So although the
workstation has 10 Mbps of bandwidth, packets flowing between these devices must cross the
slow-speed WAN link at 256 kbps.
It is rare that only a single communication flow is present on a computer network at a given
time. In reality, multiple communication flows are competing for the same bandwidth. The
calculation of the available bandwidth is much more complex when multiple flows are
traversing the network. The calculation of the available bandwidth in the figure is a rough
approximation.
Ways to Increase Available

Bandwidth
IPTX v2.06-14
The best approach is to increase the link capacity in order to accommodate all applications and
users with some extra bandwidth to spare. This solution sounds simple enough, but in the real
world it brings a high cost in terms of the money and time it takes to implement. Very often,
there are also technological limitations to upgrading to a higher bandwidth.
Another option is to classify traffic into QoS classes and prioritize it according to importance
(business-critical traffic should get enough bandwidth, voice should get enough bandwidth, and
prioritized forwarding and the least important traffic should get the remaining bandwidth).
There are a wide variety of mechanisms available in Cisco IOS software that provide
bandwidth guarantees, for example:
Priority queuing (PQ)
Custom queuing (CQ)
Class-based weighted fair queuing (CBWFQ)
Low latency queuing (LLQ)
LLQ is the preferred bandwidth guarantee mechanism in a Voice over IP (VoIP) network. LLQ
establishes a strict priority queue for voice packets and CBWFQ for other traffic classes.
Optimizing link usage by compressing the payload of frames (virtually) increases the link
bandwidth. Compression, on the other hand, also increases delay because of the complexity of
compression algorithms. Using hardware compression can accelerate the compression of packet
payloads. Stacker and Predictor are two compression algorithms available in Cisco IOS
software.
Another link efficiency mechanism is header compression. This mechanism is especially
effective in networks where most packets carry small amounts of data (payload-to-header ratio
is small). Typical examples of header compression are TCP Header Compression and RealTime Transport Protocol (RTP) Header Compression.
End-to-End Delay
This topic explains how end-to-end delay can adversely impact QoS in a network and describes
ways to effectively reduce delay.
End-to-End Delay
Bad Voice Due to

Delay Variation
Delay = P1 + Q1 + P2 + Q2 + P3 + Q3 + P4 = X ms
End-to-end delay equals a sum of all propagation, processing

and queuing delays in the path
Propagation delay is fixed, processing and queuing delays are
unpredictable in best-effort networks
IPTX v2.06-15
Delay must be considered over the entire communication path, end to end. Therefore, the total
end-to-end delay is the sum total of all delay experience over a communication path between a
sender and receiver. The figure illustrates the impact a network has on the end-to-end delay.
Each hop in the network adds to the overall delay because of these factors:
Propagation delay is caused by the speed-of-light traveling in the media (for example,
speed-of-light traveling in fiber optics or copper media).
Serialization delay is the time it takes to clock all the bits in a packet onto the wire. This is
a fixed value that is a function of the link bandwidth.
Processing and queuing delays within a router, caused by a wide variety of conditions.
People generally ignore propagation delay, but it can be significant (about 40 ms coast to coast
over optical). Ping is one way to measure the round-trip time of IP packets in a network.
Example: Effects of Delay

Customer routers in New York and San Francisco are connected by a 128-kbps WAN link. The
customer sends a 66-byte voice frame across the link. Transmitting the frame (528 bits)
requires 4.125 ms to clock out (serialization delay), but the last bit won t arrive until 40 ms
after it clocks out (propagation delay). The total delay is 44.125 ms. Change the circuit to a
T1 the 528-bit frame takes 0.344 ms to clock out (serialization delay) and the last bit arrives
40 ms after transmission (propagation delay), for a total delay of 40.344 ms. In this case, the
significant factor is propagation delay. In the same situation, but between Seattle and San
Francisco, serialization delay remains the same and propagation delay drops to around 6 ms,
resulting in 528 bits taking 10.125 (128k link) and 6.344 (T1 link). As you can see, both
serialization and propagation delays must be taken into account.
Ways to Reduce Delay
IPTX v2.06-24
Assuming that a router is powerful enough to make a forwarding decision in a negligible

amount of time, it can be said that most of the processing, queuing, and serialization delay is
influenced by the following factors:
Average length of the queue
Average length of packets in the queue
Link bandwidth
There are several approaches to accelerate packet dispatching of delay-sensitive flows:
Increase link capacity. Enough bandwidth causes queues to shrink, making sure packets do
not have to wait long before they can be transmitted. Additionally, more bandwidth reduces
serialization time. On the other hand, this might be an unrealistic approach because of the
costs associated with the upgrade.
A more cost-effective approach is to enable a queuing mechanism that can give priority to
delay-sensitive packets by forwarding them ahead of other packets. There are a wide
variety of queuing mechanisms available in Cisco IOS software that have pre-emptive
queuing capabilities, for example:
PQ
CQ
LLQ
Payload compression reduces the size of packets and, therefore, virtually increases link
bandwidth. Additionally, compressed packets are smaller and need less time to be
transmitted. On the other hand, compression uses complex algorithms that take time and
add to the delay. This approach is, therefore, not used to provide low-delay propagation of
packets.
Header compression is not as CPU-intensive and can be used in combination with other
mechanisms to reduce delay. It is especially useful for voice packets that have a bad
payload-to-header ratio, which is improved by reducing the header of the packet (RTP
Header Compression). By minimizing delay, jitter is also reduced (delay is more
predictable).
Packet Loss
This topic explains how packet loss can adversely impact QoS in a network and describes ways
to manage packet loss so that QoS is not affected.
Packet Loss
Bad Voice Due

to Packet Loss
Tail-drops occur when the output queue is full. These are common
drops which happen when a link is congested
Many other types of drops exist, usually the result of router
congestion, that are uncommon and may require a hardware upgrade
(input drop, ignore, overrun, frame errors)
IPTX v2.06-25
The usual packet loss occurs when routers run out of buffer space for a particular interface
(output queue). The figure illustrates a full output queue of an interface, which causes newly
arriving packets to be dropped. The term used for such drops is simply output drop or taildrop (packets are dropped at the tail of the queue).
Routers might also drop packets for other (less common) reasons, for example:
Input queue dropmain CPU is congested and cannot process packets (the input queue is
full)
Ignorerouter ran out of buffer space
OverrunCPU is congested and cannot assign a free buffer to the new packet
Frame errors (CRC, runt, giant)hardware detected error in a frame
Ways to Prevent Packet Loss
IPTX v1.07-30
Packet loss is usually a result of congestion on an interface. Most applications that use TCP
experience slowdown because of TCP adjusting to the networks resources (dropped TCP
segments cause TCP sessions to reduce their window sizes). There are some other applications
that do not use TCP and cannot handle drops (fragile flows).
The following approaches can be taken to prevent drops of sensitive applications:
Increase link capacity to ease or prevent congestion.
Guarantee enough bandwidth and increase buffer space to accommodate bursts of fragile
applications. There are several mechanisms available in Cisco IOS software that can
guarantee bandwidth and provide prioritized forwarding to drop-sensitive applications, for
example:
PQ
CQ
IP RTP prioritization
CBWFQ
LLQ
Prevent congestion by dropping other packets before congestion occurs. Weighted random
early detection (WRED) can be used to start dropping other packets before congestion
occurs.
There are some other mechanisms that can also be used to prevent congestion:
Traffic shaping delays packets instead of dropping them (generic traffic shaping, frame
relay traffic shaping, and class-based shaping).
Traffic policing can limit the rate of less important packets to provide better service to
drop-sensitive packets (committed access rate and class-based policing).
QoS Requirements
The following topic describes the QoS traffic requirements for voice, video, and data traffic.
QoS Traffic Requirements:

Voice
Latency
<150 ms*
Jitter
< 30 ms*
Loss
< 1%*
17-106 kbps guaranteed
priority bandwidth
per call
150 bps (+ layer 2
overhead) guaranteed
bandwidth for VoiceControl traffic per call
*one-way requirements
IPTX v2.06-31
Voice traffic has extremely stringent QoS requirements. Voice traffic usually generates a
smooth demand on bandwidth and has minimal impact on other traffic as long as it is managed.
While voice packets are typically small (60120 bytes), they cannot tolerate delay or drops.
The result of delays and drops are poor, and often unacceptable, voice quality. But drops cannot
be tolerated, so User Datagram Protocol (UDP) is used to package voice packets because TCP
retransmit capabilities have no value.
Voice packets can tolerate no more than a 150-ms delay (one-way requirement) and no more
than a 1 percent packet loss.
A typical voice call requires from 17 to 106 kbps of guaranteed priority bandwidth plus an
additional 150 bps per call for voice-control traffic. Multiplying these bandwidth requirements
times the maximum number of calls expected during the busiest time period provides an
indication of the overall bandwidth required for voice traffic.

Video-Conferencing
Latency
< 150 ms
Jitter
< 30 ms
Loss
< 1%
Minimum priority
bandwidth guarantee
required is:
Video-Stream + 20%
e.g. a 384 kbps stream would
require 460 kbps of priority
bandwidth
*one-way requirements
IPTX v2.06-32
Video-conferencing applications also have stringent QoS requirements that are similar to voice.
But video-conferencing traffic is often bursty and greedy in nature, and as a result, it can
impact other traffic. Therefore, it is important to understand the video-conferencing
requirements for a network and to provision carefully for it.
The minimum bandwidth for a video-conferencing stream requires the actual bandwidth of the
stream (depending upon the type of video-conferencing coder-decoder [codec] being used) plus
some overhead. For example, a 384-kbps video stream actually requires a total of 460 kbps of
priority bandwidth.

Data
Different applications have
different traffic characteristics
Different versions of the same
application can have different
traffic characteristics
Classify Data into relative-priority
model with no more than four to
five classes:
Mission-Critical Apps: Locally
defined critical applications
Transactional: Interactive
traffic, preferred data service
Best-Effort: Internet, Email,
Unspecified traffic
Less-Than-Best-Effort
(Scavenger): Napster / Kazaa,
peer-to-peer applications
IPTX v2.06-33
The QoS requirements for data traffic vary greatly.

Different applications (for example, a human resources application vs. an ATM application)
can make very different demands on the network. Even different versions of the same
application can have varying network traffic characteristics.
Whereas data traffic can demonstrate either smooth or bursty characteristics, depending upon
the application, data traffic differs from voice and video in terms of delay and drop sensitivity.
Almost all data applications can tolerate some delay and generally can tolerate high drop rates.
Because data traffic can tolerate drops, the retransmit capabilities of TCP become important,
and as a result, many data applications use TCP.
In enterprise networks, important (business-critical) applications are usually easy to identify.
Most applications can be identified based on TCP or UDP port numbers. Some applications use
dynamic port numbers that makes classification somewhat more difficult. Cisco IOS software
supports network-based application recognition (NBAR), which can be used to recognize
dynamic port applications.
It is recommended that data traffic be classified into no more than four to five classes as
described in the figure. Additional classes for voice and video will still remain.
QoS Policy
This topic describes a QoS policy.
QoS Policy
A network-wide
definition of the
specific levels of
quality of service
assigned to different
classes of network
traffic
IPTX v2.06-34
A QoS policy is a networkwide definition of the specific levels of quality of service that are
assigned to different classes of network traffic.
Having a QoS policy is just as important in a converged network as a security policy. A written
and public QoS policy allows users to understand and negotiate for QoS in the network.
QoS Policy (Cont.)

Align Network Resources with Business Priorities
IPTX v2.06-35
The figure shows an example of a QoS policy that could be defined for a network that has the
following three different traffic types:
Enterprise resource planning (ERP) applications have a high QoS priority and must be
available at all times to support replication between systems.
Video applications are guaranteed 100 kbps of bandwidth, but can only operate between
the hours of 9 a.m. to 5 p.m. on weekdays.
Voice traffic is guaranteed less than 150 ms delay in each direction, but that QoS guarantee
is limited to the hours of 9 a.m. to 5 p.m. on weekdays because there are no interoffice calls
during nonbusiness hours. Toll calls are completely restricted to avoid personal long
distance calls.
QoS for Converged Networks
This topic describes the steps for creating a QoS policy.
Step 1:
Identify Traffic and its Requirements
Network audit
Identify traffic on the
network
Business audit
Determine how each
type of traffic is
important for
business
Service levels required
Determine required
response time
IPTX v2.06-36
The first step in implementing a QoS policy is identifying the traffic on the network and
determining the QoS requirements for the traffic.
Determine what users perceive the QoS problems to be. Measure the traffic on the network
during congested periods. Conduct CPU utilization assessment on each of their network devices
during busy periods to determine where problems might be occurring.
Determine the business model and business goals and obtain a list of business requirements.
This will help you define the number of classes of traffic and determine the business
requirements for each.
Define the service levels required by the different classes of traffic in terms of response time
and availability. What is the impact on business if a transaction is delayed by two or three
seconds? Can file transfers wait until the network is quiescent?
Step 2:
Divide the Traffic into Service Classes
IPTX v2.06-37
Once the majority of network traffic has been identified and measured, use the business
requirements to define classes of traffic.
Voice traffic, because of its stringent QoS requirements, will almost always exist in a class by
itself. And Cisco has developed specific QoS mechanisms, such as LLQ, that ensure that voice
always receives priority treatment over all other traffic.
Once the applications with the most critical requirements have been defined, the remaining
traffic classes are defined using the business requirements.
Example: Traffic Classification

For example, a typical enterprise might define five traffic classes as:
Voice: Absolute priority for VoIP traffic
Mission-critical applications: Small set of locally defined critical business applications
Transactional: Database access, transaction services, interactive traffic, preferred data
services
Best-effort: Internet, e-mail
Less-than-best-effort (scavenger): Napster, Kazaa, and other point-to-point applications
Step 3:
Define Policies for Each Service Class
Set minimum
bandwidth guarantee
Set maximum
bandwidth limits
Assign priorities to
each class
Manage congestion
IPTX v2.06-38
Finally, define a QoS policy for each class of service. Defining a QoS policy involves:
Setting a minimum bandwidth guarantee
Setting a maximum bandwidth limit
Assigning priorities to each class
Using QoS technologies, such as advanced queuing, to manage congestion
Example: Defining QoS Policies

For example, using the classes of service defined before, QoS policies could be determined as:
Voice: Minimum bandwidth 1 Mbps; use QoS marking to mark voice packets as priority 5;
use LLQ to always give voice priority
Mission-critical: Minimum bandwidth 1 Mbps; use QoS marking to mark critical data
packets as priority 4; use CBWFQ to prioritize critical class traffic flows
Best-effort: Maximum bandwidth 500 kbps; use QoS marking to mark these data packets
as priority 2; use CBWFQ to prioritize best-effort class traffic flows below mission-critical
and voice
Less-than-best-effort: Maximum bandwidth 100 kbps; use QoS marking to mark lessthan-best-effort data packets as priority 0; use WRED to drop these packets whenever the
network has a propensity for congestion
LAN QoS Considerations
This topic describes LAN QoS considerations.
LAN QoS Considerations
Bandwidth typically not an issue

Buffer congestion is an issue
Buffer congestion occurs when there is a rate change or if
many interfaces are aggregated to a single uplink
IPTX v2.06-39
Until recently, the conventional wisdom has been that QoS was not an issue in an enterprise
campus network where bandwidth is plentiful. As applications such as IP telephony and videoconferencing and mission-critical data applications have been implemented in the campus, it
has become evident that buffer management, not just bandwidth, is an issue that must be
addressed. QoS functions are required to manage bandwidth and buffers to minimize loss,
delay, and delay variation.
In campus LANs, serialization delay is not a significant concern. The amount of time required
for LAN interfaces to serialize the bits of packets onto the physical media is negligible; it is not
significant enough to affect delay-sensitive applications. In addition, propagation delay is of
little concern in LANs because by their very nature, LANs are not geographically dispersed.
The type of delay that is present in LANs is variation in delay, or jitter. This can adversely
affect voice and video quality by introducing packet loss through jitter buffer overruns and
underruns.
An additional contributor to packet loss in campus networks is transmit (Tx) buffer congestion.
Tx buffer congestion can happen if a rate change occurs or if many interfaces are aggregated
into a single uplink, resulting in an oversubscription of the uplink s capacity to buffer packets.
The bits of a traffic flow that run through a high-speed campus network serialize into and out of
switches at different rates depending on the link speed of the physical interfaces they are
traversing. When traffic serializes into a campus switch at gigabit speeds and is switched to a
100-Mb interface, the switch must have buffering capabilities in order to hold, or queue, the
bits while it waits to transmit them. When a Tx buffer fills, ingress interfaces are not able to
place new traffic into the Tx buffer of the target interface. When the switch cannot place a
packet into the transmit queue because of Tx buffer congestion or exhaustion, packet drops will
occur.
Using multiple queues on the transmit interfaces minimizes the potential for dropped or delayed
traffic caused by Tx buffer congestion. By separating voice, video, and mission-critical data
(which are all sensitive to loss, delay, and delay variation) into their own queues, you can
prevent flows from being dropped at the ingress interface even when Tx buffer congestion is
experienced. You can also minimize delayed transmission owing to non-QoS-sensitive traffic
congestion by servicing the QoS-sensitive queues in a priority fashion.
Summary
Summary
Quality of Service (QoS) is the ability of the
network to provide better or special service to
users/applications.
Converged networks create new requirements for
managing network traffic.
Converged networks suffer from different quality
issues including, lack of adequate bandwidth,
end-to-end and variable delay, and lost packets.
Many technologies exist today which can
overcome the problems presented by lack of
bandwidth, delay, variable delay, and packet loss.
IPTX v2.06-40
Summary (Cont.)
Voice, video, and data have very different quality of
service requirements to run effectively on a
network
A QoS Policy is a network-wide definition of the
specific levels of quality of service assigned to
classes of network traffic
Building Quality of Service requires three steps:
identify requirements, classify network traffic, and
define network-wide policies for quality
IPTX v2.06-41
Lesson 2
Describing the Differentiated

Services Model
Overview
Differentiated services (DiffServ) is a multiple-service model designed to satisfy various QoS

requirements. With DiffServ, the network tries to deliver a particular kind of service based on
the QoS specified by each packet. This specification can occur in different ways, for example,
the DiffServ code point (DSCP)in IP uses the QoS specification of each packet to classify,
shape, and police traffic and to perform intelligent queuing of network traffic.
Objectives
Upon completing this lesson, you will be able to describe the DiffServ model and explain how
it can be used to implement QoS in a network. This includes being able to meet these
objectives:
Explain the purpose and key features of the DiffServ model
Describe the basic format and explain the purpose of the DSCP field in the IP header
Define and explain the different per-hop behaviors that are used in DSCP
Explain the interoperability between DSCP-based and IP-precedence-based devices in a
network
Describe data link layer to network layer interoperability between QoS markers
Differentiated Services Model
This topic explains the purpose and function of the DiffServ model.
Differentiated Services Model

Differentiated Services model describes services
associated with traffic classes
Complex traffic classification and conditioning is
performed at network edge resulting in a perpacket Differentiated Services Code Point (DSCP)
No per-flow/per-application state in the core
Core only performs simple per-hop behavior's on
traffic aggregates
The goal is scalability
IPTX v2.06-3
The DiffServ architecture is based on a simple model in which traffic entering a network is
classified and possibly conditioned at the boundaries of the network. The class of traffic is then
identified with either a DSCP or bit marking in the IP header.
DSCP values are used to mark packets and to select a per-hop behavior. Within the core of the
network, packets are forwarded according to the per-hop behavior associated with the DSCP.
The per-hop behavior is defined as an externally observable forwarding behavior applied at a
DiffServ-compliant node to a collection of packets with the same DSCP value.
One of the primary principles of the DiffServ model is that packets should be marked as close
to the edge of the network as possible. It is often a difficult and time-consuming task to
understand to which class of traffic a given data packet belongs, so you want to classify the
data as few times as possible. By marking the traffic at the network edge, core network devices
and other devices along the forwarding path are able to quickly determine the proper class of
service (CoS) to apply to a given traffic flow.
The primary advantage of the DiffServ model is scalability.
Differentiated Services Model (Cont.)

Wide variety of services and provisioning policies
Decouple service and application in use
No application modification
No hop-by-hop signaling
Interoperability with non-DS-compliant nodes
Incremental deployment
IPTX v2.06-4
DiffServ is used for mission-critical applications and for providing end-to-end QoS. Typically,
DiffServ is appropriate for aggregate flow because it performs a relatively coarse level of
traffic classification.
The DiffServ model describes services and allows for many user-defined services to be enabled
in a DiffServ-enabled network.
Services are defined as QoS requirements and guarantees that are provided to a collection of
packets that have the same DSCP value. Services are provided to classes. A class can be
identified as a single application, as multiple applications with like service needs, or as being
based on the source or destination IP addresses in a packet.
Provisioning is used to allocate resources to defined traffic classes. An example of provisioning
is the set of methods used to set up the network configurations on devices that correctly enables
the devices to provide the correct set of capabilities for a particular class of traffic.
The idea is for the network to recognize a class without having to receive any request from
applications. This allows the QoS mechanisms to be applied to applications that do not have the
Resources Reservation Protocol (RSVP) functionality, which is the case with 99 percent of
applications that use IP.
The introduction of DSCPs replaces IP precedence, a 3-bit field in the ToS byte of the IP
header that was originally used to classify and prioritize types of traffic, but maintains
interoperability with non-DiffServ-compliant devices (those that still use IP precedence).
Because of this backward compatibility, DiffServ can be gradually deployed in large networks.
DSCP Encoding
This topic describes the basic format of and explains the purpose of the DSCP field in the IP
header.
DSCP Encoding
DS field: the IPv4 header ToS octet or the IPv6 Traffic

Class octet when interpreted in conformance with
the definition given inRFC2474
DiffServ Code Point (DSCP): the first six bits of the
DS field, used to select a PHB (Per-Hop Behavior;
forwarding and queuing method)
IPTX v2.06-5
The DiffServ model uses the DiffServ field in the IP header to mark packets according to their
classification into behavior aggregates (BAs). The DiffServ field occupies the same 8 bits of
the IP header that were previously used for the CoS byte.
There are three Internet Engineering Task Force (IETF) standards that describe the purpose of
those 8 bits:
RFC 791 includes specification of the CoS field in which the high-order 3 bits are used for
IP precedence. The other bits are used for delay, throughput, reliability, and cost.
RFC 1812 modifies the meaning of the CoS field by removing any meaning from the 5
low-order bits (those bits should all be 0). This gained widespread use and became known
as the original IP precedence.
RFC 2474 replaces the CoS field with the DiffServ field where the 6 high-order bits are
used for the DSCP. The remaining 2 bits are used for explicit congestion notification.
Each DSCP value identifies a BA. Each BA is assigned a per-hop behavior (PHB). Each PHB
is implemented using the appropriate QoS mechanism or set of QoS mechanisms.
Per-Hop Behaviors
This topic defines and explains the different PHBs used in DSCP.
Per-Hop Behavior
DS Code point selects per-hop behavior (PHB)

throughout the network
Default PHB (FIFO, Tail Drop)
Expedited Forwarding (EF) PHB
Assured Forwarding (AF) PHB
Class Selector (IP precedence) PHB
IPTX v2.06-6
The following PHBs are defined by IETF standards:

Default PHB
used for best-effort service (bits 5-7 of DSCP = 000)
Expedited Forwarding PHB

Assured Forwarding PHB
001, 010, 011, or 100)
used for low-delay service (bits 5-7 of DSCP = 101)

used for guaranteed bandwidth service (bits 5-7 of DSCP =
Class-Selector PHB used for backward compatibility with non-DiffServ-compliant

devices (RFC 1812 compliant devices) (bits 2-4 of DSCP = 000)
Per-Hop Behavior (Cont.)
Expedited Forwarding (EF) PHB:

Ensures a minimum departure rate
Guarantees bandwidth the class is guaranteed an amount of
bandwidth with prioritized forwarding
Polices bandwidth the class is not allowed to exceed the guaranteed
amount (excess traffic is dropped)
DSCP value: 101110; looks like IP precedence 5 to
non-DS compliant devices
Bits 5-7: 101 = 5 (Same three bits used for IP Precedence)
Bits 3-4: 11 = No drop probability
Bit 2: just 0
IPTX v2.06-7
The Expedited Forwarding PHB is identified based on the following parameters:

Ensures a minimum departure rate to provide delay-sensitive applications with the
lowest possible delay
Guarantees bandwidth to prevent starvation of the application if multiple applications are
using Expedited Forwarding PHB
Polices bandwidth to prevent starvation of other applications and classes that are not using
Expedited Forwarding PHB
Packets requiring Expedited Forwarding should be marked with DSCP binary value 101110 (46
or 0x2E).
Non-DiffServ-compliant devices regard Expedited Forwarding DSCP value 101110 as IP
precedence 5 (101), which is the highest user-definable IP precedence and is typically used for
delay-sensitive traffic such as VoIP. Bits 5-7 of the Expedited Forwarding DSCP value are 101,
which matches IP precedence 5 and hence allows backward compatibility.
Assured Forwarding (AF) PHB:

Guarantees bandwidth
Allows access to extra bandwidth if available
Four standard classes (af1, af2, af3 and af4)
DSCP value range: aaadd0
aaa is a binary value of the class
dd is drop probability
IPTX v2.06-8
The Assured Forwarding PHB is identified based on the following parameters:

Guarantees a certain amount of bandwidth to an Assured Forwarding class
Allows access to extra bandwidth, if available
Packets requiring Assured Forwarding PHB should be marked with DSCP value aaadd0, where
aaa is the number of the class and dd is the drop probability
There are four standard-defined Assured Forwarding classes. Each class should be treated
independently and have bandwidth allocated based on the QoS policy.
Each AF class uses three DSCP values

Each AF class is independently forwarded with its guaranteed
bandwidth
Congestion Avoidance is used within each class to prevent
congestion within the class
IPTX v2.06-9
As the figure illustrates, three DSCP values are assigned to each of the four Assured
Forwarding classes.
Assured Forwarding Class
Assured Forwarding Class
Drop Probability
Assured Forwarding Class 1 Low 001 01 0

Medium 001 10 0
High 001 11 0
Medium 010 10 0
High 010 11 0
Medium 011 10 0
High 011 11 0
Medium 100 10 0
High 100 11 0
DSCP Value

A DS node must allocate a configurable,
minimum amount of forwarding resources
(buffer space and bandwidth) per AF class
Excess resources may be allocated between
non-idle classes. The manner must be specified
Reordering of IP packets of the same flow is not
allowed if they belong to the same AF class
IPTX v2.06-10
An Assured Forwarding implementation must attempt to minimize long-term congestion within

each class while allowing short-term congestion resulting from bursts. This requires an active
queue management algorithm. An example of such an algorithm is the congestion avoidance
technique WRED.
The Assured Forwarding specification does not define the use of a particular algorithm, but
does require that several properties hold.
An Assured Forwarding implementation must detect and respond to long-term congestion
within each class by dropping packets while handling short-term congestion (packet bursts) by
queuing packets. This implies the presence of a smoothing or filtering function that monitors
the instantaneous congestion level and computes a smoothed congestion level. The dropping
algorithm uses this smoothed congestion level to determine when packets should be discarded.
The dropping algorithm must treat all packets within a single class and precedence level
identically. This implies that, for any given smoothed congestion level, the discard rate of a
particular microflows packets within a single precedence level will be proportional to that
flows percentage of the total amount of traffic passing through that precedence level.
Backward Compatibility Using the Class Selector
This topic explains the interoperability between DSCP-based and IP precedence based devices
in a network.
Backward Compatibility Using the Class

Selector
Class Selector xxx000 DSCP

Compatibility with current IP precedence usage (RFC
1812) = maps IP precedence to DSCP
Differentiates probability of timely forwarding ( xyz000) >=
(abc000) if xyz > abc
If a packet has DSCP = 011000, then It has a greater
probability of timely forwarding than a packet with
DSCP = 001000
IPTX v2.06-11
The meaning of the 8 bits in the DiffServ field of the IP packet has changed over time to meet
the expanding requirements of IP networks.
Originally, the field was referred to as the CoS field and the first 3 bits of the field (bits 7-5)
defined a packets IP precedence value. A packet could be assigned one of six priorities based
on the value of the IP precedence value (8 total values minus 2 reserved values). IP precedence
5 (101) was the highest priority that could be assigned (RFC 791).
RFC 2474 replaced the CoS field with the DiffServ field in which a range of eight values
(Class-Selector PHB) is used for backward compatibility with IP precedence. There is no
compatibility with other bits used by the CoS field.
The Class-Selector PHB was defined to provide backward compatibility for DSCP with CoSbased IP precedence. RFC 1812 prioritizes packets according to the precedence value. The
PHB is defined as the probability of timely forwarding. Packets with higher IP precedence
should (on average) be forwarded in less time than packets with lower IP precedence.
The last three bits of the DSCP (2-4) set to 0 identify a Class-Selector PHB.
Mapping CoS to Network Layer QoS
This topic describes the different QoS markers that can be used for interoperability between
data link layer and network layer QoS.
Mapping CoS to Network Layer QoS
IPTX v2.06-12
IP headers are preserved end-to-end when IP packets are transported across a network; data link
layer headers are not. This means that the IP layer is the most logical place to mark packets for
end-to-end QoS. However, there are edge devices that can mark frames only at the data link
layer, and there are many other network devices that operate only at the data link layer. To
provide true end-to-end QoS, the ability to map QoS marking between the data link layer and
the network layer is essential.
Enterprise networks typically consist of a number of remote sites connected to the headquarters
campus via a WAN. Remote sites typically consist of a switched LAN, and the headquarters
campus network is both routed and switched. Providing end-to-end QoS through such an
environment requires that CoS markings that are set at the LAN edge be mapped into QoS
markings (such as IP precedence or DSCP) for transit through campus or WAN routers.
Campus and WAN routers can also map the QoS markings to new data link headers for transit
across the LAN. In this way, QoS can be preserved and uniformly applied across the enterprise.
Service providers offering IP services have a requirement to provide robust QoS solutions to
their customers. The ability to map network layer QoS to link layer CoS enables these
providers to offer a complete end-to-end QoS solution that does not depend on any specific link
layer technology.
Summary
Summary
The Differentiated Services model describes services
associated with traffic classes.
Complex traffic classification and conditioning is performed
at network edge resulting in a per-packet Differentiated
Services Code Point (DSCP).
A per-hop behavior is an externally observable forwarding
behavior applied at a DS-compliant node to a DS behavior
aggregate.
The Expedited Forwarding (EF) PHB guarantees and polices
bandwidth while ensuring a minimum departure rate.
The Assured Forwarding (AF) PHB guarantees bandwidth
while providing four classes each having three DSCP values.
The DSCP is backward compatible with IP Precedence
(Class Selector Code point).
IPTX v2.06-13
Lesson 3
Understanding IP QoS
Mechanisms
Overview
IP QoS mechanisms are used to implement a coordinated QoS policy in devices throughout the
network. The moment an IP packet enters the network, it is classified and usually marked with
its class identification. From that point on, the packet is treated by a variety of IP QoS
mechanisms according to the packets classification. Depending upon the mechanisms it
encounters, the packet could be expedited, delayed, compressed, fragmented, or even dropped.
Objectives
Upon completing this lesson, you will be able to correctly match QoS actions to mechanisms
for implementing QoS and identify where in a network the different QoS mechanisms are
commonly used. This includes being able to meet these objectives:
List the key mechanisms that are used to implement QoS in an IP network
Define classification and identify where classification is commonly implemented in a
network
Define marking and identify where marking is commonly implemented in a network
Explain the concept of trust boundaries and how they are used with classification and
marking
Define congestion management and identify where congestion management is commonly
implemented in a network
Define traffic shaping and identify where shaping is commonly implemented in a network
Explain the functions of compression and identify where compression is commonly
implemented in the network
Explain the functions of link fragmentation and interleaving (LFI) and identify where LFI
is commonly implemented in the network
QoS Mechanisms
This topic lists the key mechanisms use to implement QoS in an IP network.
QoS Mechanisms
Classification: Each class-oriented QoS mechanism has to
support some type of classification
Marking: Used to mark packets based on classification
and/or metering
Congestion Management: Each interface must have a
queuing mechanism to prioritize transmission of packets
Traffic Shaping: Used to enforce a rate limit based on the
metering by delaying excess traffic
Compression: Reduces serialization delay and bandwidth
required to transmit data by reducing the size of packet
headers or payloads
Link Efficiency: Used to improve bandwidth efficiency
through compression and link fragmentation and interleaving
IPTX v2.06-3
This figure shows the main categories of QoS tools used in IPTX implementations and
describes how they contribute to QoS.
Classification and marking are the identifying and splitting of traffic into different classes and
the marking of traffic according to behavior and business policies.
Congestion management is the prioritization, protection, and isolation of traffic based on
markings.
Traffic conditioning mechanisms shape traffic to control bursts by queuing traffic.
One type of link efficiency technology is packet header compression, which improves the
bandwidth efficiency of a link. Another technology is LFI, which can decrease the jitter of
voice transmission by reducing voice packet delay.
Classification
This topic defines classification and identifies where classification is commonly implemented
in a network.
Classification
Classification is the identifying and splitting of traffic into

different classes
Traffic can be classed by various means including the DSCP
Modular QoS CLI allows classification to be implemented
separately from policy
IPTX v2.06-6
Classification is the identifying and splitting of traffic into different classes. In a QoS-enabled
network, all traffic is classified at the input interface of every QoS-aware device. Packet
classification can be recognized based on many factors, including:
DSCP
IP precedence
Source address
Destination address
The concept of trust is key for deploying QoS. Once an end device (such as a workstation or an
IP Phone) marks a packet with CoS or DSCP, a switch or router has the option of accepting or
not accepting values from the end device. If the switch or router chooses to accept the values,
the switch or router trusts the end device. If the switch or router trusts the end device, it does
not need to do any reclassification of packets coming from that interface. If the switch or router
does not trust the interface, then it must perform a reclassification to determine the appropriate
QoS value for packets coming from that interface. Switches and routers are generally set to not
trust end devices and must specifically be configured to trust packets coming from an interface.
Marking
This topic defines marking and identifies where marking is commonly implemented in a
network.
Marking
Marking, which is also known as coloring, marks each packet

as a member of a network class so that the packets class can
be quickly recognized throughout the rest of the network
IPTX v2.06-9
Marking, which is also known as coloring, involves marking each packet as a member of a
network class so that devices throughout the rest of the network can quickly recognize the
packets class. Marking is performed as close to the network edge as possible and is typically
done using the Modular QoS command-line interface (CLI) (MQC).
QoS mechanisms set bits in the DSCP or IP precedence fields of each IP packet according to
the class that the packet is in. Other fields can also be marked to aid in the identification of a
packets class, such as CoS or a Frame Relay discard eligible (DE) bit.
Other QoS mechanisms use these bits to determine how to treat the packets when they arrive. If
they are marked as high-priority voice packets, the packets generally are never dropped by
congestion avoidance mechanisms and are given immediate preference by congestion
management queuing mechanisms. On the other hand, if the packets are marked as low-priority
file transfer packets, they are dropped when congestion is occurring and are generally moved to
the end of the congestion management queues.
Trust Boundaries
This topic describes the concept of trust boundaries and how they are used with classification
and marking.
Trust Boundaries
Classify Where?
Ciscos QoS model assumes that the CoS carried in a frame may or
may not be trusted by the network device
For scalability, classification should be done as close to the edge as
possible
End hosts can mostly not be trusted to tag a packet s priority correctly
The outermost trusted devices represent the trust boundary
1
1 and 2
2 are optimal, 3
3 is acceptable (if access switchcannot
perform classification)
IPTX v2.06-10
The concept of trust is important and is integral to deploying QoS. After the end devices have
set CoS or TOS values, the switch has the option of trusting them. If the switch trusts the
values, it does not need to reclassify; if it does not trust the values, then it must perform
reclassification for the appropriate QoS.
The notion of trusting or not trusting forms the basis for the trust boundary. Ideally,
classification should be done as close to the source as possible. If the end device is capable of
performing this function, the trust boundary for the network is at the end device. If the device is
not capable of performing this function or if the wiring closet switch does not trust the
classification done by the end device, the trust boundary might shift. How this shift happens
depends on the capabilities of the switch in the wiring closet. If the switch can reclassify the
packets, the trust boundary is in the wiring closet. If the switch cannot perform this function,
the task falls to other devices in the network, going toward the backbone. In this case, one good
rule is to perform reclassification at the distribution layer. This means that the trust boundary
has shifted to the distribution layer. It is likely that there is a high-end switch in the distribution
layer with features to support this function. If possible, try to avoid performing this function in
the core of the network.
Trust Boundaries
Mark Where?
For scalability, marking should be done as close to the

source as possible
IPTX v2.06-11
Classification should take place at the network edge, typically in the wiring closet or within
endpoints (servers, hosts, video endpoints, or IP telephony devices) themselves.
For example, consider the campus network containing IP telephony and host endpoints. Frames
can be marked as important by using link layer CoS settings or the IP precedence and DSCP
bits in the CoS and DiffServ field in the IPv4 header. Cisco IP Phones can mark voice packets
as high priority using CoS as well as ToS. By default, the IP Phone sends 802.1p tagged
packets with the CoS and ToS set to a value of 5 for its voice packets. Because most PCs do not
have an 802.1q-capable network interface card (NIC), they send packets untagged. This means
that the frames do not have an 802.1p field. Also, unless the applications that are running on the
PC send packets with a specific CoS value, this field is 0.
Note
A special case exists in which the TCP/IP stack in the PC has been modified to send all
packets with a ToS value other than 0. Typically this does not happen, and the ToS value is
zero.
Even if the PC is sending tagged frames with a specific CoS value, Cisco IP Phones can zero
out this value before sending the frames to the switch. This is the default behavior. Voice
frames coming from the IP Phone have a CoS of 5, and data frames coming from the PC have a
CoS of 0.
If the end device is not a trusted device, the reclassification function (setting/zeroing the bits in
the CoS and ToS fields) can be performed by the access layer switch if that device is capable of
doing so. If the device is not capable, then the reclassification task falls to the distribution layer
device. If reclassification cannot be performed at one of these two layers, a hardware upgrade
or a Cisco IOS software upgrade or both may be necessary.
Connecting the IP Phone
802.1Q trunking between the switch and IP phone for multiple VLAN support
(separation of voice/data traffic) is preferred
The 802.1Q header contains the VLAN information and the CoS 3-bit field,
which determines the priority of the packet
For most Cisco IP phone configurations, traffic sent from the IPphone to the
switch is trusted to ensure that voice traffic is properly prioritized over other
types of traffic in the network
The trusted boundary feature usesCDP to detect an IP phone and otherwise
disables the trusted setting on the switch port to prevent misuse of a highpriority queue
IPTX v2.06-13
In a typical network, you connect a Cisco IP Phone to a switch port as shown in the figure.
Traffic sent from the telephone to the switch is typically marked with a tag that uses the 802.1q
header. The header contains the VLAN information and the CoS 3-bit field, which determines
the priority of the packet. For most Cisco IP Phone configurations, the traffic sent from the
telephone to the switch is trusted to ensure that voice traffic is properly prioritized over other
types of traffic in the network.
By using the mls qos trust device cisco-phone and the mls qos trust cos interface
configuration commands, you can configure the switch port to which the telephone is
connected to trust the CoS labels of all traffic received on that port.
Congestion Management
This topic defines congestion management and identifies where congestion management is
commonly implemented in a network.
Congestion Management
Congestion management uses the marking on each packet to

determine which queue to place packets in
Congestion management utilizes sophisticated queuing
technologies such as Weighted Fair Queuing (WFQ) and Low
Latency Queuing (LLQ) to ensure that time-sensitive packets
like voice are transmitted first
IPTX v2.06-14
Congestion management mechanisms (queuing algorithms) use the marking on each packet to
determine which queue to place packets in. Different queues are given different treatment by
the queuing algorithm based on the class of packets in the queue. Generally, queues with
higher-priority packets receive preferential treatment.
All output interfaces in a QoS-enabled network use some kind of congestion management
(queuing) mechanism to manage the outflow of traffic. Each queuing algorithm is designed to
solve a specific network traffic problem and has a particular effect on network performance.
The Cisco IOS software features for congestion management, or queuing, include:
First-in, first-out (FIFO)
PQ
CQ
Weighted fair queuing (WFQ)
CBWFQ
LLQ
LLQ is now the preferred method. It is a hybrid (of PQ and CBWFQ) queuing method that was
developed specifically to meet the requirements of real-time traffic, such as voice.
Traffic Shaping
This topic defines traffic shaping and identifies where traffic shaping is commonly
implemented in a network.
Shaping
Shaping queues packets when a pre-defined limit is

reached
IPTX v2.06-17
Shaping helps smooth out speed mismatches in the network and limits transmission rates.
Shaping mechanisms are used on output interfaces. They are typically used to limit the flow
from a higher-speed link to a lower-speed link to ensure that the lower-speed link does not
become overrun with traffic. Shaping can also be used to manage the flow of traffic at a point
in the network where multiple flows are aggregated.
Ciscos QoS software solutions include two traffic-shaping tools to manage traffic and
congestion on the network: generic traffic shaping and Frame Relay traffic shaping (FRTS).
Compression
This topic explains the functions of compression and identifies where compression is
commonly implemented in the network.
Compression
Header compression can dramatically reduce the

overhead associated with voice transport
IPTX v2.06-21
Cisco IOS QoS software offers link-efficiency mechanisms that work in conjunction with
queuing and traffic shaping to manage existing bandwidth more efficiently and predictably.
One of these is compressed RTP (cRTP).
RTP is a host-to-host protocol used for carrying converged traffic, including packetized audio
and video, over an IP network. RTP provides end-to-end network transport functions that are
intended for applications that are transmitting real-time requirements, such as audio, video,
simulation data multicast, or unicast network services.
A voice packet carrying a 20-byte voice payload, for example, typically carries a 20-byte IP
header, an 8-byte UDP header, and a 12-byte RTP header. As shown in the figure, by using
cRTP, the three headers of a combined 40 bytes are compressed down to 2 or 4 bytes,
depending on whether the cyclic redundancy check (CRC) is transmitted. This compression can
dramatically improve the performance of a link.
Typically, compression is used on WAN links between sites to improve bandwidth efficiency.
Link Fragmentation and Interleaving
This topic explains the functions of LFI and identifies where it is commonly implemented in
the network.
Link Fragmentation and Interleaving
Without Link Fragmentation and Interleaving, time-sensitive

voice traffic can be delayed behind long, non-time-sensitive
data packets
Link Fragmentation breaks long data packets apart and
interleaves time-sensitive packets so that they are not delayed
IPTX v2.06-23
Interactive traffic, such as Telnet and VoIP, is susceptible to increased latency and jitter when
the network processes large packets, such as LAN-to-LAN FTP Telnet transfers traversing a
WAN link. This susceptibility increases as the traffic is queued on slower links.
LFI can reduce delay and jitter on slower-speed links by breaking up large datagrams and
interleaving low-delay traffic packets with the resulting smaller packets.
Typically, LFI is used on WAN links between sites to ensure minimal delay for voice and video
traffic.
Summary
Summary
Different mechanisms can be used to implement QoS in a
network: classification, marking, congestion management,
shaping, compression, and link efficiency.
First step is always to identify classes of traffic so that the
appropriate QoS treatment can be applied to different traffic
types.
Traffic conditioners such as shapers are used to limit the
maximum rate of traffic sent or received on an interface.
Compression is a technique that is used to reduce the
amount of bandwidth required to transmit data by
compressing packet headers or payloads.
Bandwidth efficiency can be improved through link efficiency
mechanisms such as compression and fragmentation and
interleaving.
IPTX v2.06-24
Lesson 4
Introducing Modular QoS CLI

Overview
This chapter explains how to implement QoS policies using MQC.
Objectives
Upon completing this lesson, you will be able to describe MQC and its associated components.
Explain at a high level, the MQC method of configuring QoS
Differentiate between class maps, policy maps, and service policies
Describe how a class map is used to define a class of traffic
Describe the Cisco IOS MQC commands that are required to configure and monitor a class
map
Describe how a policy map is used to assign a QoS policy to a class of traffic
Describe the Cisco IOS MQC commands that are required to configure and monitor a
policy map
Explain how a service policy is assigned to an interface
Describe the MQC commands that are used to attach a service policy to an interface
Introducing Modular QoS CLI
This topic describes the MQC method for implementing QoS on a network.
Modular QoS CLI

The Modular QoS CLI
(MQC) provides a
modular approach to
configuration of QoS
mechanisms
First build modules
defining classes of
traffic
Then build modules
defining QoS policies
and assign classes to
policies
Finally, assign the
policy modules to
interfaces
IPTX v2.06-5
MQC was introduced to allow any supported classification to be used with any QoS
mechanism.
The separation of classification from the QoS mechanism allows new Cisco IOS versions to
introduce new QoS mechanisms and reuse all available classification options. And old QoS
mechanisms can benefit from new classification options.
Another important benefit of MQC is the reusability of configuration. MQC allows the same
QoS policy to be applied to multiple interfaces. MQC, therefore, is a consolidation of all the
QoS mechanisms that have so far only been available as stand-alone mechanisms.
Modular QoS CLI Components
This topic describes the three steps involved in implementing a QoS policy using MQC.
Modular QoS CLI Components
Define Classes
of Traffic
Define QoS Policies

for Classes
What traffic do
we care about?
What will be done to

this traffic?
Each class of
traffic is defined
using a Class Map
Defines a Policy Map

which configures the
QoS features
associated with a
traffic class previously
identified using a
class map
Apply a Service
Policy
Where will this
policy be
implemented?
Attaches a Service
Policy configured
with a policy map
to an interface
IPTX v2.06-8
Implementing QoS by using MQC consists of three steps:

First, configure classification by using the class-map command.
Second, configure traffic policy by associating the traffic class with one or more QOS
features using the policy-map command.
Third, attach the traffic policy to inbound or outbound traffic on interfaces, subinterfaces,
or virtual circuits by using the service-policy command.
Example: Configuring MQC

Consider a network with voice telephony:
First, classify traffic as voice, high priority, low priority, and browser in a class map
Second, build a single policy map that defines three different traffic policies (different
bandwidth and delay requirements for each traffic class): NoDelay, BestService, and
Whenever and assign the already-defined classes of traffic to the policies. Voice is assigned
to NoDelay. High priority traffic is assigned to BestService. Both low priority and browser
traffic are assigned to Whenever.
Finally, assign the policy map to selected router and switch interfaces.
Class Maps
This topic describes the use of class maps.
Class Maps
What traffic do we care about?
Each class is identified using a Class Map
A traffic class contains three major elements:
A case-sensitive name
A series of match commands
If more than one match command exists in the traffic class, an
instruction on how to evaluate these match commands
Class maps can operate in two modes:
Match All: all conditions have to succeed
Match Any: at least one condition must succeed
The default mode is Match all
Multiple traffic classes can be configured as a single traffic class
(nested)
IPTX v2.06-9
Class maps are used to create classification templates that are later used in policy maps where
QoS mechanisms are bound to classes.
Routers can be configured with a large number of class maps (currently limited to 256). Each
traffic policy, however, may support a limited number of classes, for example, CBWFQ and
class-based LLQ are limited to 64 classes.
A class map is created using the class-map global configuration command. Class maps are
identified by case-sensitive names. Each class map contains one or more conditions that
determine if the packet belongs to the class.
There are two ways of processing conditions when there is more than one condition in a class
map:
Match all
Match any
all conditions have to be met to bind a packet to the class

at least one condition has to be met to bind the packet to the class
The default match strategy of class maps is Match all.
Classification Using Class Maps
Match-all requires all conditions to return a positive answer. If one

condition is not met the class map will return a no match result
Match-any requires at least one condition to return a positive answer.
If no condition is met the class map will return a no match result
IPTX v2.06-10
The figure illustrates the full process of determining if a packet belongs to a class (match) or
not (no match).
The process goes through the list of conditions:
A match result is returned if one of the conditions is met and the match-any strategy is
used.
A match result is returned if all conditions are met and the match-all strategy is used.
Otherwise, a no match result is returned.
Configuring and Monitoring Class Maps
This topic explains the commands necessary for configuring and monitoring class maps.
Configuring Class Maps
-- --
Enter the class-map configuration mode

Specify the matching strategy
Match-all is the default matching strategy
Use at least one condition to match packets
- -
It is recommended to use descriptions in large and complex

configuration
The description has no operational meaning
IPTX v2.06-11
Use the class-map global configuration command to create a class map and enter the class map
configuration mode. A class map is identified by a case-sensitive name; therefore, all
subsequent references to the class map must use exactly the same name.
At least one match command should be used within the class-map configuration mode (match
none is the default).
The description command is used for documenting a comment about the class map.
Example: Class-Map Example

The following example shows a traffic class configured with the class-map match-all
command:
-- -

-
--
If a packet arrives on a router with traffic class called cisco1 configured on the interface, the
packet is evaluated to determine if it matches the IP protocol, QoS group 4, and access group
101. If all three of these match criteria are met, the packet matches traffic class cisco1.
Configuring Classification Using

Special Options
The not keyword inverts the condition
-- --
One class map can use another class map for classification
Nested class maps allow generic template class maps to be
used in other class maps
The any keyword can be used to match all packets

IPTX v2.06-12
The match commands are used to specify various criteria for classifying packets. Packets are
checked to determine whether they match the criteria specified in the match commands; if a
packet matches the specified criteria, that packet is considered a member of the class and is
forwarded according to the QoS specifications set in the traffic policy. Packets that fail to meet
any of the matching criteria are classified as members of the default traffic class. MQC does not
necessarily require that users associate a single traffic class with one traffic policy. Multiple
traffic classes can be associated with a single traffic policy using the matchany command.
Match not inverts the condition specified. It specifies a match criterion value that prevents
packets from being classified as members of a specified traffic class. All other values of that
particular match criterion belong to the class.
MQC allows multiple traffic classes (nested traffic classes, which are also called nested class
maps) to be configured as a single traffic class. This nesting can be achieved with the use of the
match class-map command. The only method of combining match-any and match-all
characteristics within a single traffic class is with the match class-map command.
Example: Using the match Command

The following example shows a traffic class configured with the class-map match-any
command:
-- -

-
--
In traffic class cisco2, the match criteria are evaluated consecutively until a successful match
criterion is located. The packet is first evaluated to determine whether IP protocol can be used
as a match criterion. If IP protocol is not a successful match criterion, then QoS group 4 is
evaluated as a match criterion. If QoS group 4 is not a successful match criterion, then accessgroup 101 is evaluated as a match criterion. Each matching criterion is evaluated to see if the
packet matches that criterion. Once a successful match occurs, the packet is classified as a
member of traffic class cisco2. If the packet matches none of the specified criteria, the packet is
classified as a member of the traffic class.
Example: Nested Traffic Class to Combine match-any and

match-all Characteristics in One Traffic ClassThe only method of including
both match-any and match-all characteristics in a single traffic class is to use the match classmap command. To combine match-any and match-all characteristics into a single class, a
traffic class created with the match-any instruction must use a class configured with the matchall instruction as a match criterion (through the match class-map command) or vice versa.
The following example shows how to combine the characteristics of two traffic classes, one
with match-any and one with match-all characteristics, into one traffic class with the match
class-map command. The result of traffic class class4 requires a packet to match one of the
following three match criteria to be considered a member of traffic class class4: IP protocol and
QoS group 4, destination MAC address 1.1.1, or access group 2.
In this example, only the traffic class called class4 is used with the traffic policy called policy1.
-- --

-

-- --
-- --
---
--

-- --

- ---

Monitoring Class Maps
- -- --
Displays all class maps and their matching criteria
- --
-- --
--
-- --

-- --

IPTX v2.06-13
The show class-map command lists all class maps with their match statements.
The show class-map command with a name of a class map displays the configuration of the
selected class map.
The example in the figure shows three class maps:
The first, class-3, matches any packet to access-group 103.
The second, class-2, matches IP packets.
The third matches any input from interface Ethernet 1/0.
Policy Maps
This topic describes how to implement QoS policies using policy maps.
Policy Maps
What will be done to this traffic?
Defines a traffic policy which configures the QoS features
associated with a traffic class previously identified using a
class map
A traffic policy contains three major elements:
A case-sensitive name
A traffic class
The QoS policy associated with that traffic class
Up to 256 traffic classes can be associated with a single
traffic policy
Multiple policy maps can be nested to influence the
sequence of QoS actions
IPTX v2.06-14
The policy-map command is used to create a traffic policy. The purpose of a traffic policy is to
configure the QoS features that should be associated with the traffic that has been classified in a
user-specified traffic class or classes. A traffic policy contains three elements: a case-sensitive
name, a traffic class (specified with the class command), and the QoS policies.
The name of a traffic policy is specified in the policy-map CLI (for example, issuing the
policy-map class1 command creates a traffic policy named class1). Once the policy-map CLI
is issued, the user is placed into policy map configuration mode. The name of a traffic class can
then be entered, and the user enters policy-map class configuration mode. Here is where the
user enters QoS features to apply to the traffic that matches this class.
MQC does not necessarily require that users associate only one traffic class to a single traffic
policy. When packets match to more than one match criterion, multiple traffic classes can be
associated with a single traffic policy.
Note
A packet can match only one traffic class within a traffic policy. If a packet matches more
than one traffic class in the traffic policy, the first traffic class defined in the policy will be
used.
Configuring and Monitoring Policy Maps
This topic describes the commands necessary to configure and monitor policy maps.
Configuring Policy Maps

Enter policy-map configuration mode
Policy maps are identified by a case-sensitive name
-- -- --
Enter the per-class policy configuration mode by using the name of a
previously configured class-map
Use the name class-default to configure the policy for the default
class
-- --
Optionally you can define a new class-map by entering the condition
after the name of the new class map
Class map will use the match-any strategy
IPTX v2.06-15
Service policies are configured using the policy-map command. Up to 256 classes can be used
within one policy map using the class command with the name of a preconfigured class map.
A nonexistent class can also be used within the policy-map configuration mode if the match
condition is specified after the name of the class. The running configuration will reflect such a
configuration by using the match any strategy and inserting a full class-map configuration.
The following table shows starting and resulting configuration modes for the class-map,
policy-map and class commands:
Configuration Modes
Starting configuration mode
Command
Configuration mode
--
--
All traffic that is not classified by any of the class-maps used within the policy map is part of
the default class class-default. This class has no QoS guarantees by default. When used on
output, the default class can use one FIFO queue or flow-based WFQ. The default class is part
of every policy map even if not configured.
Configuring Policy Maps(Cont.)
- -
It is recommended to use descriptions in large and complex configurations
The description has no operational meaning
-
Per-class service policies are configured within the per-class policy-map
configuration mode
MQC Supports the following QoS mechanisms:
Class-based Weighted Fair Queuing (CB-WFQ)
Low-latency Queuing (LLQ)
Class-based Policing (CB-Policing)
Class-based Shaping (CB-Shaping)
Class-based Marking (CB-Marking)
IPTX v2.06-16
Policy maps, like class maps, should use descriptions in large QoS implementations in which a
large number of different policy maps are used.
Renaming a policy map normally requires the renaming of all the references to the policy map.
However, using the rename command simplifies the renaming process by automatically
renaming all references.
Example: Policy Map

The example shows the configuration of a policy map using three classes. The first two classes
were separately configured using the class-map command. The third class was configured on
the fly by specifying the match condition after the name of the class.
-- -

--
-- -

--
-
-- -

-- -

-- - --


--- -
--- -
Class Test1 has two match conditions evaluated in the match-all strategy. Classes Test2 and
Test3 use the match-any strategy.
Hierarchical (Nested) Policy Maps

--
Policy maps are normally applied to interfaces

Nested policy maps can be applied directly inside
other policy maps to influence sequence of QoS
actions
For example: shape all traffic to 2 Mbps; queue
shaped traffic to provide priority and bandwidth
guarantees
IPTX v2.06-17
The service-policy policy-map-name command is used to create hierarchical service policies in

policy map class configuration mode.
This command is different from the service-policy [input | output] policy-map-name
command used in interface configuration mode. The purpose of the service-policy [input |
output] policy-map-name is to attach service policies to interfaces.
The child policy is the previously defined service policy that is being associated with the new
service policy through the use of the service-policy command. The new service policy using
the pre-existing service policy is the parent policy. In the example in the next section, service
policy child is the child policy and service policy parent is the parent policy.
This command has the following restrictions:
The set command is not supported on the child policy.
The priority command can be used in either the parent or the child policy, but not in both
policies simultaneously.
The fair-queue command cannot be defined in the parent policy
Hierarchical (Nested) Policy Maps Example

--

--
-
-
-
-
--

--

Example policy
Shape all traffic on FastEthernetto 2 Mbps
Out of the 2 Mbps, guarantee 1 Mbps to HTTP traffic
IPTX v2.06-18
In the example diagram, a child policy map QueueAll is created that guarantees bandwidth of 1
Mbps to HTTP traffic. The QueueAll policy map is then nested within a parent policy map
named ShapeAll. Finally, the parent policy map ShapeAll is applied to the FastEthernet
interface. Traffic out of the FastEthernet interface will first be shaped to 2 Mbps, then HTTP
traffic will be guaranteed 1 Mbps of the 2 Mbps of shaped traffic.
Example: Hierarchical Policy Map

Follow these steps to apply a hierarchical policy:
Step 1
Create a child or lower-level policy that configures a queuing mechanism. In the

example below, we configure LLQ using the priority command.

--

Step 2
Create a parent or top-level policy that applies class-based shaping. Apply the child
policy as a command under the parent policy because the admission control for the
child class is done based on the shaping rate for the parent class.

-- --
-
-
Step 3
Apply the parent policy to the subinterface.

-
Monitoring Policy Maps
-
Displays the configuration of all classes for a specified service
policy map or all classes for all existing policy maps
-
-
-- -

- - -
-- -

- - -
-- -

- - -
IPTX v2.06-19
The show policy-map command can be used to verify the configuration of a policy map.
In the output shown in the figure, three classes are defined called Test1, Test2, and Test3. Test1
is allocated a bandwidth of 100 kbps. Test2 is allocated a bandwidth of 200 kbps. Test3 is
allocated a bandwidth of 300 kbps.
Monitoring Policy Maps
-
- -
-
-
-- -
- - --
--

-
- - -
--
- -
-- --
- -
IPTX v2.06-20
The show policy-map command also displays live information if the interface keyword is
used. The sample output shows the parameters and statistics of the policy map attached to
outbound traffic on interface FastEthernet0/0.
This command is useful for determining if traffic is exceeding its allocation. In the example in
the figure, both total drops and no-buffer drops are 0, indicating that traffic matching Test1 is
not exceeding the configured bandwidth of 100 kbps.
Service Policy
This topic describes how to attach a QoS policy to an interface using service policies.
Service Policy
Where will this policy be implemented?
Attaches a traffic policy configured with a policy

map to an interface
Service policies can be applied to an interface for
inbound or outbound packets
IPTX v2.06-21
The last configuration step when configuring QoS mechanisms using MQC is to attach a policy
map to the inbound or outbound packets, using the service-policy command.
Using the service-policy command, it is possible to assign a single policy map to multiple
interfaces or to assign multiple policy maps to a single interface (a maximum of one in each
direction, inbound and outbound).
A service policy can be applied for inbound or outbound packets.
Attaching Service Policies to Interfaces

This topic explains how to attach service policies to interfaces.
Attaching Service Policies to Interfaces
Attaches the specified service policy map to the input or

output interface
--

--

-- --

IPTX v2.06-22
Use the service-policy interface configuration command to attach a traffic policy to an

interface and to specify the direction in which the policy should be applied (either on packets
coming into the interface or on packets leaving the interface).
The router immediately verifies the correctness of parameters used in the policy map. If there is
a mistake in the policy-map configuration, the router displays a message explaining what is
wrong with the policy map.
The sample configuration shows how a policy map is used to separate HTTP from other traffic.
HTTP is guaranteed 2 Mbps. All other traffic belongs to the default class and is guaranteed
6 Mbps.
Example: Complete MQC Configuration

Traffic Classes Defined
In the following example, two traffic classes are created and their match criteria are defined.
For the first traffic class, called class1, access control list (ACL) 101 is used as the match
criterion. For the second traffic class, called class2, ACL 102 is used as the match criterion.
Packets are checked against the contents of these ACLs to determine if they belong to the class.
-- --
--

-- --
--

Traffic Policy Created

In the following example, a traffic policy called policy1 is defined to contain policy
specifications for the two classesclass1 and class2. The match criteria for these classes were
defined in the traffic classes.
For class1, the policy includes a bandwidth allocation request and a maximum packet count
limit for the queue reserved for the class. For class2, the policy specifies only a bandwidth
allocation request.

-- --

-- --

Traffic Policy Attached to an Interface

The following example shows how to attach an existing traffic policy (which was created in the
preceding section) to an interface. After you define a traffic policy with the policy-map
command, you can attach it to one or more interfaces to specify the traffic policy for those
interfaces by using the service-policy command in interface configuration mode. Although you
can assign the same traffic policy to multiple interfaces, each interface can have only one traffic
policy attached at the input and one traffic policy attached at the output.

-

-

Summary
Summary
Modular QoS (MQC) is a modular approach to
designing and implementing an overall QoS policy.
Applying an overall QoS policy involves three steps:
defining class maps to identify classes of traffic,
defining a QoS policy maps, and assigning the policy
maps to interfaces.
Each class of traffic is defined in a class map module.
A policy map module defines a traffic policy which
configures the QoS features associated with a traffic
class previously identified using a class map
A service policy attaches a traffic policy configured
with a policy map to an interface.
IPTX v2.06-23
Lesson 5
Implementing AutoQoS
Overview
Cisco AutoQoS represents innovative technology that simplifies network administration

challenges, by reducing QoS complexity, deployment time, and cost. Cisco AutoQoS
incorporates value-added intelligence in Cisco IOS software and Cisco Catalyst operating
system software to provision and manage large-scale QoS deployments. Cisco AutoQoS
provides QoS provisioning for individual routers and switches, simplifying deployment and
reducing human error.
The first phase of Cisco AutoQoS offers straightforward capabilities to automate VoIP
deployments for customers who want to deploy IP telephony, but who lack the expertise or
staffing, or both, to plan and deploy IP QoS and IP services.
Objectives
Upon completing this lesson, you will be able to correctly identify capabilities provided by
AutoQoS and to use AutoQoS to successfully configure QoS on a network that has QoS issues.
Explain how AutoQoS is used to implement QoS policy
Describe the router environments in which AutoQoS can be used
Describe the switch environments in which AutoQoS can be used
Describe the prerequisites for configuring AutoQoS
Configure AutoQoS on a network using CLI
Use Cisco IOS commands to examine and monitor a network configuration after AutoQoS
has been enabled
Identify several of the QoS technologies that were automatically implemented on the
network via AutoQoS
AutoQoS
This topic describes the basic purpose and function of AutoQoS.
AutoQoS
One command per interface to enable and configure QoS
IPTX v2.06-4
AutoQoS enables customer networks to deploy QoS features for converged IP telephony and
data networks much faster and more efficiently. It simplifies and automates the MQC definition
of traffic classes and the creation and configuration of traffic policies (AutoQoS generates
traffic classes and policy maps using CLI templates). Therefore, when AutoQoS is configured
at the interface or a permanent virtual circuit (PVC), the traffic receives the required QoS
treatment automatically. In-depth knowledge of the underlying technologies, service policies,
link efficiency mechanisms, and Cisco QoS best practice recommendations for voice
requirements is not required to configure AutoQoS.
AutoQoS can be extremely beneficial for the following scenarios:
Small- to medium-sized businesses that need to deploy IP telephony quickly, but lack the
experience and staffing to plan and deploy IP QoS services
Large customer enterprises that need to deploy Cisco IP telephony on a large scale while
reducing the costs, complexity, and time frame for deployment and ensuring that the
appropriate QoS for voice applications is being set in a consistent fashion
International enterprises or service providers requiring QoS for VoIP where little expertise
exists in different regions of the world and where provisioning QoS remotely and across
different time zones is difficult
Service providers requiring a template-driven approach to delivering managed services and
QoS for voice traffic to large numbers of customer premise devices
AutoQoS (Cont.)
Manual QoS

--
--

-

--

--

AutoQoS

--
-
IPTX v2.06-5
AutoQoS automatically creates the QoS-specific features required for supporting the
underlying transport mechanism and link speed of an interface or PVC type. For example,
FRTS would be automatically configured and enabled by AutoQoS for Frame Relay links. LFI
and cRTP would be automatically configured via the AutoQoS template for slow link speeds
(less than 768 kbps). Therefore, it is very important that the bandwidth statement be properly
set on the interface prior to configuring AutoQoS because the resulting configuration will vary
based on this configurable parameter.
Using AutoQoS, VoIP traffic is automatically provided with the required QoS template for
voice traffic via the auto qos voip command on an interface or PVC. AutoQoS enables the
required QoS based on Cisco best practice methodologies (the configuration generated by
AutoQoS can be modified if desired).
AutoQoS (Cont.)
Application Classification
Automatically discovers applications
and provides appropriate QoS treatment
Policy Generation
Automatically generates initial and
ongoing QoS policies
Configuration
Provides high level business
knobs, and multi-device / domain
automation for QoS
Monitoring & Reporting
Generates intelligent, automatic
alerts and summary reports
Consistency
Enables automatic, seamless
interoperability among all QoS features and
parameters across a network topology
LAN, MAN, and WAN
IPTX v2.06-6
AutoQoS simplifies and shortens the QoS deployment cycle. AutoQoS helps in all five major
aspects of successful QoS deployments:
Application classification: AutoQoS leverages intelligent classification on routers,
utilizing Cisco NBAR to provide deep and stateful packet inspection. AutoQoS uses Cisco
Discovery Protocol (CDP) for voice packets, ensuring that the device attached to the LAN
is really an IP phone.
Policy generation: AutoQoS evaluates the network environment and generates an initial
policy. It automatically determines WAN settings for fragmentation, compression,
encapsulation, and Frame Relay-ATM interworking, eliminating the need to understand
QoS theory and design practices in various scenarios. Customers can meet additional and
special requirements by modifying the initial policy as they normally would.
The first release of AutoQoS provides the necessary AutoQoS-VoIP feature to automate
QoS settings for VoIP deployments. This feature automatically generates interface
configurations, policy maps, class maps, and ACLs. AutoQoS-VoIP automatically employs
Cisco NBAR to classify voice traffic and mark it with the appropriate DSCP value.
AutoQoS-VoIP can be instructed to rely on, or trust, the DSCP markings previously
applied to the packets.
Configuration: With one command, AutoQoS configures the port to prioritize voice traffic
without affecting other network traffic while still offering the flexibility to adjust QoS
settings for unique network requirements.
Not only does AutoQoS automatically detect IP Phones and enable QoS settings, but it also
disables the QoS settings when a IP Phone is relocated or moved to prevent malicious
activity.
AutoQoS-generated router and switch configurations are customizable using the standard
Cisco IOS CLI.
Monitoring and reporting: AutoQoS provides visibility into the classes of service
deployed via system logging and Simple Network Management Protocol (SNMP) traps,
with notification of abnormal events (for example, VoIP packet drops).
Consistency: AutoQoS enables automatic and seamless interoperability between all of the
QoS features and parameters across the network topology, including LAN, MAN, and
WAN.
Copyright 2005, Cisco Systems, Inc. Introducing IP Quality of Service 6-79
AutoQoS: Router Platforms
This topic identifies the router and switch platforms on which AutoQoS operates.
AutoQoS:
Router Platforms
Cisco 1760, 2600, 3600, 3700
and 7200 Series Routers
User can meet the voice QoS
requirements without
extensive knowledge about:
Underlying technologies
(i.e.: PPP, FR, ATM)
Service policies
Link efficiency
mechanisms
AutoQoS lends itself to
tuning of all generated
parameters & configurations
IPTX v2.06-7
Initial support for AutoQoS includes the Cisco 2600, 2600-XM, 3600, 3700, and 7200 series
routers. Support for additional platforms will become available.
The AutoQoS VoIP feature is supported only on the following interfaces and PVCs:
Serial interfaces with PPP or High-Level Data Link Control (HDLC)
Frame Relay data-link connection identifiers (DLCIs) (PPP subinterfaces only)
AutoQoS does not support Frame Relay multipoint interfaces.
ATM PVCs
Cisco AutoQoS VoIP is supported on low-speed ATM PVCs on PPP subinterfaces
only (link bandwidth less than 768 kbps).
Cisco AutoQoS VoIP is fully supported on high-speed ATM PVCs (link bandwidth
greater than 768 kbps).
AutoQoS: Switch Platforms
This topic identifies the switch platforms on which AutoQoS operates.
AutoQoS:
Switch Platforms
Cisco Catalyst 6500, 4500,
3550, 3560, 2970 and
2950(EI) Switches
User can meet the voice
QoS requirements without
extensive knowledge about:
Trust boundary
CoS to DSCP mappings
Weighted Round Robin
(WRR) & Priority Queue
(PQ) Scheduling
parameters
Generated parameters and
configurations are user
tunable
6500
4500
3750
3550
3560
2970
2950EI
IPTX v2.06-8
Initial support for AutoQoS includes the Cisco Catalyst 6500, 4500, 3550, 3560, 2970, and
2950EI Series switches. Support for additional platforms, including the Cisco Catalyst 4000,
will become available.
The Enhanced Image (EI) is required on the Cisco Catalyst 2950 Series switches.
AutoQoS:
Switch Platforms (Cont.)
Single command at the interface level configures interface
and global QoS
Support for Cisco IP Phone & Cisco Soft Phone
Support for Cisco Soft Phone currently exists only on
the Cat6500
Trust Boundary is disabled when IP Phone is
moved/relocated
Buffer Allocation & Egress Queuing dependent on
interface type (GE/FE)
Supported on Static, dynamic-access, voice VLAN access,
and trunk ports
CDP must be enabled for AutoQoS to function properly
IPTX v2.06-9
To configure the QoS settings and the trusted boundary feature on the IP Phone, you must
enable CDP version 2 or later on the port. If you enable the trusted boundary feature, a syslog
message warns you if CDP is not enabled or if CDP is running version 1.
You need to enable CDP only for the ciscoipphone QoS configuration; CDP does not affect the
other components of the automatic QoS features. When you use the ciscoipphone keyword
with the port-specific automatic QoS feature, a warning displays if the port does not have CDP
enabled.
When executing the port-specific automatic QoS command with the ciscoipphone keyword
without the trust option, the trust-device feature is enabled. The trust-device feature is
dependent on CDP. If CDP is not enabled or not running version 2, a warning message displays
as follows:
- - - - -
- - - - - -
- - - -
- - -
-- -
- - - -
-
-
AutoQoS Prerequisites
This topic describes some of the key prerequisites for using AutoQoS.
Configuring AutoQoS:
Prerequisites for Using AutoQoS
Cisco Express Forwarding (CEF) must be enabled at the
interface or ATM PVC
This feature cannot be configured if a QoS policy
(service policy) is attached to the interface
An interface is classified as low-speed if its bandwidth is less
than or equal to 768 kbps. It is classified as high-speed if its
bandwidth is greater than 768 kbps
The correct bandwidth should be configured on all
interfaces or sub-interfaces using the bandwidth
command
If the interface or sub-interface has a link speed of 768
kbps or lower, an IP address must be configured using
the ip address command
IPTX v2.06-10
Before configuring AutoQoS, the following prerequisites must be met:

Cisco Express Forwarding (CEF) must be enabled at the interface or ATM PVC. Cisco
AutoQoS uses NBAR to identify various applications and traffic types, and CEF is a
prerequisite for NBAR.
Ensure that no QoS policies (service policies) are attached to the interface. AutoQoS cannot
be configured if a QoS policy (service policy) is attached to the interface.
AutoQoS classifies links as either low-speed or high-speed depending upon the link
bandwidth. Remember that on a serial interface, the default bandwidth if not specified is
1.544 Mbps. Therefore, it is important that the correct bandwidth be specified on the
interface or subinterface where AutoQoS is to be enabled.
For all interfaces or subinterfaces, be sure to properly configure the bandwidth by
using the bandwidth command. The amount of bandwidth allocated should be based
on the link speed of the interface.
If the interface or subinterface has a link speed of 768 kbps or lower, an IP address
must be configured on the interface or subinterface using the ip address command.
By default, AutoQoS enables multilink PPP and copies the configured IP address to
the multilink bundle interface.
In addition to the AutoQoS prerequisites, the following are recommendations and requirements
when configuring AutoQoS. Be aware that these may change with Cisco IOS releases and
should be verified before implementing AutoQoS in your environment.
The AutoQoS VoIP feature is supported only on the following interfaces and PVCs:
Serial interfaces with PPP or HDLC
Frame Relay DLCIs (PPP subinterfaces only)
AutoQoS does not support Frame Relay multipoint interfaces.
ATM PVCs
CLI generated by configuring AutoQoS on an interface or PVC can be tuned manually (via
CLI configuration) if desired.
AutoQoS cannot be configured if a QoS service policy is already configured and attached
to the interface or PVC.
Multilink PPP (MLP) is configured automatically for a serial interface with low-speed link.
The serial interface must have an IP address, which is removed and put on the MLP bundle.
AutoQoS VoIP must also be configured on the other side of the link.
The no auto qos voip command removes AutoQoS. However, if the interface or PVC
AutoQoS-generated QoS configuration is deleted without configuring the no auto qos voip
command, AutoQoS VoIP will not be completely removed from the configuration properly.
AutoQoS SNMP traps are only delivered when an SNMP server is used in conjunction with
AutoQoS.
The SNMP community string AutoQoS should have write permissions.
If the device is reloaded with the saved configuration after configuring AutoQoS and
saving the configuration to NVRAM, some warning messages may be generated by
Remote Monitoring (RMON) threshold commands. These warnings messages may be
ignored. (To avoid further warning messages, save the configuration to NVRAM again
without making any changes to the QoS configuration.)
By default, Cisco 7200 Series routers and below that support MQC QoS, reserve up to 75
percent of the interface bandwidth for user-defined classes. The remaining bandwidth is
used for the default class. However, the entire remaining bandwidth is not guaranteed for
the default class. This bandwidth is shared proportionately between the different flows in
the default class and excess traffic from other bandwidth classes. At least 1 percent of the
available bandwidth is reserved and guaranteed for class default traffic by default (up to 99
percent can be allocated to the other classes) on Cisco 7500 Series routers.
Configuring AutoQoS
This topic describes how to configure AutoQoS.
Routers

- -
Configures the AutoQoS VoIP feature

Untrusted mode by default
trust: Indicates that the differentiated services code point
(DSCP) markings of a packet are trusted (relied on) for
classification of the voice traffic
fr-atm: For low-speed Frame Relay DLCIs interconnected
with ATM PVCs in the same network, the fr-atm keyword
must be explicitly configured in the auto qos voip
command to configure the AutoQoS VoIP feature properly
IPTX v2.06-11
To configure the AutoQoS VoIP feature on an interface, use the auto qos voip command in
interface configuration mode or Frame Relay DLCI configuration mode. To remove the
AutoQoS VoIP feature from an interface, use the no form of the auto qos voip command.auto
qos voip [trust] [fr-atm]
no auto qos voip [trust] [fr-atm]
Syntax Description
Parameter
Description
(Optional) Indicates that the DSCP markings of a packet are trusted

(relied on) for classification of the voice traffic. If the optional trust
keyword is not specified, the voice traffic is classified using NBAR,
and the packets are marked with the appropriate DSCP value.
(Optional) Enables the AutoQoS VoIP feature for the Frame

Relayto-ATM links. This option is available on the Frame Relay
DLCIs for Frame Relayto-ATM interworking only.
The bandwidth of the serial interface is used to determine the speed of the link. The speed of
the link is one element that is used to determine the configuration that is generated by the
AutoQoS VoIP feature. The AutoQoS VoIP feature uses the bandwidth at the time the feature
is configured and does not respond to changes made to bandwidth after the feature is
configured.
For example, if the auto qos voip command is used to configure the AutoQoS VoIP feature on
an interface with 1000 kbps, the AutoQoS VoIP feature generates configurations for high-speed
interfaces. However, if the bandwidth is later changed to 500 kbps, the AutoQoS VoIP feature
does not use the lower bandwidth. It retains the higher bandwidth and continues to use the
generated configurations for high-speed interfaces.
To force the AutoQoS VoIP feature to use the lower bandwidth (and thus generate
configurations for the low-speed interfaces), use the no auto qos voip command to remove the
AutoQoS VoIP feature, then reconfigure the feature.
Example: Configuring the AutoQoS VoIP Feature on a HighSpeed Serial Interface

In this example, the AutoQoS VoIP feature is configured on the high-speed serial interface
s1/2.

-

--
-
Example: Configuring the AutoQoS VoIP Feature on a LowSpeed Serial Interface

In this example, the AutoQoS VoIP feature is configured on the low-speed serial interface s1/3.

-

--
-
Cisco Catalyst 6500 Switch
-
- - -
Global configuration command

All the global QoS settings are applied to all ports in the
switch
Prompt displays showing the CLI for the port-based
automatic QoS commands currently supported
- - - -
-- -- - -
-
- -
- -
- - - - --
- - - ---
IPTX v2.06-12
When you execute the global AutoQoS macro, all the global QoS settings are applied to all
ports in the switch. After completion, a prompt displays the CLI for the port-based AutoQoS
commands currently supported.
Cisco Catalyst 6500 Switch (Cont.)
-
- - - - --
trust dscp and trust cos are automatic QoS keywords

used for ports requiring a "trust all" type of solution.
trust dscp should be used only on ports that connect to
other switches or known servers as the port will be
trusting all inbound traffic marking Layer 3 (DSCP)
trust cos should only be used on ports connecting other
switches or known servers as the port trusts all inbound
traffic marking in Layer 2 (CoS).
The trusted boundary feature is disabled and no QoS
policing is configured on these types of ports
IPTX v2.06-13
The port-specific AutoQoS macro handles all inbound QoS configuration that is specific to a
particular port.
The QoS ingress port-specific settings include port trust, default CoS, classification, and
policing but does not include scheduling. Input scheduling is programmed through the global
AutoQoS macro. Together with the global AutoQoS macro command, all QoS settings are
configured properly for a specific QoS traffic type.
Any existing QoS ACLs that are already associated with a port are removed if AutoQoS
modifies ACL mappings on that port. The ACL names and instances are not changed.
If the trust dscp or trust cos keyword is used, the trusted boundary feature is disabled. This
means an IP Phone will not rewrite the DSCP or CoS values from an attached PC.
Cisco Catalyst 6500 Switch (Cont.)
-
- - - --
-
ciscosoftphone
The trusted boundary feature must be disabled for Cisco SoftPhone ports
QoS settings must be configured to trust the Layer 3 markings ofthe traffic
that enters the port
Only available on Catalyst 6500
ciscoipphone
The port is set up to trust-cos as well as to enable the trusted boundary feature
Combined with the global automatic QoS command, all settings areconfigured
on the switch to properly handle the signaling and voice bearer and PC data
entering and leaving the port
CDP must be enabled for the ciscoipphone QoS configuration
IPTX v2.06-14
The port-specific automatic QoS macro accepts a mod/port combination and must include a
Cisco IP Telephony type keyword. The ciscoipphone, ciscosoftphone, and trust keywords are
supported.
With the ciscoipphone keyword, the port is set up to trust CoS as well as to enable the trusted
boundary feature. Combined with the global AutoQoS command, all settings are configured on
the switch to properly handle the signaling and voice bearer and the PC data entering and
leaving the port.
In addition to the switch-side QoS settings covered by the global AutoQoS command, the
phone has a few QoS features that need to be configured in order for proper labeling to occur.
QoS configuration information is sent to the phone through the CDP from the switch. The QoS
values that need to be configured are the trust settings of the PC port on the phone (trust or
untrusted) and the CoS value that is used by the phone to remark packets in case the port is
untrusted.
Only the Catalyst 6500 supports AutoQoS for Cisco SoftPhone. On the ports that connect to a
Cisco SoftPhone, QoS settings must be configured to trust the Layer 3 markings of the traffic
that enters the port. Trusting all Layer 3 markings is a security risk because PC users could
send nonpriority traffic with DSCP 46 and gain unauthorized performance benefits. Although
not configured by AutoQoS, policing on all inbound traffic can be used to prevent malicious
users from obtaining unauthorized bandwidth from the network. Policing is accomplished by
rate-limiting the DSCP 46 (Expedited Forwarding) inbound traffic to the codec rate used by the
Cisco SoftPhone application (worst case G.723). Any traffic that exceeds this rate is marked
down to the default traffic rate (DSCP 0 best effort). Signaling traffic (DSCP 24) is also
policed and marked down to 0 if excess signaling traffic is detected. All other inbound traffic
types are reclassified to default traffic (DSCP 0 best effort).
Note
You must disable the trusted boundary feature for Cisco SoftPhone ports.
Example: Using the Port-Specific AutoQoS Macro

This example shows how to use the ciscoipphone keyword:
- - - -
- - - - - --
- - -
---
- - - - -
-- -
- - - -
-
-
This example shows how to use the ciscosoftphone keyword:

- - - - --
-- -
- - - -
-
-
This example shows how to use the trust cos keyword:

- - - - - -
- - - -
-
-
This example shows how to use the trust dscp keyword:

- - - - - -
-
- - - -
-
-
Catalyst 2950EI, 3550 Switches
- -
The uplink interface is connected to a trusted switch or

router, and the VoIP classification in the ingress packet is
trusted
- -
Automatically enables the trusted boundary feature,

which uses the CDP to detect the presence or absence of
a Cisco IP Phone
If the interface is connected to a Cisco IP Phone, the QoS
labels of incoming packets are trusted only when the IP
phone is detected
IPTX v2.06-15
When you enable the AutoQoS feature on the first interface, QoS is globally enabled ( mls qos
global configuration command).
When you enter the auto qos voip trust interface configuration command, the ingress
classification on the interface is set to trust the CoS QoS label received in the packet, and the
egress queues on the interface are reconfigured. QoS labels in ingress packets are trusted.
When you enter the auto qos voip cisco-phone interface configuration command, the trusted
boundary feature is enabled. It uses the CDP to detect the presence or absence of an IP Phone.
When an IP Phone is detected, the ingress classification on the interface is set to trust the QoS
label received in the packet. When an IP Phone is absent, the ingress classification is set to not
trust the QoS label in the packet. The egress queues on the interface are also reconfigured. This
command extends the trust boundary if IP Phone detected.
Monitoring AutoQoS
This topic describes the commands used to monitor AutoQoS configurations.
Monitoring AutoQoS:
Routers
- -
Displays the interface configurations, policy maps, class

maps, and ACLs created on the basis of automatically
generated configurations
- -

- -
IPTX v2.06-16
When the auto qos voip command is used to configure the AutoQoS VoIP feature,
configurations are generated for each interface or PVC. These configurations are then used to
create the interface configurations, policy maps, class maps, and ACLs. The show auto qos
command can be used to verify the contents of the interface configurations, policy maps, class
maps, and ACLs.
The show auto qos interface command can be used with Frame Relay DLCIs and ATM PVCs.
When the interface keyword is used along with the corresponding interface type argument, the
show auto qos interface [interface type] command displays the configurations created by the
AutoQoS VoIP feature on the specified interface.
When the interface keyword is used but an interface type is not specified, the show auto qos
interface command displays the configurations created by the AutoQoS VoIP feature on all the
interfaces or PVCs on which the AutoQoS VoIP feature is enabled.
Example: show auto qos command and show auto qos

interface command
The show auto qos command displays all of the configurations created by the AutoQoS VoIP
feature.
-

--
--
--

- -

Monitoring AutoQoS:
Routers (Cont.)
-
Displays the packet statistics of all classes that are configured for all
service policies either on the specified interface or subinterface
- -
-

-- -
- - -
-
- -
- - -
-

-
IPTX v2.06-17
To display the configuration of all classes configured for all service policies on the specified
interface or to display the classes for the service policy for a specific permanent virtual circuit
(PVC) on the interface, use the show policy-map interface EXEC or privileged EXEC
command.
-

Monitoring AutoQoS:
Switches
- -
Displays the auto-QoS configuration that was initially applied
Does not display any user changes to the configuration that
might be in effect
-

-
-
-
-
- - --
-
- - - -
- - - -
IPTX v2.06-18
To display the initial AutoQoS configuration, use the show auto qos [interface [interface-id]]
privileged EXEC command. To display any user changes to that configuration, use the show
running-config privileged EXEC command. You can compare the show auto qos and the
show running-config command output to identify the user-defined QoS settings.
Monitoring AutoQoS:
Switches (Cont.)
- - -
- - ---
--
Displays QoS information at the interface level
- - - ----
-- -

--

--
-
- -

-
IPTX v2.06-19
Display QoS information at the interface level, including the configuration of the egress queues
and the CoS-to-egress-queue map, which interfaces have configured policers, and ingress and
egress statistics (including the number of bytes dropped).
If no keyword is specified with the show mls qos interface command, the port QoS mode
(DSCP trusted, CoS trusted, untrusted, and so forth), default CoS value, DSCP-to-DSCPmutation map (if any) attached to the port, and policy map (if any) attached to the interface are
displayed. If an interface is not specified, the information for all interfaces is displayed.
Expressions are case sensitive. For example, if you enter | exclude output, the lines that
contain output are not displayed, but the lines that do not contain output are displayed,
including any lines that contain Output or OUTPUT.
Monitoring AutoQoS:
Switches (Cont.)
- - - - -- -- -
- --
- -
--
Maps are used to generate an internal Differentiated

Services Code Point (DSCP) value, which represents the
priority of the traffic
- - - - ---
-
This command shows the current mapping of DSCP to CoS.
IPTX v2.06-20
Automation with Cisco AutoQoS
This topic identifies several of the QoS technologies that are automatically implemented on the
network when using AutoQoS.
Automation with Cisco AutoQoS:

DiffServ Functions Automated
IPTX v2.06-21
Cisco AutoQoS performs the following functions:

WAN
Automatically classifies RTP payload and VoIP control packets: H.323, H.225 Unicast,
Skinny Client Control Protocol (SCCP), session initiation protocol (SIP), and Media
Gateway Control Protocol (MGCP)
Builds service policies for VoIP traffic that are based on Cisco MQC
Provisions LLQ and PQ for VoIP bearer and bandwidth guarantees for control traffic
Enables WAN traffic shaping that adheres to Cisco best practices, where required
Enables link efficiency mechanisms, such as LFI and cRTP where required
Provides SNMP and syslog alerts for VoIP packet drops
LAN
Enforces the trust boundary on Cisco Catalyst switch access ports and on uplinks and
downlinks
Enables Cisco Catalyst strict priority queuing (also known as expedite queuing) with
Weighted Round Robin (WRR) scheduling for voice and data traffic, where appropriate
Configures queue admission criteria (maps CoS values in incoming packets to the
appropriate queues)
Modifies queue sizes and weights where required
Summary
Summary
QoS can be enabled on a network by a single
command per interface using AutoQoS.
AutoQoSworks on a variety of Cisco routers and
switches.
AutoQos automatically configures and enables the
Diffserv mechanisms necessary for QoS.
IPTX v2.06-22
Lesson 6
Case Study: QoS Mechanisms

Overview
This case study activity provides information regarding the QoS administrative policy
requirements of a large, multisite network. Your task is to work with a partner to evaluate the
QoS requirements, then based on these requirements, identify where QoS mechanisms should
be applied. You will discuss your solution with the instructor and other classmates, and the
instructor will present a solution for the case study to the class.
Relevance
The ability to properly sort traffic into service classes and correctly position QoS mechanisms
is important in correctly implementing an administrative QoS policy.
Objectives
In this activity, you will you will correctly identify which QoS mechanisms can be used and
where QoS mechanisms should be applied to the network to implement an administrative QoS
policy. Upon completing this case study, you will be able to meet these objectives:
Review customer QoS requirements
Identify QoS service class requirements
Identify which QoS mechanisms should be used to meet customer requirements
Identify where QoS mechanisms should be applied to the network to meet customer
requirements
Present a solution to the case study
Learner Skills and Knowledge

To benefit fully from this activity, you must have these prerequisite skills and knowledge:
Basic knowledge of internetworking with TCP/IP concepts
Required Resources
These are the resources required to complete this exercise:
Case Study Activity: QoS Mechanisms
A workgroup consisting of two learners
Job Aids
No job aids are required to complete this case study
Outline
This activity includes these tasks:
Step 1
Review customer QoS requirements. Completely read the customer requirements

provided.
Step 2
Identify QoS service class requirements. With the aid of your partner, identify the
service classes that are required in order to implement the administrative QoS policy
based on customer requirements.
Step 3
Identify network locations where QoS mechanisms should be applied. Identify

locations in the network where the QoS mechanisms should be applied in order to
most effectively implement QoS policy.
Step 4
Present your solution. After the instructor presents a solution to the case study,
present your solution to the class with your partner.
Case Study Verification

You have completed this activity when your case study solution has been presented to the class
and you have justified any major differences between your solution and the solution presented
by the instructor.
Review Customer QoS Requirements

Company Background
Nuevo Health Care Systems (NHCS) provides health care information to health care
professionals in ten major regions of the country.
Customer Situation
NHCS network currently has limited bandwidth capacity in their WAN links, and they do not
envision being able to increase bandwidth in the near future. All ten remote sites (two pictured
in the network diagram below) connect to the central site through a service provider via a
Frame Relay, Layer 2, 1 Mbps link service. The NHCS headquarters also connects to the
service provider via a Frame Relay, Layer 2, 1 Mbps link. NHCS LAN bandwidth is 10 Mbps.
NHCS connects to the Internet through its headquarters.
Since the installation of a new IP telephony system, NHCS has been encountering increasingly
serious problems with their network.
Users of the enterprise resource planning (ERP) applications have been complaining of
unacceptable response times. Their previously sub-second response time has stretched to
multiple seconds in many cases and up to a minute in some cases.
Key patient information files that used to arrive almost instantly are now taking 10 to 15
minutes to be transferred from headquarters to users at the remote sites (these are moderatesized, mostly text files).
Patient graphics files (x-rays, MRIs, and so on) that used to take 20 to 30 minutes to
transfer between the remote sites and headquarters now often have to be transferred
overnight (this is not deemed unacceptable as they are usually not needed immediately and
they tend to be extremely large files).
Users of the new IP telephony devices are the most upset. The quality of their calls is very
poor and their calls often just drop.
The key applications that are running on NHCS network are listed in the table.
Applications Running on NHCS Network
Application
Application
Importance
Response Time
Requirements
Use of Bandwidth
(Daytime)
Enterprise Resource Planning
critical
immediate
moderate
Patient Information Files
important
immediate
moderate
Patient Graphics Files
important minimal heavy
IP Telephony
important
no delay
moderate
Browser Traffic
not important
minimal
heavy
Nuevo Health Care Systems Network
n Device no. on Problem Spreadsheet

IPTX v2.06-5
Device Number
Device Type
1 IP Phone
2 LAN Switch
3 Customer Edge Router
4 Service Provider Router
Identify QoS Service Class Requirements
Given NHCS network, how would you recommend classifying network traffic?
Traffic Classification and Prioritization
Type of Traffic (Application)
Traffic Priority
(Rank from 1 to 5)
Identify Network Locations Where QoS

Mechanisms Should be Applied
Given NHCS network, how would you recommend deploying QoS mechanisms? In the
following four tables, mark each box (X) that represents where you believe that QoS
mechanisms could be applied in order to effectively resolve QoS problems at NHCS.
Where to Apply QoS Mechanisms: Classification and Marking
Device
Network Device Interface
#
1 IP Phone
1 IP Phone
2 Switch
2 Switch
Classification
on Input
Classification
on Output
Marking
on Input
Marking
on
Output
Interface to
Workstation
Switch
Phone
Interface to
Interface to IP
Interface to
Customer Edge Router

Interface to Switch
Interface to WAN (Service

Provider Router)
Interface to Customer Edge

Router
Where to Apply QoS Mechanisms: Congestion Management and Avoidance

Device
#
2 Switch
2 Switch
Phone
Congestion
Management
on Input
Interface to IP
Interface to

Interface to Switch

Provider Router)
Interface to Customer
Edge Router
Congestion
Management
on Output
Where to Apply QoS Mechanisms: Traffic Shaping

Device
#
2 Switch
2 Switch
Traffic
Shaping
on Input
Traffic
Shaping
on Output
Interface to IP Phone
Edge Router

Interface to Switch

Provider Router)

Router
Where to Apply QoS Mechanisms: Link Efficiency

Device
#
2 Switch
2 Switch
Compression
on Input
Compression
on Output
LFI on
Input
LFI on
Output
Interface to IP Phone
Edge Router

Interface to Switch

Provider Router)

Router
Present Your Solution
Together with your partner, present your solution to the class. Include the following
information:
Customer service class requirements
Network diagrams indicating where classification and marking should be applied
Justification for differences from the solution presented by the instructor
Case Study Answer Key

Traffic Classification and Prioritization
Type of Traffic (Application)
Traffic Priority
IP Telephony Highest
Enterprise Resource Planning High
Patient Information Files Moderate
Patient Graphics Files Low
Browser Traffic Low
Where to Apply QoS Mechanisms: Classification and Marking

Device
Classification
on Input
Link to
Workstation
X X*
#
1 IP Phone
1 IP Phone
Link to Switch
2 Switch
2 Switch
Link to IP Phone
Link to Customer
Edge Router
X No,
Marking
on
Output
trusted*

Link to WAN (Service
Provider Router)
Note
Marking
on Input

Link to Switch
Link to Customer Edge

Router
Classification
on Output
*The IP Phone is normally set to re-mark any traffic coming from its downstream workstation
(the IP Phones connection to the workstation is untrusted). The switch, on the other hand,
does not re-mark traffic coming from the IP Phone (traffic from the IP Phone is trusted).
Further explanation of trusted and untrusted interfaces is provided in Module 6 of this
course.
Where to Apply QoS Mechanisms: Congestion Management and Avoidance

Device
#
2 Switch
2 Switch
Link to IP Phone
Link to
Congestion
Management
on Input
Congestion
Management
on Output
X
X

Link to Switch

Link to WAN (Service
Provider Router)

Router
Where to Apply QoS Mechanisms: Traffic Shaping

Device
#
2 Switch
2 Switch
Traffic
Shaping
on Input
Link to IP Phone
Router

Switch
Link to

Link to
WAN (Service Provider Router)
Possible

Link to
Possible
Traffic
Shaping on
Output
Where to Apply QoS Mechanisms: Link Efficiency

Device
#
2 Switch
2 Switch
Compression
on Input
LFI on
Input
LFI on
Output
Link to IP Phone
Link to Customer
Edge Router

to Switch
Link

Link
to WAN (Service Provider
Router)
X X

Link
to Customer Edge Router
X X
Note
Compression
on Output
This is a Frame Relay network, so the service provider passes frames through transparently
without compressing or fragmenting the frames.
Module Summary
Module Summary
Quality of Service (QoS) is the ability of the network to provide
better or special service to select users and applications.
Converged networks create new requirements which create
challenges for managing network traffic as voice, video, and
data have very different requirements.
A QoS Policy is a network-wide definition of the specific levels
of quality of service assigned to classes of network traffic.
The Differentiated Services model is highly scalable and offers
the capability to define many different levels of service.
IP networks use a variety of mechanisms to implement QoS
including: classification, marking, congestion management,
metering, traffic shaping, compression, and link efficiency.
IPTX v2.06-1
Module Summary (Cont.)

Modular QoS is a three-step, building block approach to
implementing QoS in a network.
Each class of traffic is defined in a class map module.
A policy map module defines a traffic policy which
configures the QoS features associated with a traffic class
previously identified using a class map
A service policy attaches a traffic policy configured with a
policy map to an interface.
QoS can be enabled on a network by a single
command per interface using AutoQoS.
AutoQoS works on a variety of Cisco routers and switches,
and automatically configures and enables the mechanisms
necessary for QoS.
IPTX v2.06-2
Voice and video traffic present new challenges to networking. QoS is the network glue that
makes it possible to incorporate voice and video traffic into a traditional networking
environment. An understanding of QoS is essential to guaranteeing voice quality in a
converged network. Prior to configuring QoS, a QoS policy should be developed.
DiffServ is a multiple-service model designed to satisfy various QoS requirements. With
DiffServ, the network tries to deliver a particular kind of service based on the QoS specified by
each packet. This specification can occur in different ways, for example, using the DSCP in IP
packets or source and destination addresses. The network uses the QoS specification of each
packet to classify, shape, and police traffic and to perform intelligent queuing.
IP networks use a variety of mechanisms to implement QoS, including classification, marking,
congestion management, traffic shaping, and link efficiency. IP QoS mechanisms are used to
implement a coordinated QoS policy in devices throughout the network. The moment an IP
packet enters the network, it is classified and usually marked with its class identification. From
that point on, the packet is treated by a variety of IP QoS mechanisms according to the packet s
classification. Depending upon the mechanisms it encounters, the packet could be expedited,
delayed, compressed, fragmented, or even dropped.
Both the MQC and Cisco AutoQoS were designed to aid in more rapid and consistent design,
implementation, and maintenance of QoS policies for converged networks. The MQC offers a
three-step, building-block approach to implementing extremely modular QoS policies for
network administrators who are required to carefully manage large and complex networks.
Cisco AutoQoS provides an easy-to-use, mostly automated means to provide consistent QoS
policies throughout a network, with minimal design and implementation effort.
References
Cisco Systems, Inc. Implementing Quality of Service: QOS Packet Marking.
http://www.cisco.com/en/US/partner/tech/tk543/tk757/technologies_white_paper09186a00
8017f93b.shtml. (CCO login required)
Blake, et. al. An Architecture for Differentiated Services.
http://www.ietf.org/rfc/rfc2475.txt.
Nichols, et. al. Definition of the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers. http://www.ietf.org/rfc/rfc2474.txt.
Heinanen, et. al. Assured Forwarding Per-Hop Behavior (PHB) Group.
Jacobson, et al. An Expedited Forwarding Per-Hop Behavior (PHB).
Cisco Systems, Inc. Quality of Service (QoS).
http://www.cisco.com/en/US/tech/tk543/tsd_technology_support_category_home.html.
Modular Quality of Service Command-Line Interface Overview.
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_c
hapter09186a00800bd908.html.
Configuring the Modular Quality of Service Command-Line Interface.
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_c
hapter09186a00800bd909.html.
Cisco Systems, Inc. Cisco AutoQoS Whitepaper: QOS Configuration and Monitoring.
http://www.cisco.com/en/US/tech/tk543/tk759/technologies_white_paper09186a00801348
bc.shtml.
Configuring Automatic QoS.
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_c
hapter09186a0080121d11.html.
Configuring QoS.
http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_guide_c
aapter09186a0080115928.html.
Module Self-Check Overview
Q1) Which of the following is the term used to describe the time it takes to actually transmit
a packet on a link (put bits on the wire)? (Source: Defining Quality of Service)
A) encoding delay
B) processing delay
C) serialization delay
D) transmission delay
Q2) Which three of the following are characteristics of converged network traffic? (Choose
three.) (Source: Defining Quality of Service)
A) constant small packet flow
B) time-sensitive packets
C) brief outages unacceptable
D) bursty small packet flow
Q3) How much one-way delay can a voice packet tolerate? (Source: Defining Quality of
Service)
A) 15 ms
B) 150 ms
C) 300 ms
D) 200 ms
Q4) Which transport layer protocol is used for voice traffic? (Source: Defining Quality of
Service)
A) UDP
B) TCP
C) XNS
D) HTTP
Q5) Which three of the following represent components of the definition of a QoS policy?
(Choose three.) (Source: Defining Quality of Service)
A) user-validated
B) network-wide
C) specific levels of quality of service
D) different classes of network traffic
Q6) Services are provided to which entities in the differentiated services model? (Source:
Describing the Differentiated Services Model)
A) frames
B) packets
C) applications
D) classes of traffic
Q7) Which Assured Forwarding class and what drop probability would be indicated if the
DSCP was equal to 100100? (Source: Describing the Differentiated Services Model)
A) AF Class 1 and medium
B) AF Class 4 and medium
C) AF Class 1 and high
D) AF Class 4 and high
Q8) Which command would you use to attach a QoS policy to an interface? (Source:
Introducing Modular QoS CLI)
A)
B)
C)
D)
policy-set-interface
policy-map
policy-interface
service-policy
Q9) How can a service policy be attached to an interface? (Source: Introducing Modular
QoS CLI)
A) for inbound packets only
B) for outbound packets only
C) for inbound or outbound, not both
D) for inbound only, for outbound only, or for both inbound and outbound
Q10) What does the trust parameter in auto qos voip indicate should be trusted (relied
upon)? (Source: Implementing AutoQoS)
A) source address
B) MAC address of sender
C) DES keyword
D) DSCP
Q11) Which three of following is displayed by the show auto qos interface command?
(Choose three.) (Source: Implementing AutoQoS)
A) ACLs
B) class maps
C) policy maps
D) service maps
Q12) Which command would you use on a Catalyst switch to display the configuration of the
egress queues? (Source: Implementing AutoQoS)
A)
B)
C)
D)
show mls qos maps

show auto qos
show auto qos interface
show mls qos interface
Q13) Which three of the following does AutoQoS VoIP automatically do when used to
automatically configure a WAN interface? (Choose three.) (Source: Implementing
AutoQoS)
A) enables payload compression
B) provisions LLQ
C) classifies RTP payload and VoIP control packets
D) enables LFI where required

Q1) C
Q2) A, B, C
Q3) B
Q4) A
Q5) B, C, D
Q6) D
Q7) B
Q8) D
Q9) D
Q10) D
Q11) A, B, C
Q12) D
Q13) B, C, D
Module 7
Designing Cisco CallManager

Express and Cisco Unity
Express Networks
Overview
This is a foundation module to compare and contrast traditional telephony with Voice over IP
(VoIP). When deploying and designing a Cisco CallManager Express and Cisco Unity Express
(CUE) installation, there are some deployment models and caveats that need to be taken into
consideration. These include voice mail and other issues.
Module Objectives
Upon completing this module, you will be able to compare and contrast traditional telephony
with VoIP. This includes being able to meet these objectives:
Discuss deploying Cisco CallManager Express with approved deployment models
Describe integration with CUE and other voice mail applications
Lesson 1
Describing Deployment
Scenarios and Design
Considerations
Overview
This lesson addresses some of the considerations regarding the design and deployment
considerations that should be understood when deploying Cisco CallManager Express and
Cisco Unity Express (CUE).
Objectives
Upon completing this lesson, you will be able to discuss deploying Cisco CallManager Express
with approved deployment models. This includes being able to meet these objectives:
Describe design considerations for standalone Cisco CallManager Express with
PSTN interfaces
Describe the design considerations for integration of Cisco CallManager Express with a
SIP network
Describe the design considerations for Cisco CallManager Express integration with
Cisco CallManager
Describe design consideration issues of Cisco CallManager Express migration to
Cisco CallManager and SRST
Describe the design issues and solutions of Cisco CallManager Express H.323
interoperability
Standalone Cisco CallManager Express

This topic describes the standalone Cisco CallManager Express.

Simple deployment
Scales up to 240 IP Phones and 720 voice ports
CUE module can be located in same chassis as the Cisco
CUE module can be located in a chassis that is separate from
the Cisco CallManagerExpress router
PSTN for incoming and outgoing calls
Analog: FXO and E&M
Digital: BRI, PRI, T1, E1
WAN connection for Internet, e-mail, chat, etc.
IPTX v2.07-3
A standalone Cisco CallManager Express deployment can support a small- to medium-sized

branch office with a maximum of 240 users and 720 voice ports. This allows a small- to
medium-sized enterprise to consolidate the data and voice functions it needs onto a single
router. In addition to the telephony services, a CUE module can also be installed co-resident in
the Cisco CallManager Express chassis. This provides all the typical services that many
enterprises may need to address their telephony and data requirements.
Standalone Cisco CallManager ExpressCisco CallManager Express with PSTN

Interfaces
The Cisco CallManager Express router can support many types of connections to the public
switched telephone network (PSTN). They are:
Analog Foreign Exchange Office (FXO)
Analog ear and mouth (E&M)
Digital BRI ISDN
Digital PRI ISDN
Digital T1 or E1
Connections to telephony devices include:
IP Phones via an external switch
Analog phones via a Foreign Exchange Station (FXS) port
Fax via FXS ports
Analog phones via Cisco Analog Telephone Adaptor (ATA) 186 and 188
Copyright 2005, Cisco Systems, Inc. Designing Cisco CallManager Express and Cisco Unity Express Networks 7-5
A WAN connection to a carrier network can be set up for e-mail, Internet, chat, and other
services.
The following are call types:
Local calls
IP Phone to IP Phone
IP Phone to analog phones on the Cisco CallManager Express router FXS ports
Incoming calls from the PSTN to extensions 1011, 1012, and 1013 by using the following:
Private line, automatic ringdown (PLAR) connection via FXO port
Direct inward dialing (DID) and translation rules via ISDN
Outgoing calls via the PSTN
Incoming and outgoing calls from WAN and the Internet via H.323
Analog phones can appear as Skinny Client Control Protocol (SCCP) endpoints via
Cisco ATA 186 and 188
Voice mail can be hosted by the Server Message Block (SMB) and branch office (refer to
the section on Cisco CallManager Express integration with voice mail)
We have two options for fax support:
Connect the fax machine to the ATA that is connected to Cisco CallManager Express; only
fax passthrough is supported on the ATA
Connect the fax machine to the FXS port of the Cisco CallManager Express router; this
supports fax passthrough, T.38, and Cisco fax relay

(Cont.)
ATA
V
Cisco CallManagerExpress/CUE
Internet
PSTN
Single physical site
Small-to medium-sized businesses

Cannot scale above 240 ephones
IPTX v2.07-4
A single site standalone deployment is the simplest implementation of Cisco CallManager

Express to install and configure. In this type of topology, there are several call types that can
take place. The call types are:
Local calls
IP Phone to IP Phone
IP Phone to analog phones on the Cisco CallManager Express router, FXS ports, or
ATA device
Incoming calls from the PSTN to an internal extension (either IP Phone or analog)
PLAR connection via FXO port
DID and translation rules via ISDN
Outgoing calls via the PSTN
Incoming and outgoing calls from WAN and the Internet via H.323
Call to voice mail, such as CUE, Cisco Unity, or Octel
Fax machines are commonly found and can be supported through either an FXS port or by
connecting the fax to ATA 186 or 188. The fax machine appears as an SCCP device when
connected to the ATA. The following lists the support for fax in Cisco CallManager Express:
Connect the fax machine to the FXS port of the Cisco CallManager Express router:
supports fax passthrough, T.38, and Cisco fax relay
Cisco CallManager Express in SIP Network
This topic describes Cisco CallManager Express in the session initiation protocol (SIP)
network.

Integration with a SIP-based network
Inbound calls to Cisco CallManagerExpress IP

Phones from a SIP network
Outbound calls from Cisco CallManagerExpress IP
Phones to a SIP network
Direct attachment of SIP IP Phones to Cisco
CallManagerExpress is not supported
Call transfer is supported
Call forward is supported
SIP interface with the BTS 10200 is possible
IPTX v2.07-5
Integration of Cisco CallManager Express with a SIP network is supported and can be
implemented. This is more a function of the IOS software than a feature of Cisco CallManager
Express. The Cisco IOS software can support SIP dial peers, and this is how SIP integration is
accomplished with Cisco CallManager Express. This allows for the support of basic calls to and
from Cisco CallManager Express and the SIP network, as well as the ability to blindly transfer,
consultative transfer, and forward to SIP destinations.
Note
SIP endpoints cannot register to or be under the direct control of Cisco CallManager
Express.

(Cont.)
Cisco CallManagerExpress,
CUE Localized Call Processing
SIP Invite,
Redirect, or Refer
PSTN
IP WAN
SIP Integration
SIP Site
SIP support in dial peers is an IOS software function

Use either the notify-based DTMF relay mechanism that is
proprietary to Cisco or RFC 2833based DTMF relay
Cisco CallManagerExpress router must be configured if E.164
numbers are going to register with the SIP registrar server
IPTX v2.07-6
SIP redirect and SIP refer can be used for call transfer and call forwarding features from Cisco
CallManager Express. The mechanisms that are used are similar in function to H.450.2 and
H.450.3. Cisco SCCP phones, such as those used with Cisco CallManager Express systems, do
not support the standard in-band dual tone multifrequency (DTMF) relay mechanism used by
SIP phones to send keypad digits and, as a result, a nonstandard DTMF relay must be
configured on the SIP dial peers. The DTMF relay mechanism that is chosen will either be the
RFC 2833compliant mechanism or the Cisco-proprietary Notify method. The mechanism
that is selected must be configured the same on both ends of the call setup. To configure the
RFC 2833compliant mechanism, use the dtmf-relay rte-nte command under the appropriate
dial peer(s). The command that enables the Cisco Notify mechanism under the dial peer is
dtmf-relay sip-notify.
The SIP DTMF relay method is needed in the following situations:
When SIP is used to connect a Cisco CallManager Express system to a SIP-based
interactive voice response (IVR) or voice mail application
When SIP is used to connect a Cisco CallManager Express system to a SIP-PSTN voice
gateway that goes through the PSTN to a voice mail or an IVR application
Enabling a SIP gateway to register the E.164 numbers with a SIP proxy or SIP registrar is
similar to the way in which H.323 gateways can register E.164 numbers with a gatekeeper. SIP
gateways allow registration of E.164 numbers to a SIP proxy or registrar on behalf of analog
telephone voice ports (FXS ports) and IP Phone virtual voice ports (enhanced FXS [EFXS]
ports) for local SCCP phones.
When registering E.164 numbers in dial peers with an external registrar, you can also register
them with a secondary SIP proxy or registrar to provide redundancy. The secondary registration
can be used if the primary registrar fails. By default, SIP gateways do not generate SIP register
messages. If this function is desired, it must be enabled with the command sip-ua. After you
enter this mode, the primary and secondary registrar servers can be configured with the
registrar command.
Cisco CallManager Express Integration with

Cisco CallManager
This topic describes Cisco CallManager Express integration with Cisco CallManager.

Cisco CallManager
CallManager 3.3(3) or greater
Connection to Cisco CallManageris through the
H.323 protocol
Connection through a QoS-enabled WAN link
Cisco CallManagerdoes not support H.450
protocols
SIP connection in the future
IPTX v2.07-7
The integration of Cisco CallManager Express and Cisco CallManager is accomplished through
an H.323 connection. This H.323 connection is through a WAN link that should be quality of
service (QoS)-enabled for both the call setup messages and the Real-Time Transport Protocol
(RTP) stream.
Cisco CallManager uses Empty Capabilities Set (ECS), a nonstandard protocol, which does not
handle multiple transfers of the same call gracefully and adds signaling delay for each transfer.
Cisco CallManager Express does support incoming ECS requests from other voice gateways
like Cisco CallManager, but Cisco CallManager Express will not initiate an ECS transfer
request. The H.450.X protocols are supported in Cisco CallManager Express, but are not
supported in Cisco CallManager. The workarounds for these issues, which are covered later in
this lesson, include hairpinning and tandem gateways.

Cisco CallManager (Cont.)
Networked
Location A
SRST,
SRST, CUE
CUE
Router
Router
PSTN
Cisco CallManager
Phones
Cisco CallManager
Express Phones
Branch
Branch Office
Office
Cisco CallManager
Cluster Central
Call Processing
Applications
(UM, IVR, IPCC, etc.)
Fat pipe
QoSenabled
IP WAN
Cisco CallManager
Express, CUE
Localized Call
Processing
Central Site
IPTX v2.07-8
In the scenario of Cisco CallManager Express and Cisco CallManager, the most common
topology would be one or more branch offices running Cisco CallManager Express and a
headquarters or other large site running Cisco CallManager. These sites would be connected via
QoS-enabled WAN links with appropriate service level agreements (SLAs), with VoIP calls
traversing the WAN link. The PSTN would be the backup link if the WAN went down or lost
connectivity and for connectivity customers and vendors.

Cisco CallManager (Cont.)
Cisco CallManager
Cisco CallManager
Voice
mail
Distributed Cisco
CallManager with
CUE at small,
remote locations
Voice
mail
PSTN
Fat pipe
Cisco CallManager
Express, CUE
QoSenabled
IP WAN
Cisco CallManager
Express, CUE
IPTX v2.07-9
Another scenario in which Cisco CallManager Express can be integrated with Cisco
CallManager is when one or more branch offices running Cisco CallManager Express are
integrated with more than one Cisco CallManager cluster. This would likely be found in
situations where there are multiple sites with more than 480 users. This is because 480 is the
maximum number of phones supported in Survivable Remote Site Telephony (SRST). In this
scenario, the WAN link must be QoS-enabled and have an appropriate SLA.
Cisco CallManager Express Migration to Cisco

CallManager and SRST
This topic describes Cisco CallManager Express migration to Cisco CallManager and SRST.
Cisco CallManager Express Migration to

Cisco CallManager/SRST
Branch offices router can be migrated from a
Cisco CallManagerExpress router to an SRST
router in a Centralized Cisco CallManager Cluster
Requires changes to configuration of the router
Investment protection is built into Cisco
CallManagerExpress license
Allows for easy segmented migration plan
IPTX v2.07-10
The Cisco CallManager Express deployment solution is designed to fully protect a customer s
investment if they decide to migrate to a Cisco CallManager and SRST solution because of
some specific feature needs or because they outgrow the 240-user limit of Cisco CallManager
Express. The full-featured data router that provides Cisco CallManager Express functionality
can be transitioned into a high-availability gateway in a centralized Cisco CallManager and
SRST design with only some configuration changes.
The Cisco CallManager Express feature license and phone seat licenses can be converted to
SRST licenses. Customers will not have to deal with additional upgrade issues unless they are
adding users above the current level. This allows a customer to choose Cisco CallManager
Express for the present and upgrade to Cisco CallManager and SRST in the future with no
additional costs.
When the customer wants to change to SRST on the router, this can be done on a site-by-site
basis. This allows for segmented upgrades in which a single branch office at a time can be
migrated to the more scalable Cisco CallManager and SRST configuration.
Cisco CallManager Express Migration to

Cisco CallManager/SRST (Cont.)
Networked
Location A
CallManagerExpress
SRST
PSTN
SRST
QoSEnabled
IPWAN
Cisco CallManagerExpress,
CUE Localized Call
Processing
CallManagerExpress Phones
CallManagerPhones
Applications
(UM, IVR, ICD, etc.)
Fat pipe
Phones CCM Phones
CallManagerExpress
Cisco CallManager
Cluster Central
Call Processing
Central Site
Cisco
IPTX v2.07-11
When a site is migrated to an SRST-based design, the IP Phone that was previously registered
to the Cisco CallManager Express router will now register and be under the control of the Cisco
CallManager cluster. As a result, some additional signaling and keepalive messages will
traverse the WAN link during normal operation. When the WAN link is down or connectivity
is lost, the IP Phones register to what used to be the Cisco CallManager Express router and is
now the SRST router. This SRST router is very similar to the functionality of the Cisco
The router that used to run Cisco CallManager Express will need some configuration changes
in order to migrate to an SRST configuration. These changes are not difficult, but do require
some planning and forethought. During normal operations, the router will use H.323 to
communicate with the Cisco CallManager cluster. For additional SRST configuration
guidelines, see the following reference.
Reference
http://cisco.com/application/pdf/en/us/guest/products/ps5049/c1091/ccmigration_09186a008
01d1e94.pdf
Cisco CallManager Express H.323

Interoperability Solutions
This topic describes Cisco CallManager Express H.323 interoperability solutions.
Cisco CallManagerExpress H.323 Interoperability

Solutions H.450-Compliant Networks
1000
1000
Cisco
Cisco CallManager
CallManager
ExpressA
ExpressA
Step 4 Call is
transferred or
forwarded
Step 1 -Call from

1000 to 2000
2000
2000
Step 2 -Transfer
or forward to 3000
Cisco CallManager
ExpressB
3000
3000
IP WAN
Cisco
Cisco
CallManager
CallManager
ExpressC
ExpressC
Step 3 H.450.X message to Cisco

CallManagerExpress A and Cisco
CallManagerExpress C
Step 5 Cisco CallManager

Express B is no longer involved
with the call
IPTX v2.07-12
H.450-Compliant Networks
In an environment in which all the devices are H.450-compliant, the forwarding and
transferring of calls is seamless and efficient. When a call is forwarded or transferred to a
phone on another Cisco CallManager Express router, the H.450.X protocols can be used to
ensure efficient use of bandwidth and resources.

Solutions Non-H.450-Compliant Networks
Hairpinningmechanism can be used for nonH.450-compliant networks like Cisco CallManager,
BTS, and PGS
Hairpinningcan be used to allow H.323 devices to
interact with the CUE module
Hairpinningcan cause bandwidth consumption
problems
Tandem gateway can address the bandwidth
consumption issues
IPTX v2.07-13
Non-H.450-Compliant Networks
In a mixed network that involves two or more types of call agents or managers, there can be
H.323 communication protocol discrepancies and dependencies. Therefore, there is the
opportunity for interoperability glitches. These discrepancies show up most often when a call is
being transferred or forwarded. The recent Cisco CallManager Express releases have
introduced features to address these discrepancies and enable transparent transferring and
forwarding of calls across VoIP networks.
These issues can be addressed when not all gateways support H.450.X protocols, like Cisco
CallManager, BTS 10200, and PGW 2200. One way to address these issues is through the
hairpinning of calls. Hairpin call routing uses the VoIP-to-VoIP connection mechanisms that
were introduced in Cisco CallManager Express 3.1 to transfer and forward calls that cannot use
H.450 standards. When a call that originally terminated on a voice gateway is transferred or
forwarded by a phone or other application attached to the gateway, the gateway originates the
call again and routes the call as appropriate, making a VoIP-to-VoIPor hairpinconnection.
This approach avoids any protocol dependency on the far-end transferred-party endpoint or
transfer-destination endpoint.
Hairpinning can cause an inefficient use of bandwidth because one call is coming in and one
call is going out over the WAN link that is connecting sites. Additional issues arise because of
the increased latency and jitter as more links are traversed.
Another way to use this hairpinning function is to set up a separate gateway at the location of
the non-H.450.X device. This gateway would support H.450.X protocols, and it would front
end all transfers and forwards. This results in more efficient bandwidth utilization and WAN
utilization.

Solutions Non-H.450-Compliant NetworksHairpinning
1000
1000
Cisco
Cisco CallManager
CallManager
ExpressA
ExpressA
Non-H.450
Gateway
Step 1 -Call from

1000 to 2000
2000
2000
Cisco CallManager
ExpressB
Step 2 -Transfer
or forward to 3000
IP WAN
Step 3 Call is hairpinned
and connected to 3000
3000
3000
-
-
IPTX v2.07-14
Non-H.450-CompliantNetworks Hairpinning
A call is placed from one Phone under the control of a Cisco CallManager Express system to
another Phone under a different Cisco CallManager Express system. The recipient of the phone
call is forwarded to a Phone on a Cisco CallManager cluster. Because Cisco CallManager does
not support H.450.X protocols, the call must be hairpinned on the recipient Cisco CallManager
Express router. This consumes bandwidth equal to two calls instead of one call. In addition, the
latency from the originator of the call to the Cisco CallManager cluster phone incurs two times
the latency of the WAN link where it is hairpinned.
Note
If Cisco CallManager Express B goes down while a call is in progress using the hairpin, the
call will be disconnected.
Although this is not the optimal solution, it is currently necessary when H.323 protocol
mismatches occur. This hairpinning of calls can be implemented in another fashion to reduce
the latency and bandwidth issues. Ultimately, this issue will be resolved with the introduction
of SIP support into the Cisco CallManager cluster in a future release.
Note
Hairpinning should be avoided if possible.
Cisco CallManagerExpress H.323

Interoperability Solutions H.323 to SIP
Step 1 A H.323 call
arrives to the CUE
Auto Attendant pilot
number
CUE
SIP
Step 3 The SIP

connection to the
CUE module is setup
H.323
H.323
Skinny
IP WAN
Gateway
3000
3000
Cisco
CallManager
Express
-
Step 2 A hairpin between the
H.323 call leg and the SIP call leg to
the CUE module is set up
- -
IPTX v2.07-15
H.323 to SIPHairpinning
H.323 to SIP call routing to CUE supports call transfer and call forward of incoming H.323
calls to CUE without using loopback-dns. The feature is enabled by configuring allowconnections h323 to sip in voice service voip configuration mode. When this command is
enabled, on any incoming H.323 calls that are forwarded or transferred to CUE, the H.323 call
leg and SIP call leg to CUE is hairpinned on the Cisco CallManager Express router. This
feature does not support hairpinning to any SIP endpoint other than CUE.
Example: show voiprpt connections Detail
- -
View the current RTP connections
- -
Connection 1 Call Id maps to connection 2

Call Id as its destination Call Id
IPTX v2.07-16
To view a hairpinned call, use the show voip rtp connections command.

Solutions Non-H.450-Compliant NetworksTandem
Gateway
Cisco
Cisco CallManager
CallManager
Express
Express A
A
1000
1000
Step 4 Call is
transferred or forwarded
H.450
Tandem
Gateway
Step 1 Call made

from 1000 to 2000
Cisco CallManager
Express B
2000
2000
IP WAN
3000
3000
Step 2 -Transfer or
forward from 2000
to 3000
Step 3 H.450.2 or H.450.3

message to tandem
gateway and Cisco
CallManagerExpress A
Step 5 Local
hairpin at Cisco
CallManagersite,
not across WAN
IPTX v2.07-17
Non-H.450-Compliant NetworksTandem Gateway

A tandem gateway allows for the more efficient use of bandwidth and optimizes the latency and
jitter of a call that is forwarded or transferred. The tandem gateway is installed at the same
location as the non-H.450.X device. The most common configuration that this is used with is a
Cisco CallManager cluster in which the tandem gateway is local to the cluster. The tandem
gateway does not have to be dedicated to this function and can perform other functions.
A call is connected between Phones on two different Cisco CallManager Express systems. The
call is then transferred to a Phone on the Cisco CallManager cluster. The Cisco CallManager
Express system that transferred the call sends an H.450.2 message to the tandem gateway,
which allows for the efficient use of bandwidth and WAN link. The call is then hairpinned on
the tandem gateway to reach the Cisco CallManager cluster.
The tandem gateway is enabled with the allow connections h323 to h323 command.

Trunk Configuration
Gatekeeper controlled
or non-gatekeeper
controlled
Media Termination
Point Required must be
selected
Cisco CallManager
Express will register
with Cisco CallManager
MTP selected
IP address of Cisco
CallManagerExpress
or tandem gateway
IPTX v2.07-18
Integrating Cisco CallManager Express and a Cisco CallManager cluster requires configuration
of an H.323 dial peer on the Cisco CallManager Express router and some configuration on the
Cisco CallManager cluster. The configuration of the Cisco CallManager cluster includes the
creation of an intercluster trunk. The trunk may be either gatekeeper-controlled if bandwidth is
an issue and Call Admission Control (CAC) is required or non-gatekeeper-controlled if
bandwidth is plentifulfor example, in a LAN environment. The IP address of the trunk must
be configured. It will either be populated with the address of the Cisco CallManager Express
router if hairpinning is done on the Cisco CallManager router or with the IP address of the
tandem gateway if hairpinning is done there. In addition to the IP address, the use of a media
termination point (MTP) is required and must be selected when adding the trunk.

Solutions Non-H.450-Compliant Networks (Cont.)
Modify the service parameters of the Cisco
CallManagerservice to the following settings
Set H.323 Faststart Inbound to Falsethis is the default
Set Send H225 User Info message to H225 Info for Ringback
IPTX v2.07-19
There are some other settings that must also be configured in order to enable the integration to
work properly.
The first is the H.323 Faststart Inbound service parameter setting on the Cisco CallManager
service. It must be set to False (the default setting).
The second setting under the service parameters of the Cisco CallManager service is Send
H225 User Info Message, and it needs to be set to H225 Info for Ringback.
Cisco CallManagerExpress H.323

Interoperability Solutions H.323 Gatekeeper
H.323 Gatekeeper
Part of the H.323 standard
Can be used with Cisco CallManager Express router
Call Admission Control (CAC) functions
Can be used for centralizing dial plan
IPTX v2.07-20
H.323 Gatekeeper
The gatekeeper is a part of the H.323 protocol suite. The gatekeeper can be used by the Cisco
CallManager Express system to perform some telephony functions. The primary function that
Cisco CallManager Express uses the gatekeeper for is CAC. CAC allows the gatekeeper to
regulate the number of calls that can be traversing a link at any one time. It can also deny
access to the regulated link. This prevents oversubscription of the WAN link, which can happen
when too many calls are allowed.
Another function that can be performed by the gatekeeper is to centralize the dial plan for
interCisco CallManager Express connections. This has the benefit of centralizing dial plan
management and administration, as well as minimizing the configuration changes on Cisco

Solutions H.323 Gatekeeper (Cont.)
Pod1
Recommended for 20+ sites
Pod2
Gatekeeper pair running

HSRP and GUP
Pod6
Pod3
WAN
Pod7
Pod4
Pod8
Pod5
IPTX v2.07-21
A gatekeeper is often used in larger multisite deployments, as well as for connecting to service
provider networks. The gatekeeper is a function that can run on a Cisco IOS router. There is
one instance or zone per site, and the CAC functions can be defined on a per-zone basis. The
dial plan is also often centralized and configured on a per-zone basis.
Note
It is important to have an organized, well-thought-out dial plan that does not overlap.
The location of the gatekeeper does not need to be local to the WAN links that are being
governed. There just needs to be IP connectivity. Gatekeeper functionality should be deployed
in a pair of IOS routers with Hot Standby Router Protocol (HSRP) for redundancy and
Gatekeeper Update Protocol (GUP) to synchronize gatekeeper state information in case of a
failure.

-
--

-
The E.164 number will register,

the primary will not
-
-
-
-
-
-
-
-

-
WAN
Cisco CallManager
Express
Gatekeeper
IPTX v2.07-22
This figure shows a sample configuration for both Cisco CallManager Express and the
gatekeeper.
Summary
Summary
The Cisco CallManagerExpress system can be configured
in a fashion similar to a key switch, PBX, or a hybrid of
both.
The simplest deployment will have a single site with one
Cisco CallManagerExpress router and up to 240 phones.
Cisco CallManagerExpress communicates with CUE via
the SIP protocol.
Cisco CallManagerExpress can be integrated with Cisco
CallManager.
The Cisco CallManagerExpress system can be migrated
to an SRST router with the migrating phones being under
the control of Cisco CallManager.
Cisco CallManager does not support H.450 protocols.
When integrating with Cisco CallManagerExpress, this
can be dealt with by hairpinningcalls or a tandem
gateway.
IPTX v2.07-23
Lesson 2
Deploying Voice Mail with

Overview
This lesson defines the different ways in which voice mail can be integrated with Cisco
CallManager Express. This includes Cisco Unity Express (CUE), Cisco Unity 4.0, and Octel.
Objectives
Upon completing this lesson, you will understand the issues involved in voice mail integration.
Describe the architecture of how CUE is integrated with Cisco CallManager Express using
SIP
Describe the architecture of how CUE and Cisco Unity are connected in the network for
voice mail integration using SCCP
Describe the procedures for integrating to a voice mail system using analog DTMF
SIP Integration with Cisco Unity Express
This topic describes the session initiation protocol (SIP) integration with CUE.
SIP Integration with Cisco Unity Express

Cisco CallManager
Express
SIP
CUE
SIP
SCCP
PSTN
PSTN
Gateway
Voice mail fully integrated with Cisco CallManagerExpress in same chassis

SIP use is internal to CUE architecture and cannot yet be used with SIP
phones or SIP VoIP deployments
Cisco CallManagerExpress does call routing between gateway interfaces,
phones, and voice mail
Cisco CallManagerExpress, CUE, and gateway functions may all be
integrated into the same physical chassis or on separate routers
IPTX v2.07-3
When integrating Cisco CallManager Express with CUE, the call control protocol is SIP. This
integration is used internally across the backplane of the router and cannot be used for phones
to directly set up a call to voice mail. When users check their voice mail from an IP Phone,
Skinny Client Control Protocol (SCCP) will be used to communicate with Cisco CallManager
Express, which will then set up a call to the CUE system using SIP. After the call is set up,
there will be two Real-Time Transport Protocol (RTP) streams going to and from the CUE
system.
The CallManager Express, Unity Express, and gateway functions can all reside in the same
chassis or can be physically separate from each other.
Skinny Integration with Cisco Unity Server

This topic describes the skinny integration with the Cisco Unity server.
Skinny Integration with Cisco Unity Server

Cisco Unity 3.1 or higher required
Requires configuration of the Cisco Unity server
and matching configuration on the Cisco
One Cisco Unity server can be integrated with
more than one Cisco CallManagerExpress router
Uses the SCCP, SIP, or H.323 protocol for the
integration
Does not require analog or digital trunks; only
requires IP connectivity
IPTX v2.07-4
The integration of Cisco Unity 3.1 or higher with Cisco CallManager Express uses SCCP.
The phone system sends the following information in the form of skinny packets with
forwarded calls:
The extension of the called party
The extension of the calling party (for internal calls) or the phone number of the calling
party (if it is an external call and the system uses caller ID)
The reason for the forward (the extension is busy, does not answer, or is set to forward all
calls)
Cisco Unity uses this information to answer the call appropriately. For example, a call
forwarded to Cisco Unity is answered with the personal greeting of the subscriber. If the phone
system routes the call to Cisco Unity without this information, Cisco Unity answers with the
opening greeting.
Skinny Integration with Cisco Unity Server (Cont.)
Cisco Unity 3.1 or higher

Branch/Retail
Branch/Retail Outlet,
Outlet, Etc.
Etc.
Location
Location B
B
PSTN
IP WAN
SCCP
RTP
Cisco
Unity
Central Site
IPTX v2.07-5
A Cisco CallManager Express router registers Cisco Unity ports as skinny devices and
perceives them as ephones in which the voice mail pilot number is configured as an ephone-dn
and the voice mail device is configured as an ephone. For a four-port Cisco Unity server
integration, you need to configure four ephone-dns and four ephones for the four voice mail
ports and four voice-mail device IDs, respectively. Cisco CallManager Express voice mail
integration with Cisco Unity supports the following:
Direct access to the voice mail system
Call forward all, forward busy, and forward no answer to personal greeting
Message Waiting Indicator (MWI)
To access a mailbox from an IP Phone, users press the Messages button on the phone or dial the
voice mail number (for example, 52222). Then users are asked to enter their PIN to listen to
their own messages. To access their mailbox from the public switched telephone network
(PSTN), users dial a voice mail number (for example, 408 555-2222), then enter their extension
and PIN. After they are authenticated, they can listen to, then delete or store their messages.
When a calling party places a call to an extension connected to the Cisco CallManager Express
router and the extension is configured with the call forward option, the call is forwarded to
Cisco Unity voice mail for the extension dialed if the call is not answered, if the extension is
busy, or if forward all is set. Cisco CallManager Express communicates with the Cisco Unity
server via SCCP.
When a call is forwarded to the Cisco Unity voice mail server, the calling number, called party
number, and redirect number are all forwarded to the Cisco Unity server. Thus, the call is
forwarded to the called extensions own voice mailbox and the personal greeting can be heard.
Message Waiting Indicator

Upon receiving the MWI status from the Cisco Unity voice mail system for an extension, the
Cisco CallManager Express router can signal the IP Phone to turn the MWI lamp on or off.
Configure the Messages Button to Access the Voice Mail System (Pilot Number)
Directly
You may configure voice mail 52222 in telephony-service configuration mode:
telephony-service
voice mail 52222
Pressing the Messages button on the IP Phone or dialing 52222 will let you access the Cisco
Unity voice mail system.
To integrate with a four-port Cisco Unity server, configure four ephone-dns for the four ports
on the Cisco Unity server with the same voice mail number, 52222, for answering calls. Also
configure the MWI with preference 0, 1, 2, and 3 so that if the first port is busy, it will go to the
second port and so on. Alternatively, you may configure three ephone-dns for the three ports on
Cisco Unity with the same voice mail number, 52222, for answering calls and the fourth one
with number 52223, which is equivalent to the fourth port on Cisco Unity and is primarily for
dial-out MWI.
Analog DTMF Integration
This topic describes the analog dual tone multifrequency (DTMF) integration.
Analog DTMF Integration

Requires traditional analog circuits to the voice
mail server
Active Voice Reception and Octel supported
DTMF tones sent to the voice mail system will
need to match an integration file on the voice
mail system
Uses DTMF tones at the beginning of the call to
send information to the voice mail
IPTX v2.07-6
Both Octel and Active Voice Reception voice mail systems support integration via traditional
analog ports. The calling, called, and redirected numbers are sent to the voice mail system in
the form of DTMF tones at the start of the call when integrating with an analog voice mail
system. The DTMF tones that are sent must match on both the Cisco CallManager Express and
an integration file on the voice mail server.
Note
Simplified Message Desk Interface (SMDI) and digital integration are not supported.
Analog DTMF Integration (Cont.)

Legacy Voice mail
FXS
DTMF
Tones
Analog Connection to Legacy Voice Mail

Reception or Octel Voice Mail Server
Analog ports
Treated as a normal extension for Cisco CallManager

Express
MWI sent from the voice mail to Cisco CallManager
Express
IPTX v2.07-7
This figure shows that the connection between Cisco CallManager Express and Active
Voice Reception or Octel voice mail system is via Foreign Exchange Station (FXS) using
analog DTMF.
The voice mail system is connected to the FXS port of the router and is treated as a normal
extension for the Cisco CallManager Express router. For DTMF integrations, information on
how to route incoming or forwarded calls in the form of DTMF digits is sent by the Cisco
CallManager Express router, and MWI codes are sent from the voice mail system in the form of
DTMF packets. Voice mail systems are designed to respond to DTMF after the system has
answered the incoming calls.
Users can access their voice mail from an IP Phone by pressing the button on the Phone. When
the voice mail system answers the call, the Cisco CallManager Express router sends a DTMF
packet to inform the voice mail system that this is a direct call from extension 1011, and users
are automatically put into their own voice mailbox and prompted to enter the option to check
the messages.
Analog DTMF Integration (Cont.)

-
-
-
-

-

-

-

-

Integration on the
voice mail server that
matches the pattern
command settings
and number of ports
1/1/0 1/1/3
Cisco CallManager
Express
IPTX v2.07-8
The Cisco CallManager Express router communicates with the analog voice mail system by
sending DTMF patterns. The voice mail integration configuration in the figure and listed below
includes four call-forwarding scenarios when call forwarding to the voice mail system is
configured with DTMF patterns set to 4, 5, 6, and 7, respectively. This also requires that the
Active Voice Reception system be configured with correct patterns accordingly.
pattern ext-to-ext no-answer
The Cisco CallManager Express router sends 5 to notify the voice mail system to play a
personal greeting for no answer when a call coming from one extension to another is forwarded
with no answer.
pattern ext-to-ext busy
personal greeting for busy when a call coming from one extension to another is forwarded
with busy.
pattern trunk-to-ext no-answer
personal greeting for no answer when a call coming from Foreign Exchange Office (FXO) to
an extension is forwarded with no answer.
pattern trunk-to-ext busy
personal greeting for busy when a call coming from FXO to an extension is forwarded
with busy.
Router Configuration: Two Commands

This topic describes the two commands for router configuration.
Enable voice-mail integration with DTMF and analog

voice mail systems
Configures the DTMF digit pattern forwarding that is

necessary to activate the voice mail systemwhen
the Messages button is pressed
IPTX v2.07-9
The command vm-integration is used to enable DTMF integration and enter vm-integration
mode. From within vm-integration mode, the digits that will be forwarded when a user presses
the Messages or Envelope icon button can be configured with the command pattern direct
tag1.

(Cont.)
Digit pattern forward that is necessary to activate the

voice mail system when an internal extension is
forwarded to voice mail if the called extension does
not answer

voice mail system when an internal extension is
forwarded to voice mail if the called extension is
busy
IPTX v2.07-10
There are four situations in which a call can be forwarded to a voice mail system. The first of
the four commands is pattern ext-to-ext no-answer tag1.This handles calls going from an
extension to another extension when no one answers. The second command is pattern ext-toext busy tag1. It is for when an extension calls another extension and the destination is busy.
Note
The tag must match an integration file setting on the voice mail system.

(Cont.)

voice mail system when an external trunk call is
forwarded to voice mail if the called extension does
not answer

voice mail system when an external trunk call is
forwarded to voice mail if the called extension is
busy
IPTX v2.07-11
The third of the four commands is pattern trunk-to-ext no-answer tag1.This handles calls
going from a PSTN trunk to another extension when no one answers. The final command is
pattern trunk-to-ext busy tag1. It is for when a call from a PSTN trunk goes to an extension
while the destination is busy.
Note
The tag must match an integration file setting on the voice mail system.
Summary
Summary
Integrating Cisco CallManagerExpress with CUE
requires configuration on both devices.
Cisco CallManagerExpress can be integrated with
Cisco Unity via the SCCP.
DTMF digits are used to integrate Cisco
CallManagerExpress with an analog voice mail.
IPTX v2.07-12
Module Summary
Module Summary
It is important to understand issues that may arise
in a Cisco CallManagerExpress deployment.
There are design concerns when integrating Cisco
CallManagerExpress with a Cisco Unity voice mail
system or a legacy voice mail system.
IPTX v2.07-1
References
Cisco CallManager Express Security Guide and Best Practices.
http://cisco.com/en/US/netsol/ns340/ns394/ns165/ns391/networking_solutions_design_gui
dance09186a00801f8e30.html.
Cisco CallManager Express 3.2: Integrating Voice Mail.
a00802d255e.html.
Module Self-Check
Q1) What is the maximum number of voice ports that can be supported on a Cisco
CallManager Express system? (Source: Describing Deployment Scenarios and Design
Considerations)
A) 300
B) 800
C) 720
D) 750
Q2) What is the maximum number of users that can be supported by the Cisco CallManager
Express system? (Source: Describing Deployment Scenarios and Design
Considerations)
A) 120
B) 150
C) 175
D) 240
E) 250
Q3) When Cisco CallManager Express and Cisco Unity Express communicate with one
another across the backplane of the router in a collocated installation, what protocol is
used? (Source: Describing Deployment Scenarios and Design Considerations)
A) MGCP
B) SCCP
C) H323
D) SIP
Q4) When joining two VoIP calls together, or hairpinning, what is true regarding the codecs
that are used? (Source: Describing Deployment Scenarios and Design Considerations)
A) One call leg may be H.323 and the other SIP.
B) One call leg may be SIP and the other SCCP.
C) Both call legs must be SIP only.
D) It does not matter.
E) None of the above.
Q5) What is the primary responsibility of the gatekeeper in a Cisco CallManager Express
environment? (Source: Describing Deployment Scenarios and Design Considerations)
A) dial plan
B) CAC (Call Admission Control)
C) control all voice gateways
Q6) In a Cisco CallManager Express environment containing five sites, how many
gatekeeper routers will be required? (Source: Describing Deployment Scenarios and
Design Considerations)
A) 7
B) 5
C) 3
D) 1
Q7) What are the two ways that you can access the Cisco Unity server from the IP Phone?
(Choose two.) (Source: Deploying Voice Mail with Cisco CallManager Express)
A) Dial the extension of your voice mailbox.
B) Dial the Cisco Unity Auto Attendant.
C) Push the Messages button.
D) Use the 800 voice mail number.
Q8) When integrating with a traditional analog voice mail system, what is sent as DTMF
tones at the start of the call? (Choose all that apply.) (Source: Deploying Voice Mail
with Cisco CallManager Express)
A) calling number
B) called number
C) redirected number
D) CED
Q9) What type of port is used to connect to an analog voice mail from a voice-enabled
router? (Source: Deploying Voice Mail with Cisco CallManager Express)
A) Ethernet port
B) FXS port
C) FXO port
D) ATA 186 and 188

Q1) C
Q2) D
Q3) D
Q4) A
Q5) B
Q6) D
Q7) A, C
Q8) A, B, C
Q9) B
IPTX
IP Telephony
Express
Version 2.0
Lab Guide
Text Part Number: 97-2197-01
Copyright 2005, Cisco Systems, Inc. All rights reserved.

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

Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this activity, you will set up the Cisco CallManager Express network. After completing this
activity, you will be able to meet these objectives:
Describe the firmware location and download process
Identify the DHCP setup command
Describe the process to set up IP Phones
Identify configuration commands of ephone-dn and ephone
Visual Objective
The figure illustrates what you will accomplish in this activity.
Visual Objective for Lab 2-1:Configuring

Pod1Pod8
PodX
Data VLAN =80
Data VLAN =10

Voice VLAN =15
X000 X001
Voice VLAN =85
Voice VLAN =X0
1000100180008001
Data VLAN =X5
Required Resources
These are the resources and equipment required to complete this activity:
Cisco CallManager Express router
Two Cisco IP Phones
Inline-power-capable switch
Student PC
IPTX v2.03
Command List
The table describes the commands used in this activity.
Command
Description
Enters privileged EXEC mode
Enters global configuration mode
Assigns a host name to the router
-- -
Assigns a password to enter privileged EXEC mode
Enters line mode
Disables
Enables logins on vty connections
-- -
Sets a password cisco on the vty
--
Enables synchronous logging of messages
Prevents the current connection from timing out
Enters FastEthernet 0/0 configuration mode
Sets the trunking protocol to dot1q and specifies a vlan to

associate the subinterface with.
--
Sets the IP address on the FastEthernet 0/0 interface
Enables the interface
Goes back one configuration level
Starts EIGRP with an autonomous system of 100
Runs EIGRP on all interfaces with a 10.0.0.0 network assigned to

it
- -
Shows the contents of the flash
-
-
Copies a file from the source to the destination specified
Starts a Telnet session to the specified ip address

- -
Extracts the contents of a tar to the destination specified
- -
Displays the configuration of the system hardware, the software

version, the names and sources of configuration files, and the
boot images
Shows the current configuration that is loaded and running in

RAM on the router
-
-
Enters the setup utility
- -
Sets the date and time

--
Sets a range of addresses to be excluded from the DHCP pool
Lab Guide 3
Command
Description
Defines a DHCP pool and enters a DHCP pool mode
Enters a network range and subnet mask to use to assign an

address and mask to the DHCP clients
Sets the default gateway that will be assigned to the DHCP

clients
Sets the TFTP server that will be assigned to the DHCP clients
- -
Configures the Flash memory device on the router as a TFTP

server
Clears the Cisco CallManager Express configuration
Sets the maximum ephones that can be present
Sets the maximum ephone-dns that can be present
Loads the firmware to use for the 7960 and 7940 IP Phones
--
Sets the interface where Cisco CallManager Express will listen

for Skinny messages
Sets the time zone for a Cisco IP Phone clock
Creates XML files for configuring the IP Phones
Sets the keepalive to 10 seconds
Creates an ephone-dn
Assigns a directory number to the ephone-dn
Assigns a name to the ephone-dn
Creates an ephone
--
Assigns a physical device to an ephone
Displays Cisco IP phone registration activity
Assigns a model of IP Phone to the ephone
Assigns an ephone-dn to a line on the ephone
--
Turns on auto-registration and configuration of new ephone-dns
Job Aids
These job aids are available to help you complete the lab activity.
Table 1
Pod
Hostname
of Cisco
CallManager
Express
Router
IP Address
on Fa0/0
Type
Pod
1
CMERouter1 10.10.0.1 /24 Data 10.10.0.1-10.10.0.10 10.10.0.0 /24 10.10.0.1
10.15.0.1/24 Voice 10.15.0.1-10.15.0.10

Pod
2
10.35.0.0 /24 10.35.0.1 10.30.0.1
10.45.0.0 /24 10.45.0.1 10.40.0.1
10.55.0.0 /24 10.55.0.1 10.50.0.1
10.65.0.0 /24 10.65.0.1 10.60.0.1
CMERouter7 10.70.0.1 /24 Data 10.70.0.1-10.70.0.10 10.70.0.0 /24 10.70.0.1
10.75.0.1/24 Voice 10.75.0.1-10.75.0.10

Pod
8
10.25.0.0 /24 10.25.0.1 10.20.0.1
CMERouter6 10.60.0.1 /24 Data 10.60.0.1-10.60.0.10 10.60.0.0 /24 10.60.0.1
10.65.0.1/24 Voice 10.65.0.1-10.65.0.10

Pod
7
10.15.0.0/24 10.15.0.1 10.10.0.1
CMERouter5 10.50.0.1 /24 Data 10.50.0.1-10.50.0.10 10.50.0.0 /24 10.50.0.1
10.55.0.1/24 Voice 10.55.0.1-10.55.0.10

Pod
6
Option 150
CMERouter4 10.40.0.1 /24 Data 10.40.0.1-10.40.0.10 10.40.0.0 /24 10.40.0.1
10.45.0.1/24 Voice 10.45.0.1-10.45.0.10

Pod
5
Default
Router
CMERouter3 10.30.0.1 /24 Data 10.30.0.1-10.30.0.10 10.30.0.0 /24 10.30.0.1
10.35.0.1/24 Voice 10.35.0.1-10.35.0.10

Pod
4
IP Network
for DHCP
Pool
CMERouter2 10.20.0.1 /24 Data 10.20.0.1-10.20.0.10 10.20.0.0 /24 10.20.0.1
10.25.0.1/24 Voice 10.25.0.1-10.25.0.10

Pod
3
DHCP Pool
Exclusion
10.75.0.0 /24 10.75.0.1 10.70.0.1
CMERouter8 10.80.0.1 /24 Data 10.80.0.1-10.80.0.10 10.80.0.0 /24 10.80.0.1
10.85.0.1/24 Voice 10.85.0.1-10.85.0.10
10.85.0.0 /24 10.85.0.1 10.80.0.1
Lab Guide 5
Table 2
Pod
Dial Plan Extension

Numbers
Voicemail Extension
Pod 1 1000-1099 1999 2015559000

Pod 2 2000-2099 2999 2025559000
Pod 3 3000-3099 3999 2035559000
Pod 4 4000-4099 4999 2045559000
Pod 5 5000-5099 5999 2055559000
Pod 6 6000-6099 6999 2065559000
Pod 7 7000-7099 7999 2075559000
Pod 8 8000-8099 8999 2085559000
First E.164 DID Number
Worksheets
These worksheets may be used to document and as a reference for Labs 2, 3, 4, and 5.
Completed versions of the worksheets appear at the end of the lab guide.
Pod 1 Ephone-dn Worksheet

Tag or
Seq #
Number
Function
Applied to
Settings
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Lab Guide 7
Pod 1 Dial Peer Worksheet

Tag
#
Destination
Pattern
Incoming
Called-number
Port or Session Target
Settings
1
2
3
4
5
6
7
8
Pod 1 Identity
Username
First Name
Last Name
Ephone
CME
Administrator
CME Administrator
CUE
Administrator
CUE Administrator
Customer
Administrator
CME Customer
Administrator
First user
Second user
Pod 1 CUE Numbers

Number
Comments
Voice mail pilot number

Default automated attendant
Administrator TUI
MWI on
MWI off
Custom automated attendant
Domain
Comments
Task 1: Initial Configuration

In this task, you will construct an initial network configuration on the Cisco CallManager
Express router.
Activity Challenge Tasks

In this lab, the company ACME has decided to deploy Cisco CallManager Express in the
enterprise. First, you must configure the Cisco CallManager Express router and verify
connectivity. You should configure the router with the following: (Go to the Activity Procedure
if you are unable to configure any of these goals):
A name of CMERouterX, where X is your assigned pod number
An enable password of cisco
The ability to telnet to the system with a password of cisco
Console messages that cause any entered characters to be redisplayed on the terminal
Name resolution disabled (because no DNS is available in classroom)
A DHCP scope that will hand out the IP addresses, subnet mask, and default gateway for
your assigned data subnet
The lowest FastEthernet interface configured with an 802.1q trunk and IP addresses for
your assigned voice and data subnets
EIGRP configured with an autonomous system of 100 and able to route for all 10.0.0.0
networks
Connectivity by pinging other pods
Activity Procedure
Complete these steps:
Step 1
The instructor assigns the pod number for the class.
Step 2
Connect to the console of your Cisco CallManager Express router.
Step 3
Enter the command enable to enter privileged EXEC mode.
Step 4
Enter global configuration mode by entering the command configure terminal.
Step 5
From the router(config)# prompt, enter the hostname of your router using the
hostname CMERouterX, where X is the pod number. Use Table 1 to verify your
configuration.
Step 6
Set an enable password of cisco by using the enable password cisco command
(please do not deviate from this password).
Step 7
Use the command no ip domain-lookup to disable name resolution (because there

is no DNS server in the classroom lab).
Step 8
Enter the command line vty 0 4 to enter the line subconfiguration mode.
Step 9
From (config-line)# mode, enter the command password cisco.
Step 10
From (config-line)# mode, enter the command login.
Step 11
From (config-line)# mode, enter the command logging synchronous.
Lab Guide 9
Step 12
From (config-line)# mode, enter the command no exec-timeout.
Step 13
Enter the command line console 0 in order to enter the line subconfiguration mode.
Step 14
From (config-line)# mode, enter the command password cisco.
Step 15
From (config-line)# mode, enter the command login.
Step 16
From (config-line)# mode, enter the command logging synchronous.
Step 17
From (config-line)# mode, enter the command no exec-timeout.
Step 18
Enter the configuration mode for the Fast Ethernet interface 0/0.X0 by using the
command interface fastethernet 0/0.X0 (where X is the pod number).
Step 19
Enter the command encapsulation dot1q X0 (where X is the pod number). If a

warning message appears, ignore it.
Step 20
From subinterface configuration mode, enter the IP address for the data VLAN from
Table 1 using the ip address 10.X0.0.1 255.255.255.0 command (where X is the pod
number).
Step 21
Enter the configuration mode for the Fast Ethernet interface 0/0.X5 by using the
command interface fastethernet 0/0.X5 (where X is the pod number).
Step 22
Enter the command encapsulation dot1q X5 (where X is the pod number).
Step 23
From subinterface configuration mode, enter the IP address for the voice VLAN
from Table 1 using the ip address 10.X5.0.1 255.255.255.0 command (where X is
the pod number).
Step 24
Enter the configuration mode for the Fast Ethernet interface 0/0 by using the
command interface fastethernet 0/0.
Step 25
From subinterface configuration mode, enter the no shutdown command.
Step 26
Enter exit to return to global configuration mode.
Step 27
Enter the command ip dhcp excluded-address 10.X0.0.1 10.X0.0.10 (where X is the

pod number).
Step 28
Enter the command ip dhcp pool CMEDataX (where X is the pod number).
Step 29
Use the network 10.X0.0.0 255.255.255.0 command to set up the range of addresses
that will be used (where X is the pod number).
Step 30
Enter the default-router 10.X0.0.1 command (where X is the pod number).
Step 31
Step 32
Use the router eigrp 100 command to start an EIGRP process with an autonomous
system of 100.
Step 33
Enter the network 10.0.0.0 command to enable EIGRP on all 10.0.0.0 networks.
Step 34
A console message should appear indicating that an adjacency has been formed.
Step 35
Use the show ip route command to verify that EIGRP routes appear in the routing
table.
Step 36
Verify connectivity by pinging the 10.X0.0.2 address (where X is the pod number).
Step 37
Save the configuration by using the copy running-config startup-config command.
Activity Verification
You have completed this task when you attain these results:
Verify the ability to ping the 10.X0.0.1 addresses of all other pods.
Verify that the configuration has been saved.
Task 2: Viewing the Switch Configuration

In this task, you will view the switch configuration.

In this task, ACME has configured the router with a basic configuration and now the
configurations of the switches need to be verified.
Telnet to the switch at 10.0.0.4 (or the IP provided by the instructor).
Verify that the proper configuration is on the switch ports that have been assigned to your
pod.
Activity Procedure
Step 1
The instructor will diagram the ports that are assigned to the two phones in the pods.
Step 2
Telnet to the switch by entering telnet 10.0.0.4 (if different, the instructor will give
the IP address).
Step 3
The password is cisco.
Step 4
Enter the command enable to enter privileged EXEC mode. The password is cisco.
Step 5
Use the command show running-config to view the configuration that is present on
your IP Phone ports.
Step 6
What is the data VLAN? __________
Step 7
What is the voice VLAN? _________
Verify that you can view the configuration on your assigned ports.
Verify that you can obtain the data and voice VLAN.
Lab Guide 11
Task 3: Installing the Cisco CallManager Express Software

In this task, you will install the software on the Cisco CallManager Express router.

In this task, ACME has configured the router with a basic configuration but the version of IOS
software on the router does not support Cisco CallManager Express. The version of IOS
software must be updated as follows:
Use IOS commands to verify the current version of IOS software.
Use IOS commands to copy the appropriate IOS file (for example c3725-ipvoice-mz.12311.XL.bin) from the FTP server specified by your instructor. Be sure to clear the contents
of flash to make room for this version of IOS software.
Use the archive command to extract the cme-basic-123-11XL.tar files and 7970-602sr15.tar files from the location specified by your instructor to the flash memory of the router.
Save your configuration.
Activity Procedure
Step 1
From privileged EXEC mode, enter copy ftp://IP_Addr/filename_provided_by

instructor flash: (where IP_Addr of the FTP server and filename will be provided by
your instructor). For example: copy ftp://10.10.0.100/c3725-ipvoice-mz.12311.XL.bin flash:. If the file already exists, go ahead and overwrite the file.
Step 2
When prompted to overwrite flash, enter y for yes.
Step 3
The file will be written to flash and will take a couple of minutes to complete.
Step 4
Use the show flash command to verify that the IOS file is present in flash memory.
Step 5
When the upload of IOS software is complete, reload the router.
Step 6
Verify the version of IOS software running on your router by using the show
version command. The version should be 12.3(11) XL.
Step 7
Enter show flash to view the contents.
Step 8
From privileged EXEC mode, enter the command archive tar /xtract
tftp://IP_Addr/cme-basic-123-11XL.tarflash: (where IP_Addr is the TFTP server
provided by your instructor). This is used to extract the Cisco CallManager Express
files from a tar file and put them in flash locally. The URL will be provided by the
instructor.
Step 9
Enter show flash to verify that files that were extracted are present in flash RAM.
Step 10
From privileged EXEC mode, enter the command archive tar /xtract
tftp://IP_Addr/7970-602sr1-5.tarflash: (where IP_Addr is the TFTP server
provided by your instructor). This is used to extract the firmware files for the Cisco
7970 IP Phone.
Step 11
Enter show flash to verify that files that were extracted are present in flash RAM.
Step 12
Use the show running-config command to obtain a baseline understanding of the

configuration.
Verify that the Cisco CallManager Express files are present in flash.
Verify that the version of IOS software is 12.3(11)XL.
You understand the base configuration after installation.
Task 4 Configuration A (Two Cisco 7960 IP Phones): Automated

Phone Setup
In this task, you will use the setup utility to configure the Cisco CallManager Express router
and two 7960 IP Phones.

In this task, ACME desires to deploy Cisco CallManager Express and the associated IP Phones
in the easiest possible way. Use the setup utility to configure the following:
Set the voice DHCP to a scope of 10.X5.0.0, subnet mask of 255.255.255.0, default
gateway of 10.X5.0.1, and a TFTP server of 10.X5.0.1. Exclude the first ten addresses
within this subnet.
Set the source address to 10.X5.0.1 with a port of 2000.
Configure two dual-line phones.
Choose the locale that is appropriate.
The phones should have an extension range that starts with X000.
DIDs should be configured with a value from Table 2.
Set up a voice mail extension of X999 (where X is the pod number).
Verify that the IP Phones register and that calls can be placed between the two IP Phones.
Do not save the changes; reload the router.
Activity Procedure
Step 1
From global configuration mode, enter the command telephony-service setup.
Step 2
When prompted with the choice to set up the DHCP service, choose yes.
Step 3
The IP network of the DHCP pool will be 10.X5.0.0 (where X is the pod number).
Step 4
The IP subnet will be 255.255.255.0 for all pods.
Step 5
The TFTP server will be the Cisco CallManager Express router with an IP address
of 10.X5.0.1 (where X is the pod number).
Step 6
The default router for the pool will also be 10.X5.0.1 (where X is the pod number).
Lab Guide 13
Step 7
Answer yes to the question, Would you like to start setting up the telephony
service?
Step 8
For the source IP address, enter 10.X5.0.1 (where X is the pod number).
Step 9
Accept the default port of 2000 by pressing the Enter key.
Step 10
When asked how many IP Phones to configure, answer 10.
Step 11
When asked whether dual lines are desired, answer yes.
Step 12
Choose the language that is desired on the phone (if in the United States, the default
may be used just press the Enter key).
Step 13
Choose the country for call progress tones (if in the United States, the default may
be used just press the Enter key).
Step 14
Choose the first extension number that is desired (see Table 2). Example: X000 1
(where X is the pod number).
Step 15
When asked if DIDs are used, answer yes.
Step 16
When asked for the full E.164 number, enter the value from Table 2 that is specific
for the pod.
Step 17
When asked if forwarding to voice mail is desired, enter yes.
Step 18
Enter the extension number for voice mail that is in Table 2. Example: X999 1
Step 19
Press the Enter key to accept the default of 18 seconds for Call Forward timeout.
Step 20
When asked if you want to start the configuration setup over, enter NO when asked.
Click YES if any mistakes have been made and start this section of the lab over
again.
Step 21
Watch the console output to see if the phones register. Output similar to the
following should be seen on the terminal window. Mar 2 23:57:09.080:
%IPPHONE-6-REGISTER: ephone-1 :SEP000F2470F92E IP:10.15.0.11
Socket:1 DeviceType:Phone has registered.
Step 22
Place a call between the two IP Phones.
Step 23
From privileged EXEC mode, use the show running-config command and view the
changes made in the configuration, noticing the telephony service section in
particular.
Step 24
Do not save the configuration, so that a manual configuration can be completed in

the next task.
Step 25
Reload the router.
Verify that a call can be placed between the two IP Phones within the pod.
Verify that the configuration reflects the changes.
Task 4 Configuration B (One Cisco 7960 IP Phone and One

Cisco 7970 IP Phone): Automated Phone Setup
In this task, you will use the setup utility to configure the Cisco CallManager Express router
with one Cisco 7960 IP Phone and one Cisco 7970 IP Phone.

In this task, ACME desires to deploy Cisco CallManager Express and the associated IP Phones
in the easiest possible way. Use the setup utility to configure the following:
Set the voice DHCP to a scope of 10.X5.0.0, subnet mask of 255.255.255.0, default
gateway of 10.X5.0.1, and a TFTP server of 10.X5.0.1 (where X is the pod number).
Exclude the first ten addresses within this subnet.
Configure two dual-line phones.
The phones should have an extension range that starts with X000 (where X is the pod
number).
Set up a voice mail extension of X999.
Verify that the IP Phones register and that calls can be placed between the two IP Phones.
Do not save the changes; reload the router.
Activity Procedure
Step 1
From global configuration mode, enter the command telephony-service setup.
Step 2
When prompted with the choice to set up the DHCP service, choose yes.
Step 3
The IP network of the DHCP pool will be 10.X5.0.0 (where X is the pod number).
Step 4
The IP subnet will be 255.255.255.0 for all pods.
Step 5
The TFTP server will be the Cisco CallManager Express router with an IP address
of 10.X5.0.1 (where X is the pod number).
Step 6
The default router for the pool will also be 10.X5.0.1 (where X is the pod number).
Step 7
Answer yes to the question regarding starting the telephony service setup.
Step 8
For the source IP address, enter 10.X5.0.1 (where X is equal to the pod number).
Step 9
Accept the default port of 2000 by pressing the Enter key.
Step 10
When asked how many IP Phones to configure, answer 10.
Step 11
When asked whether dual lines are desired, answer yes.
Step 12
Select the language that is desired on the phone (if in the United States, the default
may be used just press the Enter key).
Lab Guide 15
Step 13
Select the country for call progress tones (if in the United States, the default may be
used just press the Enter key).
Step 14
Select the first extension number that is desired (see Table 2). Example: X000 1
Step 15
When asked if DIDs are used, answer yes.
Step 16
When asked for the full E.164 number, enter the value from Table 2 that is specific
for the pod.
Step 17
When asked if forwarding to voice mail is desired, enter yes.
Step 18
Enter the extension number for voice mail that is in Table 2. Example: X999 1
(where X is equal to the pod number).
Step 19
Press the Enter key to accept the default of eighteen seconds for Call Forward
timeout.
Step 20
When asked if you want to start the configuration over again, enter NO when asked.
Select YES if any mistakes have been made and you wish to start this section of the
lab over again.
Step 21
Watch the console output to see if the phones register. Output similar to the
following should be seen on the terminal window. Mar 2 23:57:09.080:
%IPPHONE-6-REGISTER: ephone-1 :SEP000F2470F92E IP:10.15.0.11
Socket:1 DeviceType:Phone has registered.
Step 22
Notice that the IP Phone 7960 has registered and has dial tone when it goes off hook.
Step 23
From privileged EXEC mode, use the show running-config command and view the
changes made in the configuration, noticing the telephony-service section in
particular.
Step 24
Reload the router, and do not save the configuration, so that a manual configuration
can be completed in the next task.
Verify that a call can be placed between the two IP Phones within the pod.
Verify that the configuration reflects the changes.
Task 5: Manual and Partially Automated Shared Setup
In this task, you will configure the Cisco CallManager Express router and IP Phones using the
manual and partially automated setup.

In this task, ACME desires to deploy Cisco CallManager Express and IP Phones. Use IOS
commands to achieve the following goals:
Configure a voice DHCP scope of 10.X5.0.0, subnet mask of 255.255.255.0, a default
gateway of 10.X5.0.1, and a TFTP server of 10.X5.0.1 (where X is the pod number).
Configure four dual-line phones.
The phones should have an extension range that starts with X000.
Set up a voice mail extension of X999.
Do not plug in the IP Phones yet.
Activity Procedure
Step 1
From a terminal connection to the Cisco CallManager Express router, use the show
running-config | begin tele command to verify that the telephony service has not
been configured. If a configuration exists, use the no telephony-service command to
erase any configuration.
Step 2
Unplug both IP Phones.
Step 3
Set the time and date of the router with the command clock set. This will be relevant
in a later lab and needs to be set accurately to the local time and date.
Step 4
Enter the command ip dhcp exclude-address 10.X5.0.1 10.X5.0.10 (where X is the

pod number).
Step 5
Enter the command ip dhcp pool CMEVoiceX (where X is the pod number).
Step 6
Use the network 10.X5.0.0 255.255.255.0 command to set up the range of addresses
that will be used.
Step 7
Enter the command default-router 10.X5.0.1 (where X is the pod number).
Step 8
Enter the command option 150 ip 10.X5.0.1 to assign the TFTP server.
Step 9
Enter exit to go back to global configuration mode.
Lab Guide 17
Step 10
Enter the show flash command from privileged EXEC mode and note the firmware
files present; for example: P00303020214.bin. Write down the firmware files
present in flash:
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
Step 11
Enter the command configure terminal to enter global configuration mode.
Step 12
Use the command tftp-server flash: P00303020214.bin to allow the firmware files
to be accessed through the TFTP server.
Step 13
If using an IP Phone 7970, enter the following commands to serve up the five files
required by the IP Phones 7970: tftp-server flash:Jar70.2-8-0-104.sbn; tftp-server
flash:TERM70.6-0-2SR1-0-5s.loads; tftp-server
flash:TERM70.DEFAULT.loads; tftp-server flash:cnu70.62-0-1-6.sbn; and tftpserver flash:jvm70.602ES1R6.sbn
Step 14
Enter telephony service mode by entering the command telephony-service from

Step 15
Enter the command max-ephones 2 (this will be sufficient for the classroom lab).
Step 16
Enter the command max-dn 20 (this will be sufficient for the classroom lab).
Step 17
Load the firmware and associate it with the IP Phone 7960 by entering the command
load 7960-7940 P00303020214 (Note: Do not put the firmware file suffix on the
end.)
Step 18
Load the firmware and associate it with the IP Phone 7970 by entering the command
load 7970 TERM70.6-0-2SR1-0-5s (Note: Do not put the firmware file suffix on
the end.)
Step 19
Next use the ip source-address 10.X5.0.1 port 2000 command (where X is the pod
number) to define the address where the Cisco CallManager Express router is
listening for registrations (Skinny messages).
Step 20
Set the time zone to your current location by using the command time-zone.
Step 21
Use the create cnf-files command to build XML configuration files that will be used
by the phones during the bootup process.
Step 22
Set the keepalive interval to ten seconds by entering the command keepalive 10.
Step 23
Use the command show running-config | begin tele to view the results of the
manual configuration.
Step 24
Ensure that no IP Phones are plugged in.
You have completed this task when you verify that you have successfully configured the Cisco
CallManager Express router and phones using the manual and partially automated setup.
Task 6: Manual Phone Setup
In this task, you will manually configure either an IP Phone 7970, if present, or one of two IP
Phones 7960 in the pod.

Manually configure an IP Phone 7970, if present in the pod, or one of the two 7960 IP
Phones, with an extension of X000 (where X is the pod number), and connect the IP Phone
to the network.
Assign a name of John Smith to the IP Phone.
Activity Procedure
Step 1
Verify that the IP Phones are not plugged in.
Step 2
Enter telephony service mode by entering the telephony-service command from

Step 3
Enter exit to return to global configuration mode from telephony-service mode.
Step 4
Add an ephone-dn for the first line appearance on the first phone in the pod by
entering the ephone-dn 1dual-line command.
Step 5
In ephone-dn mode, enter the number X000 command (where X is the pod number).
Step 6
Enter your name that will be associated with this directory number by using the
name firstname lastname command. Either make up a name or use a students name.
(example: name John Smith).
Step 7
Enter the command ephone 1 to enter ephone configuration mode for the first phone
in the pod.
Step 8
The MAC address is on a sticker on the bottom of the phone. In the space provided,
write down the MAC address of the phone:
_________________________________________________________________
Step 9
Now that the MAC address of the phone is known, assign it to the ephone 1 with the
mac-address H.H.H (where H is equal to four hex characters).
Step 10
Assign the ephone-dn to the ephone line with the button 1:1 command.
Step 11
Enter the debug ephone register command.
Step 12
Plug in the configured IP Phones.
Step 13
View the ephone registration debugging output.
Step 14
Verify that the phone has registered and that the proper directory number appears
with the line.
Step 15
Lab Guide 19
Step 16
Enter exit to go back to privileged EXEC mode.
Step 17
Enter undebug all to turn off all debugging.
You have completed this task when you verify that one of the two phones is configured.
Task 7: Partially Automated Setup (IP Phone 7960)
In this task, you will complete the steps required for the Cisco CallManager Express system to
assign an ephone-dn to the ephone.

Configure the second IP Phone through the use of the auto assign command.
Attach the second IP Phone to the network.
Activity Procedure
Step 1
Add a second ephone-dn by using the ephone-dn 2 dual-line command.
Step 2
Use the number X001 command to add a directory number (where X is the pod
number).
Step 3
Enter telephony service mode by entering the telephony-service command from

Step 4
Turn on the ability to auto-assign numbers by entering the command auto assign 2
to 2.
Step 5
Plug in the remaining unplugged IP Phone.
Step 6
Verify that both phones are registered and configured.
Step 7
Place a call from one phone to the other in the pod to verify the configuration.
Step 8
If successful, save your configuration by using the command copy running-config

startup-config.
Verify that both phones are configured and registered.
Verify that calls may be placed between the two phones in the pod.
Lab 2-1 Answer Key: Setting Up Cisco CallManager Express

When you complete this activity, your configuration will be similar to the following, with
differences that are specific to your device or workgroup.
-
- -- -
- -- -
- --
-
-
-- -
-

-

-

-

--
--

-

-

-

-
-
-
-
-
--
-
-
--

--

-
--

-

--

--
Lab Guide 21

-
--- -
- -
- --
- --- --
- --
- -

-

-

---
--

- --

-

--

--

-- -
-

-
-
-

-- -
-
Lab 3-1: Configuring PSTN Interfaces and Dial

Peers
Activity Objective
In this activity, you will configure analog voice interfaces, digital voice interfaces, and dial
peers to set up VoIP communications. After completing this activity, you will be able to meet
these objectives:
Configure the analog ports on the router
Configure POTS dial peers for analog ports
Configure digital ports
Configure digital dial peers for digital ports
Configure VoIP dial peers to other pods
Configure COR
Visual Objective
Visual Objective for Lab 3-1 Tasks 1-5:

Configuring PSTN Interfaces and Dial Peers
VoIP over
WAN
Pod 1
PSTN
Pod 2
Pod 7
Pod 8
Pod 3-6
202-555-9000
...
207-555-9000
201-555-9000208-555-9000
IPTX v2.04
Lab Guide 23
Required Resources
One analog phone with RJ-11 cable
Serial cable for the Frame Relay connection
RJ-11 cable to connect to the PSTN
Worksheets from Lab 2 or completed form from end of the Lab Guide
Command List
Command
Description
Enters voice port mode
Sets call progress tones
Sets the ring on a voice port
Views the voice port configuration
Sets number of rings until the FXO port is answered
Defines a dial peer and enters dial-peer mode
Defines a pattern of digits on a dial peer
Assigns a port to a dial peer
Sets the dial peer to forward all digits to the destination
Goes back one configuration level
Sets the voice port to forward to an extension without any digits

being dialed
- -
Sets the ISDN switch type
Sets the WAN interface card (WIC) to get the clock from the
router
Enters T1 interface
Sets the framing on the T1
Sets the line coding to B8ZS
Sets the clocking to be obtained from the line
--
Sets a PRI group with timeslots 124
- -
Shows the serial interface status
Command
Description
- - --
Shows the ISDN switch type and the status of Layers 1, 2, and 3
-
-
Displays the configuration beginning at the telephony-service

section

-

-
Maps an abbreviated extension number prefix digit pattern to the

full E.164 telephone number pattern
Assigns the dial peer based on the called number
Enables DID on the dial peer
Views the controller
Enters interface configuration mode
Sets the clock speed on a DCE serial interface
--
Sets an IP address and subnet mask on an interface
Enables an interface
---
Sets a VoIP target on a dial peer
Sets the codec for a dial peer
Saves changes to NVRAM
Enters COR mode where name can be defined
Defines a COR name
-
-
Sets a COR list name
Assigns a member to a COR list
-
-
Assigns an inbound COR list to the dial peer or ephone-dn
-
-
Assigns an outbound COR list to the dial peer or ephone-dn
Lab Guide 25
Job Aids
Table 3
Pod
Dial Plan
Extension Numbers
Voice-Mail
Extension
First E.164 DID on PRI

Number for the IP Phones
Pod 1 1000-1099 1999 2015559000 2015550000

Pod 2 2000-2099 2999 2025559000 2025550000
Pod 3 3000-3099 3999 2035559000 2035550000
Pod 4 4000-4099 4999 2045559000 2045550000
Pod 5 5000-5099 5999 2055559000 2055550000
Pod 6 6000-6099 6999 2065559000 2065550000
Pod 7 7000-7099 7999 2075559000 2075550000
Pod 8 8000-8099 8999 2085559000 2085550000
E.164 Number for

FXO Port
Task 1: Configuring FXO and FXS Ports

In this task, you will configure an analog phone connected to an FXS port on the Cisco
CallManager Express router. You will also configure an FXO connection to a PSTN simulator.

In this lab, ACME has configured the IP Phones and now wishes to configure the analog
phones that are on the factory floor as well as the analog connection to the PSTN. Configure
the analog ports with the following settings:
Attach and configure the analog phone on the lowest FXS port with call progress tones for
Australia and a ring pattern of 11.
Attach and configure the analog connection to the PSTN to the lowest FXO port and
configure the port to answer after three rings.
Activity Procedure
Step 1
Plug the analog phone into the lowest-numbered FXS port. Write down the port
number here:
_________________________________________________________________
Step 2
Pick up the handset of the analog phone to verify that you can hear a dial tone.
Step 3
Attempt to dial one of the two IP Phones from the analog phone. Was the call
successful?
Step 4
At the command line on the Cisco CallManager Express router, enter privileged
EXEC mode by entering enable. If asked for a password, use cisco.
Step 5
Go to global configuration mode by using the command configure terminal.
Step 6
From global configuration mode, enter the voice port by using the voice-port fxsport-that-analog-phone-is-plugged-into.
Step 7
From voice-port mode, enter the command cptone AU to set the call progress tones
to Australia.
Step 8
Set the ring cadence with the command ring cadence pattern11.
Step 9
Place a call to an IP Phone and note that the call progress tones have changed.
Step 10
Use the show voice port fxs-port-that-analog-phone-is-plugged-into command and

view the configuration of the voice port.
Verify that you can place a call to an IP Phone from the analog phone.
Verify that the call progress tones have been changed and verified.
Verify that the ring cadence has been changed (although not verified yet).
Verify that the FXO port is configured to answer the call after three rings.
Lab Guide 27
Task 2: Configuring an FXS Port and Dial Peers for the Local
Analog Phone
In this task, you will configure the dial peers that allow connections to the analog phone and
calls to and from the PSTN.

In this lab, ACME has configured the IP Phones and now wishes to configure the analog phone
so that it can be called by the IP Phones. Configure the analog ports with the following settings:
Configure a dial peer 1 with the extension number of X100
Place a call to the analog phone from the IP Phone to verify connectivity.
Activity Procedure
Step 1
Ensure that an analog phone is plugged into the lowest-numbered FXS port on the
router.
Step 2
From global configuration mode, enter dial-peer voice 1 pots.
Step 3
In dial-peer subconfiguration mode, enter the command destination-pattern X100

Step 4
In dial-peer subconfiguration mode, enter the command port FXS-port-that-analogphone-is-plugged-into.
Step 5
Call the analog phone from one of the two IP Phones and verify functionality.
You have completed this task when you attain this result:
Verify that a call can be placed from the IP Phone to the analog phone and vice versa
within the pod.
Task 3: Configuring an FXO Port and PLAR

In this task, you will configure the POTS PRI dial peers.

In this lab, ACME has configured the IP Phones and now wishes to configure the analog
connection to the PSTN. Configure the analog ports as follows:
All incoming calls should be sent to the lowest-numbered IP Phone.
Configure a dial peer 2 to use the analog port to the PSTN when the digits 120.5550... are
dialed.
Activity Procedure
Step 1
Ensure that you can make a connection to the lowest-numbered FXO port on the
router to the PSTN simulator assigned by your instructor.
Step 2
From global configuration mode, use the command voice-port mod/port to enter the
configuration for the FXO port.
Step 3
Enter the ring number 2 command to set the port to answer after two rings.
Step 4
Create an analog dial peer with the command dial-peer voice 2 pots.
Step 5
Use the command destination-pattern 120.5550... to set the digits that will match
this dial peer.
Step 6
Use the command port mod/port to associate the lowest FXO port with this dial
peer.
Step 7
Enter forward-digits all to forward all the digits to the PSTN (because POTS dial
peers consume digits).
Step 8
Step 9
Wait for your partner pod to get to this step before proceeding to the next.
Step 10
From one of your phones, dial 120Y-555-0000 (where Y is the number of your
partner pod). Pods 1 and 2 will be partners, Pods 3 and 4 will be partners, Pods 5 and
6 will be partners, and Pods 7 and 8 will be partners.
Step 11
You will hear a second dial tone after two rings; this is the default dial peer.
Step 12
Dial the extension number of one of the two IP Phones of your partner pod.
Step 13
Why is the default dial peer reached?
Step 14
Will DID work on an analog line?
Step 15
Enter the lowest FXO voice port by using the command voice-port mod/port.
Step 16
In the voice port submode, configure a PLAR to the lowest-numbered IP Phone by

using the command connection plar X000 (where X is the pod number).
Step 17
Step 18
Step 19
From one of your phones, dial 120Y-555-9000 (where Y is the number of your
Step 20
What is the result?
Step 21
Verify that the call completed without a second dial tone.
Lab Guide 29
Verify that a call can be placed across the PSTN to another pod.
Verify that a PLAR connection on the analog line sends the call to the lowest IP Phone in
the partner pod.
Task 4: Configuring PRI Interface and DID

In this task, you will configure the POTS PRI interface.

In this lab, ACME has decided that the analog connection to the PSTN is not sufficient, and
therefore a PRI will be added to give additional capacity and to add DID capability. The analog
connection will be kept for a secondary connection to the PSTN. Configure the PRI with the
following settings:
Set the ISDN switch type to primary-ni.
Set the controller to use the ESF (T1) or CRC4 (E1) framing.
Set the line code to B8ZS (T1) or HDB3 (E1).
Set the clock to be obtained from the line.
Configure a PRI group to use all channels on the PRI.
Configure a dial peer for use when 120.5559... digits are received.
Configure the DIDs to map the following E.164 numbers to the extension numbers of the
IP Phones: 20X5559000 X000 and 20X5559001 X001.
Activity Procedure
Step 1
Locate the lowest-numbered T1 or E1 port on the Cisco CallManager Express router

and write the module and port for the interface here.
__________________________________________________________________
Step 2
From global configuration mode, use the command isdn switch-type primary-ni to
set the PRI switch type (if instructed use a different switch type).
Step 3
Enter the command network-clock-participate wic slot (physical slot where T1 or

E1 WIC is installed).
Step 4
From global configuration mode, enter controller T1 module/port for the lowest T1
interface(if using E1 equipment, use E1 instead of T1).
Step 5
In T1 controller mode, enter the command framing esf (use framing crc4 if
configuring an E1) to set the framing used.
Step 6
In T1 controller mode, enter the command linecode b8zs (use linecode hdb3 if
configuring an E1)to set the line code.
Step 7
Set the clock to the line with the clock source line command.
Step 8
Use the command pri-group timeslots 1-24 (use pri-group timeslots 1-30 if
configuring an E1) to assign all the channels to the PRI.
Step 9
The B channels should go up and you should see messages to that effect on the
console.
Step 10
Step 11
Use the show interface serial mod/port:23 command to verify that the interface is
up and up.
Step 12
Use the command show isdn status and verify that Layer 1 is ACTIVE and that
Layer 2 shows MULTIPLE_FRAME_ESTABLISHED.
Step 13
Step 14
Using your analog phone, dial 120Y-555-9000 (where Y is the number of your
Step 15
What is the result? Why?
Step 16
Make a dial peer by entering dial-peer voice 3 pots from global configuration
mode.
Step 17
From within dial-peer submode, enter the command destination-pattern

120.5559 to define the destination.
Step 18
From within dial-peer submode, enter the command forward-digits all.
Step 19
From within dial-peer submode, enter the command port mod/port:23 to specify the
physical interface that will be assigned to the dial peer.
Step 20
Step 21
Step 22
Using your analog phone, dial 120Y-555-9000 (where Y is the number of your
Step 23
What is the result? Why?
Step 24
When a second dial tone is heard, dial the extension Y000 (where Y is the number of
your partner pod).
Step 25
Verify that the call succeeds. Why did DID fail?
Step 26
Use the command show run | begin telephony-service.
Step 27
From telephony service mode, enter the command dialplan-pattern 1 20X5559

extension-length 4 extension-pattern X (where X is the pod number).
Step 28
You will need a second dial peer in order to configure DID.
Step 29
Use the command dial-peer voice 4 pots to create and enter dial-peer configuration
mode.
Step 30
Enter the command incoming called-number 20X5559 to set the pattern that will
match the incoming call to this dial peer.
Lab Guide 31
Step 31
Enter the command port mod/port:23 to assign the dial peer to the PRI.
Step 32
Use the command direct-inward-dial to enable DID for this port.
Step 33
Step 34
Step 35
Using a phone, dial 120Y-555-9000 (where Y is the number of your partner pod).
Pods 1 and 2 will be partners, Pods 3 and 4 will be partners, Pods 5 and 6 will be
partners, and Pods 7 and 8 will be partners.
Step 36
What is the result?
Step 37
Verify that the DID for both IP Phones in your partner pod works.
Verify that calls across the PSTN using the PRI connection work.
Verify that DID works for the two IP Phones.
Task 5: Configuring VoIP Dial Peers Across a WAN Link

In this task, you will configure the VoIP dial peers.

In this lab, ACME has added another site with its own Cisco CallManager Express. A WAN
connection to the other site will need to be configured and tested. Configure the VoIP dial peers
as follows:
Configure and attach a serial connection to the lowest-numbered serial interface that is
configured with a speed of 115,200 bps and an IP address of 10.100.0.X /24 (where X is the
pod number).
In this lab, Pod 1 and Pod 3 will partner, Pod 2 and Pod 4 will partner, Pod 5 and Pod 7 will
partner, and Pod 6 and Pod 8 will partner.
Configure a dial peer to your partner pod that uses the G.711 codec.
Test two calls to your partner with G.711 configured on the serial interface.
Configure the dial peer to your partner pod to use the G.729 codec.
Test two calls to your partner with G.729 configured on the serial interface.
Save your changes.
Activity Procedure
Step 1
In this lab, Pod 1 and Pod 3 will partner, Pod 2 and Pod 4 will partner, Pod 5 and
Pod 7 will partner, and Pod 6 and Pod 8 will partner.
Step 2
Ensure that a serial cable is connected to the lowest serial interface on your router
terminating on the lowest serial interface on the router of your partner pod.
Step 3
Use the show controller serial mod/port for the lowest serial interface and notice if
the cable is a DCE or DTE.
Step 4
Go to the interface with the interface serial mod/port command.
Step 5
If your pod has the DCE end of the cable, use the command clock rate 115200 to set
the clock rate of the lowest serial interface.
Step 6
Leave the encapsulation at the default of HDLC unless instructed otherwise by your
instructor.
Step 7
Set an IP address on the interface by using the ip address 10.10Z.0.X 255.255.255.0

command(where Z is the lowest pod number of both partners and X is your pod
number).
Step 8
Use the command no shutdown to enable the serial interface.
Step 9
Step 10
Enter exit to return to privileged EXEC mode.
Step 11
Wait for your assigned partner pod to complete the previous steps.
Step 12
Verify connectivity by using ping to test. Enter ping 10.100.0.X (where X is the pod
number).
Step 13
Attempt to dial the four-digit extension number of one of the phones in your
partners pod.
Step 14
What was the result? Why?
Step 15
Step 16
Make a new dial peer with the command dial-peer voice 5 voip.
Step 17
To associate a pattern with the dial peer, use the destination-pattern Y... (where Y is
the number of your partner pod). For example, Pod 1s partner for this task is Pod 3,
so Y would be equal to 3 and you would enter destination pattern 3...
Step 18
Instead of a port command, use the command session target ipv4:10.10Z.0.Y (where
Z is the lowest pod number of the two pods and Y is the number of your partners
pod).
Step 19
Hardcode the codec that is to be used by entering the command codec g711ulaw.
Step 20
Step 21
Dial a four-digit extension number of one of the phones in your partner s pod and
stay connected.
Lab Guide 33
Step 22
Was the result different from before?
Step 23
Verify that the quality of the voice is acceptable.
Step 24
Coordinating with your partner pod, place a second simultaneous call between the
pods using a four-digit extension. This will force two calls on the WAN link.
Step 25
How is the voice quality? Remain connected.
Step 26
Verify that the codec is G.711 by quickly clicking the blue i or the question mark
button (depending on the model of phone) on the IP Phones twice while the calls are
connected.
Step 27
Hang up both calls.
Step 28
Enter global configuration mode by entering configure terminal.
Step 29
Make a new dial peer with the command dial-peer voice 5 voip.
Step 30
Hardcode the codec that is to be used by entering the command codecg729br8 .
Step 31
Step 32
Coordinate with your partner to place two simultaneous calls across the WAN link
by dialing the four-digit extensions.
Step 33
How is the voice quality? Remain connected.
Step 34
Verify that the codec is G.729 by quickly clicking the blue i or the question mark
button (depending on the model of phone) on the IP Phones twice while the calls are
connected.
Step 35
Save the configuration by using the command copy running-config startup-config.
Verify that you can place calls to your partner across the WAN by dialing a four-digit
extension.
Verify that the quality of the second call across the WAN link at the same time when using
G.711 is poor due to lack of bandwidth.
Verify that the codec is set to G.729 and you can place two calls across the WAN link
simultaneously.
Task 6: Configuring Class of Restriction

In this task, you will configure the class of restriction. One of the two IP Phones will be able to
call only over the VoIP WAN, the other IP Phone will be unrestricted, and the analog phone
will be able to call the PSTN through the analog connection as well as over the WAN link.
Visual Objective
Visual Objective for Lab 3-1 Task 6:

Configuring PSTN Interfaces and Dial Peers
Ephone-dn 1 can call only
over the WAN link, not to the
analog or digital PSTN
connection.
Ephone-dn 2 can call to any
destination to which the
router can set up a call.
VoIP over
WAN
PSTN
The analog phone can call the

WAN or the analog PSTN
connection.
IPTX v2.05

In this lab, ACME wishes to implement class of service (CoS) to restrict access to where
certain IP Phones can call. Configure the IP Phones as follows:
Configure the lowest-numbered IP Phone to be able to call over the WAN but not over the
PSTN.
Configure the highest-numbered IP Phone to be able to call to any destination that the
router can call.
The analog phone should be able to call across the WAN or the analog PSTN; the digital
PSTN should not be available to the analog phone.
Lab Guide 35
Activity Procedure
Step 1
In this lab, do not save your changes.
Step 2
From global configuration mode, enter the command dial-peer cor custom to enter
the COR mode.
Step 3
Enter the first name by entering the command name Analog.
Step 4
Enter the second name by entering the command name PRI.
Step 5
Enter the final name by entering the command name WAN.
Step 6
Enter exit to go to global configuration mode.
Step 7
Define a COR list by entering the command dial-peer cor list callAnalog.
Step 8
Put a member in the COR list with the command member Analog.
Step 9
Step 10
Define a COR list by entering the command dial-peer cor list callPRI.
Step 11
Put a member in the COR list with the command member PRI.
Step 12
Step 13
Define a COR list by entering the command dial-peer cor list callWAN.
Step 14
Put a member in the COR list with the command member WAN.
Step 15
Step 16
Define a COR list by entering the command dial-peer cor list Type1.
Step 17
Put a member in the COR list with the command member WAN.
Step 18
Step 19
Define a COR list by entering the command dial-peer cor list Type2.
Step 20
Put the first of two members in the COR list with the command member WAN.
Step 21
Put the second of two members in the COR list with the command member Analog.
Step 22
Step 23
Enter dial-peer voice 2 pots to enter dial-peer configuration mode.
Step 24
Assign an outbound COR list to the dial peer with the command corlist outgoing
callAnalog.
Step 25
Step 26
Enter dial-peer voice 3 pots to enter dial-peer configuration mode.
Step 27
callPRI.
Step 28
Step 29
Enter dial-peer voice 5 voip to enter dial-peer configuration mode.
Step 30
callWAN.
Step 31
Step 32
Enter ephone-dn mode by entering the command ephone-dn 1.
Step 33
In ephone-dn mode, enter the command cor incoming Type1.
Step 34
Step 35
Enter dial-peer voice 1 pots to enter dial peer configuration mode.
Step 36
Assign an outbound COR list to the dial peer with the command cor incoming
Type2.
Step 37
Test the COR settings by attempting to dial a partner pod over the WAN, over the
analog connection to the PSTN, and over the PRI connection to the PSTN. Test on
all three phones.
Step 38
When the test is successful, reload the router, making sure you do not save the
configuration.
Verify that the ephone-dn 1 can call the partner pod over the WAN link but is not able to
call over the PSTN by either the analog or PRI connection.
Verify that the ephone-dn 2 can call over the WAN, analog, and PRI to another pod.
Verify that the analog phone can call another pod over the WAN or an analog connection
but not over the PRI.
Lab Guide 37
Lab 3-1 Answer Key: Configuring PSTN Interfaces and Dial

Peers
-
- -- -
- -- -
- --
-
-
-- -
-

-

-

-

--
--

-
- -

-
--

-

-
-
-
-
-
--
-
-
--

--

-
--

-

--


-- -
-

--

-
--- -
- -
- --
- --
- --
- -- --

-

-

-

-

-

-

-
-

-
-

-

-

-

-
---
Lab Guide 39

-

-

---
--

- --
- -

-

--

--

-- -
-

-
-
-

-- -
-
Lab 4-1: Configuring Additional Cisco

Activity Objective
In this activity, you will configure additional Cisco CallManager Express system features. After
completing this activity, you will be able to meet these objectives:
Configure and use the GUI system administrator interface
Configure and use the GUI customer administrator interface
Configure and use the GUI phone user
Configure call transfer and call forward
Customize softkey layout
Configure Ephone hunt groups
Configure the B-ACD Service
Configure the IP Phone display
Configure an intercom
Configure paging groups
Configure and use the Acct softkey button
Visual Objective
Visual Objective for Lab 4-1: Configuring

Additional Cisco CallManager Express Features
PodX
Web Browser
Use to test
paging groups
X100
Sales Paging
Group
Emergency
Paging Group
Support
Paging Group
X000X001
Intercom between X000 and X001
IPTX v2.06
Lab Guide 41
Required Resources
A properly configured Cisco CallManager Express router
Two IP Phones
One analog phone
Student PC with Windows and IE 5.5 or greater
Command List
Command
Description

- -
Extracts the contents of a tar to the destination specified
Enables the HTTP server
Sets the HTTP server to use flash as the root directory
Sets the HTTP authentication method
Enters telephony service mode
--
- --
-
Sets the credentials for the system administrator
Enables configuration of directory numbers through the web

interface
Allows setting of the Cisco CallManager Express router from the

web interface
-
- --
-
Sets a username and password for the customer administrator
- -
Shows the contents of flash
10.X0.0.2
Starts an FTP session to an FTP server
Loads a customized XML file
-
-
Copies a file from source to destination
-
-
Shows the current configuration that is loaded and running in

RAM on the router. If the begin option is used, it shows the
configuration beginning at the string value
- -
-- --
Sets a username and password on an IP Phone that can be used

to log in to the phone user web page
---
-
Transfers calls using H.450.2 with consultation using a second

phone line, if available.
Command
Description
Restrict the number of digits that can be entered using the

CfwdAll soft key on an IP phone
Declares and names an ephone template to configure IP phone

soft-key display and to enter ephone-template configuration mode
-
-
-
Configures an ephone template for soft-key display during the

connected call stage
--

Configures an ephone template for soft-key display during the

idle call stage
Creates and configures a hunt group for use in a

Cisco CallManager Express system,
Defines the ephone-dn that callers dial to reach a

Cisco CallManager Express ephone hunt group
Creates a list of extensions that are members of a

Cisco CallManager Express ephone hunt group
Defines the number of seconds after which a call that is not

answered is redirected to the next number in a
Cisco CallManager Express ephone-hunt-group list
Defines a name for a voice application and specifies the location

of the Tool Command Language (Tcl) or VoiceXML document to
load for this application
Assigns a pilot number to the Cisco CallManager Express basic

automatic call distribution service
Selects a session-level application
Specifies a digit string that can be matched by an incoming call to

associate the call with a dial peer
Associates a dial peer with a specific voice port
Creates a loopback interface.
Forwards DTMF tones by using the H.245 signal User Input

Indication method.
-
--
Creates a floating extension (ephone-dn) at which calls can be

temporarily held (parked).
Creates a text identifier instead of a phone-number display for an

extension on an IP phone console
- -
Sets the IP Phone header bar
-- --
Sets a system text message that appears on the phone screens

in Cisco CallManager Express
Assigns a directory number to an ephone-dn
Sets a paging group that contains one or more paging ephonedns
Lab Guide 43
Command
Description
Views the active calls
- -
Views the previous calls
Job Aids
Table 4
Pod
Ephone
Extensi
on
First Name
1 1 1000 Ford Prefect FPrefect

1 2 1001 Arthur Dent ADent
2 1 2000 Douglas Adams DAdams
2 2 2001 Random Dent RDent
3 1 3000 Hig Hurtenflurst HHurtenflurst
3 2 3001 Humma Kavula HKavula
4 1 4000 Cynthia Fitzmelton CFitzmelton
4 2 4001 Oolon Colluphid OColluphid
5 1 5000 Rob McKenna RMckenna
5 2 5001 Yooden Vranx YVranx
6 1 6000 Zaphod Beetlebrox ZBeetlebrox
6 2 6001 Marvin Prosser MProsser
7 1 7000 Hurling Frootmig HFrootmig
7 2 7001 Max Quordlepleen MQuordlepleen
8 1 8000 Questular Rontok QRontok
8 2 8001 Frank Prak FPrak
Last Name
Username
Task 1: Configuring and Using the GUI Interface for the System
Administrator
In this task, the system administrator will be defined and the GUI web pages made available.

In this lab, ACME wishes to use the GUI web interface instead of the CLI for additions, moves,
and changes. Currently the GUI is not installed or configured. Configure and use the GUI to do
some administrative tasks, as follows:
Enable the GUI interface on the Cisco CallManager Express router using files located on
the classroom FTP server.
Use an IOS command to create the CallManager Express administrative credentials with a
username IPTX and a password cisco.
Use the GUI to create an ephone-dn and assign it to one of the two IP Phones.
Use the GUI to add a speed dial to one of the two IP Phones.
Use the GUI to change the date and time format on the IP Phones.
Use the GUI to change the system time.
Activity Procedure
Step 1
Enter the command archive tar /xtract ftp://IP_address/cme-gui-123-11XL.tar

flash: to extract the GUI files.
Step 2
Enter the command ip http server to enable the web server on the Cisco
Step 3
Enter the command ip http path flash: to define the location of the HTML files.
Step 4
Go to http://10.X0.0.1/ccme.html (where X is the pod number) and verify that a

blank username and the routers enable password (cisco) works. This authentication
is not advised in production and should be disabled by setting a web administrative
username and password.
Step 5
Enter ip http authentication local to ensure that credentials will be defined locally
on the router.
Step 6
Go to telephony service mode by using the command telephony-service.
Step 7
From telephony service mode, enter the command web admin system name IPTX
password cisco.
Step 8
Enter the command dn-webedit to allow changes to the directory number through
the web interface.
Step 9
Enter the command time-webedit to allow the Cisco CallManager Express time to
be set from the web interface.
Step 10
Step 11
Enter exit to go back to privileged EXEC mode.
Lab Guide 45
Step 12
Enter the command copy running-config startup-config.
Step 13
Open the web browser on the student PC and enter http://10.X0.0.1/ccme.html

(where X is the pod number). Use a blank username and the enable password (cisco)
to attempt to log in. This should fail.
Step 14
When asked for credentials, use IPTX for the username and cisco for the password.
Step 15
From the Configure drop-down menu, choose Extensions and view the currently
configured extensions.
Step 16
Add a new extension with an extension number of X002 (where X is the pod
number) and leave the other setting at default.
Step 17
Save the changes.
Step 18
From the Configure drop-down menu, choose Phones and view the currently
configured phones.
Step 19
Click the 2 link of one of the 7960 phones and add the extension that you just
defined to the second button of the phone.
Step 20
Add a speed dial number to the first speed dial field that is empty on the IP Phone
7960 (further down in the web page).
Step 21
Save the changes.
Step 22
From the Configure drop-down menu, choose System Parameters.
Step 23
From the System Parameters page, notice the different selections that are available.
Step 24
Notice the settings that may be changed and configured from this page.
Step 25
Use the Date and Time Format object to change the format displayed on the phone
to a nondefault format.
Step 26
Reset the two IP Phones by choosing the Configure >Phones menu. Use the Reset
All link to reset the phones.
Step 27
View the changes on the IP Phones.
Step 28
Under the Directory Service object, choose Name Schema and notice the two
choices.
Step 29
Remain on this page for the next task.
Verify that you can successfully access the GUI as the system administrator.
Verify that you can successfully add an extension and assign it to one of the IP Phones.
Verify that you can successfully change the time of the Cisco CallManager Express router
from the GUI.
Verify that you can successfully change the format of the date and time.
Task 2: Configuring and Using the GUI Interface for the

Customer Administrator
In this task, you will configure and use the GUI interface for the customer administrator.

In this lab, ACME wants an administrator assistant, or customer administrator, to have the
ability to perform a subset of the tasks that the system administrator can perform in the GUI
web interface. Configure the customer administrator in Cisco CallManager Express as follows:
Create the customer administrator credentials using the GUI or CLI. Use a username
IPTXCust and a password cisco.
Create credentials of IPTX with a password cisco.
Install the file newTemplate.xml,located on the classroom FTP server, into the flash of the
router.
Configure the system to use the new XML file and test that the access is restrictive to much
more than the system administrator.
Activity Procedure
Step 1
As the system administrator, go to the Administrators Login Account from the

System Parameters page.
Step 2
Change the Admin User Type to Customer and change the Admin User Name from
Customer to IPTXCust (remember that usernames are case sensitive).
Step 3
Set the password to cisco in both password fields.
Step 4
Click the Change button and click OK when a popup window appears.
Step 5
Close the browser window and go to the CLI of the Cisco CallManager Express
router.
Step 6
Enter enable and when asked for a password, use cisco.
Step 7
Use the show running-config | begin telephony-service command to view the

changes to the configuration.
Step 8
Notice the web admin customer name IPTXCust password cisco line.
Step 9
Minimize the terminal window.
Step 10
Go back to the GUI web page by using the URL http://10.X0.0.1/ccme.html (where
X is the pod number).
Step 11
When asked for credentials, use IPTXCust for the username and cisco for the
password.
Step 12
Notice that the level of access is exactly the same as the system administrator.
Step 13
Close the browser by clicking Logout in the upper right corner.
Step 14
Restore the terminal window to go back to the CLI.
Lab Guide 47
Step 15
Use the show flash command to view the contents of flash.
Step 16
Notice a file called xml.template.
Step 17
Go back to the student PC and start a command prompt by clicking the Start button
and choosing Run.In the Open line of the Run dialog, enter cmd, and then Enter. A
command prompt should appear. From the command line, enter cd c:\, which will
change the location to the root of the C drive. Open an FTP session to the classroom
router or a location specified by your instructor. The classroom server can be
reached by entering ftp IP_address. When asked for credentials, use the username
IPTX and the password cisco.
Step 18
Use the get xml.template command to download the file from the Cisco
CallManager Express router to the student PC.
Step 19
Enter the get newTemplate.xml command to download a modified xml.template

file.
Step 20
Using a text editor, open the xml.template file on the root of the C drive of the
student PC.
Step 21
Using another instance of a text editor, open the newTemplate.xml file found on the
root of the C drive.
Step 22
Compare the two files side-by-side.
Step 23
Go back to the terminal window and enter the copy tftp:// IP_address
/newTemplate.xml flash: command. Do not erase the contents of flash! This will
put a copy of the modified template on the local Cisco CallManager Express router.
Step 24
Enter the show flash command to verify that the newTemplate.xml file is present.
Step 25
Enter global configuration mode by entering the configure terminal command.
Step 26
Enter telephony-service mode by entering the telephony-service command from

Step 27
In telephony-service mode, enter the command web customize load

newTemplate.xml.
Step 28
Start the web browser on the student PC and go to http://10.X0.0.1/ccme.html

Step 29
When prompted to log in, use the username IPTXCust and password cisco.
Step 30
Notice that the level of access is very restrictive.
Step 31
Log out of the GUI web pages.
Verify that the ability to log in as the customer administrator is enabled.
Verify that the customer administrator has restricted access to the GUI web interface.
Task 3: Configuring and Using the GUI Interface for the Phone
User
In this task, you will configure an IP Phone user set of credentials.

In this lab, ACME needs to configure user credentials so that the users can make some settings
of their assigned phones through the GUI web interface. Configure two users as listed below
and test the levels of access:
Configure the assigned username from Table 4 and a password of cisco for the IP Phone
with a sequence number of 1 from the GUI.
Configure the assigned username from Table 4 and a password of cisco for the IP Phone
with a sequence number of 2 from the CLI.
Open the GUI and log in as one of the users just configured.
Activity Procedure
Step 1
Use the URL http://10.X0.0.1/ccme.html (where X is the pod number) to go to the

GUI web interface.
Step 2
When prompted to log in, enter the username IPTX and password cisco. These are
the system administrator credentials.
Step 3
Use the Configure drop-down menu and choose Phones.
Step 4
Click the link for IP Phone 1 and add the assigned username from Table 4 and the
password cisco to the Login Account area.
Step 5
Click the Change button to commit the new username and password.
Step 6
Save the changes by choosing the Administration >Save Router Config menu.
Step 7
Log out of the GUI web interface.
Step 8
Go to a terminal window to access the CLI of the Cisco CallManager Express router.
Step 9
Enter the command show running-config | begin ephone to view the changes made
through the GUI web interface.
Step 10
Notice under the ephone that the line username username password cisco has
changed.
Step 11
Go to global configuration mode by entering the configure terminal command.
Step 12
From global configuration mode, enter the command ephone 2 to enter ephone
configuration mode.
Step 13
Enter the command username username password cisco to configure a phone user
for the second phone (the assigned username is in Table 4).
Step 14
Enter the exit command to go back to global configuration mode.
Step 15
Enter the exit command to go back to privileged EXEC mode.
Lab Guide 49
Step 16
Enter the command copy running-config startup-config to save the changes.
Step 17
Open a web browser and go to http://10.X0.0.1/ccme.html (where X is the pod

number). When asked for credentials, authenticate with the assigned username and a
password cisco.
Step 18
Notice that the interface is has fewer options than when logged in as the
administrator.
Verify that you can successfully log into the GUI as a phone user.
Verify that both phones have a phone user associated with them.
Task 4: Configuring Call Transfer and Call Forward

In this task, you will transfer a call, and then set up call forwarding.

In this lab, ACME currently has the system default of blind transfers and wishes to change to
consultative transfers system-wide. Configure Cisco CallManager Express to use consultative
transfers. However, the ability to forward calls should be restricted the user should not be
able to forward calls from the IP Phones. Configure Cisco CallManager Express as follows:
Configure consultative transfer.
Use the IP Phone to configure call forwarding to all the other IP Phones.
Use IOS commands to restrict the ability to forward calls from the IP Phones.
Activity Procedure
Step 1
Place a call from the analog phone to one of the IP Phones.
Step 2
Using the Trnfer softkey button (this is one of the buttons along the bottom of the
screen on the IP phone), enter the extension of the other IP Phone.
Step 3
Notice that the transfer is blind.
Step 4
Open a console connection to the Cisco CallManager Express system.
Step 5
Enter enable to enter privileged EXEC mode.
Step 6
Enter configure terminal to enter global configuration mode.
Step 7
Enter telephony-service to enter telephony-service mode.
Step 8
Use the command transfer-system full-consult to enable consultative transfers.
Step 9
Step 10
Place a call from the analog phone to one of the IP Phones.
Step 11
Use the Trnfer softkey button and enter the extension of the other IP Phone.
Step 12
Notice that the call is not automatically transferred. In fact, the caller (analog phone)
is on hold.
Step 13
Answer the transfer target IP Phone and from the IP Phone that initiated the transfer,
press the Trnfer softkey button a second time to complete the transfer.
Step 14
From one of the IP Phones in the pod, press the CFwdAll softkey button, and then
enter the number of the other IP Phone followed by the pound ( #) key. This is to
forward all calls to the other IP Phone.
Step 15
From the analog phone, call the number of the first IP Phone. The call should be
forwarded.
Step 16
Press the CFwdAll softkey button to disable call forwarding.
Step 17
From the terminal window, enter ephone-dn 1 to enter ephone-dn mode.
Step 18
Enter the command call-forward max-length 0 to disable call forwarding from the
IP Phone.
Step 19
From the IP Phone with ephone-dn 1 assigned to it, press the CFwdAll softkey
button. Is the behavior the same as it was before? Notice that call forwarding can no
longer be set in this way.
Step 20
Log on to the GUI web interface as a phone user and configure call forward all, call
forward busy, and call forward no answer. Notice that the user can still configure
forward settings from the GUI even though the call-forward max-length 0 is set.
Step 21
Use the analog phone to verify functionality of the call forwards.
Verify that a call can be transferred.
Verify that call forward all, call forward busy, and call forward no answer have been
successfully configured.
Task 5: Customizing Softkey Layout

In this task, you will customize the layout of the softkeys on the IP Phone.

In this lab, ACME has some users that should not be able to start conferences. There is another
set of users that use the DND softkey frequently and wish to have it moved to be present on the
first screen of the IP Phone without having to press the more button. Complete these tasks:
Configure a Cisco 7960 IP Phone so that no conferencing softkey button is present on the
IP Phone when a call is active.
Configure the Cisco 7970 IP Phone if present or the other Cisco 7960 IP Phone if present
so that the DND softkey appears on the first page of softkey buttons.
Lab Guide 51
Activity Procedure
Step 1
Place a call between the two IP Phones and, when the call is connected, view the
softkeys that are present and their order. Write down the order here:
____________________________________________________________________
Step 2
From global configuration mode, use the command ephone-template 1 to define

and create an ephone template.
Step 3
In ephone template mode, use the command softkey connected Acct Endcall Flash
Hold Trnsfer to exclude the Confrn softkey.
Step 4
Step 5
Enter the ephone configuration mode by using the command ephone 2 (This should
be a Cisco 7960 IP Phone).
Step 6
From ephone configuration mode, use the command ephone-template 1 to apply the
template to the ephone.
Step 7
Reset the phone by either pressing **#** on the keypad or typing reset from ephone
configuration mode.
Step 8
Step 9
Once the IP Phone has reset, place a call and note the order, and the lack of a Confrn
softkey.
Step 10
With the second IP Phone on hook, notice the softkeys present and their order.
Document the order here:
____________________________________________________________________
Step 11
Create a second ephone template by typing the command ephone-template 2.
Step 12
In ephone template mode, enter the command softkey idle Dnd Redial Newcall
Pickup Gpickup Login to change the order of the softkeys.
Step 13
Step 14
Enter the ephone configuration mode by using the command ephone 1 (This should
be a Cisco 7970 IP Phone if present, or a 7960 IP Phone if no 7970 is being used).
Step 15
From ephone configuration mode, use the command ephone-template 2 to apply the
template to the ephone.
Step 16
Reset the phone by either pressing **#** on the keypad or typing reset from ephone
mode.
Step 17
Step 18
Notice the order of the softkeys when the IP Phone is finished resetting.
Step 19
Save your changes by using the command copy run start.
Verify that the softkey template is applied to the ephone.
Verify that the order of the softkeys has been changed.
Task 6: Configuring Ephone Hunt Groups

In this task, you will configure an ephone hunt group using the two IP Phones and four lines.

In this lab, ACME has a group of users that need to answer calls that are incoming to the
company. Configure the various types of ephone hunt groups and test their behaviors to
determine which configuration is best for the ACME Company. Complete these tasks:
Configure a third line on the first IP Phone of X010 (where X is the pod number).
Configure a second line on the second IP Phone of X011.
Configure a sequential ephone hunt group that hunts in X000, X010, X001, and X011 with a
pilot of X200 and a timeout of five seconds.
Configure a longest idle ephone hunt group with a pilot of X201 and a timeout of five
seconds.
Configure a peer ephone hunt group with a pilot of X202 and a timeout of five seconds.
Configure the previously configured sequential ephone hunt group to automatically log out
any lines that do not answer a call sent to them by the hunt group.
Activity Procedure
Step 1
Configure a new ephone DN with the command ephone-dn 4 from global

configuration mode.
Step 2
Assign the new DN a number of X010 (where X is the pod number).
Step 3
Go to the first ephone with the command ephone 1 command.
Step 4
Assign the ephone-dn to button 2 of the ephone with the command button 1:1 2:3
3:4.
Step 5
Step 6
Configure a new ephone DN with the command ephone-dn 5 from global

configuration mode.
Step 7
Assign the new DN a number of X011 (where X is the pod number).
Step 8
Assign the ephone-dn to button 2 of the ephone with the command button 1:2 2:5.
Step 9
Now create a sequential hunt group with the command ephone-hunt 1 sequential.
Step 10
In ephone hunt configuration mode, enter a pilot of X200 with the command pilot
X200 (where X is the pod number).
Lab Guide 53
Step 11
Create the order of the sequential hunt group by using the list X000, X002, X010,
X001, X011 command.
Step 12
Set the amount of time the call will ring on each line before redirecting to the next
number in the list to five seconds by using the command timeout 5.
Step 13
Step 14
From the analog phone in your pod, call the pilot number of X200 and answer the
call immediately on the first line that rings. Which line rang? _____________
Step 15
Step 16
From the analog phone in your pod, call the pilot number of X200 and do not answer
the call immediately on the first line that rings. What order do the lines ring in?
___________________________________________________________________
Step 17
Now create a longest idle hunt group with the command ephone-hunt 2 longestidle.
Step 18
Step 19
Create the order of the sequential hunt group by using the list X000, X001, X010,
X011 command.
Step 20
Set the time the call will ring on each line before redirecting to the next number in
the list to five seconds by using the command timeout 5.
Step 21
Step 22
Step 23
Step 24
Step 25
Step 26
On one of the two IP Phones, use the DND softkey to put the IP Phone in the DND
state.
Step 27
call immediately on the first line that alerted. Which line rang? _____________
Step 28
Step 29
Step 30
From the analog phone in your pod call the pilot number of X201 and answer the
Step 31
Remove the DND state from the phone by pressing the DND softkey.
Step 32
Now create a sequential hunt group with the command ephone-hunt 3 peer.
Step 33
Step 34
Create the order of the peer hunt group by using the list X000, X002, X010, X001,
X011 command.
Step 35
Set the time the call will ring on each line before redirecting to the next number in
the list to five seconds by using the command timeout 5.
Step 36
Step 37
Step 38
Step 39
Step 40
Step 41
Return to the first configured hunt group by using the command ephone-hunt 1
sequential.
Step 42
Turn on automatic logout by using the command auto logout.
Step 43
the call until X001 is ringing.
Step 44
the call. What is the order that is used by the hunt group?
__________________________________________________________________
Step 45
Notice that ephone 1 is in the DND state. Remove the DND and call the pilot
number of X200 again.
Verify that ephone hunt groups function.
Verify the auto logout functions.
Lab Guide 55
Task 7: Configuring the B-ACD Service

In this task, you will configure the B-ACD (basic automatic call distribution) service to provide
automated attendant and call queuing functions.

In this lab, ACME desires to extend the functionality of their hunt groups to include call
queuing. ACME also wishes all callers from the outside to be greeted by an automated
attendant which will allow the caller to self-direct the call. The audio files have already been
recorded and included in the .tar file. Complete these tasks:
Configure the B-ACD service to present option 1 as dial by extension.
Configure the B-ACD service to present option 2 as widgets and use ephone hunt group 1.
Configure the B-ACD service to present option 3 as gadgets resources and use ephone hunt
group 2.
Configure the B-ACD service to present option 4 as roadrunner hunting gear and use
ephone hunt group 3.
Configure the B-ACD service to present option 0 as the operator.
Set the AA Retry timer to 15 seconds.
Set the automated attendant time between the second greeting messages to 120 seconds.
Set the automated attendant maximum time in queue to 600 seconds.
Define the automated attendant operator as one of your lines.
Set the automated attendant voice mail as X900 (where X is the pod number).
Set the automated attendant language to English and use flash as the storage location.
Set the queue length to ten callers.
Enable debugging of the script.
Create the required dial peers and associate the application to the dial peer.
Test what happens when no agents are available and when all agents are in the DND state.
Activity Procedure
Step 1
From privileged EXEC mode, use the command archive tar /xtract
ftp://ftp_ip_address/cme-b-acd-IPTXcustomprompts.tar flash: to extract the two
TCL scripts and the seven audio files to flash on the CallManager Express router.
Step 2
Use the command show flash to verify that all nine files are present in flash.
Step 3
Load the automated attendant TCL script from global configuration mode by using
the command call application voice aa flash:app-b-acd-aa-2.0.0.0.tcl . A read
succeeded message should be sent to the console.
Step 4
Set the pilot number of the automated attendant application to X300 by using the call
application voice aa aa-pilot X300 command (where X is the pod number).
Step 5
Set the call retry setting to try and connect the caller every 15 seconds with the call
application voice aa call-retry-timer 15 command.
Step 6
Set the time before the caller hears the second greeting to 30 seconds with the call
application voice aa second-greeting-time 30 command.
Step 7
Set the maximum time in queue to 60 seconds with the command call application
voice aa max-time-call-retry 60.
Step 8
Set the maximum number of times that transferring to voice mail may be attempted
to two with the command call application voice aa max-time-vm-retry 2.
Step 9
Associate the name of the call queuing application with the automated attendant
using the command call application voice aa service-name queue.
Step 10
Set the zero out to operator function by using the call application voice aa operator
X100 command (where X is the pod number).
Step 11
Define which option will be used to dial an extension with the call application
voice aa dial-by-extension-option 1 command.
Step 12
Set the voice mail extension with the command call application voice aa voicemail X900.
Step 13
Set the number of hunt groups to three with the command call application voice aa
number-of-hunt-grps 3.
Step 14
Assign the language with the command call application voice aa language 1 en.
Step 15
Set the language to English with the command call application voice aa setlocation en 0 flash:
Step 16
Define the call queuing TCL script with the command call application voice queue
flash:app-b-acd-2.0.0.0.tcl.
Step 17
Set the call queue length to ten callers with the command call application voice
queue queue-len 10.
Step 18
Set option 2 in the menu to use hunt group X200 with the command call application
voice queue aa-hunt3 X200.
Step 19
Set option 3 in the menu to use hunt group X201 with the command call application
voice queue aa-hunt4 X201.
Step 20
Set the option 4 in the menu to use hunt group X202 with the command call
application voice queue aa-hunt2 X202.
Step 21
Set the number of hunt groups to three with the command call application voice
queue number-of-hunt-grps 3.
Step 22
Associate the automated attendant name with the call queuing application with the
command call application voice queue aa-name aa.
Step 23
Enable debugging of the B-ACD scripts with the command call application voice
queue queue-manager-debugs 1.
Step 24
Make a new dial peer by using the command dial-peer voice 6 pots.
Lab Guide 57
Step 25
In dial peer mode, enter the command application aa to associate the B-ACD
service to the dial peer.
Step 26
In dial peer mode, enter the command incoming called-number X300 to match the
call incoming.
Step 27
Use the command port module/submodule/port to associate the physical port to the
dial peer (Use the lowest numbered FXS port which should currently have your
analog phone attached).
Step 28
Step 29
Create a loopback interface that will be used for a VoIP dial peer by entering the
command interface loopback 0.
Step 30
In loopback interface mode, assign an IP address to the interface with the command
ip address 10.X1.0.1 255.255.255.0 (where X is the pod number).
Step 31
Step 32
Make a new dial peer by entering the command dial-peer voice 7 voip.
Step 33
In dial peer mode, enter the command application aa to associate the B-ACD
service to the dial peer.
Step 34
In dial peer mode, enter the command incoming called-number X300 to match the
call incoming.
Step 35
In dial peer mode, enter the command destination-pattern X300.
Step 36
Point to the loopback IP address with the command session target ipv4:10.X1.0.1.
Step 37
Enable DTMF relay with the command dtmf-relay h245-alphanumeric.
Step 38
Set the codec to G.711 with the command codec g711ulaw.
Step 39
Disable VAD with the command no vad.
Step 40
Step 41
Pick up the analog phone in your pod and place a call to the pilot number of X300
and verify that the B-ACD service automated attendant answers the call.
Step 42
Use the command show call application session to verify that the application has
been invoked.
Step 43
Explore the menu options making sure to go to an ephone hunt group with agents
and then to an ephone hunt group with all agents in the DND state.
Step 44
Turn on debugging of the B-ACD service by using the command debug voip ivr
script.
Step 45
Place a call to the pilot of X300 and view the output.
Verify that calls to the pilot number of the B-ACD service are answered by the automated
attendant.
Verify that the automated attendant presents the menus to the callers.
Verify that the menus work and transfer calls to the ephone hunt groups.
Verify that when all phones are in the DND state, any calls to that hunt group are queued
by the call queuing of the B-ACD service.
Task 8: Configuring Call Park

In this task, you will customize the IP Phone display.

In this lab, ACME has an overhead page that is used by the company operator to page someone
who is not answering a transferred consultative call. The ability to park the call is needed so
that the person who is being paged can retrieve the call from any phone in the Cisco
CallManager Express system. Complete these tasks:
Configure the ability to park a call at the extension X800 (where X is the pod number).
Set the park to send a reminder after ten seconds and to repeat this three times.
Retrieve a parked call from the other IP Phone.
Activity Procedure
Step 1
Open a console connection to the Cisco CallManager Express system.
Step 2
Enter enable to enter privileged EXEC mode.
Step 3
Enter configure terminal to enter global configuration mode.
Step 4
Enter the command ephone-dn 8 to create an ephone for use as a call park slot.
Step 5
Use the number X400 command to assign an extension.
Step 6
Use the command park-slot timeout 10 limit 3 to set a reminder after ten seconds
and to terminate the call after three reminders.
Step 7
Reset the IP Phones by using the keys on the IP Phones to enter **#**.
Step 8
From the analog phone, call one of the IP Phones and answer the call.
Step 9
Use the More softkey button to find and press the Park softkey button.
Step 10
Wait ten seconds. What do you hear on the analog phone and on the IP Phone?
Step 11
Wait another twenty seconds. What happens to the call?
Step 12
Step 13
Lab Guide 59
Step 14
From the second IP Phone, use the More softkey button to find and press the
PickUp softkey button. When a dial tone is heard, dial X400 to retrieve the parked
call.
Step 15
Hang up the call.
Step 16
Step 17
Step 18
From the IP Phone that parked the call, use the More softkey button to find and
press the PickUp softkey button. When a dial tone is heard, dial * to retrieve the
call.
Step 19
Step 20
Use the Trnsfr softkey button to transfer the call to the extension number X400.
Step 21
From the second IP Phone, use the More softkey button to find and press the
PickUp softkey button. When a dial tone is heard, dial X400 to retrieve the parked
call.
Step 22
Hang up the call.
You have completed this task when you verify that the call park functions properly.
Task 9: Configuring the IP Phone Display

In this task, you will customize the IP Phone display.

In this lab, ACME wishes to customize the IP Phones with the DID number of the phone, the
company name on the display, and a label on the line. Configure the following with IOS
commands or by using the GUI:
Configure the top line of the two IP Phones to have the DID number 20X5559000 or
20X5559001.
Replace the Cisco CallManager Express text on the phone with IPTX Classroom.
Label the first line with my line X000 on the lowest-numbered IP Phone.
Activity Procedure
Step 1
Go to http://10.X0.0.1/ccme.html (where X is the pod number) to access the GUI

web interface. Use the system administrator credentials of IPTX and cisco.
Step 2
From the Configure drop-down menu, choose System Parameters.
Step 3
On the System Parameters page, highlight the System Message object and enter a
message of IPTX Classroom.
Step 4
Go to a terminal and enter the CLI of the Cisco CallManager Express router.
Step 5
Go to global configuration mode by using the configure terminal command.
Step 6
Enter the ephone configuration mode for the first IP Phone by using the ephone-dn
1 command.
Step 7
Enter the description Phone1 command to set the label on the IP Phone header bar.
Step 8
Enter the ephone configuration mode for the second phone by using the ephone-dn
2 command.
Step 9
Enter the command description 20X5559001 (where X is the pod number) to set the
IP Phone header bar.
Step 10
Step 11
Enter the command ephone-dn 1 to enter the configuration for your first ephone-dn.
Step 12
Enter the command label my line X000 (where X is equal to the pod number) to set
a label on ephone-dn 1.
Step 13
Reset all the IP Phones by pressing **#** on the keypad of both IP Phones.
Step 14
Enter the show running-config | begin telephony-service command to view the

changes.
Step 15
Enter the copy running-config startup-config to save the changes.
Step 16
Notice the system message of IPTX Classroom.
Step 17
Verify that the changes you implemented are present on the IP Phones.
You have completed this task when you verify that the displays on the IP Phones are
customized.
Task 10: Configuring a Nondialable Intercom

In this task, you will configure a nondialable intercom between the two IP Phones.

In this lab, ACME wishes to configure an intercom between the CEO and the corresponding
administrator assistant. No one else in the company should be able to dial this intercom.
Complete these tasks:
Configure an intercom between the two IP Phones.
Test that the intercom works and that the analog phone cannot dial it.
Activity Procedure
Step 1
As the system administrator, configure a new extension by choosing the Configure

>Extension menu from the GUI web-based interface.
Step 2
Add a new directory number with an extension number of D3333, a sequence

number of 5, an extension type of Intercom, a name of Intercom, a top label field
on the page of Intercom, and an intercom number of D4444. Leave all other settings
at default.
Lab Guide 61
Step 3
Add a second new extension.
Step 4
Set the extension number to D4444 with a sequence number of 6, an extension type
of Intercom, a name of Intercom, a top label field on the page of Intercom, and an
intercom number of D3333. Leave all other settings at default.
Step 5
Assign ephone-dn 7 to a free line of ephone 1 by going to the Configuration >

Phones menu.
Step 6
Assign ephone-dn 8to a free line of ephone 2.
Step 7
Reset both phones by pressing **#** on the keypads.
Step 8
Verify that the intercom connects in both directions by going off hook and choosing
the second line to which the intercom ephone-dn was assigned. This should work in
both directions.
Step 9
Go to a terminal window and, at the CLI, enter privileged EXEC mode using the
enable command.
Step 10
Enter the show running-config | telephony-service to view the changes made to the
configuration.
Step 11
Notice the settings under the ephone-dn and ephone section.
You have completed this task when you verify that an intercom works in both directions
between the two IP Phones.
Task 11: Configuring a Dialable Intercom

In this task, you will configure a dialable intercom between the two IP Phones.

In this lab, ACME wishes to configure an intercom that goes to the receptionist at the front
desk that anyone in the enterprise can dial. Complete these tasks:
Configure a second intercom on the two IP Phones.
Test that the intercom works and that the analog phone can dial it.
Activity Procedure
Step 1
As the system administrator, configure a new extension by choosing the Configure

>Extension menu from the GUI web-based interface.
Step 2
Set the extension number to X500 (where X is the pod number) with a sequence
number of 9, an extension type of Intercom, a name of Dialable Int, a top label
field on the page of Dialable Int, and an intercom number of X550. Leave all other
settings at default.
Step 3
Add a second new extension.
Step 4
Set the extension number to X550 (where X is the pod number) with a sequence
number of 10, an extension type of Intercom, a name of Dialable Int, a top label
field on the page of Dialable Int, and an intercom number of X500. Leave all other
settings at default.
Step 5
Assign ephone-dn 9 to a free line of ephone 1 by choosing the Configuration>

Phones menus.
Step 6
Assign ephone-dn 10to a free line of ephone 2.
Step 7
Verify that the intercom connects in both directions by going off hook and choosing
the second line to which the intercom ephone-dn was assigned. This should work in
both directions.
Step 8
Using the analog phone, dial X500 (where X is the pod number).
Step 9
Verify that the intercom works.
Step 10
Using the analog phone, dial X550 (where X is the pod number).
Step 11
Verity that the intercom works.
Step 12
Go to a terminal window and at the CLI, enter privileged EXEC mode using the
enable command.
Step 13
Use the show running-config | begin tele to view the changes made to the
configuration.
Step 14
Notice the settings under the ephone-dn and ephone sections.
Verify that an intercom works between the two IP Phones and that it works in both
directions.
Verify that both intercoms can be dialed from the analog phone.
Lab Guide 63
Task 12: Configure Paging Groups

In this task, you will set up two paging groups. Each IP Phone will be in one paging group, and
both paging groups will belong to yet another paging group.

In this lab, ACME wishes to configure paging groups that will use the speaker phones of the IP
Phones. A paging group for the sales staff and the technical support staff are required. In
addition, when an emergency page is needed, all phones in the sales paging group and the tech
support group should receive the emergency page. Configure the IP Phones as follows:
Configure one IP Phone in the sales paging group that uses X600.
Configure the other IP Phone in the tech support paging group that uses X700.
Configure the emergency paging group to contain all sales and support phones and use
X800.
Test the pages.
Configure all pages to use multicast.
Test all pages.
Activity Procedure
Step 1
As the system administrator, choose the Configure >Extension menu in the GUI
web interface.
Step 2
Add a paging extension using an extension number of X600 (where X is the pod
number) with a sequence number of 11, a name of Sales,and a description of Sales.
Step 3
Add a second paging extension with an extension number of X700 (where X is the
pod number), a sequence number of 12, a name of Support,and a description of
Support.
Step 4
Assign the paging ephone-dn X600 to ephone 1 and X700to ephone 2. Click yes for
Unicast.
Step 5
Test the paging function by dialing X600 and X700 from the analog phone.
Step 6
Use the terminal to access the CLI and enter privileged EXEC mode with the enable
command.
Step 7
From privileged EXEC mode, enter the configure terminal command to go to

Step 8
From global configuration mode, enter the ephone-dn 13 command to create a new
ephone-dn.
Step 9
Assign a directory number to the page using the number X800 command (where X
is the pod number).
Step 10
Enter the name EmergencyAll command to assign a name.
Step 11
Enter the command paging ip 239.1.1.1. port 2000.
Step 12
Enter the command paging group 11,12.
Step 13
Step 14
Enter exit to go to privileged EXEC mode.
Step 15
Use the copy running-config startup-config to save the changes.
Step 16
Use the analog phone to test the paging function by dialing the X700 paging number.
You have completed this task when you verify that the pages to the paging extensions function
correctly.
Task 13: Configuring and Using the Acct Softkey Button

In this task, you will configure and use the Acct softkey button.

In this lab, ACME has a tech support group that needs to start billing for phone calls with
established customers. This is to be done by a third-party reporting software package that will
use CDRs that have account numbers embedded in them. The account number is entered by the
technical support person that receives the call. The task is to configure the ability to embed an
account number in the CDRs of Cisco CallManager Express.
Activity Procedure
Step 1
Place a call from one IP Phone to the other IP Phone in the pod.
Step 2
While the call is in progress, press the Acct softkey and enter 12341234#.
Step 3
Enter the show call active voice command to view the account number.
Step 4
Hang up the call and enter the show call history voice last 2 command and view the
account number appended at the end of the information for the last call.
You have completed this task when you verify that the account number shows up in the show
commands.
Lab Guide 65
Lab 4-1 Answer Key: Configuring Additional Cisco CallManager

Express Features
-
- -- -
- -- -
- --
-
-
-- -
-

-

-

-

--
--

-
- -

-
--

-

--
-
-
-
-
-
--
-
-
--

--

-
--

-

-66 IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
-

-- -
-

--

-
--- -

-
- --- --
- ---
- -
- --
-

-

-
-

-

-

-

-

- -

-

-

-
-

-
Lab Guide 67

-
---

-
---

-

-

---
-- -- --

- --
- -

-
-- -- -
- - -- -
-
--- -

-- - -

--

-
-

-

-


--

--

-

-

-

-

-

-

-
-
-

-- -
-
Lab Guide 69
Lab 5-1: Configuring Cisco Unity Express
Activity Objective
In this activity, you will integrate CUE with Cisco CallManager Express. After completing this
activity, you will be able to meet these objectives:
Installation of the Unity Express software and the post-installation automated macro
process
Run the Initialization Wizard to configure the CUE module
Configure the default automated attendant
Create and run a custom automated attendant
Create users and mailboxes
Troubleshoot CUE with trace and syslog messages
Visual Objective

Cisco Unity Express
PodX
Unity
Express
SIP
CallManager
Express
Web browser
for Using the
GUI Interface
Use to the
Automated
Attendant
X100
SCCP
SCCP
IPTXUser1 With
a Mailbox
IPTXUser2 With
a Mailbox
X000X001
IPTX v2.07
Required Resources
A Cisco CallManager Express router configured with the baseline configuration from the
end of Lab 4-1
Two IP Phones
One analog phone
Student PC with Windows and IE 5.5 or greater
An NM-CUE or an AIM-CUE
Command List
Command
Description
- -
Displays the installed software version and hardware
Displays an overview of interfaces, IP addresses, and status
Enters the configuration for a service engine module
Assigns the interface to be unnumbered
-
-- -
Assigns an IP address to the service module
Assigns a default gateway to the service module
Enables the interface
Goes back one level
Defines and enters a dial-peer configuration mode
Sets the digit that will match a dial peer
--- -
Defines the protocol when using a dial peer to be SIP
Defines the DTMF relay to use the proprietary out-of-band SIP

notification method
---
Sets the VoIP dial-peer target to an IP address
Sets the codec to use for this dial peer
Disables voice activity detection
Enters and defines an ephone-dn mode
Defines the directory number for the ephone-dn
Lab Guide 71
Command
Description
Defines this ephone-dn as an MWI On
Defines this ephone-dn as an MWI Off
- -
Sets the date and time.
Sets this router as an NTP master
Saves the changes
Views the configuration of the router
-
-
---
Connects to the CUE module across the backplane using the

back-to-back console connection
Reloads the CUE module
Starts the configuration of the boot loader
Enables the upgrade or installation process
- -

Installs a software package on the CUE module, either a license

or software
- - --
Displays the versions of software installed
- - --
Displays the current licensed capabilities
- -
Enters the debugging mode for SIP calls
Displays the logging that is currently enabled
Sends error syslog messages to the console
Sends warning syslog messages to the console
Displays the current trace level on the CUE module
Displays the trace output currently in the buffer
Flushes the contents of the trace buffer
Job Aids
Terminal software to connect to the CLI
IE 6.0 web browser
Windows student PC
Table 5 - VPIM Networking

Pod
Domain Name
Location
ID
Location
Name
Abbreviation
VPIM Broadcast
ID
Partner
Pod
1 seattle.cisco.com 10 seattle sea sea-broadcast 2

2 boston.cisco.com 20 boston bos bos-broadcast 1
3 atlanta.cisco.com 30 atlanta atl atl-broadcast 4
4 dallas.cisco.com 40 dallas dfw dfw-broadcast 3
5 portland.cisco.com 50 portland pdx pdx-broadcast 6
6 raleigh.cisco.com 60 raleigh rdu rdu-broadcast 5
7 phoenix.cisco.com 70 phoenix phx phx-broadcast 8
8 miami.cisco.com 80 miami mia mia-broadcast 7
Task 1: Prerequisite Cisco CallManager Express Configuration

In this activity, the Cisco CallManager Express router will be configured to support the CUE
module that will be installed in the next task.
Activity Procedure
Step 1
From the console of your router, enter the command enable. Enter the enable
password (cisco) when prompted.
Step 2
Enter the show version command to verify that the Cisco service engine is detected.
Step 3
Enter the show ip interface brief command to determine the interface number of the
service engine. Write the interface number here: _________________.
Step 4
Enter global configuration mode by using the configure terminal command.
Step 5
Go to the service engine interface with the interface service-engine Module/Port

command using the information from the show ip interface brief command.
Step 6
Under the service engine mode, use the command ip unnumbered fastethernet
0/0.X0 (where X is equal to the pod number) to assign an address to the interface.
Step 7
Use the command service-module ip address 10.X0.0.10 255.255.255.0 (where X is

the pod number) to apply an address to the module.
Lab Guide 73
Step 8
Set a default gateway on the module by using the service-module ip defaultgateway 10.X0.0.1 command.
Step 9
Enable the interface by typing the no shutdown command.
Step 10
Step 11
Use the command ip route 10.X0.0.10 255.255.255.255 service-engine

Module/Port to create a host route to the service engine CUE module.
Step 12
Create the SIP dial peer that is used to set up a call to the Cisco Unity Express
module. This is started by using the command dial-peer voice 8 voip.
Step 13
In dial-peer mode, enter the command destination-pattern X9.. (where X is the pod
number).
Step 14
Enter the command session protocol sipv2 to use SIP for this dial peer.
Step 15
Enter the command dtmf-relay sip-notify to send DTMF digits in notify packets.
Step 16
Enter the session target ipv4:10.X0.0.10 command (where X is the pod number) to
specify the IP of the service engine.
Step 17
Set the codec to G.711 with the command codec g711ulaw.
Step 18
Disable voice activity detection with the command no vad.
Step 19
Step 20
To create a MWI on an ephone-dn, enter the command ephone-dn 14.
Step 21
In the ephone-dn submode, enter number 9001.... (the four periods represent the
four digits in the dial plan).
Step 22
Enter the command mwi on.
Step 23
Create the MWI off on an ephone-dn by entering ephone-dn 15.
Step 24
In the ephone-dn submode, enter number 9000.... (the four periods represent the
four digits in the dial plan).
Step 25
Enter the command mwi off.
Step 26
Step 27
Enter the command ntp master to enable network time protocol.
Step 28
Enter exit to go to privileged EXEC mode
Step 29
Use the clock set hh:mm:ss day-of-month month year command to set the time to
your current location (the month must be spelled out).
Step 30
Enter the command copy running-config startup-config to save the changes.
Step 31
Use the command show running-config to view the configuration.
Verify that all commands have been entered properly.
Verify that the configuration shows the desired changes.
Verify that the configuration is saved.
Task 2: Installing, Upgrading, and Completing the PostInstallation Procedure

In this task, the CUE software image will be installed on the module. The post-installation
procedure will then be performed.
Activity Procedure
Step 1
Collect the IP address of the classroom TFTP server from the instructor:
_________________
Step 2
Collect the IP address of the classroom FTP server from the instructor:
__________________
Step 3
Ping the TFTP and FTP servers (they may be the same machine) to verify
connectivity. If any problems occur, tell your instructor.
Step 4
Enter the command service-module service-engine Module/Port session to connect

to the CUE module. (When you see trying, press the Enter key to see the prompt.)
Step 5
Enter the command reload at the prompt. If you are sure a reload is wanted, enter y
when prompted.
Step 6
Watch carefully as the module is reloaded and enter *** (three asterisks) within ten
seconds of seeing the Please enter *** to change boot configuration: prompt. If
the ten-second window is missed, the module will have to be reloaded and this step
repeated.
Step 7
The module will then be in a ServiceEngine boot-loader mode.
Step 8
At the prompt, enter config to configure the boot helper.
Step 9
Enter an IP address of 10.X0.0.10 (where X is the pod number).
Step 10
Enter a subnet mask of 255.255.255.0.
Step 11
Enter the address of the TFTP server that your instructor gave you.
Step 12
Enter a default gateway of 10.X0.0.1 (where X is the pod number).
Step 13
Enter cue-installer.2.1.0.17 as the name of the installer file.
Step 14
Accept the default setting of internal for the Ethernet interface.
Step 15
Accept the default setting of disk for default boot.
Lab Guide 75
Step 16
Accept the default setting of primary for the default boot loader. This will now
save the boot loader configuration to flash.
Step 17
Ping the TFTP and FTP servers (they may be the same machine).
Step 18
Enter the command boot helper to initialize the installation file. If any errors occur,
notify your instructor. A spinning prompt should be seen. This indicates that the
installer is being downloaded (this may take several minutes). If the prompt is not
spinning, tell your instructor.
Step 19
A menu will be presented allowing the installer to select to either install software or
to reload the module. Choose the install software option.
Step 20
When asked for the package name, enter cue-vmlicense_50mbx_cme_eng_2.1.0.17.pkg. If a typo is made, continue through the next
steps and, when prompted to install software, start this step over.
Step 21
When asked for the URL, enter the following: ftp://ip-address/ (where the IP
address is provided by the instructor).
Step 22
When prompted for a username, enter anonymous or a username provided by your

instructor.
Step 23
When prompted for a password, leave the field blank or enter the password provided
by your instructor.
Step 24
When asked for the package name, enter cue-vm.2.1.0.17.pkg. If a typo is made,
continue through the next steps and, when prompted to install software, start this
step over.
Step 25
When asked for the URL, enter the following ftp://ip-address/ (where the IP address
is provided by the instructor).
Step 26
When prompted for a username, enter anonymous or a username provided by your

instructor.
Step 27
When prompted for a password, leave the field blank or enter the password provided
by your instructor.
Step 28
Next, a language menu will appear. Select the desired language by entering the
corresponding number. Up to two languages may be selected.
Step 29
When the desired language(s) have been selected, enter x to continue with the
installation of the package.
Step 30
The installation or upgrade will take a few minutes. At the end of the installation or
upgrade, the system will ask if you want to start the configuration. Enter y.
Step 31
When prompted, and if you are sure, enter y.
Step 32
Important! If you are asked if the configuration should be restored, enter n to not
restore the configuration.
Step 33
When prompted, enter a hostname of CUEX (where X is the pod number).
Step 34
When prompted for a domain name, refer to Table 5 to specify the pod domain
name.
Step 35
When asked if DNS is going to be used, enter n. Then enter y when prompted if you
are sure.
Step 36
When asked for the IP address of the primary NTP server, enter 10.X0.0.1 (where X
is the pod number).
Step 37
When asked for the IP address of the secondary NTP server, press the Enter key to
bypass.
Step 38
Choose the continent that you are on.
Step 39
Choose the country where you are.
Step 40
Choose the time zone if prompted.
Step 41
If your choices are correct, enter 1 to end the post-installation routine and the system
will then load the operating system and the CUE application. Please be patient
because this may take some time to load (especially if using AIM cards).
Step 42
When prompted for an administrator ID, enter CUEAdmin.
Step 43
When prompted for a password, enter cisco.
Step 44
When prompted for confirmation, enter cisco.
Step 45
The prompt should now show CUEX> (where X is the pod number).
Step 46
Use the command show software versions to verify that the version of CUE is 2.1.1
(it is okay if the boot loader is not 2.1.1).
Step 47
Use the command show software licenses and verify that there are 50 personal
mailboxes. Verify that the application mode is equal to CCME.
Verify that the CUE system reloads itself successfully.
Verify that the appropriate licensed capacity and version are installed.
Task 3: Running the Initialization Wizard

In this activity, you will run the Initialization Wizard.
Activity Procedure
Step 1
Verify that the command web admin exists by using the show running-config |
begin web admin command.
Step 2
Open Internet Explorer and enter the URL http://10.X0.0.10 (where X is the pod
number) from the student PC.
Step 3
A web page will appear with these words in red: System is not initialized. Only
Administrator logins are allowed. On this page, enter the username of CUEAdmin
and a password of cisco, then click Login.
Step 4
Choose the option Run Initialization Wizard to start the configuration process.
Lab Guide 77
Step 5
The first of five steps appears. The credentials for Cisco CallManager Express must
be entered. Enter a username of IPTX and a password of cisco, then click Next.
Step 6
The second step imports the Cisco CallManager users. In this interface, choose only
the user associated with the X000 and make sure to choose the mailbox and
administrator checkbox. Make sure the other user is not selected (this user and
mailbox will be created later in the lab). Click Next.
Step 7
The third step allows the default setting and actions to be defined. Leave all settings
at the default. Click Next.
Step 8
The fourth step defines the call handling. On this page, enter X900 for the Voice
Mail Number (where X is the pod number).
Step 9
Set the Voice Mail Operator to X000.
Step 10
Enter X901 for the Auto Attendant Access Number (where X is the pod number).
Step 11
Enter X001 for the Auto Attendant Operator Number (where X is the pod number).
Step 12
Enter X902 for the Administration Via Telephony Number (where X is the pod
number).
Step 13
Verify that the MWI settings are automatically populated with the configuration
settings performed on the Cisco CallManager Express router, including the four
periods at the end of the MWI numbers.
Step 14
Leave all other settings to default, then click Next.
Step 15
Review the information for accuracy and if correct, click the checkbox Finally, save
to startup configuration, then click Finish. This can take a couple of minutes to
complete.
Step 16
A summary page will be displayed. Note the password and PIN for the user
imported and write them down here. Password_______________________
PIN________
Step 17
Verify that there are no failures. If there are failures, notify your instructor, then
click Logout.
Step 18
Click Login Again and enter a username of CUEAdmin and a password of cisco
and verify that the administrative web page can be accessed.
Verify that the Initialization Wizard runs successfully without errors.
Verify that the system administrator can log in to the administrative web pages.
Task 4: System Defaults

In this activity, you will view the system defaults.
Activity Procedure
Step 1
From the administrative web interface, logged in as the administrator, choose the
Defaults>User menu.
Step 2
View the user defaults and available options.
Step 3
Choose the Defaults > Mailbox menu.
Step 4
View the mailbox defaults for any new mailboxes.
Step 5
Choose the Defaults>Voice Mail menu.
Step 6
View the voice mail defaults and notice the available options.
You have completed this task when the defaults of the system have been viewed.
Task 5: Setting Up the Mailbox and Using the TUI

In this task, the user will be modified, the mailbox will be set up through the Telephony User
Interface (TUI) of CUE, and a message left and checked.
Activity Procedure
Step 1
From the administrative web page, choose Configure>Users .
Step 2
From the Users menu, choose the user JDoe. A User Profile page will appear.
Step 3
On the properties page, set the first name and last name based on Table 4
Step 4
For the Primary E.164 Number field, enter 20X5559000 (where X is the pod
number).
Step 5
Enter cisco in the Password and Confirm Password fields.
Step 6
Enter 1234 in the PIN and Confirm PIN fields.
Step 7
Click Apply to apply the changes.
Step 8
Press the Messages or Envelope icon button on your X000 IP Phone (where X is the
pod number).
Step 9
When prompted for a password, enter 1234# (this is really the PIN setting; the
password is used for logging in to the web page as a user).
Step 10
The tutorial will play and prompt you to record a name by pressing 1. Record a
name at the tone, then review and approve it.
Lab Guide 79
Step 11
You will then be played a standard greeting and will be presented with the option to
record a personal greeting by pressing 1.
Step 12
Next, a new PIN must be entered twice. Use 4321.
Step 13
Hang up the call to voice mail.
Step 14
From the X001 IP Phone, call the X000 IP Phone (where X is the pod number in both
cases) and let the call go into voice mail.
Step 15
Leave a message with urgent priority (the minimum length of a message is two
seconds).
Step 16
Notice that the MWI light is lit on the X000 IP Phone (where X is the pod number)
and has an envelope icon next to it.
Step 17
Press the Messages or Envelope icon button on the X000 IP Phone (where X is the
pod number), enter the PIN of 4321, and check the message in the mailbox.
Step 18
When done, delete the message.
A voice mail appears in the mailbox of the first phone.
The voice mail is checked and deleted.
Task 6: Adding a User and a Mailbox in the GUI Web Interface

In this task, a second user will be added to the CUE system, then a mailbox will be created and
associated with that user.
Activity Procedure
Step 1
Open the CUE administrative web page by going to http://10.X0.0.10 (where X is the
pod number) or, if the page is still open, click Login Again on the page.
Step 2
Log in as the administrator with the credentials of CUEAdmin and a password of

cisco.
Step 3
Choose the Configure>Users menu . On the Users page, add a new user.
Step 4
The Add a New User page will appear. Fill in the page with the information in the
following steps.
Step 5
Set the User ID, First name, and Last name for the second ephone based upon Table
4.
Step 6
Set the Primary E.164 Number to 20X5559001 (where X is the pod number).
Step 7
Associate a Primary Extension by clicking Add/Edit and choosing the second IP

Phone in your pod X001.
Step 8
Click Specify.
Step 9
Set a password of cisco.
Step 10
Click Specify.
Step 11
Set a PIN of 1234.
Step 12
Click the Create Mailbox checkbox. Click the Add button.
Step 13
The Add a New Mailbox page will appear. Leave the settings at the default and click
Add.
Step 14
Verify that the new user appears on the Users page within the administrative web
pages.
Step 15
On the second IP Phone (X001), call voice mail and set up the mailbox by recording
a recorded name and a personal greeting.
Step 16
Set the PIN to a new value of 4321.
Verify that there are two users and two personal mailboxes.
Verify that the system administrator can log in to the administrative web pages.
Verify that the second mailbox is set up and the tutorial has been completed.
Task 7: VPIM Networking

In this task, VPIM networking will be configured between two Unity Express modules.
Activity Procedure
Step 1
Open the CUE administrative web page by browsing to http://10.X0.0.10 (where X is

the pod number).
Step 2
Log in as the administrator with the credentials of CUEAdmin and a password

cisco.
Step 3
Choose the Administration>Network Locations menu. From this page, click

Add.
Step 4
Using Table 5, configure the pop-up window Add a New Location to configure
your partner pod networking location. Assign a location ID of your partner pod,
location name of your partner pod, abbreviation of your partner, IP address of your
partner's CUE module, null prefix blank, VPIM broadcast ID of your partner, min
extension length 4, max extension length 4, and all other settings to default. Then
click Add.
Step 5
Click Add a second time and define the local pod information.
Step 6
Using Table 5, configure the pop-up window Add a New Location to configure
your pods networking location. Assign the local location ID, location name,
abbreviation, IP address of the local CUE module, null prefix blank, VPIM
broadcast ID, min extension length 4, max extension length 4, and leave all other
settings at the default. Click Add to commit.
Lab Guide 81
Step 7
In the Local Location ID field, enter the location ID of the local location and click
Apply.
Step 8
Test VPIM by pressing the message button on the lowest number extension and
when prompted enter the PIN (the TUI will ask for a password).
Step 9
In the TUI, compose a message by pressing 2 when prompted. Spell out the last
name of the user associated with the top line of ephone 2 in your partner pod. What
is the result?
Step 10
In the TUI, compose a message by pressing 2 when prompted. Change to numeric

mode by pressing # # and enter the location ID followed by the top extension
number of your partners ephone 2. For example, if pod 1 is composing a message
for extension 2000 on pod 2, the number entered will be 202000. What is the result?
Step 11
Check the message that arrives.
Step 12
View the least recently used (LRU) cache by using the command show remote
cache from the CLI of the CUE module. Verify that information from your partner
appears in the cache before proceeding to the next step.
Step 13
Dial into the AVT(Administration Via TUI) pilot number of X902 and when
prompted enter the extension number of X000 and a PIN of 4321.
Step 14
Press 3 for voice mail administration
Step 15
Press 2 for spoken name administration.
Step 16
Press 1 for a spoken name for a location.
Step 17
Enter the location ID for your partner pod.
Step 18
When prompted, record the name of the location for the pod of your partner. When
completed, disconnect the call.
Step 19
From ephone 2 in your pod, compose a message from the TUI using spell-by-name
of the user associated with the top line of ephone 1 in your partner pod. What is the
result? How did spell-by-name work? Is this learning permanent?
Step 20
Using Table 4, configure both users for your partner pod by choosing the Configure
>Remote Users menu.
Step 21
Click Add and, in the window that appears, configure the user associated with Y000
by configuring the username, first name, last name, primary extension (Y000), and
the location ID. Click Add to commit the changes.
Step 22
Click Add and, in the window that appears, configure the user associated with Y001
by configuring the username, first name, last name, primary extension (Y001), and
the location ID. Click Add to commit the changes.
Step 23
From ephone 2 in your pod, compose a message from the TUI using spell-by-name
of the user associated with the top line of ephone 1 in your partner pod. What is the
result? How did spell-by-name work? Is this learning permanent?
Task 8: Distribution Lists

In this task, a public distribution list will be configured for the sales team.
Activity Procedure
Step 1
Browse to the CUE administrative web page at http://10.X0.0.10 (where X is the pod
number).
Step 2

cisco.
Step 3
Choose the Voice Mail>Distribution Lists menu and then choose Public Lists.
Step 4
On the Public Lists page, click Add.
Step 5
In the Add a Public Distribution List window that appears, configure a name of
Sales and a number of X998. Click Add when completed.
Step 6
Choose the new distribution list named Sales from the Public Lists page.
Step 7
In the Public List Sales web page, choose the Members tab and then click Add
Member.
Step 8
On the Find web page, choose the ID radio button and then click Find.
Step 9
The list of users should appear in a Find window. Select the lowest numbered
extension for your pod and the pod of your partner. Then click Select Rows. This
will add a local user and a remote user to the distribution list.
Step 10
From a phone that is not in the distribution list, press the Messages button and log in
to the voice mailbox.
Step 11
When prompted to send a message, press 2.
Step 12
Spell the name of sales by pressing 7 2 5 3 7.
Step 13
Record a test message to the sales distribution list and verify that the local phone and
the phone of your partner receive a copy of the message in their voice mailbox.
You have completed this task when you verify that both members of the Sales public
distribution list receive a message to the list.
Lab Guide 83
Task 9: General Delivery Mailboxes

In this task, a general delivery mailbox will be configured for the sales department.
Activity Procedure
Step 1
number).
Step 2

cisco.
Step 3
Choose the Configure>Extensions menu. Click Add.
Step 4
The Add an Extension Number page appears. Configure an Extension Number of

X150, Sequence Number of 16, Extension Type of Normal, Name of Sales, Call
Forward busy of X900, Call Forward no-answer of X900, timeout in 10, and all other
settings left at default. Then click Add.
Step 5
Choose the Configure>Phones menu item.
Step 6
Choose the first IP Phone and then click an unassigned button. This will bring up
the line page. Choose a ring type of Feature Ring and check the box in front of
extension X150. Click Save and then the Change button to commit the changes.
Step 7
Repeat the previous steps for the second IP Phone in the pod.
Step 8
Choose the Configure>Groups menu. From the Groups page, click Add.
Step 9
An Add a New Group page appears. On the Group ID field, enter Sales. In the
Primary Extension field, enter X150. In the Primary E.164 Number field, enter
20X5559150, click the Create Mailbox check box, and finally, click Add.
Step 10
The Add a New Mailbox page will open up. Leave the defaults settings and click
Add.
Step 11
Choose the Configure>Groups menu. From the Groups page, choose the Sales
group and go to the Owners/Members tab.
Step 12
Click +Subscribe member to open a Find page. Click the blue Find button, choose
both of the pods users, and click +Select row(s).
Step 13
Click +Subscribe owner to add an owner to the group mailbox. Click the blue Find
button and click the checkbox in front of the user associated with ephone 1. Click
Select Rows to commit the changes.
Step 14
Call voice mail by pressing the envelope icon button on an IP Phone and, when
prompted, enter the PIN number of 4321.
Step 15
There should be a new option in the TUI. When prompted, press 9 to enter the
general delivery mailbox management. Choose general delivery mailbox X150 when
prompted and press 1. (Only one IP Phone at a time is permitted in the general
delivery mailbox.)
Step 16
The tutorial will play. Record a name and personal greeting for the group.
Step 17
Call the extension number for the general delivery mailbox at X150, let the call go to
voice mail, and leave a message. Notice that both phones have an indicator in the
form of an envelope icon on the line to which the sales ephone-dn was assigned.
(Only the top line appearance can use the MWI light of the IP Phone.)
Step 18
Call voice mail by pressing the envelope icon button on the phone and, when
prompted, enter the PIN number of 4321.
Step 19
There should be a new option in the TUI. When prompted, press 9 to enter the
general delivery mailbox management for X150. Check and delete the message by
following the TUI prompts.
Verify that a sales general delivery mailbox has been successfully configured.
Verify that a message has been left and checked from the TUI.
Task 10: Broadcast Messages

In this task, a broadcast message user will be configured and send a broadcast to all users.
Activity Procedure
Step 1
Attempt to dial the Administrative TUI by dialing X902 from extension X000. Enter
the extension and PIN when prompted. What is the result?
Step 2
number).
Step 3

cisco.
Step 4
Choose the Configure>Groups menu. From this menu, choose the Sales group
that was previously configured.
Step 5
Click the Voicemail Broadcaster checkbox and click Apply to save the changes.
Step 6
Dial the Administrative TUI by dialing X902 from extension X000. Enter the
extension and PIN when prompted. What is the result?
Step 7
Press 3 for voice mail administration.
Step 8
Press 1 for broadcast administration.
Step 9
Press 1 to send a broadcast to subscribers on this server.
Step 10
Record the message. Send the message by pressing #. Who received the message?
Step 11
Dial the Administrative TUI by dialing X902 from extension X000. Enter the
extension and PIN when prompted. What is the result?
Step 12
Press 3 for voice mail administration.
Step 13
Press 1 for broadcast administration.
Lab Guide 85
Step 14
Press 2 to send another location.
Step 15
Press 2 to send to one or more locations.
Step 16
Enter the location ID of your partner followed by #.
Step 17
Record the message. Send the message by pressing #. Who received the message?
Task 11: Defining the business hours

In this task, a business hour schedule called summerschedule will be defined.
Activity Procedure
Step 1
From the CLI of the CUE module, use the command show clock to determine the
time and date of the CUE module. Write down the time and date here.
Step 2
In the administrative web interface choose the Voice Mail > Business Hour
Settings menu.
Step 3
Notice that there is a Business Hour Schedule of systemschedule defined by default.
Step 4
What are the open hours by default? ___________________________-
Step 5
Add a new schedule by clicking Add.
Step 6
In the Add a New Schedule web page that appears, define a name for the new
schedule called summerschedule.
Step 7
Note that by default the schedule is always open.
Step 8
Note the current day and time.
Step 9
Set the current half hour time interval and the next half hour interval to closed. For
example, if the time is currently Thursday at 2:15 p.m., you would set the 2:00 2:29
p.m. and 2:303:00 p.m. intervals to closed. This will allow you to test what happens
when the current time is closed.
Step 10
Choose Apply to commit the changes to the summerschedule.
Task 12: Using the Automated Attendant

In this task, the automated attendant will be invoked and used from the analog phone.
Activity Procedure
Step 1
From the analog phone, dial the number of the automated attendant. This should be
Step 2
The call should enter the automated attendant. Press 1 to enter the extension of one
of the two IP Phones and notice that you are connected.
Step 3
Hang up the call.
Step 4
Dial the automated attendant again and enter the automated attendant prompts.
Step 5
Press 2 to spell the name of a user. Spell out the last name of the user associated
with ephone 1 using the keypad, and the call should be connected to the IP Phone.
Step 6
Hang up the call.
Step 7
Go to the web interface and log in as an administrator with the credentials of

CUEAdmin and a password of cisco.
Step 8
Choose the Voice Mail>Auto Attendant menu.
Step 9
Choose the default automated attendant called Autoattendant and an Automated

Attendant Profile page will appear.
Step 10
Click Next.
Step 11
On the Script Parameter page, set operExtn* to X000, and note that the
businessSchedule parameter is selected by default, then click Next.
Step 12
Click Finish.
Step 13
Dial the automated attendant again and enter the automated attendant prompts.
Step 14
Press 0 for the operator when prompted.
Step 15
Step 16

Step 17
Click Next.
Step 18
On the Script Parameter page, set the businessSchedule parameter to

summerschedule, then click Next.
Step 19
Click Finish.
Step 20
Dial the automated attendant again. What is the result?
Step 21
Step 22

Lab Guide 87
Step 23
Click Next.
Step 24
On the Script Parameter page, set the businessSchedule parameter back to the
default of systemschedule, then click Next.
Step 25
Click Finish.
Step 26
Choose the Voice Mail>Holiday Settings menu.
Step 27
Click Add.
Step 28
On the Add New Holiday web page, click the calendar icon and select today s date.
Step 29
Click Add to commit the holiday.
Step 30
Dial the automated attendant again. What is the result?
Step 31
Choose the Voice Mail>Holiday Settings menu.
Step 32
Select the previously configured holiday and click Delete.
Verify that the default automated attendant has been tested and that it works.
Verify that the operator extension has been tested and defined.
Verify that the business hours function.
Verify that the holiday settings function.
Task 13: Creating Prompts for a Custom Automated Attendant

In this task, a custom automated attendant will be invoked and used from the analog phone.
Activity Procedure
Step 1
Add the users to the administrator group by choosing the Configure>Groups

menu.
Step 2
Choose the Administrators group and, on the Group Profile page that appears,
choose the Owners/Members tab.
Step 3
Click the checkboxes for both users and click Subscribe Member.
Step 4
Enter the Administrative TUI by calling X902 and entering your extension and PIN.
Step 5
Choose 2 to administer custom prompts.
Step 6
Press 1 when prompted to create a new prompt.
Step 7
Record a prompt for the ACME company that says Thank you for calling
ACME.
Step 8
Create a second prompt that says For sales, press one; for support, press two; for
the operator, press zero.
Step 9
Create a third prompt that says I am sorry that you are having problems.
Step 10
Create a fourth prompt that says I am sorry the number you are trying to reach
is busy, please call back later.
Step 11
Create a fifth prompt that says I am sorry but we are currently closed.
Step 12
Hang up the call.
Step 13
Open the web administrative GUI interface by logging in with the CUEAdmin
username and a password of cisco.
Step 14
Choose the VoiceMail>Prompts menu. Notice that the four prompts are present in
the order recorded with a timestamp.
Step 15
Notice the name of the .wav file that was recorded. There is a timestamp embedded
in the name.
Step 16
Choose the prompt that was recorded first and rename it to ACMEWelcome.wav
and then click Apply.
Step 17
Choose the prompt that was recorded second and rename it to ACMEMenu.wav and
then click Apply.
Step 18
Choose the prompt that was recorded third and rename it to ACMEProblems.wav
and then click Apply.
Step 19
Choose the prompt that was recorded fourth and rename it to ACMEClosed.wav and
then click Apply.
Step 20
Choose the prompt that was recorded fifth and rename it to ACMEBusy.wav and
then click Apply.
You have completed this task when you verify that five new prompts are created in the CUE
system.
Task 14: Installing the CUE Editor and Creating a Custom

Automated Attendant
In this task, the CUE Auto Attendant Editor will be installed and used to create a very simple
custom automated attendant script that will then be configured and tested in CUE.
Activity Procedure
Step 1
The instructor will instruct you on the location of the CUEEditor.2.1.1.exe.
Step 2
Run the CUEEditor.2.1.1.exe application to install the CUE Auto Attendant Editor.
Step 3
Click Next to start the install.
Step 4
Click Yes to the licensing agreement.
Step 5
Click Next to accept the default installation path.
Lab Guide 89
Step 6
When the installation completes, click Finish.
Step 7
To start the CUE Auto Attendant Editor, click the Start button in MSWindows on
your PC and go to the Program Files.
Step 8
From Program Files, move to the Cisco CUE Developer object and then start the
Cisco CUE Editor.
Step 9
Press CTRL-N to start a new script.
Step 10
A page will appear with a Start flag on it.
Step 11
Expand all of the folders on the left pane to view all of the steps.
Step 12
In the variable pane (bottom left pane), click the blue arrow icon to add a new
variable.
Step 13
The Edit Variable window will appear. Give the variable a case-sensitive name of
welcomeGreetingACM.
Step 14
For the Type field, choose Prompt. Leave the value blank, check the Parameter
box, and click OK.
Step 15
In the variable pane (bottom-left pane), click the blue arrow icon to add a new
variable.
Step 16
The Edit Variable window will appear. Give the variable a (case-sensitive) name of
menuACME.
Step 17
For the Type field, choose Prompt. Leave the value blank, click the Parameter
checkbox, and click OK.
Step 18
variable.
Step 19
The Edit Variable window will appear, give the variable a (case-sensitive) name of
systemProblemsACME.
Step 20
Step 21
variable.
Step 22
The Edit Variable window appears. Give the variable a (case-sensitive) name of
systemSchedule.
Step 23
For the Type field, choose Schedule. Leave the value null, click the Parameter
Step 24
variable.
Step 25
systemClosedACME.
Step 26
Step 27
variable.
Step 28
systemBusyACME.
Step 29
Step 30
variable.
Step 31
operatorExtensionACME.
Step 32
For the Type field, choose String. Set the value to 0 (quotes must be included here),
click the Parameter checkbox, and click OK.
Step 33
In the variable pane (bottom-left pane), select the blue arrow icon to add a new
variable.
Step 34
salesSharedDNACME.
Step 35
For the Type field, choose String. Set the value to X201 (quotes must be included
here and X is the pod number), click the Parameter checkbox, and click OK.
Example: the value for Pod 9 would be 9201.
Step 36
variable.
Step 37
supportExtensionACME.
Step 38
For the Type field, choose String. Set the value to X000 (quotes must be included
here and X is the pod number), click the Parameter checkbox, and click OK.
Example: the value for Pod 9 would be 9000.
Step 39
Drag the Accept step from the Contact folder in the left pane and drop it on top of
the Start step.
Step 40
From the Media folder, drag and drop the Play Prompt step on top of the Accept
step.
Step 41
Right-click Play Prompt and choose Properties.
Step 42
Choose the Prompt tab and click the button with the ellipsis on it.
Step 43
From the drop-list of variables, choose the welcomeGreetingACME, then click

OK.
Step 44
Click OK to close the properties page for the Play Prompts step.
Step 45
From the General folder, drag and drop the Label step on top of the Play Prompt
step.
Step 46
Right-click the Label step and choose Properties.
Step 47
Change the name of the label to ACMECLOSED and click OK.
Lab Guide 91
Step 48
From the General folder, drag and drop another Label step on top of the
ACMECLOSEDLabel step.
Step 49
Right-click the Label step and choose Properties.
Step 50
Change the name of the label to ACMEMENU and click OK.
Step 51
From the General folder, drag and drop the Is Holiday step on top of the Play
Prompt step. This will add the step above the two label steps.
Step 52
Expand the plus in front for the Is Holiday step to reveal the Yes and No logic
branches.
Step 53
From the General folder, drag and drop the Goto step on top of the Yes branch of
the Is Holiday step.
Step 54
Right-click the Goto step and choose Properties.
Step 55
Select the ACMECLOSED label from the drop down.
Step 56
From the General folder, drag and drop the Business Hours step on top of the No
icon under the Is Holiday step.
Step 57
Right-click the Business Hours step and choose Properties.
Step 58
Select the systemSchedule variable and click OK.
Step 59
Expand the plus in front of the Business Hours step to reveal the Open and Closed
logic branches.
Step 60
From the General folder, drag and drop the Goto step on top of the Closed branch of
the Business Hours step.
Step 61
Step 62
Select the ACMECLOSED label from the drop down.
Step 63
From the General folder, drag and drop the Goto step on top of the Open branch of
the Business Hours step.
Step 64
Step 65
Select the ACMECMENU label from the drop down.
Step 66
From the Media folder, drag and drop the Menu step on top of the ACMEMENU
label step.
Step 67
Right-click Menu and choose Properties.
Step 68
On the General tab, highlight Output 1 and notice the 1 is checked. Click Modify,
rename it to Sales, and then click OK.
Step 69
On the General tab, highlight Output 2 and notice the 2 is checked. Click Modify
and rename it to Support, then click OK.
Step 70
On the General tab, highlight Output 3 and notice the 3 is checked. Click the 0
checkbox and clear the 3 checkbox. Click Modify, rename it to Operator, and then
click OK.
Step 71
On the Prompt tab, click the button with the ellipsis on it.
Step 72
Choose the list of variables and choose menuACME, then click OK.
Step 73
From the Input tab, notice the setting for timeouts and retries.
Step 74
Click OK to close the properties page for the Menu step.
Step 75
Drag and drop a Call Redirect step from the Call Contact folder onto the Sales
branch of the Menu step.
Step 76
Right-click the Call Redirect step and choose Properties.
Step 77
For the Extension field, choose salesSharedDNACME, then click OK to save and
close the Properties page.
Step 78
Drag and drop an End step from the General folder onto the Successful branch of
the Call Redirect step.
Step 79
Drag and drop a Play Prompt step from the Media folder onto the Busy branch of
Step 80
Right-click the Play Prompt step and choose Properties.
Step 81
Step 82
Choose the variables menu and choose the systemBusyACME variable. Then click
OK.
Step 83
Click OK to exit the Properties pages.
Step 84
Drag and drop a Terminate step from the Contact folder onto the Play Prompt in the
Busy branch of the Call Redirect step.
Step 85
Drag and drop an End step from the General folder onto the Terminate in the Busy
branch of the Call Redirect step.
Step 86
Drag and drop a PlayPrompt step from the Media folder onto the Invalid branch of
Step 87
Right-click the PlayPrompt step and choose Properties.
Step 88
Step 89
Choose the Variables menu and choose the systemProblemsACME variable. Click
OK.
Step 90
Step 91
Invalid branch of the Call Redirect step.
Step 92
Drag and drop an End step from the General folder onto the Terminate in the Invalid
Step 93
Drag and drop a Play Prompt step from the Media folder onto the Unsuccessful
Step 94
Right-click the PlayPrompt step and choose Properties.
Step 95
Lab Guide 93
Step 96
Choose the Variables menu and select the systemProblemsACME variable. Click
OK.
Step 97
Click OK to exit the properties pages.
Step 98
Unsuccessful branch of the Call Redirect step.
Step 99
Drag and drop an End step from the General folder onto the Unsuccessful branch of
Step 100
Highlight the CallRedirect step under the Menu, right-click it, and choose Copy.
Step 101
Highlight the Support folder under the Menu step, right-click it, and paste the Call
Redirect step onto it.
Step 102
Highlight the Operator folder under the Menu step, right-click it, and paste the Call
Redirect step onto it.
Step 103
Right-click the new Call Redirect under the Support folder and choose Properties.
Step 104
For the Extensions setting, change the variable to supportExtension.
Step 105
Step 106
Right-click the new Call Redirect under the Operator folder and choose Properties.
Step 107
For the Extensions setting, change the variable to operatorExtension.
Step 108
Press OK to exit the Properties pages.
Step 109
For the Timeout branch of the Menu step, drag and drop Goto from the General
folder.
Step 110
Right-click Goto and choose the Properties menu item. Choose the ACMEMENU
label from the drop-down menu on the Properties page.
Step 111
Click OK.
Step 112
For the Unsuccessful branch of the Menu step, drag and drop Goto from the General
folder.
Step 113
Right-click Goto and choose the Properties menu item. Choose ACMEMENU
label from the drop-down menu on the Properties page.
Step 114
Click OK.
Step 115
Drag and drop a Play Prompt step from the Media folder onto the Label step called
ACMECLOSED.
Step 116
Right-click the Play Prompt step and choose Properties.
Step 117
Select the variable named systemClosedACME from the prompt tab.
Step 118
Drag and drop a Terminate step from the Contact folder onto the Play Prompt under
the ACMECLOSED Label step.
Step 119
Drag and drop an End step from the General folder onto the Play Prompt under the
ACMECLOSED Label step.
Step 120
Validate the script by pulling down the Tools menu and choosing Validate .
Step 121
If validation succeeds, save by choosing the File>Save As menu.
Step 122
Save the file to the desktop as acmeaa.aef.
Step 123
Open the administrative web interface and choose the VoiceMail>Auto

Attendant menu.
Step 124
On the Auto Attendant page, click Add to add a new automated attendant.
Step 125
This will start a three-step process. In the first step, click Upload.
Step 126
This will open an Upload page. Click Browse to choose acmeaa.aef.
Step 127
Click Upload to upload the file.
Step 128
Fill in the application name with acmeaa.
Step 129
Click Next to go to the second step.
Step 130
For the systemClosedACME prompt, choose ACMEClosed.wav.
Step 131
For the welcomeGreetingACME prompt, choose ACMEWelcome.wav.
Step 132
For the salesSharedDNACME prompt, choose X201 (where X is the pod number).
Step 133
For the SupportExtensionACME prompt, choose X000 (where X is the pod number).
Step 134
For the menuACME prompt, choose ACMEMenu.wav.
Step 135
For the systemProblemsACME prompt, choose ACMEProblems.wav.
Step 136
For the systemBusyACME prompt, choose ACMEBusy.wav.
Step 137
For the systemSchedule choose systemschedule.
Step 138
For the operatorExtensionACME prompt, choose X001 (where X is the pod number).
Step 139
Click Next to move to the third step.
Step 140
Define a pilot number of X903 for this new automated attendant and leave the other
settings to defaults.
Step 141
Click Finish to complete the addition of a custom automated attendant.
Step 142
From the analog phone, call the number X903 and test all three options to verify
functionality.
You have completed this task when you verify that the custom automated attendant has been
tested and works.
Lab Guide 95
Task 15: Debugging Calls to Voice Mail or the Automated

Attendant
In this task, the debugging of calls from the CUE module will be viewed from the Cisco
CallManager Express point of view.
Activity Procedure
Step 1
From the console of the Cisco CallManager Express router, enter enable to enter
privileged EXEC mode.
Step 2
Enter the command debug ccsip calls.
Step 3
Place a call to voice mail. Notice the output.
Step 4
Place a call to the custom automated attendant and notice the output.
You have completed this task when you verify that the debug output can be viewed from the
Task 16: Syslog Messages and Trace for Troubleshooting

In this task, the syslog messages and trace output will be enabled and viewed from the CUE
module.
Activity Procedure
Step 1
Go to the CLI of the CUE module by entering the command #service-module

service-engine mod/port session.
Step 2
Enter enable to go to privileged EXEC mode.
Step 3
Enter the command show logging to view the current level of console logging.
Step 4
Step 5
From global configuration mode, enter the command log console errors and log
console warning to enable all syslog messages to the console.
Step 6
Enter exit to return to privileged EXEC mode.
Step 7
Enter the command show logging to verify which levels of logging are turned on.
Step 8
Attempt to check the voice mail on one of your IP Phones. Enter an incorrect PIN
three times in a row. Note the output.
Step 9
Hang up the call.
Step 10
Minimize the terminal window.
Step 11
Go to the GUI web interface as the administrator, choose the Administration>

Trace menu.
Step 12
Notice the default level of tracing that is enabled (if an AIM-CUE is used, all tracing
will be disabled).
Step 13
Disable all tracing if using the NM-CUE.
Step 14
Enter a checkmark enabling tracing for the root level Voicemail folder, which will
enable all tracing underneath it for voice mail.
Step 15
Click Apply to commit the tracing changes.
Step 16
Minimize the web interface.
Step 17
Go back to the CLI of the CUE module and enter the command clear trace.
Step 18
Enter the show trace command to view the tracing that is enabled.
Step 19
Call one of the IP Phones and leave a message.
Step 20
Enter the command show trace buffer to view the output. Note the details in the
output.
Step 21
Use the web interface to disable all tracing.
Step 22
In the ccn folder, check the box for all subfolders that start with Step .
Step 23
Click Apply to commit the tracing changes.
Step 24
Go back to the CLI of the CUE module and enter the command clear trace.
Step 25
Call the custom automated attendant at X903 (where X is the pod number) and
choose one of the options.
Step 26
Back at the CLI, use the show trace buffer command to view the output.
Verify that the syslog messages appear on the console.
Verify that the tracing output is generated and viewed.
Lab Guide 97
Lab 5-1 Answer Key: Configuring Cisco Unity Express

Example Configuration of the CallManager Express/Host Router

- - -
-
- -- -
- -- -
- --
-
-
-- -
-

-

-

-

--
--

-
- -

-
--

-

--
-
-
-
-
-
--
-
-
--

--

-
--

-

--

-- -
-

-
- --
-

-
---
-

-
- --- -- -- --
- ---
- -
- --
-

-

-
-

-

-

-

-

- -

-

-

-
Lab Guide 99
-

-

-
---

-
---

-
--- -
---
-

-

-

---
-- -- --

- --
- -

-
-- -- -
- - -- -
-
--- -

-- - -

--

-
-
-

-
-


- - -- -
--

-
--

-

-

-

-

-

-

-
-
-
Lab Guide 101

-- -
-
-
Example Configuration of the Unity Express module

--
--
-
- - -
--
--
-
-
-
-
-

-

-

--
-- --
-- -- -
-- -
-- -
- -
-
- ---

-

-
----
-
- ---

-- ----
-- -

--- ---

----
-
- ---

-- ----
-- -

--- ---

-
- -
----
- -
-
-

-
----
-

-
----
- -
----
---

---
--
---
--- -
--
---
-

----

-

----

-

----

Lab Guide 103

-

-
- --
-

-

-
- --
-

-
-
-
-

-
-

- -
- -

-
-

Lab 6-1: Configuring AutoQoS
Activity Objective
In this activity, you will set up AutoQoS. After completing this activity, you will be able to
meet these objectives:
Configure AutoQoS on Cisco IOS routers
Configure AutoQoS on the Catalyst 2950 workgroup switch
Use Cisco IOS monitoring commands and network connectivity tools (ping) to gather
network response time data
Visual Objective

AutoQos
VoIP over
Frame
Relay
Pod 1
PSTN
Pod 2
Pod 7
Pod 8
Pod 3-6
202-555-9000
...
207-555-9000
201-555-9000208-555-9000
DLCI = 100DLCI = 200DLCI = 700DLCI = 800

IPTX v2.08
Lab Guide 105
Required Resources
Lab topology configured for QoS
Student workgroup consisting of one user-controlled Cisco 3725 router and one usercontrolled Cisco 3550 workgroup switch
Classroom reference materials as follows:
QoS Student Guide
QoS Lab Guide
Student pod workstation with Telnet or console access to workstation pod devices
Command List
Command
Description
Displays the contents of the currently running configuration file
Enables CEF on the router
Enters interface configuration mode and the physical interface

identification
Configures the AutoQoS-VoIP feature on an interface
Displays the configurations created by the AutoQoS-VoIP feature

on a specific interface or all interfaces
Lists an information and status summary of an interface IP
Displays the administrative and operational status of all interfaces

or a specified interface
Clears the interface counters
-
-
Sets the encapsulation method used by the interface
Saves your entries in the configuration file
Enters interface configuration mode and the physical interface

identification
Configures AutoQoS for VoIP within a QoS domain
Displays the AutoQoS configuration that is applied
Saves your entries in the configuration file
Job Aid
The job aid available to help you complete the lab activity is your assigned workgroup pod
number provided by the instructor.
Task 1: Configuring AutoQoS on Cisco IOS Routers

In this task, you will enable the AutoQoS for VoIP feature on your workgroup router interfaces.
Activity Procedure
Step 1
Display and examine the running configuration of your CMERouterX.
Step 2
Enable CEF on your CMERouterX.
Step 3
Enable the AutoQoS for VoIP feature for traffic on the Sx/x interface. Do not
configure AutoQoS to trust DSCP markings.
Step 4
Display and examine the resulting AutoQoS configuration after enabling AutoQoS.
The following is an example output:
---

---

-- -

--
-- -
--
--
-
- -
-
-
-- -

- -
-- -

- -
--
- -
-- --

--
Lab Guide 107

--

--
-
--
--

- -
Step 5
Enter the show ip interface brief command on CMERouterX and ensure that the
Frame Relay subinterface is up.
You have completed this task when you verify that you have successfully enabled the AutoQoS
for VoIP feature on CMERouterX.
Task 2: Configuring AutoQoS on the Catalyst 3550 Switch

In this task, you will enable the AutoQoS for VoIP feature on your workgroup Catalyst 3550
switch.
Activity Procedure
Step 1
Display and examine the running configuration of your CMESwitchX switch.
Step 2
Enable the AutoQoS for VoIP feature for traffic on the Fa0/1 interface of
CMESwitchX and trust the CoS markings from the core switch.
Step 3
Display and examine the resulting AutoQoS configuration after enabling AutoQoS.

-
-
-
-
- - --
-
- - - - -
You have completed this task when you verify that you have successfully enabled the AutoQoS
for VoIP feature on CMESwitchX.
Job Aids
The job aids available to help you complete the lab activity are the tables on the following
pages.

Tag or
Seq #
Number
Function
Applied to
Settings
1 1000 DN Ephone 1 button 1 Dual

4 1010 DN Ephone 1 button 3
6 1400 Park N/A Timeout 10 seconds with 3
notifications
7 D3333 Non Dialable Intercom Ephone 1 button 4 Intercom to D4444

9 1500 Dialable Intercom Ephone 1 button 5 Intercom to 1550
11 1600 Page Ephone 1
13 1800 Page N/A Page to 1600 and 1700
groups, multicast to 239.1.1.1
14 9001.... MWI on N/A mwi on

15 9000.... MWI off N/A mwi off
16 1150 Group DN Ephone 1 button 6
Ephone 2 button 6
Applied to two ephones
Lab Guide 109

Tag
#
Destination
Pattern
Incoming
Called-number
Settings
1 1100 Lowest FXS

2 120.5550... Lowest FXO Forward all digits
3 120.5559... Lowest T1 port
port:23 Forward all digits
4 120.5559... Lowest T1 port
port:23 Direct inward dial
5 2... 10.101.0.2 codec g711ulaw, then g729br8

6 1300 application aa
7 1300 1300 10.11.0.1 application aa, dtmf-relay h458 19.. 10.10.0.10 dtmf-relay sip-notify, sipv2,
alphanumeric, g711ulaw, no vad

g711ulaw, no vad
Pod 1 Identity
Username
IPTX
First Name
Last Name
Ephone
CME Administrator
CUEAdmin
IPTXCust
CUE Administrator
CME Customer Administrator
FPrefect Ford Prefect Ephone 1 Import to Unity from CME

ADent Arthur Dent Ephone 2 Create in Unity
Pod 1 CUE Numbers

Number
Comments
1900 Voice mail pilot number

1901 Default automated
attendant
1902 Administrator TUI
9001.... MWI on
9000.... MWI off
1903 Custom automated
attendant
seattle.cisco.com Domain Name
Comments

Tag or
Seq #
Number
Function
Applied to
Settings

notifications

13 2800 Page N/A Page to 2600 and 2700 groups,
multicast to 239.1.1.1

Ephone 2 button 6

Tag
#
Destination
Pattern
Incoming
Called-number
Settings
1 2100 Lowest FXS

3 120.5559... Lowest T1 port
4 120.5559... Lowest T1 port


g711ulaw, no vad
Lab Guide 111
Pod 2 Identity
Username
IPTX
First Name
Last Name
Ephone
CME Administrator
CUEAdmin
IPTXCust
CUE Administrator
DAdams Douglas Adams Ephone 1 Import to Unity from CME

Random Dent RDent Ephone 2 Create in Unity
Pod 2 CUE Numbers

Number
Comments

attendant
9001.... MWI on
9000.... MWI off
attendant
boston.cisco.com Domain Name
Comments

Tag or
Seq #
Number
Function
Applied to
Settings

notifications


Ephone 2 button 6

Tag
#
Destination
Pattern
Incoming
Called-number
Settings
1 3100 Lowest FXS

3 120.5559... Lowest T1 port
4 120.5559... Lowest T1 port


g711ulaw, no vad
Lab Guide 113
Pod 3 Identity
Username
IPTX
First Name
Last Name
Ephone
CME Administrator
CUEAdmin
IPTXCust
CUE Administrator
HHurtenflurst Hig Hurtenflurst Ephone 1 Import to Unity from CME

HKavula Humma Kavula Ephone 2 Create in Unity
Pod 3 CUE Numbers

Number
Comments

attendant
9001.... MWI on
9000.... MWI off
attendant
atlanta.cisco.com Domain Name
Comments

Tag or
Seq #
Number
Function
Applied to
Settings

notifications


Ephone 2 button 6

Tag
#
Destination
Pattern
Incoming
Called-number
Settings
1 4100 Lowest FXS

3 120.5559... Lowest T1 port
4 120.5559... Lowest T1 port


g711ulaw, no vad
Lab Guide 115
Pod 4 Identity
Username
IPTX
First Name
Last Name
Ephone
CME Administrator
CUEAdmin
IPTXCust
CUE Administrator
CFitzmelton Cynthia Fitzmelton Ephone 1 Import to Unity from CME

OColluphid Oolon Colluphid Ephone 2 Create in Unity
Pod 4 CUE Numbers

Number
Comments

attendant
9001.... MWI on
9000.... MWI off
attendant
dallas.cisco.com Domain Name
Comments

Tag or
Seq #
Number
Function
Applied to
Settings

notifications


Ephone 2 button 6

Tag
#
Destination
Pattern
Incoming
Called-number
Settings
1 5100 Lowest FXS

3 120.5559... Lowest T1 port
4 120.5559... Lowest T1 port


g711ulaw, no vad
Lab Guide 117
Pod 5 Identity
Username
IPTX
First Name
Last Name
Ephone
CME Administrator
CUEAdmin
IPTXCust
CUE Administrator
RMckenna Rob McKenna Ephone 1 Import to Unity from CME

YVranx Yooden Vranx Ephone 2 Create in Unity
Pod 5 CUE Numbers

Number
Comments

attendant
9001.... MWI on
9000.... MWI off
attendant
portland.cisco.com Domain Name
Comments

Tag or
Seq #
Number
Function
Applied to
Settings

notifications


Ephone 2 button 6

Tag
#
Destination
Pattern
Incoming
Called-number
Settings
1 6100 Lowest FXS

3 120.5559... Lowest T1 port
4 120.5559... Lowest T1 port


g711ulaw, no vad
Lab Guide 119
Pod 6 Identity
Username
IPTX
First Name
Last Name
Ephone
CME Administrator
CUEAdmin
IPTXCust
CUE Administrator
ZBeetlebrox Zaphod Beetlebrox Ephone 1 Import to Unity from CME

MProsser Marvin Prosser Ephone 2 Create in Unity
Pod 6 CUE Numbers

Number
Comments

attendant
9001.... MWI on
9000.... MWI off
attendant
raleigh.cisco.com Domain Name
Comments

Tag or
Seq #
Number
Function
Applied to
Settings

notifications


Ephone 2 button 6

Tag
#
Destination
Pattern
Incoming
Called-number
Settings
1 7100 Lowest FXS

3 120.5559... Lowest T1 port
4 120.5559... Lowest T1 port


g711ulaw, no vad
Lab Guide 121
Pod 7 Identity
Username
IPTX
First Name
Last Name
Ephone
CME Administrator
CUEAdmin
IPTXCust
CUE Administrator
HFrootmig Hurling Frootmig Ephone 1 Import to Unity from CME

MQuordlepleen Max Quordlepleen Ephone 2 Create in Unity
Pod 7 CUE Numbers

Number
Comments

attendant
9001.... MWI on
9000.... MWI off
attendant
phoenix.cisco.com Domain Name
Comments

Tag or
Seq #
Number
Function
Applied to
Settings

notifications


Ephone 2 button 6

Tag
#
Destination
Pattern
Incoming
Called-number
Settings
1 8100 Lowest FXS

3 120.5559... Lowest T1 port
4 120.5559... Lowest T1 port


g711ulaw, no vad
Lab Guide 123
Pod 8 Identity
Username
IPTX
First Name
Last Name
Ephone
CME Administrator
CUEAdmin
IPTXCust
CUE Administrator
QRontok Questular Rontak Ephone 1 Import to Unity from CME

FPrak Frank Prak Ephone 2 Create in Unity
Pod 8 CUE Numbers

Number
Comments

attendant
9001.... MWI on
9000.... MWI off
attendant
miami.cisco.com Domain Name
Comments

KnowledgeNet IP Telephony Express (IPTX) 2.0 Student Guide PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KnowledgeNet IP Telephony Express (IPTX) 2.0 Student Guide PDF

Uploaded by

Copyright:

Available Formats

IPTX

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

Introducing Cisco CallManager Express 1-1

Describing Key Features of Cisco CallManager Express and CUE 1-3

Explaining Differences Between Traditional Telephony and VoIP 1-21

Understanding VoIP Challenges and Solutions 1-45

Configuring Cisco CallManager Express 2-1

Understanding Cisco CallManager Express Features and Functionality 2-3

Configuring Cisco CallManager Express Network Parameters 2-37

Understanding the IP Phone Registration Process 2-81

Defining Ephone-dn and Ephone 2-97

Describing Cisco CallManager Express Files 2-127

Understanding Initial Phone Setup 2-137

ii IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.

Understanding Analog and Digital Voice Interfaces 3-3

Configuring Analog and Digital Voice Interfaces 3-15

Configuring Dial Peers 3-45

Understanding Call Setup and Digit Manipulation 3-59

2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 iii

Understanding Class of Restriction 3-77

Describing H.450.x Protocols 3-91

Configuring Additional Cisco CallManager Express Features 4-1

Configuring Cisco CallManager Express GUI Features 4-3

Configuring Phone Features 4-27

iv IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.

Example: Sample RingList.xml 4-80

Understanding Call Center Features 4-93

Defining TAPI Support for Cisco CallManager Express 4-131

Describing Network Management for Cisco CallManager Express 4-143

Understanding Cisco Unity Express Features and Functionality 3

Describing Cisco Unity Express Installation and Initialization 15

2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 v

Restoring the Factory Defaults 35

Configuring Cisco Unity Express Auto Attendant 75

Configuring Cisco Unity Express Users and Groups 147

Configuring Cisco Unity Express Voice Mail 189

Troubleshooting Cisco Unity Express 253

vi IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.

System-Level Troubleshooting 288

Understanding Quality of Service 6-3

Describing the Differentiated Services Model 6-29

Understanding IP QoS Mechanisms 6-41

Introducing Modular QoS CLI 6-53

2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 vii

Example: Configuring MQC 6-55

Implementing AutoQoS 6-75

Case Study: QoS Mechanisms 6-101

Describing Deployment Scenarios and Design Considerations 7-3

Cisco CallManager Express in SIP Network 7-8

Deploying Voice Mail with Cisco CallManager Express 7-27

2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 ix

x IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.

IP Telephony Express (IPTX) v2.0 provides an understanding of Cisco CallManager Express

Learner Skills and Knowledge

Prerequisite Learner Skills

2005 Cisco Systems, Inc. All rights reserved.

Course Goal and Objectives

2 IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.

Course Flow Diagram

This topic covers the suggested flow of the course materials.

Course Flow Diagram

2005 Cisco Systems, Inc. All rights reserved.