IPTX v2.0

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
1 3 4
Course Introduction 1
Overview Learner Skills and Knowledge 1 Course Goal and Objectives 2 Course Flow Diagram Additional References Cisco Glossary of Terms 4
Introducing Cisco CallManager Express 1-1

Overview Module Objectives 1-1 1-1 1-3 1-3
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
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
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 Overview Objectives Requirements of Voice in an IP Internetwork 1-46 Challenges in VoIP Bandwidth Requirements in VoIP 1-56 Summary
Understanding VoIP Challenges and Solutions 1-45
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 Overview Module Objectives
Configuring Cisco CallManager Express 2-1

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 Overview Objectives Voice VLANs Configuring Voice VLANs 2-41 DHCP Service Setup DHCP Relay Server Network Time Protocol Transcoding Summary
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
Configuring Cisco CallManager Express Network Parameters 2-37
Understanding the IP Phone Registration Process 2-81

Overview Objectives Files IP Phone Information Download and Registration 2-89 Summary Overview Objectives Ephone-dn Ephone Type of Ephone-dns Number of Ephone-dns 2-124 Summary
Defining Ephone-dn and Ephone 2-97
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 Express TAPI Integration 2-134 Additional Files Summary
2-132 2-135 2-136 2-137 2-137 2-139 2-159
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
2-172 2-173
ii IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
References Module Self-Check Module Self-Check Answer Key 2-179
2-173 2-174
Volume 2 Configuring PSTN Interfaces and Voice Dial Peers 3-1

Overview Module Objectives 3-1 3-1 3-3 3-3 3-4 3-5
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
3-13 3-14 3-15 3-16
Configuring Analog and Digital Voice Interfaces 3-15

Overview Objectives Foreign Exchange Station Port Configuration 3-17 Configuration Parameters 3-18 Foreign Exchange Office Port Configuration 3-20 Configuration Parameters 3-20 Ear and Mouth Port Configuration 3-22 Configuration Parameters 3-22 Timers and Timing Configuration Parameters 3-24 Digital Voice Port Configuration 3-26 Configuration Parameters 3-26 Channel Associated Signaling Configuration 3-29 Common-Channel Signaling: BRI 3-31 Common-Channel Signaling: PRI 3-38 Summary 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 Overview Objectives What Are Call Legs? Example End-to-End Calls Matching Inbound Dial Peers 3-63 Matching Outbound Dial Peers 3-65
3-24
Configuring Dial Peers 3-45
3-43 3-45 3-45 3-46 3-50 3-51 3-52 3-55 3-57 3-58 3-59 3-59 3-60 3-60 3-61
Understanding Call Setup and Digit Manipulation 3-59
Copyright
2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 iii
Example Digit Collection and Consumption 3-67 Example What Is Digit Manipulation? 3-70 Example PLAR Summary
3-66 3-68 3-72 3-74 3-76 3-77 3-77 3-78
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 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 Module Self-Check Answer Key 3-122 Overview Module Objectives
3-90 3-91 3-91
Describing H.450.x Protocols 3-91
3-106 3-116 3-117 3-117 3-118
Configuring Additional Cisco CallManager Express Features 4-1

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
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 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
Configuring Phone Features 4-27
iv IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
Example: Sample RingList.xml 4-80 Timer Settings Music on Hold Summary
4-81 4-82 4-92 4-93 4-93 4-94 4-108 4-129 4-131 4-131
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 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 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 Module Self-Check Answer Key 4-164
Defining TAPI Support for Cisco CallManager Express 4-131
4-142 4-143 4-143 4-146 4-150 4-151 4-154 4-154 4-155 4-155 4-156
Describing Network Management for Cisco CallManager Express 4-143
Volume 3 Configuring Cisco Unity Express Automated Attendant and Voice Mail 1
Overview Module Objectives 1 2 3 3 4 6 7 10 13 15 15 18
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
2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 v
Copyright
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
36 43
73 75 75 82 84 85
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 Overview Objectives User Interface User Configuration Group Configuration Group Mailboxes Summary
99 100 109 136 144 146 147 147 148 155 166 180 188 189 189 202 214 222 243 251 253 253 254
Configuring Cisco Unity Express Users and Groups 147
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
256
vi IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.
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

Understanding Quality of Service 6-3
Overview Module Objectives 6-1 6-1 6-3 6-3 6-5 6-9 6-11 6-15 6-17 6-20
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-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
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 Overview Objectives QoS Mechanisms Classification Marking Trust Boundaries Congestion Management 6-48 Traffic Shaping Compression Link Fragmentation and Interleaving 6-51 Summary Overview Objectives Introducing Modular QoS CLI 6-54 Modular QoS CLI Components 6-55
Understanding IP QoS Mechanisms 6-41
Introducing Modular QoS CLI 6-53
Copyright
2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 vii
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
6-56
6-60 6-62
6-70 6-73 6-75 6-75 6-76 6-83 6-85
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 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 Module Self-Check Answer Key 6-118 Overview Module Objectives
6-92 6-99 6-101 6-101 6-101 6-102 6-102
Case Study: QoS Mechanisms 6-101
6-113 6-114
Designing Cisco CallManager Express and Cisco Unity Express Networks 7-1
7-1 7-1 7-3 7-3
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.
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
7-26 7-27 7-27
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 Module Self-Check Answer Key 7-42
7-38 7-39 7-39 7-40
Copyright
2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 ix
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 Basic Internetworking Skills PSTN Operations and Technologies PBX Essentials IPTX
2005 Cisco Systems, Inc. All rights reserved.
IPTX v2.0 7
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 Configuring Cisco CallManager Express Configuring PSTN Interfaces and Voice Dial Peers Configuring Additional Cisco CallManager Express Features 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
A M
Introducing Cisco CallManager Express
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.0 11
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 Phone PIX Firewall (right and left)
PBX (small)
IP Phone
PC
Si Si
Network Cloud, White Network Cloud, Standard Color
Phone 2
Laptop
Multilayer Switch, with Text, without Text, and Subdued
ATM Switch
Cisco CallManager Express Workgroup
PBX/ Switch
Voice-Enabled Communications Server
Generic Softswitch
Web Browser
Voice-Enabled ATM Switch
Server
IPTX v2.0 12
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.
What Is Cisco CallManager Express?

Cisco CallManager Express
Trunks
PSTN
WAN
Call processing for small-to medium-sized deployments VoIP integrated solution Up to 240 IP Phones IOS software!based solution
2005 Cisco Systems, Inc. All rights reserved. IPTX v2.0 1-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.
What Is Cisco CallManager Express? (Cont.)

Integrated services routers Multiservice access routers
3800
2800
3700
2600XM
1700
IPTX v2.0 1-3
Cisco CallManager Express enables Cisco s 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.0 1-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.0 1-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.0 1-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 software !based call control agent.
Register
Register
Phones register with Cisco CallManager Express and are then under its control.
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.
How Do Cisco CallManager Express and Cisco Unity Express Work? (Cont.)
Cisco CallManager Express is an IOS software !based call control agent.
Phone A places call to Phone B
SCCP RTP
SCCP
Phone APhone B
RTP
Call Control is centralized on Cisco CallManager Express.

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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7
Phone A picks up the handset and dials the number of Phone B. The dialed digits are sent through SCCP to Cisco CallManager Express. Cisco CallManager Express knows the location of Phone B (because of the registration) and its status (busy, on hook, off hook). 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. Phone B is answered. Cisco CallManager Express informs each IP Phone about the settings of the other Phone and instructs both Phones to construct RTP connections. The IP Phones construct two one-way RTP connections for the voice to travel across, one for Phone A s voice to travel to B and one for Phone B s voice to travel to A. The call takes place. Phone B hangs up, and an SCCP message is sent to Cisco CallManager Express. Cisco CallManager Express sends an SCCP message to Phone A telling it that the call has been disconnected.
Step 8 Step 9 Step 10
Connection(s) to PSTN
Analog Digital
PSTN
IPTX v2.0 1-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 4 Cisco CallManager Express uses SIP to set up a call to the CUE module.
CUE Cisco CallManager Express
SIP
Step 5 The call is set up, and voice flows between the CUE and the PSTN gateway function of the router.
PSTN
Step 1 A call arrives from the PSTN that maps through DID to the IP Phone whose extension is 1000.
PSTN Gateway Function
Step 2 An SCCP message causes the IP Phone to ring.
1000
Step 3 No answer occurs within the set time value.

IPTX v2.0 1-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:
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. Cisco CallManager Express sends an SCCP message to the IP Phone and causes the IP Phone to ring. 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. A session initiation protocol (SIP) message is sent to the CUE module s IP address to set up a voice connection using one of the virtual voice ports. 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.
Step 4 Step 5
PSTN
H.323 H.323
H.323
WAN
Cisco CallManager Express Cluster
SIP
PSTN
PSTN Gateway and IP-to-IP Gateway Functionality
WAN
IPTX v2.0 1-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.0 1-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) Feature License FL-CCME-72 (up to 72 users) Feature License FL-CCME-96 (up to 96 users) Feature License FL-CCME-120 (up to 120 users) Feature License FL-CCME-144 (up to 144 users) Feature License FL-CCME-168 (up to 168 users) Feature License FL-CCME-192 (up to 192 users) Feature License FL-CCME-240 (up to 240 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.
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 2811-CCME/K9 ! 2811-V router, DSP resources for 16 calls, 36 Cisco CallManager Express seats, and IOS SP Services 2821-CCME/K9 ! 2821-V router, DSP resources for 32 calls, 48 Cisco CallManager Express seats, and IOS SP Services 2851-CCME/K9 ! 2851-V router, DSP resources for 48 calls, 96 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 Express seats, and IOS SP Services
Release Compatibility
Feature Personal Mailboxes General Delivery Mailboxes NM-CUE: Hours of Storage NM-CUE-EC: Hours of Storage NM-CUE: # of Ports NM-CUE-EC: # of Ports 12 Mailboxes 12 5 100 100 8 16 25 Mailboxes 25 10 100 100 8 16 50 Mailboxes 50 15 100 100 8 16 100 Mailboxes 100 20 100 100 8 16
IPTX v2.0 1-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 AIM-CUE, 512 MB: Hours of Storage AIM-CUE, 1GB: Hours of Storage AIM-CUE, 512 MB, 2600XM and 2691: # of Ports AIM-CUE, 512 MB, 2800, 3700, and 3800: # of Ports AIM-CUE, 1GB, 2600XM and 2691: # of Ports AIM-CUE, 1GB, 2800, 3700 and 3800 : # of Ports 12 Mailboxes 8 14 4 6 4 6 25 Mailboxes 8 14 4 6 4 6 50 Mailboxes 100 Mailboxes 8 14 4* 6* 4* 6 Not Supported Not Supported Not Supported Not Supported Not Supported Not Supported
*Not recommended because of port blocking and mailbox size limitations

IPTX v2.0 1-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.0 1-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.0 1-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 customer s 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.0 1-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 On cradle On hook/open circuit No Off cradle Off hook/closed circuit Yes Circuit Current Flow
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.0 1-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.0 1-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.0 1-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.0 1-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 1. Procedure Description
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. 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. Encode the value into 8-bit digital form. (Optional) Compress the samples to reduce bandwidth. PBX output is a continuous analog voice waveform. T1 digital voice is a snapshot of the wave, encoded in ones and zeros. Although not essential to the conversion of analog signals to digital, signal compression is widely used to reduce bandwidth.
2.
3.
4.
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 step!compression!to 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.0 1-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.0 1-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.0 1-10
Linear sampling of analog signals causes small-amplitude signals to have a higher noise-tosignal ratio!and therefore poorer quality !than 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.0 1-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 ! G.726 rate: 32 kbps = (2 x 4 kHz) x 4 bits/sample ! G.726 rate: 24 kbps = (2 x 4 kHz) x 3 bits/sample ! G.726 rate: 16 kbps = (2 x 4 kHz) x 2 bits/sample
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 G.726 rate: 32 kbps = (2 * 4 kHz) * 4 bits per sample G.726 rate: 24 kbps = (2 * 4 kHz) * 3 bits per sample G.726 rate: 16 kbps = (2 * 4 kHz) * 2 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
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.0 1-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
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.0 1-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.
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
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.
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.
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.

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.0 1-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 m ning, 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
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.

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
To provide telephony users the same or close to the same level 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.0 1-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.0 1-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.0 1-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 overhead 6 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 overhead 2 bytes for control (or type), and 2 bytes for CRC 1 byte for flag, 1 byte for address,
Frame Relay Forum 12 (FRF.12): Carries 6 bytes of overhead 2 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.0 1-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.0 1-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.0 1-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.0 1-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 RTP RTP 10.10.0.100:1692210.10.0.101:18355 10001001
SCCP Signaling
IPTX v2.0 1-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 other s 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 Step 2
An IP Phone with extension 1000 (Phone 1000) goes off hook for the 1000 extension. 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.) 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. Phone 1001 rings and is answered. An SCCP message is sent to Cisco CallManager Express that says that extension 1001 has been answered. 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. The two IP Phones set up RTP connections to each other, and the voice conversation can flow. Cisco CallManager Express ceases to be involved in the call until the call is transferred or terminated.
Step 4
Step 5 Step 6 Step 7 Step 8
PSTN Calls with Cisco CallManager Express As the PSTN Gateway

SCCP signaling is used between the IP Phone and Cisco CallManager Express. Appropriate signaling is used between Cisco CallManager Express and the PSTN. RTP is used to carry traffic between the IP Phone and the Cisco CallManager Express router. Cisco CallManager Express acts as an MTP. Voice is sent to the PSTN.
PSTN Voice
Analog or Digital Trunk(s) Cisco CallManager Express
Voice over IP UDP 16,384 ! 32,768
Signaling TCP 2000
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:
An IP Phone with extension 1000 goes off hook for the 1000 extension. 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). 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.) 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). 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.
Step 4
Step 5
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. The voice gateway acts as an MTP. Voice is sent to the PSTN from the voice gateway.
PSTN Voice
Analog or Digital Trunk(s) Cisco CallManager Express
PSTN Gateway
H.323 SCCP Signaling
RTP
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 Step 2
An IP Phone with extension 1000 goes off hook for the 1000 extension. 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). 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.) A match is found to the PSTN destination. 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. On the PSTN gateway trunk, either analog or digital is used to connect to the PSTN. 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. The Cisco CallManager Express router ceases its involvement until the call is transferred or terminated.
Step 3
Step 4 Step 5
Intersite Calls
PSTN IP WAN
SCCP H.323 or SIP RTP SCCP
1000
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.
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.
An IP Phone with extension 1000 goes off hook. 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). 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.) A match is found to the dialed number, 2000, across the WAN link. 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. 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. 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. 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 4 Step 5
Step 6
Step 7
Step 8
Step 9
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.
Note
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.
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.0 1-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.
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.0 1-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.
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.0 1-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.
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.0 1-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 CallManager Express. 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 IP Per-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 D) none of the above 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 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 Q2) A, B, C
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
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 This lesson introduces you to the key features and functionality of Cisco CallManager Express.
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.0 2-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.0 2-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 external source internal versus external German, French, Italian, and Spanish MOH live feed
Distinctive ringing
International language support Directory services using XML
System speed dial option via XML service 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 T1 and E1 Frame Relay, ATM, Multilink PPP (MLP), and digital subscriber line Digital trunk support WAN link support (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
Tip
H.323, analog dual tone multifrequency (DTMF)
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

Supported Platforms
This topic describes the supported platforms and telephones of Cisco CallManager Express.
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 3845
IPTX v2.0 2-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 36 48 72 96 144 192 168 240
License
FL-CCME-SMALL FL-CCME-36 FL-CCME-MEDIUM FL-CCME-72 FL-CCME-96 FL-CCME-144 1 FL-CCME-192 FL-CCME-168 FL-CCME-240
2610XM, 2611XM, 2620XM, 2621XM, 2811 2650XM, 2651XM, 2821 2691 2851 3725 3745 3825 3845
IPTX v2.0 2-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.0 2-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.0 2-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 Minimum Recommended Flash/RAM
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
Supported Telephones
7902G7905G7910G+SW7912G
7920
7935, 7936
7940G7960G
7970G
7971G-GE
7940 + 7914, 7960 + 7914
ATA 186, 188

IPTX v2.0 2-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.0 2-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 G.711 and G.729 codecs Call-monitoring mode Single line XML application protocol SCCP support Power over Ethernet
IPTX v2.0 2-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
G.711 and G.729 codecs Call-monitoring mode Single line 802.1q support 10/100 Ethernet switch port SCCP support Four programmable keys
No XML application support
IPTX v2.0 2-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
Four programmable keys Single line Lighted hold key Call-monitoring function G.711 and G.729 codecs SCCP support 802.1q support 10/100 Ethernet switch port Power over Ethernet
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 G.711 and G.729 codecs SCCP support
IPTX v2.0 2-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 G.711 and G.729 codecs 360-degree coverage Power brick required No XML application SCCP support External microphone connection (7936 only)
IPTX v2.0 2-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 G.711 and G.729 codecs 10/100 Ethernet switch port Power over Ethernet XML application support SCCP support
IPTX v2.0 2-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 G.711 and G.729 codecs 10/100 Ethernet switch port Power over Ethernet XML application support SCCP support
IPTX v2.0 2-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 G.711 and G.729 codecs Color touch screen 10/100 Ethernet switch port Power over Ethernet External power required for full screen brightness XML application support SCCP support Stereo jack sockets
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 G.711 and G.729 codecs Color touch screen Gigabit Ethernet switch port Power over Ethernet External power required for full screen brightness XML application support SCCP support Stereo jack sockets
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.0 2-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.0 2-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.0 2-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
V
SCCP
H.323
SCCP
IPTX v2.0 2-22
Cisco CallManager Express can use both H.323 and SCCP to control IP Phones, analog phones, and faxes.
Supported Protocols and Integration Options

SCCP Client Control Protocol
Cisco-proprietary protocol Call control protocol Lightweight protocol Low memory requirements Low complexity Low CPU requirements
This topic describes the supported protocols and integration options of Cisco CallManager Express.
IPTX v2.0 2-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.0 2-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.0 2-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
V
H.323 Cisco CallManager Express
ATA
H.323
IPTX v2.0 2-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 Register
1000 2095551000
Register extension number, E.164 number, or both
Gatekeeper
2000 3095552000
Register extension number, E.164 number, or both
IPTX v2.0 2-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.0 2-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 Cisco CallManager Express PSTN SIP WAN
V
H.323
SIP Cisco CallManager Express
SIP
IPTX v2.0 2-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.0 2-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 Express capable. 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.0 2-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
Cisco CallManager Express does not support TAPI v2.1 #Cisco 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.0 2-33
Lesson 2
Configuring Cisco CallManager Express Network Parameters

Overview
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 This lesson describes the Cisco CallManager Express network parameters and the steps to configure these parameters.
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.0 2-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 percent of 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 171.68.249.100
Recommended
IP Phone + PC on same switch ports 171.68.249.100 10.1.1.1
171.68.249.101
Public IP addresses IP Phone + PC on separate switch ports 171.68.249.101 171.68.249.100
IP Phone uses private network IP Phone + PC on separate switch ports 10.1.1.1 171.68.249.100
Public IP addresses
IP Phone uses private network

IPTX v2.0 2-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.0 2-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 VLAN a voice VLAN it 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.
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

- - - - - - - -- - - - - -
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
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.0 2-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.0 2-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 non $IP 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
A DHCP scope can be configured on the Cisco CallManager Express router. The scope should define the following: Range of available IP addresses Subnet mask Default gateway Address of the TFTP server DNS server(s)
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.
IPTX v2.0 2-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.
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
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 router#s 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

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.0 2-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 Server
DHCP Broadcast
The router!s default behavior is to not forward broadcasts; the DHCP request times out.
This issue can be addressed with a DHCP relay server.
IPTX v2.0 2-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
DHCP Broadcast Unicast or Directed 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.
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 router or another device must 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.0 2-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 DHCP Server
fa0/0
WAN
10.200.0.1
- - --
IPTX v2.0 2-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.
Network Time Protocol
This topic describes how to configure NTP.
Network Time Protocol

The IP Phone gets its displayed time from the Cisco CallManagerExpress router. The time of the Cisco CallManager Express router !s 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.0 2-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
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 ADT Atlantic Daylight Time, as UTC EST Eastern Standard Time, as UTC EDT Eastern Daylight Time, as UTC CST Central Standard Time, as UTC CDT Central Daylight Time, as UTC 4 hours 3 hours 5 hours 4 hours 6 hours 5 hours
ET Eastern Time, either as EST or EDT, depending on place and time of year
CT Central Time, either as CST or CDT, depending on place and time of year
MT Mountain Time, either as MST or MDT, depending on place and time of year MST Mountain Standard Time, as UTC MDT Mountain Daylight Time, as UTC PST Pacific Standard Time, as UTC PDT Pacific Daylight Time, as UTC AKST Alaska Standard Time, as UTC AKDT Alaska Daylight Time, as UTC HST Hawaiian Standard Time, as UTC 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. 7 hours 6 hours 8 hours 7 hours 9 hours 8 hours 10 hours
PT Pacific Time, either as PST or PDT, depending on place and time of year
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. Cisco CallManagerExpress router time synchronizes with the NTP server.
- - - - - - -
IPTX v2.0 2-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
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.0 2-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
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.0 2-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.0 2-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 Cisco CallManager Express
- --
Specifies the address and priority where the DSP farm will register
Enables SCCP and the associated processes

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.0 2-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 G.711Capable Only G.711 DSP Farm G.729 10.1.1.1 WAN
- -- - - - - - - - ---- -
IPTX v2.0 2-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 DSP Farm G.729
10.1.1.1
- -- - - - - - - - ---- -
IPTX v2.0 2-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.0 2-31
Setting up TI-5510$based 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.0 2-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.
----
Specifies the maximum number of sessions supported by the DSP farm

-
-- -
Associates SCCP to the DSP farm profile
IPTX v2.0 2-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.
- --
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

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.
-- -
Associates a DSP farm profile with a Cisco CallManager Express group and assigns the registered name
-
Sets the number of keepalive retries
IPTX v2.0 2-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 10.1.1.1 WAN DSP Farm G.729
G.711Capable Only G.711
OR
NM-HD-1V or NM-HD-2V or NM-HDV2 G.711Capable Only G.711 10.1.1.1 DSP Farm WAN G.729
IPTX v2.0 2-36
This is an example of a router with a TI-5510 $based 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.0 2-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

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

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
Stream-ID:2 mtp:1 10.1.1.1 17502 Local:2000 START 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: codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:0
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 2 3 4 5 6 2 2 2 2 2 2 IDLE -1 IDLE -1 START -1 START -1 IDLE -1 IDLE -1 0 0 0 0 3 3 G711Ulaw64k /20ms G711Ulaw64k /20ms MoH (DN=3 , CH=1) FE=TRUE G729 /20ms MoH (DN=3 , CH=1) FE=FALSE G711Ulaw64k /20ms G711Ulaw64k /20ms 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 Stream-ID:1 mtp:1 10.10.10.3 18404 Local:2000 START usage:Ip-Ip codec:G711Ulaw64k duration:20 vad:0 peer Stream-ID:2
Stream-ID:2 mtp:1 10.10.10.3 17502 Local:2000 START 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.0 2-41
Lesson 3
Understanding the IP Phone Registration Process

Overview
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 This lesson details the process of registering IP Phones with the Cisco CallManager Express router and the files that must be downloaded.
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.0 2-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
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
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*
<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.0 2-5
SEP
XML
*AAAABBBBCCCC = the MAC address
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> <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> <loadInformation8 model="IP Phone 7940">P00303020214</loadInformation8> <loadInformation7 model="IP Phone 7960">P00303020214</loadInformation7> <loadInformation20000 model="IP Phone 7905"></loadInformation20000> <loadInformation30008 model="IP Phone 7902"></loadInformation30008> <loadInformation30002 model="IP Phone 7920"></loadInformation30002> <loadInformation30019 model="IP Phone 7936"></loadInformation30019> <loadInformation30007 model="IP Phone 7912"></loadInformation30007> </Default>
Default
XML
Notice that there is no ATA or 7914.

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.
IP Phone Information
This topic describes how Cisco CallManager Express identifies IP Phones.
IP Phone Information
There is no 7914 in the XMLDefault.cnf.xml file.
Default
<loadInformation6 model="IP Phone 7910">P00403020214</loadInformation6> <loadInformation124 model="Addon 7914"></loadInformation124> <loadInformation9 model="IP Phone 7935"></loadInformation9> <loadInformation8 model="IP Phone 7940">P00303020214</loadInformation8> <loadInformation7 model="IP Phone 7960">P00303020214</loadInformation7> <loadInformation20000 model="IP Phone 7905"></loadInformation20000> <loadInformation30008 model="IP Phone 7902"></loadInformation30008> <loadInformation30002 model="IP Phone 7920"></loadInformation30002> <loadInformation30019 model="IP Phone 7936"></loadInformation30019> <loadInformation30007 model="IP Phone 7912"></loadInformation30007> <loadInformation30040 model= !ATA"></loadInformation30040>
XML
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.
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 FLP
Step 2 -Phone returns FLP to switch because of a completed circuit
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
Needed Power
CDP
IPTX v2.0 2-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 Step 2
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. 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. The switch applies power to the line. The link should go up within 5 seconds. The powered device (IP Phone) boots up. 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
Needed Power
CDP
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 Step 2 Step 3 Step 4 Step 5 Step 6
The switch constantly applies DC current to all ports that may have a powered device attached to them. The powered device is connected and will have a resistance of 25 ohms if it is PoEcompliant. The switch detects that the device is a PoE-capable device. Power is applied to the link in low power mode, which is 6.3 watts. The powered device (the IP Phone) boots up. 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.
Voice VLAN Step 8 -The IP Phone initializes the IP stack and sends a DHCPDISCOVER broadcast message.
CDP
DHCPDISCOVER
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.0 2-10
Step 7 Step 8
Through CDP, the switch informs the IP Phone of its voice VLAN (auxiliary VLAN). The IP Phone initializes the IP stack and sends out a DHCPDISCOVER broadcast requesting an IP address on the voice VLAN scope.
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.
Note
Step 9
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 AAAABBBBCCCC is the MAC address). If the alias is found, the IP Phone will register.
SEP
TFTP Request for the SEP000F2470AA32.cnf.xml file SEP000F2470AA32.cnf.xml file
XML
If no SEP XML file is found, go to Step 14.

Step 10 Step 11
The Phone receives the DHCPOFFER and applies the values obtained. 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.0 2-12
Step 12 Step 13
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. The IP Phone reboots after the firmware is downloaded.
Phone Bootup: Unknown IP Phone

Cisco CallManager Express is the TFTP server.
Default
Unknown IP Address with MAC 000F.2470.AA32
Step 14 -If no SEP XML file is found, the IP Phone downloads the XMLDefault.cnf.xmlfile from TFTP server. TFTP Request for the XMLDefault.cnf.xml file XMLDefault.cnf.xml file
XML
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.0 2-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. 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.
Step 15
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.0 2-14
Lesson 4
Defining Ephone-dn and Ephone

Overview
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 This lesson defines ephone-dn (Ethernet phone directory number) and ephone (Ethernet phone) and describes the different types of 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.0 2-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
DN1 and DN2

Ephone-dn
One phone extension on a dual-line ephone-dn for ephone-dns that need call waiting, consultative transfer, and conferencing
DN1 DN1
Ephone-dn
IPTX v2.0 2-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.
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 1001
One line or channel
Assigns a primary extension number to an ephone-dn
IPTX v2.0 2-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 2 DN Button 4 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
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 device!s defined MAC address with the ephone
IPTX v2.0 2-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.0 2-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 Phone s 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
000F.2470.F8F8
ephone-dn 7: one virtual port
--
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
Button 1
1008 1008 1009 1009
1008 on Line 1 1009 on Line 2
Button 2
Button 1
1010 1010 1011 1011
Two physical phones Four dual-line ephone-dns defined Two ephones defined
Button 6
IPTX v2.0 2-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.0 2-11
This example shows the configuration of the multiple ephone-dns shown in the previous figure.
Multiple Ephone-dns
Button 1
1008 1008 1009 1009
Button 2
Button 1
1010 1010 1011 1011
Two physical phones Four dual-line ephone-dns defined Two ephones defined
Button 6
IPTX v2.0 2-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.0 2-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 Overlay ephone-dn on an ephone
1001
1002 1002
1004 and 1005
1006
1006
1003 1003
1003 1003
1007
IPTX v2.0 2-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.0 2-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 1002 1002
Two channels
The ephone-dn creates one virtual voice port.
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.
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
The ephone-dn creates one virtual voice port. 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.0 2-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
1006 1006

Button 2
1100
Button 1
1007 1007
One ephone-dn is applied on two different ephones. Only one Phone can use the ephone-dn at a time. 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.
Button 2
1100
IPTX v2.0 2-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. The configuration for this follows.
Example: Configuration for Shared Ephone-dn
- -- --
IPTX v2.0 2-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
1003 1003 1003 1003
preference 0 no huntstop preference 1 huntstop
Button 2
Ephone 4
Button 2
1004 1004
preference 0 no huntstop
Ephone 5
Button 2
1004 1004
preference 1 huntstop
IPTX v2.0 2-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.0 2-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) ephone-dn 10 (channel 2) ephone-dn 11 (channel 1) ephone-dn 11 (channel 2) ephone-dn 12 (channel 1) ephone-dn 12 (channel 2)

huntstop Commands
1020 DN
Preference 0 no huntstop no huntstop channel no huntstop no huntstop channel huntstop no huntstop channel
Ephone-dn 10 Channel 1 Channel 2 Ephone-dn 11 Channel 1 Channel 2 Ephone-dn 12 Channel 1 Channel 2 Ephone-dn 13 Channel 1 Channel 2
Call arrives at first ephone-dn Busy Busy Busy Busy Busy
1020 DN
Preference 1
1020 DN
Preference 2
1020 DN
Preference 3
Same directory number on the ephone-dns
Ring no answer timeout of 10 seconds set globally
IPTX v2.0 2-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.

1020 DN
no huntstop
huntstop channel Commands

Ephone-dn 10
huntstop channel
Call arrives at first ephone-dn
Preference 0
Channel 1 Channel 2
Busy
1020 DN
no huntstop
Ephone-dn 11 Channel 1 Channel 2
Preference 1
huntstop channel huntstop no huntstop channel
1020 DN
Ephone-dn 12 Channel 1 Channel 2 Ephone-dn 13 Channel 1 Channel 2
Busy
Preference 2
Busy
1020 DN
Preference 3
Ring no answer timeout of 10 seconds set globally
IPTX v2.0 2-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 1003 on Line Button 2 Ephone 3
Button 1
1003 1003 1003 1003
preference 0 no huntstop preference 1 huntstop
Button 2
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.
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. The configuration for this follows.
Example: Configuration for Two Ephone-dns, One Number, Same Ephone
- - --
IPTX v2.0 2-25
This example shows the configuration for two ephone-dns with one number on the same ephone.
Multiple Ephone-dns on Different Ephones

1004 on Line Button 2 Ephone 4
Button 2
1004
preference 0 no huntstop
1004 on Line Button 2

Ephone 4 is used first if available.
Ephone 5
Button 2
1004
preference 1 huntstop
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.
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. The configuration for this follows.
Example: Configuration for Two Ephone-dns, One Number, Different Ephones

- - -- --
IPTX v2.0 2-27
This example shows the configuration for two ephone-dns that have one number on different ephones.
Overlay Ephone-dn
Button 4
1101 Preference 0 no huntstop 1101 Preference 1 huntstop
Button 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
Button 4
1101 Preference 0 no huntstop 1101 Preference 1 huntstop
Button 4
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 line#ten 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
- -- --
IPTX v2.0 2-29
This shows the configuration for an overlay ephone-dn.
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.0 2-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.)

DN DN DN

DN DN DN
DN DN
DN DN
IPTX v2.0 2-31
Attempts to create an 11th ephone-dn will fail.

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
Lesson 5
Describing Cisco CallManager Express Files

Overview
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 This lesson describes Cisco CallManager Express files.
Cisco CallManager Express Files

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

TFTP or FTP server
GUI Files Firmware Music on Hold IOS
FLASH
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
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.
Bundled Cisco CallManager Express Files
IPTX v2.0 2-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.
Bundled Cisco CallManager Express Files (Cont.)

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 ! CP7905040000SCCP40701A.sbin ! CP7912040000SCCP40701A.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.0 2-4
The extracted cme-123-11XL.zip file yields:
* All files are specific to the version of Cisco CallManagerExpress.

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.0 2-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.0 2-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 admin_user.html admin_user.js CiscoLogo.gif
The extracted cme-gui-123-11XL.tar yields:
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.0 2-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.
This topic identifies telephony service provider (TSP) files for Telephony Application Programming Interface (TAPI) integration.
TAPI Integration
Cisco CallManager Express 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.0 2-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. Use the xml.template file to allow or restrict the GUI functions that are available to an optional customer administrator.
xml.template
IPTX v2.0 2-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.0 2-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
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.0 2-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
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.0 2-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)
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
-
7920 Firmware
7920
Filenames are case sensitive.
7910 Firmware
7910G+SW
IPTX v2.0 2-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 7905 Selects the firmware load file for the 7905G Phone 7910 Selects the IP Phone firmware load file for the 7910G+SW Phone 7912 Selects the firmware load file for the 7912G 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
- ---
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
- 2005 Cisco Systems, Inc. All rights reserved. IPTX v2.0 2-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 the load 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 10!65535 seconds If three successive keepalives missed, device must register again
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.0 2-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 company s internal Voice over IP (VoIP) H.323 network!the 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.0 2-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 don%t 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.0 2-13
In a partially automated setup, you don t 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.0 2-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.0 2-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.0 2-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 process !the 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.0 2-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.0 2-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.0 2-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
Dutch
Norwegian
Swedish
French
Portuguese
English
German
Russian
Japanese
IPTX v2.0 2-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.0 2-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.0 2-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
Hard reboot Phone firmware changes User locale changes Network locale changes URL parameter changes DHCP and TFTP invoked More time-consuming than restart
restart Command
Soft reboot Phone button changes Phone line changes Speed dial number changes System message changes DHCP and TFTP not invoked
IPTX v2.0 2-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.0 2-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.0 2-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 Phone%s firmware installation. Verify that the locale is correct. Verify Phone setup. Review the configuration.
IPTX v2.0 2-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 Phone s 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 CallManager Express router. Verify that the default gateway is correct.
IPTX v2.0 2-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.0 2-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
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.0 2-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.0 2-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.0 2-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.0 2-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.
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.
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
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 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 non IP 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 D) none of the above 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 D) none of the above 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 D) none of the above 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 D) none of the above 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 D) none of the above 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 D) none of the above
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 Cisco s 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
Local-Loop Connections
This topic describes the parts of a traditional telephony local-loop connection between a telephone subscriber and the telephone company.
Local-Loop Connections
IPTX v2.0 3-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 wires one 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
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 device !s 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
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
Tie-Line
E&M
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
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

Channel Associated Signaling Systems
This topic describes channel associated signaling (CAS) and its uses with T1 transmission.
IPTX v2.0 3-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
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.0 3-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 8000 samples per second 1 byte per sample Partial E1 may be available Signaling is carried out-of-band
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.0 3-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 BRI 2B+D
Carrier
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
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.0 3-13
Lesson 2
Configuring Analog and Digital Voice Interfaces

Overview
The connections to analog devices the PSTN and WAN links between sites may 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.0 3-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
- - - -
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.0 3-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.0 3-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.0 3-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
- -
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.0 3-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
- - - - - -
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.0 3-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
Basic T1/E1 Controller Configuration (Cont.)
Configures the line code for a T1 line
Configures the line code for an E1 line
IPTX v2.0 3-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 ami b8zs hdb3 Description Alternate mark inversion; used for T1 configurations Binary 8-zero substitution; used for T1 PRI configurations 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.
- -
Configures the framing for a T1 line
Configures the framing for an E1 line
IPTX v2.0 3-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 sf esf crc4 or no-crc4 Description Super Frame; used for some older T1 configurations Extended Superframe; used for T1 PRI configurations 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.
- - -- -- - - - - - -- - -
Creates the voice ports of the T1 or E1 and the signaling that is used
Sets the source of the clocking

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
- - -- - - - -- - -
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.0 3-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.0 3-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)
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 basic-5ess basic-dms100 basic-ni basic-qsig basic-net3 none Note Description AT&T basic rate switches (United States) NT DMS-100 (North America) National ISDN-1 (North America) PINX (PBX) switches with QSIG signaling per Q.931 NET3 switch type for United Kingdom, Europe, Asia, and Australia No switch defined 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.0 3-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 spid-number Description 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. (Optional) Seven-digit local directory number that is assigned by the ISDN service provider.
ldn
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.0 3-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.0 3-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)
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 primary-4ess primary-5ess primary-dms100 primary-ni primary-ntt primary-net5 primary-qsig None Description AT&T Primary-4ESS switches (United States) AT&T Primary-5ESS switches (United States) NT DMS-100 switches (North America) National ISDN switch type NTT ISDN PRI switches (Japan) European and Australian ISDN PRI switches QSIG signaling per Q.931 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 t1 e1 Description Specifies the controller interface for North America and Japan 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.0 3-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 timeslots range Description 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 slot/port unit 23 15 Description The slot/port of the channelized controller The unit number of the channelized controller on a Cisco 4000 or AS5000 Series router A T1 interface that designates channelized DS0s 0 to 22 as the B channels, and DS0 23 as the D channel 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.0 3-24
The table describes the commands found in the figure. PRI Configuration Commands
Command isdn switch-type primary-ni controller t1 0/1 pri-group timeslots 1 !24 Description Selects a switch type of National ISDN Selects the T1 controller 0/1 Establishes the interface port to function as PRI with 24 timeslots (including D channel) designated to operate at a speed of 64 kbps Selects ESF framing, a T1 configuration feature Selects line code B8ZS for T1 Specifies the T1 line as the clock source for the router Identifies the D channel on serial interface 0/0
framing esf linecode b8zs clock source line interface serial 0/0:23
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 1 31 rather than 1 24, 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.0 3-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.
Lesson 3
Configuring Dial Peers

Overview
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 lesson describes voice dial peers, digit manipulation, the matching of calls to dial peers, and COR.
What Is a Dial Peer?
This topic describes dial peers and their applications.
What Is a Dial Peer?

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.0 3-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.0 3-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.0 3-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 3 Use the destination !pattern command in the dial peer to configure the telephone number. 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.0 3-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 4 Use the destination-pattern command to configure a range of numbers reachable by the remote router or gateway. 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.0 3-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 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.
5551234 Matches one telephone number exactly, 5551234.
What Is the Default Dial Peer?

This topic describes the default dial peer.
Default Dial Peer 0
IPTX v2.0 3-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.
Lesson 4
Understanding Call Setup and Digit Manipulation

Overview
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 This lesson describes call flows, digit manipulation, digit collection, and digit consumption as they relate to inbound and outbound dial peers.
What Are Call Legs?
This topic describes call legs and their relationship to other components.
Dial-Peer Call Legs
IPTX v2.0 3-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.0 3-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)
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 Called number Dialed Number Identification Service (DNIS) Calling number automatic number identification (ANI) Description This is the call-destination dial string, and it is derived from the ISDN setup message or the CAS DNIS. 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.0 3-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 -pattern command under the dial peer
1 The router or gateway uses the destination to determine how to route the call. 2 The
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.0 3-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.0 3-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 5551234 555 555 5551234 555T 5551234 Destination Pattern "" 5551234 ". 5551234 Dialed Digits Collected
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
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 number #without the 9#before 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.0 3-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 port in that order to match inbound dial peers.
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.
Lesson 5
Understanding Class of Restriction

Overview
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 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.
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.0 3-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.0 3-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 No COR No COR Incoming COR applied Incoming COR applied is a superset of outgoing COR Incoming COR applied not a superset of outgoing COR
Result Call succeeds Call succeeds
Reason COR is not applied The no (null) incoming COR condition has highest COR priority Incoming COR list is a superset of the no (null) outgoing COR list Incoming COR list is a superset of outgoing COR list TncomingCOR list is not a superset of outgoing COR list
IPTX v2.0 3-5
No COR Outgoing COR applied No COR
Call succeeds
Outgoing COR applied Outgoing COR applied
Call succeeds
Call cannot be completed
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.0 3-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
IPTX v2.0 3-7
Step 1
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 CMERouter(config-dp-cor)#name1800 CMERouter(config-dp-cor)#name1900
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
IPTX v2.0 3-8
Step 2
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 CMERouter(config)# dial-peer cor listcall1800 CMERouter(config-dp-corlist) member1800 CMERouter(config)# dial-peer cor listcall1900 CMERouter(config-dp-corlist) member1900
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
IPTX v2.0 3-9
Step 3
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
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 Ext 1000
Ephone-dn 2 Executive Ext 2000

IPTX v2.0 3-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.
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.

- - - - - - - - - - - -
Step 2 ! Define the COR lists and members.

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

-
IPTX v2.0 3-15
Step 3
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.
Note

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

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 protocols H.323, session initiation protocol (SIP), Media Gateway Control Protocol (MGCP), H.248, and so on and 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.2 H.450.3 H.450.12 call transfers call forwarding detection of H.450.x series protocols on a remote device
Call Transfer Using H.450.2

H.450.2 Transfer
B A B A A A B A B A
This topic describes the H.450.2 protocol, which is used for call transfers.
A calls B. B wants to transfer to C and places consultation call. B and C talk. 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. A#s call to C is successful. A and C disconnect calls to B.
IPTX v2.0 3-4
C B B C C C C
H.450.2 protocol defines two ways for a transfer to take place: Transfer without consultation The call is transferred without knowing if the destination to which the call is transferred will answer. Transfer with consultation The 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:
A calls B. B transfers to C with a consultation call to C. B talks with C, B commits a transfer, B requests, then receives an H.450.2 consultation-ID from C. B sends a transfer request to A with consultation-ID. A calls C, including the consultation-ID in the call setup message. A!s 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.
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 optimization The 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 settings The settings, like codec, VAD, and others, can change from the original destination to the transferred destination. Scalable Because 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.0 3-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)
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 non%ephone-dn destinations
IPTX v2.0 3-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 . 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 "Calls 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-system full-consult
- -
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-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 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 non%ephone-dn destinations that calls can be transferred to
IPTX v2.0 3-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 non "ephone-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

H.450.3 Forwarding
B A B A B A B A B A C C C C
This topic describes call forwarding using the H.450.3 protocol.
A calls B. B wants to forward A #s call to C. B sends forward request to A. A calls C. A#s call to C is successful. A disconnects call attempt to B.
IPTX v2.0 3-10
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:
A calls B. B has been configured to forward all calls to C. B sends an H.450.3 forward request to A. A calls C. C answers and is connected to A. A!s call to C succeeds; B is no longer involved.
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.0 3-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 optimization The 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 settings The settings, like codec, VAD, and others, can change from the initial destination to the forwarded destination. Scalable Because 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.0 3-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
H.450.3 Commands
- 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 non%ephone-dn destinations
IPTX v2.0 3-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. pattern"Digits 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: -
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.0 3-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 non "ephone-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.
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.0 3-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.0 3-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.0 3-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: CallManager Cisco CallManager does not support the H.450.x protocols. VoIP-to-VoIP A VoIP-to-VoIP hairpin can allow for transfers and forwards when not all devices support H.450.x protocols. Mixed-version environment Issues in a mixed Cisco CME 3.0 and 3.1 or greater environment present issues because of a mismatch in supported protocols. Upgrading Upgrading 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.0 3-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.
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.0 3-22
VoIP-to-VoIP Hairpin Commands

- Example: - - Example: - -
Enables VoIP-to-VoIP call connections. Use the no form of the command to disable VoIP-to-VoIP connections. 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
Step 1 -Call from 1000 to 2000

2000 2000
Non-H.450 Gateway IP WAN Step 3 % Call is hairpinned and connected to 3000

3000 3000
CallManager CallManager Express Express B B
Step 2 -Transfer or forward to 3000
- -
In this example, the following steps are happening in the call flow:
A call from an IP Phone on Cisco CallManager Express router A is placed to an IP Phone on Cisco CallManager Express router B. 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). 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.0 3-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.0 3-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.
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.
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
For additional information, refer to these resources: 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
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) 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 Differences Between Analog and Digital Voice Interfaces) A) SF B) CRC4 C) ESF D) ESC4 Q6) In E1 framing, how many channels are available for voice or data? (Source: Identifying Differences Between Analog and Digital Voice Interfaces) 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 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 Q2) A, D, F
Module 4
Configuring Additional Cisco CallManager Express Features

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
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 This lesson defines how to set up, configure, and use the Cisco CallManager Express GUI and the three different access levels.
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.0 4-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.0 4-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.0 4-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 user s 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.0 4-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.
Cisco CallManager Express GUI 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

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

Customer administrators and Phone users cannot bring about any changes with this command.
Enters telephony-service configuration mode

-
-- - -- - - -
Sets a username and password for the GUI system administrator
IPTX v2.0 4-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:
- -
- -- - -- - - -
Example: Defines a username and password for a system administrator. The default username is Admin. There is no default password. 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.0 4-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. (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.
Example:
Example:
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.0 4-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.
Configuring Administrative User Classes

To configure a customer administrator to have a subset of the system administrator!s level of access, two steps must be taken:
Create and load a custom XML configuration file Define the customer administrator credentials
IPTX v2.0 4-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 administrator s 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.
Configuring Administrative User Classes (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 the Cisco CallManager Express router.
IPTX v2.0 4-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 1. Action Notes
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. Modify the XML file. Leave only "Hide# or "Show,# whichever action is desired, deleting the other word and any brackets or pipe symbols. The name of the file can be anything as long as it is a known value.
2.
3.
Save the file with the desired name. Example:
-
4. Upload the XML file to flash memory on the Cisco CallManager Express router. You can use TFTP or FTP to move the new XML file to flash memory.
-
5. Load the template from flash to RAM on the Cisco CallManager Express router. 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
- - - - - - -- - - -- --
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.
Configuring Administrative User Classes: Demonstration (Cont.)

Step 2 # File edited for desired changes to access
- - - - - - - - - - -
IPTX v2.0 4-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 - Example: Description Used to load and parse an XML file in router flash memory to customize a Cisco CallManager Express GUI for a customer administrator.
- -
Configuring Administrative User Classes: Demonstration Results

Default system administrator access
Modified XML template applied

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.0 4-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.
Configuring the Customer Administrator Credentials (Cont.)

To add a customer administrator:
Add a username Select Customer from Admin User Type Set the password
IPTX v2.0 4-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.
Configuring the Customer Administrator Credentials (Cont.)

-
- - -- -
Sets a username and password for the customer administrator GUI
IPTX v2.0 4-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.0 4-18
Configuring Phone User Classes (Cont.)
Select the Phone of the user, then set credentials on the phone.
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.0 4-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 Example:
Description
- - - -
- - -- --
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.
Lesson 2
Configuring Phone Features

Overview
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 This lesson defines additional features that can be installed and configured to enhance a basic Cisco CallManager Express installation.
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.0 4-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.0 4-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.0 4-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. 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.
--- - -
Example:
- --- -
- -
Specifies the type of call transfer for an individual IP Phone extension number
- -
IPTX v2.0 4-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. blind :Transfers calls without consultation using a single phone line. consult :Transfers calls with consultation using a second phone line if available.
- -
Example:
- -
Allows transfer of telephone calls from Cisco IP Phones to other phones
--
IPTX v2.0 4-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 non IP 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. 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.
- - Example: - -
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.0 4-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 user!s 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.0 4-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.0 4-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
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: 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
- -Example:
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.0 4-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.0 4-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)

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.0 4-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.0 4-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.0 4-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) 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 attendant "s phone, for example.
- - -
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.0 4-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.0 4-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

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. dn-tag: The unique sequence number that identifies the ephone-dn for which the description should be in effect. 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:
- -
Example:
- -
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.0 4-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. 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
- -- --
Example:
- -- -- - -Example:
- -
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.0 4-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.
Softkey Customization
This topic describes the customization of the softkey layout.
Softkey Customization
Softkeys are along the bottom of the screen on 7905G, 7912G, 7940G, 7960G, and 7970G Phones
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.0 4-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.
$ Endcall: Ends the current 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. $ Endcall: Ends the current call. $ 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.0 4-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.)
- - -
Configures an ephone template for the softkey template during the connected state
Configures an ephone template for the softkey template during the idle state
IPTX v2.0 4-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.)
- -
Configures an ephone template for the softkey template during the seized state
IPTX v2.0 4-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.0 4-28
This figure shows the default softkeys during the connected state.
Example: SoftkeyCustomization (Cont.)
Result after ephone template is applied to the ephone
- -
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.0 4-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.0 4-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

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.0 4-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
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. $ 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.

Example:
Conferencing
This topic describes conferencing and the commands required for configuration.
Conferencing
Step 1 The conference is started, and the RTP streams are sent to the Cisco CallManager Express router.
Step 3 Cisco CallManagerExpress sends the mixed audio result out to the earpieces of all attendees of the conference.
Step 2 Cisco CallManager Express mixes the voices of all three conference attendees using software conferencing and may invoke transcoding resources if required.
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
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
- --- -
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.0 4-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.0 4-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 !to!IP 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.0 4-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 receptionist !s 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.0 4-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 - - ] Example: Description Creates an intercom by programming a pair of extensions (ephone-dns) to automatically call and answer each other. 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.0 4-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.0 4-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.0 4-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.0 4-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. 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). 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 of unicast:
Example of multicast:
-
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

IPTX v2.0 4-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.0 4-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.
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) 8000 samples per second 8 bits per sample mu-law compression Maximum ring size Minimum ring size 16080 samples 240 samples
Number of samples in the ring must be evenly divisible by 240 Ring should start and end at the zero crossing
Use an ASCII editor to edit the RingList.xml file. Use TFTP to download the new PCM files and XML file to the flash of the Cisco CallManager Express router. 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.0 4-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.0 4-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
Flash:
MyMohfile.wav
Phone on Hold
Unicastor Multicast
- -
Phone on Hold
IPTX v2.0 4-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.0 4-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 port four-wire, immediate start, auto-cut-through Unicastor Multicast

E&M Port 1/1/1
- -
Phone on Hold
IPTX v2.0 4-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

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.
Configuring MOH from a Live Source
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.0 4-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. Commands for Configuring MOH from a Live Source
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.
Configuring MOH from a Live Source (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

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. Commands for Configuring MOH from a Live Source
Command Description Enters dial-peer configuration mode
Example:

Example: Associates the dial peer with a voice port
- -
Example: Specifies either the prefix or the full E.164 telephone number to be used for a dial peer
Configuring MOH from a Live Source (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
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.
Commands for Configuring MOH from a Live Source

Command Description Enters ephone-dn configuration mode. 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.
]
Example:
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.0 4-58
Lesson 3
Understanding Call Center Features

Overview
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 This lesson defines the basic automatic call distribution (ACD) features of Cisco CallManager Express and how to configure those features.
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.0 4-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)
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.0 4-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.0 4-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
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 Second choice if busy or no answer: go to next Third choice if busy or no answer: go to next Fourth choice if busy or no answer: go to destination defined by final command
1005
1002
Top Down Selection

1003 Final
IPTX v2.0 4-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.0 4-8
This figure shows the configuration for the example that was described on the previous page.
Example: Peer Ephone Hunt Group

1002
The previous call went to extension number 1002. The call will go to extension number 1001 since the last went to extension number 1002.
1001
1000
1003
Round Robin Selection

Final
If hops setting is exceeded.

IPTX v2.0 4-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.0 4-10
This figure shows the configuration for the example that was described on the previous page.
Example: Longest Idle Ephone Hunt Group

1000
2nd 1st 3rd
1000 is active.
1001
1001 has been idle for 1:30 minutes.
1002
1002 has been idle for 4:46 minutes.
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.
1003
1003 has been idle for 39 seconds.
IPTX v2.0 4-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.0 4-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.
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.0 4-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.0 4-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
- - -
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.0 4-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.0 4-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

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 router "s 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 hours $could 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.
Configuring the B-ACD Automated 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
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
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
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.0 4-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
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.0 4-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.0 4-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

- ---
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.0 4-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 en_bacd_welcome.au en_bacd_options_menu.au Message !Thank you for calling. " Includes a 2-second pause after the message. !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. !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. !You have entered an invalid option. Please try again. " Includes a 1second pause after the message. !Please enter the extension number you want to reach. " Includes a 5second pause after the message. !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_disconnect.au
en_bacd_invalidoption.au en_bacd_enter_dest.au en_bacd_allagentsbusy.au
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 party s 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.
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.0 4-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.0 4-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.
Configuring Monitoring and Reporting on the B-ACD Service (Cont.)
- - --- - - --- - -
Displays ephone hunt group configuration, current status, and statistics information
- --- - - - - - - -- - - -- -- - -- -- ---
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:
- - - - - -- - - -- -- - -- -- --- - - -- - -- - - -- - --
- - -- - -- --- - - - - - - - -- - - -- - -- - - - - - --- - - - - - - - -- - - -- - -- - - -
Configuring Monitoring and Reporting on 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

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 sent because it is less than the configured 3 hours. At 21:00, statistics have been collected for 2:40 hours; no statistics have been sent because it is less than the configured 3 hours. 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.
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.0 4-35
Lesson 4
Defining TAPI Support for Cisco CallManager Express

Overview
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 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.
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
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 book "style 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.0 4-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 Cisco CallManager Express router Select the timeout value in seconds Select if using a headset Select to enable trace for troubleshooting
When this configuration dialog box appears, the user must enter information into the required fields.
Step 1 Step 2 Step 3 Step 4 Step 5
Enter the username and password of the Cisco IP Phone user. Enter the IP address and port number of the Cisco CallManager Express router. The Synchronous Message Timeout response from the Cisco CallManager Express router may be set (the default is 3 seconds). If you are using a headset, check the Using Headset check box. 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

TSP Configuration on the Router
This topic describes how to view the Cisco IOS TSP configuration on the router.
- -
Displays ephones that have an active TAPI integration

- - - -- - - -- - - -- --
IPTX v2.0 4-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

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
This topic describes how to modify the Cisco IOS TSP configuration on the PC.
IPTX v2.0 4-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.) Click the Advanced tab in the Phone and Modem Options dialog box. Cisco IOS Telephony Service Provider ! is in the Providers list. Choose Cisco IOS Telephony Service Provider and click Configure. Make the changes that are desired in the Cisco IOS Telephony Service Provider dialog box. 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 TSP#such as Remote Access Connection Manager #are 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
To remove the Cisco IOS TSP from the PC, follow these steps:
Click the Phone and Modem option from the PC Control Panel. ( Note: The name of this option may vary, depending on the operating system.) Click the Advanced tab in the Phone and Modem Options dialog box. Cisco IOS Telephony Service Provider ! is in the Providers list. Choose Cisco IOS Telephony Service Provider and click Remove.
Cisco CallManager Express and Microsoft CRM Integration

Cisco CallManagerExpress and Microsoft CRM Integration
This topic describes the integration of Cisco CallManager Express and the Microsoft Business Solution Customer Relationship Management (Microsoft CRM) product.
IPTX v2.0 4-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.
Cisco CallManagerExpress and Microsoft 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

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.
Cisco CallManagerExpress and Microsoft 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.0 4-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.0 4-12
Lesson 5
Describing Network Management for Cisco CallManager Express

Overview
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 This lesson defines network management features that can be used to monitor, maintain, and configure the Cisco CallManager Express system.
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.0 4-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.0 4-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.0 4-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.
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.0 4-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
- --
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.0 4-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.
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.
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.
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.0 4-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.0 4-1
Reference
For additional information, refer to these resources: Cisco CallManager Express 3.2: Overview . http://cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_chapter09186 a00802d2476.html. Cisco CallManager Express 3.2: Configuring Cisco CME PhoneFeatures . http://cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_chapter09186 a00802d241a.html. Cisco CallManager Express 3.2: Configuring an Attendant for Primary Call Coverage . http://cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_chapter09186 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 . http://cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_chapter09186 a00802d2476.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) 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 Cisco CallManager Express router. 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 B) (config-telephony-service)# 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 B) (config-telephony-service)# 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
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 This lesson describes the features and functions of Cisco Unity Express (CUE).
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
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 features such as replying to, forwarding, and saving messages; message tagging for privacy or urgency; alternate greetings; pausing, fast forwarding, and rewinding; and envelope information are 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
Auto Attendant Features
This topic describes the features of CUE Auto Attendant.
Auto Attendant Features

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
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.0 5-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 software!like CLI for administering, debugging, and troubleshooting
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 software$like 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.0 5-7
The figure illustrates the web-based GUI management features.
Network Administration
Site A Site C
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.
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.0 5-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.0 5-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 Cisco CallManager Express.
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.0 5-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.0 5-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.0 5-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 ! cue-vm-25-license.2.1.1.cme.pkg ! cue-vm-50-license.2.1.1.cme.pkg ! cue-vm-100-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.0 5-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.0 5-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.0 5-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.
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 x86!style 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.0 5-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
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.
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
Intel x86!style 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.0 5-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 0 must use slot 1 instead
IPTX v2.0 5-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
Intel x86!style platform installed with Linux 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 ! Back-to-back Ethernet ! Back-to-back console
IPTX v2.0 5-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

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

IOS Router and Cisco CallManager Express Prerequisite Configuration
IOS Router
This topic describes the prerequisite configuration necessary on the Cisco CallManager Express router and the router that hosts the CUE module.
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.0 5-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
IOS Router and Cisco CallManager Express Prerequisite Configuration (Cont.)

After the hardware installation, the CUE module shows up as an "interface Service-Engine x/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 - - -- - -
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.
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

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

-- - - - - - -- - - - - -
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.
Initial Configuration
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.
Initial Configuration
- -- - - - - -- - - -- -- - -- - -
- -
Starts the configuration of the CUE module
IPTX v2.0 5-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.

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.0 5-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
The NTP server is defined and the continent and are country set.

- - - - - - - - - - -- - - - - - - - - - - - - - - - - -
Select time zone
Confirm time zone

IPTX v2.0 5-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.
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

- - - - - -- - - - - - - - - - - -
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
- - - - - - - - -
To verify which versions of the software packages were installed, use the show software version command.
- - -
Displays the licensed capacity of the CUE module

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

- - -- - -- -- -
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.
CUE Initialization Wizard
This topic describes CUE initialization wizard and the steps required to complete it.
CUE Initialization Wizard

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.0 5-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.
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.
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.
CUE Initialization Wizard 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.
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.
CUE Initialization Wizard Step 2: Import 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
Click here to create mailboxes for all these users.
IPTX v2.0 5-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 Cisco CallManager Express.
CUE Initialization Wizard Step 3: System Defaults
IPTX v2.0 5-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.
CUE Initialization Wizard Step 4: Call Handling
IPTX v2.0 5-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 user"s 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 user "s 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.
CUE Initialization Wizard Step 5: Commit
IPTX v2.0 5-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.
CUE Initialization Wizard Final Screen: Committed Information
IPTX v2.0 5-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
-- - - - - - -- -- -- --
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 clean command 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 upgrade command 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 clean command was used. Reload the CUE module.
IPTX v2.0 5-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.
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.0 5-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.
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. ! Configuration System and application settings ! Data Application data and voice mails
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.
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.0 5-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. The CUE module will restart and the initial configuration will be invoked. 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
IPTX v2.0 5-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.)

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

IP From the CLI of CUE, enter thesoftware install upgrade command to specify the package to install. Only the files necessary for the upgrade will need to be rewritten on the hard drive. 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
IPTX v2.0 5-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.0 5-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

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. 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.
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
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.
- -- -- -- -- Boot loader - - -
Interrupt the load process within 10 seconds to get to the boot loader prompt by entering ***.
prompt is where install instructions are given.

IPTX v2.0 5-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 is ServiceEngine 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.

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

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

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.

- -- - - - - - -- - - - - - -
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.
Select 1 Install software and define the name of the package to install, the URL of the FTP server, and login credentials.

IP Select the language or languages to install. The installer overwrites the storage with the CUE image. The CUE module will reboot itself and start the initial configuration. 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 cue-vm-en_US-lang-pack.2.1.1.pkg
The license can be installed consecutively with or independently of software.

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.

- - - - -
Selects English to be installed on the CUE installation
Up to two languages may be selected.
IPTX v2.0 5-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.

- - - - -
- -
Done selecting languages
- - --
IPTX v2.0 5-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.0 5-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.
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.0 5-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.
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.
Lesson 3
Configuring Cisco Unity 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.
The automated attendant functionality of CUE plays messages that callers hear when they dial the company s 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.0 5-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

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 !
555.1212
PSTN
555.6789
555.2333
Three Different Numbers with an Application Assigned to Each

IPTX v2.0 5-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.0 5-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 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) 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
Prompt Parameters
Record Prompts
IPTX v2.0 5-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.

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
Work Area Debug and Message Window

IPTX v2.0 5-9
Variable Window
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.
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.0 5-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: $ Float A Float variable consists of decimal numbers. Java Class Name # java.lang.Float Variable Input Format (examples): $ 3.14159 $ 2E-12 $ -100 !\t", !\r", !\0", !\n", !\f", !\\", !\" !\uXXXX" can be used to represent any character using the character hexadecimal Unicode number XXXX
Integer An Integer variable consists of whole numbers from 2147483648 to 2147483647 inclusive. Java Class Name # java.lang.Integer Variable Input Format (examples): $ 234556789 $0 $ String A String variable consists of a set of Unicode characters from !\u0000" to !\uffff" inclusive. Java Class Name # java.lang.String Variable Input Format (examples): $ $u !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", u"C:\\WINNT\\win.ini", and so forth. This format supports the same escape sequences or Unicode characters described for the Character type. 23
Date The Date variable contains date information. Java Class Name # java.util.Date Variable Input Format (examples): $ 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 Variable Input Format (examples): $ 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 $ 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 #23
Long The Long variable is an expanded Integer variable. Java Class Name$java.lang.Long Variable Input Format (examples; same as Integer variable): $ 234556789 $0 $ #23
CUE AA Editor: General Steps

Step
Annotate Call Subflow Day of Week Decrement Delay End Goto If Increment Label On Exception Goto Set Start Switch Time of Day Is Holiday Business Hours
Description
Insert comments in the script (similar to C /* */ comments). Invoke a subflow. Cause script execution to branch depending on current day of week. Decrease the value of an integer variable by 1. Pause the execution of script for specified number of seconds. Designate end of script and free all allocated resources. Cause script execution to branch to specifiedLabel step. Cause script execution to branch based on evaluation of a Boolean expression. Increase the value of an integer variable by 1. Insert a label into a script as a target forGoto step. Catch an exception/problem during script execution and handle it. Change the value of a variable (assignment operator). Indicate start of the script. Cause script execution to branch to one of a number of cases. Cause script execution to branch depending on current time of day. Check if it is a holiday. Check if within defined business hours.
IPTX v2.0 5-12
On Exception Clear Remove an exception set by previousOnExceptionGoto step.
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 day s 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
User Prompt Get User Info Create Conditional Prompt Create Container Prompt Create Generated Prompt
Description
Access user attributes. Create one of two prompts based on the evaluation of a Boolean expression. Combine multiple prompts into a larger prompt. Create prompt phrases from intermediate variables, e.g. number, currency, etc.
IPTX v2.0 5-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 caller s 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 Accept Get Contact Info Set Contact Info Terminate Call Contact Call Redirect Get Call Contact Info
Description
Answer a call. Extract information from a contact and store it in script variables. Modify the context information associated with a contact. Disconnect a call. Redirect a call to another extension. Access call-specific information and store it in script variables.
IPTX v2.0 5-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
Explicit Confirmation Get Digit String Implicit Confirmation Menu Name To User Play Prompt
Description
Confirm an explicit response to a prompts, DTMF 1 for yes and 2 for no. Collect DTMF digits in response to a prompt. Confirm an action without asking a question. Provide a menu from which caller can choose a series of options. Collect DTMF and try to match it to a person "s name. Play a specified prompt to the caller.
IPTX v2.0 5-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.0 5-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.0 5-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 Year"s Day every year, the following automatically happens:

Current year"s holiday list becomes previous year "s list Upcoming year "s list becomes current year "s list Oldest year"s list is deleted (e.g., holidays for 2003 are automatically deleted on January 1, 2005)
IPTX v2.0 5-18
The administrator can delete entries from a previous year s list but cannot add or modify that list in any other way. The system automatically deletes the previous year s 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.0 5-19
To add a holiday, choose the Holiday Settings object from the Voice Mail drop-down menu, then choose the Add link.
IPTX v2.0 5-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

- - - - - - - - - - - - - -- --
IPTX v2.0 5-21
Use the command calendar holiday to configure holidays.
Example: Holiday List CLI
Displays configured holidays

- - - - - -- --
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.
There can be up to four different schedules per system. One example schedule ships with the system ($systemschedule%).
! 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).
! 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.0 5-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.0 5-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.0 5-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.0 5-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

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.0 5-28
This example shows a business hour schedule named !summerSchedule."
Business Hours Schedule show Command
- -
Displays the configured business hours schedule(s)

- - --- - - -
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.0 5-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.0 5-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.0 5-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
- -- - - - - - - -
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
Create Date: Sun Oct 31 06:57:47 PST 2004 Last Modified Date: Sun Oct 31 12:11:32 PST 2004 Length in Bytes: 21990
Name:
voicebrowser.aef
Name:
aa.aef
Name:
promptmgmt.aef
Name:
checkaltgreet.aef
Name:
aasimple
Prompts
Five prompts exist by default.

This figure shows the five system default prompts.
Custom Prompts
The bottom four prompts are custom prompts.

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
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.0 5-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 Length in Bytes: 8676
Scripts and Prompts Configuration (Cont.)
- -
Shows the name, date, and size of the prompts that are installed
- - - - - -
IPTX v2.0 5-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 Length in Bytes: 15860
Name:
UserPrompt_03082004061012.wav
Last Modified Date: Fri Mar 08 06:10:12 PST 2002 Length in Bytes: 14298
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.0 5-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
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
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

- - ---- - -- -- ---
--- ---- - ---
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: Script: Enabled:
ciscomwiapplication ciscomwiapplication 0 setmwi.aef yes
Description: ID number:
Maximum number of sessions: 8 strMWI_OFF_DN: 2997 strMWI_ON_DN: 2998 CallControlGroupID: 0 Name: Script: Enabled: voicemail voicemail 1 voicebrowser.aef yes Description: ID number:
Maximum number of sessions: 8 logoutUri: http://localhost/voicemail/vxmlscripts/mbxLogout.jsp uri: http://localhost/voicemail/vxmlscripts/login.vxml
autoattendant autoattendant 2 aa.aef yes
Maximum number of sessions: 8 busOpenPrompt AABusinessOpen.wav holidayPrompt AAHolidayPrompt.wav busClosedPrompt AABusinessClosed.wav allowExternalTransfers false MaxRetry: operExtn: 3 2001
welcomePrompt: AAWelcome.wav businessSchedule systemschedule
promptmgmt promptmgmt 3 promptmgmt.aef yes
Maximum number of sessions: 1

Custom Automated Attendant
Five automated attendant applications have been defined: four custom and the system default
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:
Choose the script and language and assign a name. Set any script variables. 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

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.0 5-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.
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.
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.0 5-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
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 Application: AutoAttendant Locale: en_US Idle Timeout: 5000
- -
Name: 6900 Type: SIP Application: AutoAttendant 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.
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
-
autoattendant autoattendant 2 aa.aef yes 3 2001
Maximum number of sessions: 5 MaxRetry: operExtn:
welcomePrompt: AAWelcome.wav 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.0 5-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.
-
autoattendant autoattendant 2 yes 3 2000 AAWelcome.wav aa.aef
welcomePrompt:
-
autoattendant autoattendant 2 aa.aef yes 5 2000
welcomePrompt: AAWelcome.wav
Application setting and parameters may be set from the GUI or the CLI. Names are case sensitive.
IPTX v2.0 5-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 party"s 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?
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 party s 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.0 5-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.0 5-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.0 5-56
This figure shows the script being uploaded from the administrator s 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.0 5-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.0 5-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.

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.0 5-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.0 5-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.
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.
IPTX v2.0 5-1
Administration via TUI
This topic describes administration via the TUI.
Administration via TUI Overview

Recording and Listening Format
TUI or an offline system, then uploaded to CUE G.711 mu-law, 8 kHz, 8 bit, Mono View list of prompts on the system Upload or download prompts Assign prompts to automated attendant script parameters 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.0 5-63
CUE Administrator GUI
TUI Access
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.0 5-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.
Lesson 4
Configuring Cisco Unity Express Users and Groups

Overview
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 This lesson defines how users interact with the Cisco Unity Express (CUE) system and how the administrator configures those users and groups.
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 user!s 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.
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.0 5-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.
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.0 5-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.0 5-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.
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.
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
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.

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

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

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

- -- - -
IPTX v2.0 5-14
Note
The minimum PIN length is three digits.
Example: User Profile

- - - - - - - - -- - - - - - - - - -
IPTX v2.0 5-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.0 5-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

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 user s 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.0 5-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.
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.0 5-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 group s 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 owner s 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.0 5-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
Configuring Cisco Unity Express Users and Groups
IPTX v2.0 5-1
Adding a New Group via the CLI
Adds a new group and configures the group in CUE

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

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

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

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

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

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.0 5-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 ID 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 the group!s username,
IPTX v2.0 5-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 ! Owner!s 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
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
In the GUI, the following two-step process creates a GDM:

Step 1 Step 2
Create the group. 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
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

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

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

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

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 user!s 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.0 5-44
Lesson 5
Configuring Cisco Unity Express Voice Mail

Overview
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 This lesson defines how to set up, configure, and manage voice mail settings.
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.
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 application s script. The trigger s 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.0 5-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.0 5-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
- ---- - ----
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.
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.0 5-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 Express !CUE 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
Assume four-digit extension
CME
1. Message left
On Off
3. Message sent to MWI directory number

The periods are very important. If not present, the MWI does not work.
IPTX v2.0 5-8
4. SCCP message sent to turn on MWI
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 telephone s 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.
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.0 5-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

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.0 5-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 mandatory "each represents one digit in the dial plan.
Refresh MWI via the GUI
- -- -
Current state of lamp cannot be queried or displayed

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

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.0 5-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.0 5-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.
In order for a user to have a mailbox on the CUE system, the user s 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.0 5-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 subscriber s 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.
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

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.0 5-26
This figure shows an example of configuring the system voice mail defaults and mailbox defaults.
Changing a User$s Mailbox Settings via the GUI
Changes here will affect only the selected user.

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 subscriber s 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 User$s Mailbox and Message Settings via the CLI
- --
Creates a mailbox and sets the maximum size, in seconds
- - - ---- -
Configure mailbox settings
IPTX v2.0 5-28
To change a user s 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 no tutorial enable Sets the number of days that a message is stored in the mailbox Disables the tutorial program that runs the first time a user logs in
Enables the mailbox
Example: Configuration of a User$s Mailbox Settings

- - - --- - --- - - - - - -- -- -- - - -- -- -- -- - - - --
This figure shows an example configuration of the settings on a user s 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.0 5-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.
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.0 5-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
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

- - ---- - - - - - - -- -- -- - -- -- -- -- - -
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
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.0 5-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.0 5-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.0 5-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
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 user s 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
-
From the GUI, the user or administrator can set the greeting type that is played to callers who leave a message in the user s 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
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 recipient s mailbox. CUE Release 2.1 adds a delayed delivery record, which is a notification left in the sender s 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 sender s 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.0 5-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 sender s 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 user $the target of a message from a local user$has 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.0 5-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
QoS Not Required
IPTX v2.0 5-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
QoS Not Required
IPTX v2.0 5-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
QoS Not Required
IPTX v2.0 5-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)

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

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

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 Configuration
Seattle
IP Network
Boston
IPTX v2.0 5-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.0 5-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
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 recipient s spoken name, if it is recorded, or the recipient s 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
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 user s 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.0 5-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

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

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.0 5-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.0 5-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.
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 recipient s name or extension. This is called blind addressing. The address of the remote recipient is the location ID of the remote system plus the recipient s 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 Extension Spoken name
from:1000@seattle.cisco.com to:2000@boston.cisco.com Spoken name of FPrefect (optional) vCard of FPrefect (optional) IP Network


IPTX v2.0 5-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

LRU Cache
MProsser
Addressed Using the LRU Cache

VM
LRU Cache
FPrefect
from:2001@boston.cisco.com to:1000@seattle.cisco.com Spoken name of MProsser (optional) vCard of MProsser (optional) IP Network


IPTX v2.0 5-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.0 5-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

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

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.0 5-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.0 5-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 user $s private lists cannot be more than 50.
IPTX v2.0 5-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 user s private lists cannot total more than 50.
Add a Private Distribution List Using the GUI
Continued on next slide
IPTX v2.0 5-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.0 5-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.0 5-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
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
Introduction and Tools
This topic describes troubleshooting methodology and tools.
Introduction and Tools Problem-Solving Model

Start Define Problem Gather Facts Consider Possibilities Create Action Plan Implement Action Plan Observe Results Utilize Process
Finished Document Facts Problem Resolved
Yes Do problem symptoms stop? No
IPTX v2.0 5-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 Cisco s 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 doesn t 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 doesn t 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 doesn t 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. Show Commands: Verify system parameters and status
MWI Refresh and system parameters and limits check Log and Trace commands require CLI access
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
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
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.0 5-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
- -- -- ---
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.0 5-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
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 -
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.

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

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

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

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 entity are activities that can be traced individually. ! Within each module are a number of entities 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.
- -
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

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

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.0 5-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.
Viewing and Interpreting 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.0 5-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.0 5-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.0 5-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.0 5-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 large !up 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.

- - -- - - -
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.
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 Cisco CallManager Express

Debug ephone is useful for troubleshooting phones.
-- - - - - - --- ---
One very useful debugging command is the debug ephone command, which displays output regarding the Cisco CallManager Express "controlled ephones.
Example
The following shows output for a message left, then retrieved and deleted.
- - -
IOS Debug Commands: SIP and Misc.

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

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 Troubleshoots GUI web page problems Displays calls being set up to a Skinny Client Control Protocol debug ip http
debug voice ccapi inout (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 Source IP Address (Sig): 10.20.0.1 Destn SIP Req Addr:Port: 0.0.0.0:5060 Destn SIP Resp Addr:Port: 0.0.0.0:0 Destination Name:
Mar 8 13:27:04.45://17/000000000000/SIP/Call/sipSPIMediaCallInfo: Number of Media Streams: Media Stream: 1 g711ulaw 1
Negotiated Codec:
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 Source IP Address (Sig): 10.20.0.1

Destn SIP Req Addr:Port: 0.0.0.0:5060 Destn SIP Resp Addr:Port: 0.0.0.0:0 Destination Name:
Mar 8 13:27:10.223://17/000000000000/SIP/Call/sipSPIMediaCallInfo: Number of Media Streams: 1 Media Stream: 1 g711ulaw
Negotiated Codec:
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
libc
Bootloader with recovery mechanisms Linux 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.0 5-31
Linux Kernel
TracingSyslogSNMPRBCP
Bootloader BIOS Hardware ! NM/AIM Hardware and Operating System

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.
Software Architecture Overview: Generic Application Infrastructure

Applications
Authentication Tomcat Open LDAP PostgreSQL Java Virtual Machine sysdbManagement Interface
! Data organized using directories, nodes, and attributes ! Provides both consumer and provider application program interfaces (APIs) to data ! Open LDAP ! PostgreSQL ! Tomcat
Startup and Shutdown Component Monitor IOS-like CLI with Programmable Syntax
CLI
Startup/Monitor
Open Source for:
sysdb
JVM
Hardware and Operating System Application Support Infrastructure

! JAAS Authentication
IPTX v2.0 5-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 Overview: 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
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.
System-Level Troubleshooting 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.
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.
System-Level Troubleshooting on Cisco CallManager Express (Cont.)

- - - - - - - - - - - - - - -
- -- - - ---- -
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.
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.
System-Level Troubleshooting: Verifying Current System Usage
- - Number of - - mailboxes - - - Capacity and usage - information -- - -- -- -- -- - -- -- - -- - - -
IPTX v2.0 5-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.
System-Level Troubleshooting: Verifying a Mailbox

- --- - - - - -- Mailbox settings -- -- - Mailbox usage - -- -- information -- -- - -
IPTX v2.0 5-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.
System-Level Troubleshooting: Show System Status

- -- - - - --
- --- -- - -- -- --
To verify the CPU utilization and to look for hung processes, use these show commands.
IPTX v2.0 5-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.
System-Level 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.0 5-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
- - - - - --- -- -- -
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.
GUI Troubleshooting: Flash Files Required

- - - - - -- - - - - - - - - -
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.
GUI Troubleshooting: Applicable CUE Trace Commands

- - --- - -- -- -
Trace module for the GUI is "trace webinterface #
IPTX v2.0 5-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.
GUI Troubleshooting: Review Administrators 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 ! Maximum number of sessions: 1 User mode: Used to manage user-owned profiles and preferences; limited capabilities ! Maximum number of sessions: 4
IPTX v2.0 5-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.
GUI Troubleshooting: Failed Login

A login attempt fails because of nondefined credentials defined
--- - --- - - -- - - --- - -
No JDoe user
to log in --- - --- - -- - --- -
A login attempt fails because of a bad password
User IPTX fails
IPTX v2.0 5-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.
GUI Troubleshooting: 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 Express !dedicated 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.
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:

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.
Voice Mail and Automated Attendant: 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.0 5-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.
Voice Mail and Automated Attendant: Interpreting TUI Sessions (Cont.)

A caller leaves a message in voice mail for John Smith
- - - - -- - -- - - - -- -- - - -- -- - -- -- -- -- -- --- -- - -
Digit "1# pressed

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.
FPrefect$s password
- -
DTMF digit of 1 is entered

- - - -- - - - -
Continued on the next slide

FPrefect $s spoken name

IPTX v2.0 5-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.0 5-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.
Voice Mail and Automated Attendant: Monitoring Database Activity

Triggering a database lookup query
- - --- - - - - -- -- -- - - -- -- -- -- - -
IPTX v2.0 5-56
The specifics of a user s 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.0 5-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.
Example: Monitoring an Auto Attendant Application (Cont.)
- -- - -- - - - - - - - -
IPTX v2.0 5-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.
Example: Monitoring an Auto Attendant Application (Cont.)
- - - - - - - - - - - - - - - - - -
IPTX v2.0 5-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.
Example: Monitoring an Auto Attendant Application
- - - - - - - - - - - -
- - - -
IPTX v2.0 5-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.
- -- - - -- - - - - --- -- -- -
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.0 5-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 mail$s LDAP access for user information Monitor user search and authentication, spoken name retrieval, etc.
User is calling in via the Message button from extension 7008
7008
IPTX v2.0 5-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

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.
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.0 5-1
Reference
For additional information, refer to the following resources: 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
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) 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 Installation and Initialization) 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 Installation and Initialization) 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: Configuring Cisco Unity Express Auto Attendant) A) 20 B) 10 C) 8 D) 12 Q9) Which is a limitation of using a variable to populate information within a script? (Source: Configuring Cisco Unity Express Auto Attendant) 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: Configuring Cisco Unity Express Auto Attendant) 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? (Source: Configuring Cisco Unity Express Auto Attendant) 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 D) none of the above 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 all that apply.) (Source: Configuring Cisco Unity Express Voice Mail) 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 all that apply.) (Source: Configuring Cisco Unity Express Voice Mail) 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 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 Q2) A, B, E
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.0 6-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
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 it#s 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.
Introducing IP Quality of Service 6-5
Converged Networks: Network After Convergence
Converged traffic characteristics:

Critical traffic must get priority Voice and video are time sensitive Brief outages not acceptable
Constant small packet voice flow competes with with bursty data flow
IPTX v2.0 6-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

Converged Networks: Quality Issues
This topic describes the basic quality issues presented by converged networks.
Phone Call: "I can#t 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. %
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 problems $echo and talker overlap. Echo is caused by the signal reflections of the speaker #s voice from the far-end telephone equipment back into the speaker #s ear. Talker overlap (or the problem of one talker stepping on the other talker #s 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.)

Lack of bandwidth: multiple flows compete for a limited amount of bandwidth
Video Lacking Proper QoS
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.0 6-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
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.0 6-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
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.0 6-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)
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 drop$main CPU is congested and cannot process packets (the input queue is full) Ignore$router ran out of buffer space Overrun$CPU 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.0 7-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 network #s 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
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 (60 $120 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.
QoS Traffic Requirements: 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
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.
QoS Traffic Requirements: 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
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.0 6-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.0 6-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
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.0 6-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.0 6-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
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.
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.0 6-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.0 6-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.0 6-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)
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
The following PHBs are defined by IETF standards: Default PHB used for best-effort service (bits 5-7 of DSCP = 000) used for low-delay service (bits 5-7 of DSCP = 101) used for guaranteed bandwidth service (bits 5-7 of DSCP = Expedited Forwarding PHB Assured Forwarding PHB 001, 010, 011, or 100)
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&
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.0 6-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
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 DSCP Value
Assured Forwarding Class 1 Low 001 01 0 Medium 001 10 0 High 001 11 0 Assured Forwarding Class 2 Low 010 01 0 Medium 010 10 0 High 010 11 0 Assured Forwarding Class 3 Low 011 01 0 Medium 011 10 0 High 011 11 0 Assured Forwarding Class 4 Low 100 01 0 Medium 100 10 0 High 100 11 0

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.0 6-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 microflow"s packets within a single precedence level will be proportional to that flow"s percentage of the total amount of traffic passing through that precedence level.
Backward Compatibility Using the Class Selector

Backward Compatibility Using the Class Selector
This topic explains the interoperability between DSCP-based and IP precedence based devices in a network.
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&
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 packet"s 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.0 6-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).
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 packet s 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
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
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 packet !s class can be quickly recognized throughout the rest of the network
IPTX v2.0 6-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 packet s 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 packet s 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?
Cisco!s 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 and 2 2 are optimal, 3 3 is acceptable (if access switchcannot 1 perform classification)
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

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
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
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.0 6-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. Cisco s 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.0 6-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
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.
Lesson 4
Introducing Modular QoS CLI

Overview
Objectives
Upon completing this lesson, you will be able to describe MQC and its associated components. This includes being able to meet these objectives: 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 This chapter explains how to implement QoS policies using MQC.
Introducing Modular QoS CLI

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
This topic describes the MQC method for implementing QoS on a network.
IPTX v2.0 6-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

!What traffic do we care about? " Each class of traffic is defined using a Class Map
Define QoS Policies for Classes

!What will be done to this traffic? " 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.0 6-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)
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
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

Configuring Class Maps
This topic explains the commands necessary for configuring and monitoring 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
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

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.0 6-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.0 6-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

Configuring Policy Maps
This topic describes the commands necessary to configure and monitor 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
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)
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.0 6-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
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.0 6-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
-
- - - - -- - - - -- -- - - - - -- - - -- -- - -
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.0 6-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.0 6-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.
-- -- -- -- -- --
Copyright 2005, Cisco Systems, Inc. Introducing IP Quality of Service 6-71
Traffic Policy Created In the following example, a traffic policy called policy1 is defined to contain policy specifications for the two classes class1 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.
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. This includes being able to meet these objectives: 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.0 6-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.0 6-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
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.
AutoQoS: Router Platforms

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
This topic identifies the router and switch platforms on which AutoQoS operates.
IPTX v2.0 6-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

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
This topic identifies the switch platforms on which AutoQoS operates.
6500
4500
3750
3550
3560 2950EI
2970
IPTX v2.0 6-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.0 6-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.0 6-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.
Configuring 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.0 6-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 Relay to-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.
- -- -
Configuring AutoQoS: 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
- - - - -- -- - - - - - - - - - - - -- - - - ---
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.
Configuring AutoQoS: 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
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.
Configuring AutoQoS: 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.0 6-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:

- - - - - - - - - - - - -
Configuring AutoQoS: 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
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.0 6-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
- - - -- - - - - - - - - - - - -
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.0 6-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

- - - ---- -- - - -- - - - -
--
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
- - - - --- - -
IPTX v2.0 6-20
This command shows the current mapping of DSCP to CoS.
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.0 6-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.0 6-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 Step 2
Review customer QoS requirements. Completely read the customer requirements provided. 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. 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. Present your solution. After the instructor presents a solution to the case study, present your solution to the class with your partner.
Step 3
Step 4
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 Enterprise Resource Planning Patient Information Files Patient Graphics Files IP Telephony Browser Traffic Application Importance critical important Response Time Requirements immediate immediate Use of Bandwidth (Daytime) moderate moderate
important minimal heavy important not important no delay minimal moderate heavy
Nuevo Health Care Systems Network
n Device no. on Problem Spreadsheet

Device Number 1 IP Phone 2 LAN Switch 3 Customer Edge Router
Device Type
4 Service Provider Router
Identify QoS Service Class Requirements

Traffic Classification and Prioritization
Type of Traffic (Application) Traffic Priority (Rank from 1 to 5)
Given NHCS network, how would you recommend classifying network traffic?
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 # 1 IP Phone 1 IP Phone 2 Switch 2 Switch ! Interface to Workstation Switch Phone ! Interface to ! Interface to IP Network Device Interface Classification on Input Classification on Output Marking on Input Marking on Output
! Interface to Customer Edge Router !
3 Customer Edge Router Interface to Switch
3 Customer Edge Router ! Interface to WAN (Service Provider Router) 4 Service Provider Router ! Interface to Customer Edge Router
Where to Apply QoS Mechanisms: Congestion Management and Avoidance

Device # 2 Switch 2 Switch Phone ! Interface to IP Network Device Interface Congestion Management on Input Congestion Management on Output
! Interface to Customer Edge Router !
3 Customer Edge Router ! Interface to WAN (Service Provider Router) 4 Service Provider Router Interface to Customer Edge Router !
Where to Apply QoS Mechanisms: Traffic Shaping

Device # 2 Switch 2 Switch ! Interface to IP Phone ! Interface to Customer Edge Router ! Network Device Interface Traffic Shaping on Input Traffic Shaping on Output
Where to Apply QoS Mechanisms: Link Efficiency

Device # 2 Switch 2 Switch ! Interface to IP Phone ! Interface to Customer Edge Router ! Network Device Interface Compression on Input Compression on Output LFI on Input LFI on Output
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) IP Telephony Highest Enterprise Resource Planning High Patient Information Files Moderate Patient Graphics Files Low Browser Traffic Low 4 4 Traffic Priority 1 2 3
Where to Apply QoS Mechanisms: Classification and Marking

Device # 1 IP Phone 1 IP Phone 2 Switch 2 Switch ! Link to Workstation ! Link to Switch ! Link to IP Phone ! Link to Customer Edge Router ! ! Network Device Interface Classification on Input X X* X X No, X X X trusted* Classification on Output Marking on Input Marking on Output
3 Customer Edge Router Link to Switch 3 Customer Edge Router Link to WAN (Service Provider Router)
4 Service Provider Router ! Link to Customer Edge Router Note
*The IP Phone is normally set to re-mark any traffic coming from its downstream workstation (the IP Phone s 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 Customer Edge Router ! ! Network Device Interface Congestion Management on Input X X X X Congestion Management on Output
3 Customer Edge Router Link to Switch 3 Customer Edge Router Link to WAN (Service Provider Router)
4 Service Provider Router ! Link to Customer Edge Router
Where to Apply QoS Mechanisms: Traffic Shaping

Device # 2 Switch 2 Switch Router ! Link to IP Phone ! Link to Customer Edge ! Link to Possible Possible Network Device Interface Traffic Shaping on Input Traffic Shaping on Output
3 Customer Edge Router Switch
3 Customer Edge Router ! Link to WAN (Service Provider Router) 4 Service Provider Router ! Link to Customer Edge Router
Where to Apply QoS Mechanisms: Link Efficiency

Device # 2 Switch 2 Switch ! Link to IP Phone ! Link to Customer Edge Router ! Link X X Network Device Interface Compression on Input Compression on Output LFI on Input LFI on Output
3 Customer Edge Router to Switch
3 Customer Edge Router ! Link to WAN (Service Provider Router) 4 Service Provider Router ! Link to Customer Edge Router Note
X X
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.0 6-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.
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
For additional information, refer to the following resources: 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 . http://www.ietf.org/rfc/rfc2597.txt. Jacobson, et al. An Expedited Forwarding Per-Hop Behavior (PHB) . http://www.ietf.org/rfc/rfc3246.txt. 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
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 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 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 Q2) A, B, C
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.
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 CallManagerExpress router 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.0 7-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 Express Interfaces
Cisco CallManager Express with PSTN
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
Standalone Cisco CallManager Express (Cont.)

ATA
V
Cisco CallManagerExpress/CUE
Internet
PSTN
Single physical site
Small-to medium-sized businesses Cannot scale above 240 ephones
IPTX v2.0 7-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.
Cisco CallManager Express in 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.0 7-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.
Cisco CallManager Express in SIP Network (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 2833 !based DTMF relay Cisco CallManagerExpress router must be configured if E.164 numbers are going to register with the SIP registrar server
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 2833!compliant 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 2833!compliant 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

Cisco CallManager Express Integration with 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
This topic describes Cisco CallManager Express integration with Cisco CallManager.
IPTX v2.0 7-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 Express Integration with Cisco CallManager (Cont.)

Networked Location A
SRST, SRST, CUE CUE Router Router Cisco CallManager Cluster ! Central Call Processing Applications (UM, IVR, IPCC, etc.)
PSTN Cisco CallManager Phones

Fat pipe
QoSenabled IP WAN
Cisco CallManager Express, CUE ! Localized Call Processing
Central Site
Cisco CallManager Express Phones

Branch Branch Office Office
IPTX v2.0 7-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 Express Integration with Cisco CallManager (Cont.)

Cisco CallManager Cisco CallManager
Voice mail
Distributed Cisco CallManager with CUE at small, remote locations PSTN

Fat pipe
Voice mail
Cisco CallManager Express, CUE
QoSenabled IP WAN
Cisco CallManager Express, CUE
IPTX v2.0 7-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

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
This topic describes Cisco CallManager Express migration to Cisco CallManager and SRST.
IPTX v2.0 7-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.)

CallManagerExpress
Networked Location A
SRST
PSTN
Cisco CallManagerExpress Phones CCM Phones CallManagerExpress SRST
Fat pipe
Cisco CallManager Cluster ! Central Call Processing
Applications (UM, IVR, ICD, etc.)
QoSEnabled IPWAN Central Site
Cisco CallManagerExpress, CUE ! Localized Call Processing
CallManagerExpress Phones CallManagerPhones

Cisco
IPTX v2.0 7-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 CallManager Express router. 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

3000 3000

2000 2000
Cisco CallManager ExpressB
IP WAN
Cisco Cisco CallManager CallManager ExpressC ExpressC
Step 2 -Transfer or forward to 3000
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

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.
Cisco CallManagerExpress H.323 Interoperability 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.0 7-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-VoIP or hairpin connection. 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.
Cisco CallManagerExpress H.323 Interoperability Solutions Non-H.450-Compliant Networks Hairpinning

1000 1000 Cisco Cisco CallManager CallManager ExpressA ExpressA

2000 2000
Non-H.450 Gateway IP WAN Step 3 ! Call is hairpinned and connected to 3000

3000 3000
Cisco CallManager ExpressB
Step 2 -Transfer or forward to 3000 -
-
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 Step 3 ! The SIP connection to the CUE module is setup
H.323
CUE
SIP
IP WAN
Skinny
H.323 Cisco CallManager Express
Gateway
3000 3000
-
Step 2 ! A hairpin between the H.323 call leg and the SIP call leg to the CUE module is set up
- -
IPTX v2.0 7-15
H.323 to SIP
Hairpinning
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

To view a hairpinned call, use the show voip rtp connections command.
Cisco CallManagerExpress H.323 Interoperability Solutions Non-H.450-Compliant Networks Tandem Gateway

Cisco Cisco CallManager CallManager Express Express A A 1000 1000
Step 4 !Call is transferred or forwarded H.450 Tandem Gateway IP WAN

3000 3000
Step 1 !Call made from 1000 to 2000

Cisco CallManager Express B 2000 2000
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.0 7-17
Tandem 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.0 7-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 plentiful for 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.
Cisco CallManagerExpress H.323 Interoperability 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 $False% this is the default
Set $Send H225 User Info message % to $H225 Info for Ringback %
IPTX v2.0 7-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.0 7-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 inter!Cisco CallManager Express connections. This has the benefit of centralizing dial plan management and administration, as well as minimizing the configuration changes on Cisco CallManager Express.
Cisco CallManagerExpress H.323 Interoperability Solutions H.323 Gatekeeper (Cont.)

Pod1
Recommended for 20+ sites

Gatekeeper pair running HSRP and GUP
Pod6
Pod2
Pod3
WAN
Pod7
Pod4
Pod5
Pod8
IPTX v2.0 7-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.0 7-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.
Lesson 2
Deploying Voice Mail with Cisco CallManager Express

Overview
Objectives
Upon completing this lesson, you will understand the issues involved in voice mail integration. This includes being able to meet these objectives: 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 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.
SIP Integration with Cisco Unity Express

SIP Integration with Cisco Unity Express
CUE SIP Cisco CallManager Express
This topic describes the session initiation protocol (SIP) integration with 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
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 CallManagerExpress router 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.0 7-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.0 7-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 extension s 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.0 7-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
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
IPTX v2.0 7-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 The Cisco CallManager Express router sends 7 to notify the voice mail system to play a personal greeting for busy when a call coming from one extension to another is forwarded with busy. pattern trunk-to-ext no-answer The Cisco CallManager Express router sends 4 to notify the voice mail system to play a 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 The Cisco CallManager Express router sends 6 to notify the voice mail system to play a 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.
Router Configuration: Two Commands
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
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.
Router Configuration: Two Commands (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
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 is busy
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.
Router Configuration: Two Commands (Cont.)
Digit pattern forward that is necessary to activate the voice mail system when an external trunk call is forwarded to voice mail if the called extension does not answer
Digit pattern forward that is necessary to activate the voice mail system when an external trunk call is forwarded to voice mail if the called extension is busy
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.0 7-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.0 7-1
References
For additional information, refer to the following resources: 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 . http://cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide_chapter09186 a00802d255e.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) 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 D) none of the above
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
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 This guide presents the instructions and other information concerning the activities for this course. You can find the solutions in the activity Answer Key.
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 Cisco CallManager Express Pod1Pod8 !

PodX
Data VLAN =10 Voice VLAN =15 Voice VLAN =X0
Data VLAN =80
X000 X001
Voice VLAN =85
1000100180008001
Data VLAN =X5
IPTX v2.0 3
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
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 DHCP Pool Exclusion IP Network for DHCP Pool Default Router Option 150
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.0/24 10.15.0.1 10.10.0.1
10.15.0.1/24 Voice 10.15.0.1-10.15.0.10 Pod 2
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.0 /24 10.25.0.1 10.20.0.1
10.25.0.1/24 Voice 10.25.0.1-10.25.0.10 Pod 3
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.0 /24 10.35.0.1 10.30.0.1
10.35.0.1/24 Voice 10.35.0.1-10.35.0.10 Pod 4
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.0 /24 10.45.0.1 10.40.0.1
10.45.0.1/24 Voice 10.45.0.1-10.45.0.10 Pod 5
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.0 /24 10.55.0.1 10.50.0.1
10.55.0.1/24 Voice 10.55.0.1-10.55.0.10 Pod 6
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.0 /24 10.65.0.1 10.60.0.1
10.65.0.1/24 Voice 10.65.0.1-10.65.0.10 Pod 7
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.0 /24 10.75.0.1 10.70.0.1
10.75.0.1/24 Voice 10.75.0.1-10.75.0.10 Pod 8
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.0 /24 10.85.0.1 10.80.0.1
10.85.0.1/24 Voice 10.85.0.1-10.85.0.10
Lab Guide 5
Table 2
Pod Dial Plan " Extension Numbers Voicemail Extension First E.164 DID Number 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
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 # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Number Function Applied to Settings
Lab Guide 7
Pod 1 Dial Peer Worksheet

Tag # 1 2 3 4 5 6 7 8 Destination Pattern Incoming Called-number Port or Session Target Settings
Pod 1 Identity
Username First Name Last Name Ephone Comments
CME Administrator CUE Administrator Customer Administrator First user Second user
X X X
X X X
X X X
CME Administrator CUE Administrator CME Customer Administrator
Pod 1 CUE Numbers

Number 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:
The instructor assigns the pod number for the class. Connect to the console of your Cisco CallManager Express router. Enter the command enable to enter privileged EXEC mode. Enter global configuration mode by entering the command configure terminal. 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. Set an enable password of cisco by using the enable password cisco command (please do not deviate from this password). Use the command no ip domain-lookup to disable name resolution (because there is no DNS server in the classroom lab). Enter the command line vty 0 4 to enter the line subconfiguration mode. From (config-line)# mode, enter the command password cisco . From (config-line)# mode, enter the command login. From (config-line)# mode, enter the command logging synchronous .
Lab Guide 9
Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20
From (config-line)# mode, enter the command no exec-timeout. Enter the command line console 0 in order to enter the line subconfiguration mode. From (config-line)# mode, enter the command password cisco. From (config-line)# mode, enter the command login. From (config-line)# mode, enter the command logging synchronous . From (config-line)# mode, enter the command no exec-timeout. 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). Enter the command encapsulation dot1q X0 (where X is the pod number). If a warning message appears, ignore it. 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). 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). Enter the command encapsulation dot1q X5 (where X is the pod number). 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). Enter the configuration mode for the Fast Ethernet interface 0/0 by using the command interface fastethernet 0/0. From subinterface configuration mode, enter the no shutdown command. Enter exit to return to global configuration mode. Enter the command ip dhcp excluded-address 10.X0.0.1 10. X0.0.10 (where X is the pod number). Enter the command ip dhcp pool CMEData X (where X is the pod number). 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). Enter the default-router 10.X0.0.1 command (where X is the pod number). Enter exit to return to global configuration mode. Use the router eigrp 100 command to start an EIGRP process with an autonomous system of 100. Enter the network 10.0.0.0 command to enable EIGRP on all 10.0.0.0 networks. A console message should appear indicating that an adjacency has been formed. Use the show ip route command to verify that EIGRP routes appear in the routing table.
Step 24 Step 25 Step 26 Step 27 Step 28 Step 29 Step 30 Step 31 Step 32 Step 33 Step 34 Step 35
Step 36 Step 37
Verify connectivity by pinging the 10. X0.0.2 address (where X is the pod number). 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
The instructor will diagram the ports that are assigned to the two phones in the pods. Telnet to the switch by entering telnet 10.0.0.4 (if different, the instructor will give the IP address). The password is cisco. Enter the command enable to enter privileged EXEC mode. The password is cisco. Use the command show running-config to view the configuration that is present on your IP Phone ports. What is the data VLAN? __________ What is the voice VLAN? _________
You have completed this task when you attain these results: 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. When prompted to overwrite flash, enter y for yes. The file will be written to flash and will take a couple of minutes to complete. Use the show flash command to verify that the IOS file is present in flash memory. When the upload of IOS software is complete, reload the router. Verify the version of IOS software running on your router by using the show version command. The version should be 12.3(11) XL. Enter show flash to view the contents. 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. Enter show flash to verify that files that were extracted are present in flash RAM. 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. Enter show flash to verify that files that were extracted are present in flash RAM.
Step 9 Step 10
Step 11
Step 12
Use the show running-config command to obtain a baseline understanding of the configuration.
You have completed this task when you attain these results: 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
From global configuration mode, enter the command telephony-service setup . When prompted with the choice to set up the DHCP service, choose yes. The IP network of the DHCP pool will be 10.X5.0.0 (where X is the pod number). The IP subnet will be 255.255.255.0 for all pods. 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). The default router for the pool will also be 10.X5.0.1 (where X is the pod number).
Lab Guide 13
Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20
Answer yes to the question, Would you like to start setting up the telephony service?! For the source IP address, enter 10.X5.0.1 (where X is the pod number). Accept the default port of 2000 by pressing the Enter key. When asked how many IP Phones to configure, answer 10. When asked whether dual lines are desired, answer yes. Choose the language that is desired on the phone (if in the United States, the default may be used just press the Enter key). Choose the country for call progress tones (if in the United States, the default may be used just press the Enter key). Choose the first extension number that is desired (see Table 2). Example: X000 1 (where X is the pod number). When asked if DIDs are used, answer yes. When asked for the full E.164 number, enter the value from Table 2 that is specific for the pod. When asked if forwarding to voice mail is desired, enter yes. Enter the extension number for voice mail that is in Table 2. Example: X999 1 (where X is the pod number). Press the Enter key to accept the default of 18 seconds for Call Forward timeout. 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. 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 . Place a call between the two IP Phones. 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. Do not save the configuration, so that a manual configuration can be completed in the next task. Reload the router.
Step 21
Step 22 Step 23
Step 24 Step 25
You have completed this task when you attain these results: 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. 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 (where X is the pod number). DIDs should be configured with a value from Table 2. 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
From global configuration mode, enter the command telephony-service setup . When prompted with the choice to set up the DHCP service, choose yes. The IP network of the DHCP pool will be 10.X5.0.0 (where X is the pod number). The IP subnet will be 255.255.255.0 for all pods. 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). The default router for the pool will also be 10.X5.0.1 (where X is the pod number). Answer yes to the question regarding starting the telephony service setup. For the source IP address, enter 10.X5.0.1 (where X is equal to the pod number). Accept the default port of 2000 by pressing the Enter key. When asked how many IP Phones to configure, answer 10. When asked whether dual lines are desired, answer yes. 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 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20
Select the country for call progress tones (if in the United States, the default may be used just press the Enter key). Select the first extension number that is desired (see Table 2). Example: X000 1 (where X is the pod number). When asked if DIDs are used, answer yes. When asked for the full E.164 number, enter the value from Table 2 that is specific for the pod. When asked if forwarding to voice mail is desired, enter yes. Enter the extension number for voice mail that is in Table 2. Example: X999 1 (where X is equal to the pod number). Press the Enter key to accept the default of eighteen seconds for Call Forward timeout. 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. 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 . Notice that the IP Phone 7960 has registered and has dial tone when it goes off hook. 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. Reload the router, and do not save the configuration, so that a manual configuration can be completed in the next task.
Step 21
Step 22 Step 23
Step 24
You have completed this task when you attain these results: 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). Set the source address to 10.X5.0.1 with a port of 2000. Configure four 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. 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. Unplug both IP Phones. 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. Enter the command ip dhcp exclude-address 10. X5.0.1 10. X5.0.10 (where X is the pod number). Enter the command ip dhcp pool CMEVoiceX (where X is the pod number). Use the network 10.X5.0.0 255.255.255.0 command to set up the range of addresses that will be used. Enter the command default-router 10.X5.0.1 (where X is the pod number). Enter the command option 150 ip 10. X5.0.1 to assign the TFTP server. 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: _________________________________________________________________ _________________________________________________________________ _________________________________________________________________
Enter the command configure terminal to enter global configuration mode. Use the command tftp-server flash: P00303020214.bin to allow the firmware files to be accessed through the TFTP server. 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 Enter telephony service mode by entering the command telephony-service from global configuration mode. Enter the command max-ephones 2 (this will be sufficient for the classroom lab). Enter the command max-dn 20 (this will be sufficient for the classroom lab). 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.) 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.) 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). Set the time zone to your current location by using the command time-zone. Use the create cnf-files command to build XML configuration files that will be used by the phones during the bootup process. Set the keepalive interval to ten seconds by entering the command keepalive 10. Use the command show running-config | begin tele to view the results of the manual configuration. Ensure that no IP Phones are plugged in.
Step 18
Step 19
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.
In this task, ACME desires to deploy Cisco CallManager Express and IP Phones. Use IOS commands to achieve the following goals: 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
Verify that the IP Phones are not plugged in. Enter telephony service mode by entering the telephony-service command from global configuration mode. Enter exit to return to global configuration mode from telephony-service mode. Add an ephone-dn for the first line appearance on the first phone in the pod by entering the ephone-dn 1dual-line command. In ephone-dn mode, enter the number X000 command (where X is the pod number). 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 student"s name. (example: name John Smith). Enter the command ephone 1 to enter ephone configuration mode for the first phone in the pod. 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 7 Step 8
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). Assign the ephone-dn to the ephone line with the button 1:1 command. Enter the debug ephone register command. Plug in the configured IP Phones. View the ephone registration debugging output. Verify that the phone has registered and that the proper directory number appears with the line. Enter exit to go back to global configuration mode.
Lab Guide 19
Step 16 Step 17
Enter exit to go back to privileged EXEC mode. 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.
In this task, ACME desires to deploy Cisco CallManager Express and IP Phones. Use IOS commands to achieve the following goals: Configure the second IP Phone through the use of the auto assign command. Attach the second IP Phone to the network.
Activity Procedure
Add a second ephone-dn by using the ephone-dn 2 dual-line command. Use the number X001 command to add a directory number (where X is the pod number). Enter telephony service mode by entering the telephony-service command from global configuration mode. Turn on the ability to auto-assign numbers by entering the command auto assign 2 to 2. Plug in the remaining unplugged IP Phone. Verify that both phones are registered and configured. Place a call from one phone to the other in the pod to verify the configuration. If successful, save your configuration by using the command copy running-config startup-config.
You have completed this task when you attain these results: 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.
- - -- - - -- - - -- - - -- - - - - - -- -- - - - - - - - - -- - - -- -- - -- - -- --
Copyright 2005, Cisco Systems, Inc. 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
PSTN
Pod 1
Pod 2 Pod 3-6 202-555-9000
Pod 7
Pod 8
...
207-555-9000
201-555-9000208-555-9000
IPTX v2.0 4
Lab Guide 23
Required Resources
These are the resources and equipment required to complete this activity: 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 privileged EXEC mode Enters global configuration mode 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 1 24 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 E.164 Number for FXO Port
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
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: _________________________________________________________________
Pick up the handset of the analog phone to verify that you can hear a dial tone. Attempt to dial one of the two IP Phones from the analog phone. Was the call successful? At the command line on the Cisco CallManager Express router, enter privileged EXEC mode by entering enable. If asked for a password, use cisco. Go to global configuration mode by using the command configure terminal. From global configuration mode, enter the voice port by using the voice-port fxsport-that-analog-phone-is-plugged-into. From voice-port mode, enter the command cptone AU to set the call progress tones to Australia. Set the ring cadence with the command ring cadence pattern11. Place a call to an IP Phone and note that the call progress tones have changed. Use the show voice port fxs-port-that-analog-phone-is-plugged-into command and view the configuration of the voice port.
You have completed this task when you attain these results: 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.
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
Ensure that an analog phone is plugged into the lowest-numbered FXS port on the router. From global configuration mode, enter dial-peer voice 1 pots. In dial-peer subconfiguration mode, enter the command destination-pattern X100 (where X is the pod number). In dial-peer subconfiguration mode, enter the command port FXS-port-that-analogphone-is-plugged-into . 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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10
Ensure that you can make a connection to the lowest-numbered FXO port on the router to the PSTN simulator assigned by your instructor. From global configuration mode, use the command voice-port mod/port to enter the configuration for the FXO port. Enter the ring number 2 command to set the port to answer after two rings. Create an analog dial peer with the command dial-peer voice 2 pots. Use the command destination-pattern 120.5550... to set the digits that will match this dial peer. Use the command port mod/port to associate the lowest FXO port with this dial peer. Enter forward-digits all to forward all the digits to the PSTN (because POTS dial peers consume digits). Enter exit to return to global configuration mode. Wait for your partner pod to get to this step before proceeding to the next. 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. You will hear a second dial tone after two rings; this is the default dial peer. Dial the extension number of one of the two IP Phones of your partner pod. Why is the default dial peer reached? Will DID work on an analog line? Enter the lowest FXO voice port by using the command voice-port mod/port. 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). Enter exit to return to global configuration mode. Wait for your partner pod to get to this step before proceeding to the next. From one of your phones, 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. What is the result? Verify that the call completed without a second dial tone.
Step 20 Step 21
Lab Guide 29
You have completed this task when you attain these results: 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. __________________________________________________________________ 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). Enter the command network-clock-participate wic slot (physical slot where T1 or E1 WIC is installed). From global configuration mode, enter controller T1 module/port for the lowest T1 interface(if using E1 equipment, use E1 instead of T1). In T1 controller mode, enter the command framing esf (use framing crc4 if configuring an E1) to set the framing used. In T1 controller mode, enter the command linecode b8zs (use linecode hdb3 if configuring an E1)to set the line code. Set the clock to the line with the clock source line command.
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. The B channels should go up and you should see messages to that effect on the console. Enter exit to go back to global configuration mode. Use the show interface serial mod/port:23 command to verify that the interface is up and up. Use the command show isdn status and verify that Layer 1 is ACTIVE ! and that Layer 2 shows MULTIPLE_FRAME_ESTABLISHED. ! Wait for your partner pod to get to this step before proceeding to the next. Using your analog 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. What is the result? Why? Make a dial peer by entering dial-peer voice 3 pots from global configuration mode. From within dial-peer submode, enter the command destination-pattern 120.5559 to define the destination. From within dial-peer submode, enter the command forward-digits all. 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. Enter exit to go back to global configuration mode. Wait for your partner pod to get to this step before proceeding to the next. Using your analog 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. What is the result? Why? When a second dial tone is heard, dial the extension Y000 (where Y is the number of your partner pod). Verify that the call succeeds. Why did DID fail? Use the command show run | begin telephony-service . From telephony service mode, enter the command dialplan-pattern 1 20 X5559 extension-length 4 extension-pattern X (where X is the pod number). You will need a second dial peer in order to configure DID. Use the command dial-peer voice 4 pots to create and enter dial-peer configuration mode. Enter the command incoming called-number 20 X5559 match the incoming call to this dial peer. to set the pattern that will
Lab Guide 31
Enter the command port mod/port :23 to assign the dial peer to the PRI. Use the command direct-inward-dial to enable DID for this port. Enter exit to return to global configuration mode. Wait for your partner pod to get to this step before proceeding to the next. 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. What is the result? Verify that the DID for both IP Phones in your partner pod works.
Step 36 Step 37
You have completed this task when you attain these results: 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
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. 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. Use the show controller serial mod/port for the lowest serial interface and notice if the cable is a DCE or DTE. Go to the interface with the interface serial mod/port command. 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. Leave the encapsulation at the default of HDLC unless instructed otherwise by your instructor. 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). Use the command no shutdown to enable the serial interface. Enter exit to return to global configuration mode. Enter exit to return to privileged EXEC mode. Wait for your assigned partner pod to complete the previous steps. Verify connectivity by using ping to test. Enter ping 10.100.0. X (where X is the pod number). Attempt to dial the four-digit extension number of one of the phones in your partner"s pod. What was the result? Why? Enter global configuration mode by entering the command configure terminal. Make a new dial peer with the command dial-peer voice 5 voip . 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 1 "s partner for this task is Pod 3, so Y would be equal to 3 and you would enter destination pattern 3... 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 partner "s pod). Hardcode the codec that is to be used by entering the command codec g711ulaw. Enter exit to return to global configuration mode. Dial a four-digit extension number of one of the phones in your partner "s pod and stay connected.
Lab Guide 33
Step 18
Was the result different from before? Verify that the quality of the voice is acceptable. 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. How is the voice quality? Remain connected. 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. Hang up both calls. Enter global configuration mode by entering configure terminal. Make a new dial peer with the command dial-peer voice 5 voip . Hardcode the codec that is to be used by entering the command codecg729br8 . Enter exit to return to global configuration mode. Coordinate with your partner to place two simultaneous calls across the WAN link by dialing the four-digit extensions. How is the voice quality? Remain connected. 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. Save the configuration by using the command copy running-config startup-config .
Step 35
You have completed this task when you attain these results: 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. The analog phone can call the WAN or the analog PSTN connection.
VoIP over WAN
PSTN
IPTX v2.0 5

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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20 Step 21 Step 22 Step 23 Step 24 Step 25 Step 26 Step 27 Step 28
In this lab, do not save your changes. From global configuration mode, enter the command dial-peer cor custom to enter the COR mode. Enter the first name by entering the command name Analog . Enter the second name by entering the command name PRI. Enter the final name by entering the command name WAN. Enter exit to go to global configuration mode. Define a COR list by entering the command dial-peer cor list callAnalog. Put a member in the COR list with the command member Analog. Enter exit to go to global configuration mode. Define a COR list by entering the command dial-peer cor list callPRI. Put a member in the COR list with the command member PRI. Enter exit to go to global configuration mode. Define a COR list by entering the command dial-peer cor list callWAN . Put a member in the COR list with the command member WAN. Enter exit to go to global configuration mode. Define a COR list by entering the command dial-peer cor list Type1 . Put a member in the COR list with the command member WAN. Enter exit to go to global configuration mode. Define a COR list by entering the command dial-peer cor list Type2 . Put the first of two members in the COR list with the command member WAN. Put the second of two members in the COR list with the command member Analog. Enter exit to go to global configuration mode. Enter dial-peer voice 2 pots to enter dial-peer configuration mode. Assign an outbound COR list to the dial peer with the command corlist outgoing callAnalog. Enter exit to go to global configuration mode. Enter dial-peer voice 3 pots to enter dial-peer configuration mode. Assign an outbound COR list to the dial peer with the command corlist outgoing callPRI. Enter exit to go to global configuration mode.
Enter dial-peer voice 5 voip to enter dial-peer configuration mode. Assign an outbound COR list to the dial peer with the command corlist outgoing callWAN. Enter exit to go to global configuration mode. Enter ephone-dn mode by entering the command ephone-dn 1. In ephone-dn mode, enter the command cor incoming Type1. Enter exit to go to global configuration mode. Enter dial-peer voice 1 pots to enter dial peer configuration mode. Assign an outbound COR list to the dial peer with the command cor incoming Type2. 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. When the test is successful, reload the router, making sure you do not save the configuration.
Step 38
You have completed this task when you attain these results: 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 4-1: Configuring Additional Cisco CallManager Express Features

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
Use to test paging groups Web Browser
X100
Sales Paging Group Emergency Paging Group
Support Paging Group
X000X001
Intercom " between X000 and X001
IPTX v2.0 6
Lab Guide 41
Required Resources
These are the resources and equipment required to complete this activity: A properly configured Cisco CallManager Express router Two IP Phones One analog phone Student PC with Windows and IE 5.5 or greater Worksheets from Lab 2 or completed form from end of the Lab Guide
Command List
Command Description Enters privileged EXEC mode Enters global configuration mode 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
- - - - - -- - -- - - - -- - - - 10.X0.0.2 - - - - - - - -- -- --- -
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 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 Last Name Username
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
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
Enter the command archive tar /xtract ftp://IP_address/cme-gui-123-11XL.tar flash: to extract the GUI files. Enter the command ip http server to enable the web server on the Cisco CallManager Express router. Enter the command ip http path flash: to define the location of the HTML files. Go to http://10.X0.0.1/ccme.html (where X is the pod number) and verify that a blank username and the router "s enable password (cisco) works. This authentication is not advised in production and should be disabled by setting a web administrative username and password. Enter ip http authentication local to ensure that credentials will be defined locally on the router. Go to telephony service mode by using the command telephony-service. From telephony service mode, enter the command web admin system name IPTX password cisco. Enter the command dn-webedit to allow changes to the directory number through the web interface. Enter the command time-webedit to allow the Cisco CallManager Express time to be set from the web interface. Enter exit to go back to global configuration mode. Enter exit to go back to privileged EXEC mode.
Lab Guide 45
Step 12 Step 13
Enter the command copy running-config startup-config . 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. When asked for credentials, use IPTX for the username and cisco for the password. From the Configure drop-down menu, choose Extensions and view the currently configured extensions. Add a new extension with an extension number of X002 (where X is the pod number) and leave the other setting at default. Save the changes. From the Configure drop-down menu, choose Phones and view the currently configured phones. 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. 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). Save the changes. From the Configure drop-down menu, choose System Parameters. From the System Parameters page, notice the different selections that are available. Notice the settings that may be changed and configured from this page. Use the Date and Time Format object to change the format displayed on the phone to a nondefault format. Reset the two IP Phones by choosing the Configure >Phones menu. Use the Reset All link to reset the phones. View the changes on the IP Phones. Under the Directory Service object, choose Name Schema and notice the two choices. Remain on this page for the next task.
Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20 Step 21 Step 22 Step 23 Step 24 Step 25 Step 26 Step 27 Step 28 Step 29
You have completed this task when you attain these results: 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
As the system administrator, go to the Administrator "s Login Account from the System Parameters page. Change the Admin User Type to Customer and change the Admin User Name from Customer! to IPTXCust (remember that usernames are case sensitive). Set the password to cisco in both password fields. Click the Change button and click OK when a popup window appears. Close the browser window and go to the CLI of the Cisco CallManager Express router. Enter enable and when asked for a password, use cisco. Use the show running-config | begin telephony-service command to view the changes to the configuration. Notice the web admin customer name IPTXCust password cisco line. Minimize the terminal window. Go back to the GUI web page by using the URL http://10. X0.0.1/ccme.html (where X is the pod number). When asked for credentials, use IPTXCust for the username and cisco for the password. Notice that the level of access is exactly the same as the system administrator. Close the browser by clicking Logout in the upper right corner. Restore the terminal window to go back to the CLI.
Lab Guide 47
Use the show flash command to view the contents of flash. Notice a file called xml.template. 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. Use the get xml.template command to download the file from the Cisco CallManager Express router to the student PC. Enter the get newTemplate.xml command to download a modified xml.template file. Using a text editor, open the xml.template file on the root of the C drive of the student PC. Using another instance of a text editor, open the newTemplate.xml file found on the root of the C drive. Compare the two files side-by-side. 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. Enter the show flash command to verify that the newTemplate.xml file is present. Enter global configuration mode by entering the configure terminal command. Enter telephony-service mode by entering the telephony-service command from global configuration mode. In telephony-service mode, enter the command web customize load newTemplate.xml. Start the web browser on the student PC and go to http://10.X0.0.1/ccme.html (where X is the pod number). When prompted to log in, use the username IPTXCust and password cisco. Notice that the level of access is very restrictive. Log out of the GUI web pages.
You have completed this task when you attain these results: 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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13 Step 14 Step 15
Use the URL http://10.X0.0.1/ccme.html (where X is the pod number) to go to the GUI web interface. When prompted to log in, enter the username IPTX and password cisco. These are the system administrator credentials. Use the Configure drop-down menu and choose Phones. Click the link for IP Phone 1 and add the assigned username from Table 4 and the password cisco to the Login Account area. Click the Change button to commit the new username and password. Save the changes by choosing the Administration >Save Router Config menu. Log out of the GUI web interface. Go to a terminal window to access the CLI of the Cisco CallManager Express router. Enter the command show running-config | begin ephone to view the changes made through the GUI web interface. Notice under the ephone that the line username username password cisco has changed. Go to global configuration mode by entering the configure terminal command. From global configuration mode, enter the command ephone 2 to enter ephone configuration mode. Enter the command username username password cisco to configure a phone user for the second phone (the assigned username is in Table 4). Enter the exit command to go back to global configuration mode. Enter the exit command to go back to privileged EXEC mode.
Lab Guide 49
Step 16 Step 17
Enter the command copy running-config startup-config to save the changes. 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. Notice that the interface is has fewer options than when logged in as the administrator.
Step 18
You have completed this task when you attain these results: 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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11
Place a call from the analog phone to one of the IP Phones. 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. Notice that the transfer is blind. Open a console connection to the Cisco CallManager Express system. Enter enable to enter privileged EXEC mode. Enter configure terminal to enter global configuration mode. Enter telephony-service to enter telephony-service mode. Use the command transfer-system full-consult to enable consultative transfers. Enter exit to go to global configuration mode. Place a call from the analog phone to one of the IP Phones. Use the Trnfer softkey button and enter the extension of the other IP Phone.
Notice that the call is not automatically transferred. In fact, the caller (analog phone) is on hold. 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. 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. From the analog phone, call the number of the first IP Phone. The call should be forwarded. Press the CFwdAll softkey button to disable call forwarding. From the terminal window, enter ephone-dn 1 to enter ephone-dn mode. Enter the command call-forward max-length 0 to disable call forwarding from the IP Phone. 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. 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. Use the analog phone to verify functionality of the call forwards.
Step 20
Step 21
You have completed this task when you attain these results: 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: ____________________________________________________________________ From global configuration mode, use the command ephone-template 1 to define and create an ephone template. In ephone template mode, use the command softkey connected Acct Endcall Flash Hold Trnsfer to exclude the Confrn softkey. Enter exit to return to global configuration mode. Enter the ephone configuration mode by using the command ephone 2 (This should be a Cisco 7960 IP Phone). From ephone configuration mode, use the command ephone-template 1 to apply the template to the ephone. Reset the phone by either pressing **#** on the keypad or typing reset from ephone configuration mode. Enter exit to go back to global configuration mode. Once the IP Phone has reset, place a call and note the order, and the lack of a Confrn softkey. With the second IP Phone on hook, notice the softkeys present and their order. Document the order here: ____________________________________________________________________ Create a second ephone template by typing the command ephone-template 2. In ephone template mode, enter the command softkey idle Dnd Redial Newcall Pickup Gpickup Login to change the order of the softkeys. Enter exit to return to global configuration mode. 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). From ephone configuration mode, use the command ephone-template 2 to apply the template to the ephone. Reset the phone by either pressing **#** on the keypad or typing reset from ephone mode. Enter exit to go back to global configuration mode. Notice the order of the softkeys when the IP Phone is finished resetting. Save your changes by using the command copy run start .
You have completed this task when you attain these results: 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
Configure a new ephone DN with the command ephone-dn 4 from global configuration mode. Assign the new DN a number of X010 (where X is the pod number). Go to the first ephone with the command ephone 1 command. Assign the ephone-dn to button 2 of the ephone with the command button 1:1 2:3 3:4. Enter exit to go back to global configuration mode. Configure a new ephone DN with the command ephone-dn 5 from global configuration mode. Assign the new DN a number of X011 (where X is the pod number). Assign the ephone-dn to button 2 of the ephone with the command button 1:2 2:5. Now create a sequential hunt group with the command ephone-hunt 1 sequential . In ephone hunt configuration mode, enter a pilot of X200 with the command pilot X200 (where X is the pod number).
Lab Guide 53
Create the order of the sequential hunt group by using the list X000, X002, X010, X001, X011 command. 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. Enter exit to return to global configuration mode. 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? _____________ 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? _____________ 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? ___________________________________________________________________ Now create a longest idle hunt group with the command ephone-hunt 2 longestidle. In ephone hunt configuration mode, enter a pilot of X201 with the command pilot X201 (where X is the pod number). Create the order of the sequential hunt group by using the list X000, X001, X010, X011 command. 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. Enter exit to return to global configuration mode. From the analog phone in your pod, call the pilot number of X201 and answer the call immediately on the first line that rings. Which line rang? _____________ From the analog phone in your pod, call the pilot number of X201 and answer the call immediately on the first line that rings. Which line rang? _____________ From the analog phone in your pod, call the pilot number of X201 and answer the call immediately on the first line that rings. Which line rang? _____________ From the analog phone in your pod, call the pilot number of X201 and answer the call immediately on the first line that rings. Which line rang? _____________ On one of the two IP Phones, use the DND softkey to put the IP Phone in the DND state. From the analog phone in your pod, call the pilot number of X201 and answer the call immediately on the first line that alerted. Which line rang? _____________ From the analog phone in your pod, call the pilot number of X201 and answer the call immediately on the first line that alerted. Which line rang? _____________ From the analog phone in your pod, call the pilot number of X201 and answer the call immediately on the first line that alerted. Which line rang? _____________ From the analog phone in your pod call the pilot number of X201 and answer the call immediately on the first line that alerted. Which line rang? _____________
Remove the DND state from the phone by pressing the DND softkey. Now create a sequential hunt group with the command ephone-hunt 3 peer. In ephone hunt configuration mode, enter a pilot of X202 with the command pilot X202 (where X is the pod number). Create the order of the peer hunt group by using the list X000, X002, X010, X001, X011 command. 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. Enter exit to return to global configuration mode. From the analog phone in your pod, call the pilot number of X202 and answer the call immediately on the first line that rings. Which line rang? _____________ From the analog phone in your pod, call the pilot number of X202 and answer the call immediately on the first line that rings. Which line rang? _____________ From the analog phone in your pod, call the pilot number of X202 and answer the call immediately on the first line that rings. Which line rang? _____________ From the analog phone in your pod, call the pilot number of X202 and answer the call immediately on the first line that rings. Which line rang? _____________ Return to the first configured hunt group by using the command ephone-hunt 1 sequential. Turn on automatic logout by using the command auto logout . From the analog phone in your pod, call the pilot number of X200 and do not answer the call until X001 is ringing. From the analog phone in your pod, call the pilot number of X200 and do not answer the call. What is the order that is used by the hunt group? __________________________________________________________________ Notice that ephone 1 is in the DND state. Remove the DND and call the pilot number of X200 again.
Step 45
You have completed this task when you attain these results: 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. Use the command show flash to verify that all nine files are present in flash. 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. 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 2 Step 3
Step 4
Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20 Step 21 Step 22 Step 23 Step 24
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. Set the time before the caller hears the second greeting to 30 seconds with the call application voice aa second-greeting-time 30 command. Set the maximum time in queue to 60 seconds with the command call application voice aa max-time-call-retry 60 . 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 . Associate the name of the call queuing application with the automated attendant using the command call application voice aa service-name queue . Set the zero out to operator function by using the call application voice aa operator X100 command (where X is the pod number). Define which option will be used to dial an extension with the call application voice aa dial-by-extension-option 1 command. Set the voice mail extension with the command call application voice aa voicemail X900. Set the number of hunt groups to three with the command call application voice aa number-of-hunt-grps 3. Assign the language with the command call application voice aa language 1 en . Set the language to English with the command call application voice aa setlocation en 0 flash: Define the call queuing TCL script with the command call application voice queue flash:app-b-acd-2.0.0.0.tcl . Set the call queue length to ten callers with the command call application voice queue queue-len 10. Set option 2 in the menu to use hunt group X200 with the command call application voice queue aa-hunt3 X200. Set option 3 in the menu to use hunt group X201 with the command call application voice queue aa-hunt4 X201. Set the option 4 in the menu to use hunt group X202 with the command call application voice queue aa-hunt2 X202. Set the number of hunt groups to three with the command call application voice queue number-of-hunt-grps 3 . Associate the automated attendant name with the call queuing application with the command call application voice queue aa-name aa. Enable debugging of the B-ACD scripts with the command call application voice queue queue-manager-debugs 1. Make a new dial peer by using the command dial-peer voice 6 pots .
Lab Guide 57
In dial peer mode, enter the command application aa to associate the B-ACD service to the dial peer. In dial peer mode, enter the command incoming called-number X300 to match the call incoming. 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). Enter exit to return to global configuration mode. Create a loopback interface that will be used for a VoIP dial peer by entering the command interface loopback 0. 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). Enter exit to return to global configuration mode. Make a new dial peer by entering the command dial-peer voice 7 voip . In dial peer mode, enter the command application aa to associate the B-ACD service to the dial peer. In dial peer mode, enter the command incoming called-number X300 to match the call incoming. In dial peer mode, enter the command destination-pattern X300. Point to the loopback IP address with the command session target ipv4:10.X1.0.1. Enable DTMF relay with the command dtmf-relay h245-alphanumeric . Set the codec to G.711 with the command codec g711ulaw. Disable VAD with the command no vad. Enter exit to return to global configuration mode. 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. Use the command show call application session to verify that the application has been invoked. 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. Turn on debugging of the B-ACD service by using the command debug voip ivr script. Place a call to the pilot of X300 and view the output.
Step 28 Step 29 Step 30 Step 31 Step 32 Step 33 Step 34 Step 35 Step 36 Step 37 Step 38 Step 39 Step 40 Step 41 Step 42 Step 43 Step 44 Step 45
You have completed this task when you attain these results: 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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13
Open a console connection to the Cisco CallManager Express system. Enter enable to enter privileged EXEC mode. Enter configure terminal to enter global configuration mode. Enter the command ephone-dn 8 to create an ephone for use as a call park slot. Use the number X400 command to assign an extension. Use the command park-slot timeout 10 limit 3 to set a reminder after ten seconds and to terminate the call after three reminders. Reset the IP Phones by using the keys on the IP Phones to enter **#**. From the analog phone, call one of the IP Phones and answer the call. Use the More softkey button to find and press the Park softkey button. Wait ten seconds. What do you hear on the analog phone and on the IP Phone? Wait another twenty seconds. What happens to the call? From the analog phone, call one of the IP Phones and answer the call. Use the More softkey button to find and press the Park softkey button.
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. Hang up the call. From the analog phone, call one of the IP Phones and answer the call. Use the More softkey button to find and press the Park softkey button. 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. From the analog phone, call one of the IP Phones and answer the call. Use the Trnsfr softkey button to transfer the call to the extension number X400. 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. Hang up the call.
Step 22
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
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. From the Configure drop-down menu, choose System Parameters. On the System Parameters page, highlight the System Message object and enter a message of IPTX Classroom. Go to a terminal and enter the CLI of the Cisco CallManager Express router. Go to global configuration mode by using the configure terminal command.
Enter the ephone configuration mode for the first IP Phone by using the ephone-dn 1 command. Enter the description Phone1 command to set the label on the IP Phone header bar. Enter the ephone configuration mode for the second phone by using the ephone-dn 2 command. Enter the command description 20X5559001 (where X is the pod number) to set the IP Phone header bar. Enter exit to go back to global configuration mode. Enter the command ephone-dn 1 to enter the configuration for your first ephone-dn. Enter the command label my line X000 (where X is equal to the pod number) to set a label on ephone-dn 1. Reset all the IP Phones by pressing **#** on the keypad of both IP Phones. Enter the show running-config | begin telephony-service command to view the changes. Enter the copy running-config startup-config to save the changes. Notice the system message of IPTX Classroom. 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 Step 2
As the system administrator, configure a new extension by choosing the Configure >Extension menu from the GUI web-based interface. 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 Step 4
Add a second new extension. 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. Assign ephone-dn 7 to a free line of ephone 1 by going to the Configuration > Phones menu. Assign ephone-dn 8to a free line of ephone 2. Reset both phones by pressing **#** on the keypads. 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. Go to a terminal window and, at the CLI, enter privileged EXEC mode using the enable command. Enter the show running-config | telephony-service to view the changes made to the configuration. 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 Step 2
As the system administrator, configure a new extension by choosing the Configure >Extension menu from the GUI web-based interface. 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. Add a second new extension.
Step 3
Step 4
Set the extension number to X 550 (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. Assign ephone-dn 9 to a free line of ephone 1 by choosing the Configuration> Phones menus. Assign ephone-dn 10to a free line of ephone 2. 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. Using the analog phone, dial X500 (where X is the pod number). Verify that the intercom works. Using the analog phone, dial X550 (where X is the pod number). Verity that the intercom works. Go to a terminal window and at the CLI, enter privileged EXEC mode using the enable command. Use the show running-config | begin tele to view the changes made to the configuration. Notice the settings under the ephone-dn and ephone sections.
You have completed this task when you attain these results: 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
As the system administrator, choose the Configure >Extension menu in the GUI web interface. 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. 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. Assign the paging ephone-dn X600 to ephone 1 and X700to ephone 2. Click yes for Unicast. Test the paging function by dialing X600 and X700 from the analog phone. Use the terminal to access the CLI and enter privileged EXEC mode with the enable command. From privileged EXEC mode, enter the configure terminal command to go to global configuration mode. From global configuration mode, enter the ephone-dn 13 command to create a new ephone-dn. Assign a directory number to the page using the number X800 command (where X is the pod number). Enter the name EmergencyAll command to assign a name. Enter the command paging ip 239.1.1.1 . port 2000.
Enter the command paging group 11,12 . Enter exit to go to global configuration mode. Enter exit to go to privileged EXEC mode. Use the copy running-config startup-config to save the changes. 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
Place a call from one IP Phone to the other IP Phone in the pod. While the call is in progress, press the Acct! softkey and enter 12341234#. Enter the show call active voice command to view the account number. 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.
- -- - - -- - --- - - - --- -- - --- - - - -- - - - - - - - - - - - - - - - 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
Visual Objective for Lab 5-1: Configuring Cisco Unity Express PodX
Unity Express
Use to the Automated Attendant
SIP
CallManager Express
Web browser for Using the GUI Interface
X100
SCCP
IPTXUser1 With a Mailbox
SCCP
IPTXUser2 With a Mailbox
X000X001
IPTX v2.0 7
Required Resources
These are the resources and equipment required to complete this activity: 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 Worksheets from Lab 2 or completed form from end of the Lab Guide
Command List
Command Description Enters privileged EXEC mode Displays the installed software version and hardware Displays an overview of interfaces, IP addresses, and status Enters global configuration mode 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
These job aids are available to help you complete the lab activity. 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
From the console of your router, enter the command enable. Enter the enable password (cisco) when prompted. Enter the show version command to verify that the Cisco service engine is detected. Enter the show ip interface brief command to determine the interface number of the service engine. Write the interface number here: _________________. Enter global configuration mode by using the configure terminal command. Go to the service engine interface with the interface service-engine Module/Port command using the information from the show ip interface brief command. 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. 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 Step 9 Step 10 Step 11 Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20 Step 21 Step 22 Step 23 Step 24 Step 25 Step 26 Step 27 Step 28 Step 29 Step 30 Step 31
Set a default gateway on the module by using the service-module ip defaultgateway 10.X0.0.1 command. Enable the interface by typing the no shutdown command. Enter exit to go back to global configuration mode. 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. 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 . In dial-peer mode, enter the command destination-pattern X9.. (where X is the pod number). Enter the command session protocol sipv2 to use SIP for this dial peer. Enter the command dtmf-relay sip-notify to send DTMF digits in notify packets. Enter the session target ipv4:10.X0.0.10 command (where X is the pod number) to specify the IP of the service engine. Set the codec to G.711 with the command codec g711ulaw. Disable voice activity detection with the command no vad. Enter exit to go back to global configuration mode. To create a MWI on an ephone-dn, enter the command ephone-dn 14. In the ephone-dn submode, enter number 9001.... ( the four periods represent the four digits in the dial plan). Enter the command mwi on. Create the MWI off on an ephone-dn by entering ephone-dn 15. In the ephone-dn submode, enter number 9000.... ( the four periods represent the four digits in the dial plan). Enter the command mwi off. Enter exit to return to global configuration mode. Enter the command ntp master to enable network time protocol. Enter exit to go to privileged EXEC mode 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). Enter the command copy running-config startup-config to save the changes. Use the command show running-config to view the configuration.
You have completed this task when you attain these results: 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
Collect the IP address of the classroom TFTP server from the instructor: _________________ Collect the IP address of the classroom FTP server from the instructor: __________________ Ping the TFTP and FTP servers (they may be the same machine) to verify connectivity. If any problems occur, tell your instructor. 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.) Enter the command reload at the prompt. If you are sure a reload is wanted, enter y when prompted. 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. The module will then be in a ServiceEngine boot-loader mode. At the prompt, enter config to configure the boot helper. Enter an IP address of 10.X0.0.10 (where X is the pod number). Enter a subnet mask of 255.255.255.0 . Enter the address of the TFTP server that your instructor gave you. Enter a default gateway of 10.X0.0.1 (where X is the pod number). Enter cue-installer.2.1.0.17 as the name of the installer file. Accept the default setting of internal! for the Ethernet interface. Accept the default setting of disk! for default boot.
Lab Guide 75
Accept the default setting of primary! for the default boot loader. This will now save the boot loader configuration to flash. Ping the TFTP and FTP servers (they may be the same machine). 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. A menu will be presented allowing the installer to select to either install software or to reload the module. Choose the install software option. 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. When asked for the URL, enter the following: ftp://ip-address/ (where the IP address is provided by the instructor). When prompted for a username, enter anonymous or a username provided by your instructor. When prompted for a password, leave the field blank or enter the password provided by your instructor. 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. When asked for the URL, enter the following ftp://ip-address/ (where the IP address is provided by the instructor). When prompted for a username, enter anonymous or a username provided by your instructor. When prompted for a password, leave the field blank or enter the password provided by your instructor. Next, a language menu will appear. Select the desired language by entering the corresponding number. Up to two languages may be selected. When the desired language(s) have been selected, enter x to continue with the installation of the package. 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. When prompted, and if you are sure, enter y. Important! If you are asked if the configuration should be restored, enter n to not restore the configuration. When prompted, enter a hostname of CUEX (where X is the pod number). When prompted for a domain name, refer to Table 5 to specify the pod domain name.
Step 19 Step 20
When asked if DNS is going to be used, enter n. Then enter y when prompted if you are sure. When asked for the IP address of the primary NTP server, enter 10.X0.0.1 (where X is the pod number). When asked for the IP address of the secondary NTP server, press the Enter key to bypass. Choose the continent that you are on. Choose the country where you are. Choose the time zone if prompted. 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). When prompted for an administrator ID, enter CUEAdmin. When prompted for a password, enter cisco. When prompted for confirmation, enter cisco. The prompt should now show CUEX> (where X is the pod number). 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). Use the command show software licenses and verify that there are 50 personal mailboxes. Verify that the application mode is equal to CCME.
You have completed this task when you attain these results: 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
Verify that the command web admin exists by using the show running-config | begin web admin command. Open Internet Explorer and enter the URL http://10.X0.0.10 (where X is the pod number) from the student PC. 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. Choose the option Run Initialization Wizard to start the configuration process.
Lab Guide 77
Step 4
Step 5 Step 6
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. 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. The third step allows the default setting and actions to be defined. Leave all settings at the default. Click Next. The fourth step defines the call handling. On this page, enter X900 for the Voice Mail Number (where X is the pod number). Set the Voice Mail Operator to X000. Enter X901 for the Auto Attendant Access Number (where X is the pod number). Enter X001 for the Auto Attendant Operator Number (where X is the pod number). Enter X902 for the Administration Via Telephony Number (where X is the pod number). 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. Leave all other settings to default, then click Next. 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. A summary page will be displayed. Note the password and PIN for the user imported and write them down here. Password_______________________ PIN________ Verify that there are no failures. If there are failures, notify your instructor, then click Logout. Click Login Again and enter a username of CUEAdmin and a password of cisco and verify that the administrative web page can be accessed.
Step 14 Step 15
Step 16
Step 17 Step 18
You have completed this task when you attain these results: 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
From the administrative web interface, logged in as the administrator, choose the Defaults>User menu. View the user defaults and available options. Choose the Defaults > Mailbox menu. View the mailbox defaults for any new mailboxes. Choose the Defaults>Voice Mail menu. 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
From the administrative web page, choose Configure>Users . From the Users menu, choose the user JDoe. A User Profile page will appear. On the properties page, set the first name and last name based on Table 4 For the Primary E.164 Number field, enter 20X5559000 (where X is the pod number). Enter cisco in the Password and Confirm Password fields. Enter 1234 in the PIN and Confirm PIN fields. Click Apply to apply the changes. Press the Messages or Envelope icon button on your X000 IP Phone (where X is the pod number). 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). 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
You will then be played a standard greeting and will be presented with the option to record a personal greeting by pressing 1. Next, a new PIN must be entered twice. Use 4321. Hang up the call to voice mail. 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. Leave a message with urgent priority (the minimum length of a message is two seconds). 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. 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. When done, delete the message.
You have completed this task when you attain these results: 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
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. Log in as the administrator with the credentials of CUEAdmin and a password of cisco. Choose the Configure>Users menu . On the Users page, add a new user. The Add a New User page will appear. Fill in the page with the information in the following steps. Set the User ID, First name, and Last name for the second ephone based upon Table 4. Set the Primary E.164 Number to 20X5559001 (where X is the pod number). Associate a Primary Extension by clicking Add/Edit and choosing the second IP Phone in your pod X001. Click Specify. Set a password of cisco.
Click Specify. Set a PIN of 1234. Click the Create Mailbox checkbox. Click the Add button. The Add a New Mailbox page will appear. Leave the settings at the default and click Add. Verify that the new user appears on the Users page within the administrative web pages. On the second IP Phone ( X001), call voice mail and set up the mailbox by recording a recorded name and a personal greeting. Set the PIN to a new value of 4321.
You have completed this task when you attain these results: 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
Open the CUE administrative web page by browsing to http://10.X0.0.10 (where X is the pod number). Log in as the administrator with the credentials of CUEAdmin and a password cisco. Choose the Administration>Network Locations menu. From this page, click Add. 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. Click Add a second time and define the local pod information. Using Table 5, configure the pop-up window Add a New Location to configure your pod"s 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 5 Step 6
In the Local Location ID field, enter the location ID of the local location and click Apply. 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). 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? 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 partner "s 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? Check the message that arrives. 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. 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. Press 3 for voice mail administration Press 2 for spoken name administration. Press 1 for a spoken name for a location. Enter the location ID for your partner pod. When prompted, record the name of the location for the pod of your partner. When completed, disconnect the call. 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? Using Table 4, configure both users for your partner pod by choosing the Configure >Remote Users menu. 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. 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. 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 10
Step 11 Step 12
Step 20 Step 21
Step 22
Step 23
Task 8: Distribution Lists

In this task, a public distribution list will be configured for the sales team.
Activity Procedure
Browse to the CUE administrative web page at http://10. X0.0.10 (where X is the pod number). Log in as the administrator with the credentials of CUEAdmin and a password of cisco. Choose the Voice Mail>Distribution Lists menu and then choose Public Lists. On the Public Lists page, click Add. In the Add a Public Distribution List window that appears, configure a name of Sales and a number of X998. Click Add when completed. Choose the new distribution list named Sales from the Public Lists page. In the Public List $ Sales web page, choose the Members tab and then click Add Member. On the Find web page, choose the ID radio button and then click Find. 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. From a phone that is not in the distribution list, press the Messages button and log in to the voice mailbox. When prompted to send a message, press 2. Spell the name of sales by pressing 7 " 2 " 5 " 3 " 7. 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
Browse to the CUE administrative web page at http://10. X0.0.10 (where X is the pod number). Log in as the administrator with the credentials of CUEAdmin and a password of cisco. Choose the Configure>Extensions menu. Click Add. 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. Choose the Configure>Phones menu item. 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. Repeat the previous steps for the second IP Phone in the pod. Choose the Configure>Groups menu. From the Groups page, click Add. 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. The Add a New Mailbox page will open up. Leave the defaults settings and click Add. Choose the Configure>Groups menu. From the Groups page, choose the Sales group and go to the Owners/Members tab. Click +Subscribe member to open a Find page. Click the blue Find button, choose both of the pod "s users, and click +Select row(s). 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. Call voice mail by pressing the envelope icon button on an IP Phone and, when prompted, enter the PIN number of 4321. 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.) The tutorial will play. Record a name and personal greeting for the group.
Step 5 Step 6
Step 14 Step 15
Step 16
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.) Call voice mail by pressing the envelope icon button on the phone and, when prompted, enter the PIN number of 4321. 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.
Step 18 Step 19
You have completed this task when you attain these results: 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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13
Attempt to dial the Administrative TUI by dialing X902 from extension X000. Enter the extension and PIN when prompted. What is the result? Browse to the CUE administrative web page at http://10. X0.0.10 (where X is the pod number). Log in as the administrator with the credentials of CUEAdmin and a password of cisco. Choose the Configure>Groups menu. From this menu, choose the Sales group that was previously configured. Click the Voicemail Broadcaster checkbox and click Apply to save the changes. Dial the Administrative TUI by dialing X902 from extension X000. Enter the extension and PIN when prompted. What is the result? Press 3 for voice mail administration. Press 1 for broadcast administration. Press 1 to send a broadcast to subscribers on this server. Record the message. Send the message by pressing #. Who received the message? Dial the Administrative TUI by dialing X902 from extension X000. Enter the extension and PIN when prompted. What is the result? Press 3 for voice mail administration. Press 1 for broadcast administration.
Lab Guide 85
Press 2 to send another location. Press 2 to send to one or more locations. Enter the location ID of your partner followed by #. 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.
In the administrative web interface choose the Voice Mail > Business Hour Settings menu. Notice that there is a Business Hour Schedule of systemschedule defined by default. What are the open hours by default? ___________________________Add a new schedule by clicking Add. In the Add a New Schedule web page that appears, define a name for the new schedule called summerschedule. Note that by default the schedule is always open. Note the current day and time. 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:30$3:00 p.m. intervals to closed. This will allow you to test what happens when the current time is closed. Choose Apply to commit the changes to the summerschedule.
Step 10
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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20 Step 21 Step 22
From the analog phone, dial the number of the automated attendant. This should be X901 (where X is the pod number). 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. Hang up the call. Dial the automated attendant again and enter the automated attendant prompts. 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. Hang up the call. Go to the web interface and log in as an administrator with the credentials of CUEAdmin and a password of cisco. Choose the Voice Mail>Auto Attendant menu. Choose the default automated attendant called Autoattendant and an Automated Attendant Profile page will appear. Click Next. On the Script Parameter page, set operExtn* to X000, and note that the businessSchedule parameter is selected by default, then click Next. Click Finish. Dial the automated attendant again and enter the automated attendant prompts. Press 0 for the operator when prompted. Choose the Voice Mail>Auto Attendant menu. Choose the default automated attendant called Autoattendant and an Automated Attendant Profile page will appear. Click Next. On the Script Parameter page, set the businessSchedule parameter to summerschedule, then click Next. Click Finish. Dial the automated attendant again. What is the result? Choose the Voice Mail>Auto Attendant menu. Choose the default automated attendant called Autoattendant and an Automated Attendant Profile page will appear.
Lab Guide 87
Click Next. On the Script Parameter page, set the businessSchedule parameter back to the default of systemschedule, then click Next. Click Finish. Choose the Voice Mail>Holiday Settings menu. Click Add. On the Add New Holiday web page, click the calendar icon and select today "s date. Click Add to commit the holiday. Dial the automated attendant again. What is the result? Choose the Voice Mail>Holiday Settings menu. Select the previously configured holiday and click Delete.
You have completed this task when you attain these results: 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
Add the users to the administrator group by choosing the Configure>Groups menu. Choose the Administrators group and, on the Group Profile page that appears, choose the Owners/Members tab. Click the checkboxes for both users and click Subscribe Member. Enter the Administrative TUI by calling X902 and entering your extension and PIN. Choose 2 to administer custom prompts. Press 1 when prompted to create a new prompt. Record a prompt for the ACME company that says Thank you for calling ACME.! Create a second prompt that says For sales, press one; for support, press two; for the operator, press zero .!
Create a third prompt that says I am sorry that you are having problems .! Create a fourth prompt that says I am sorry the number you are trying to reach is busy, please call back late r.! Create a fifth prompt that says I am sorry but we are currently closed !. Hang up the call. Open the web administrative GUI interface by logging in with the CUEAdmin username and a password of cisco. Choose the VoiceMail>Prompts menu. Notice that the four prompts are present in the order recorded with a timestamp. Notice the name of the .wav file that was recorded. There is a timestamp embedded in the name. Choose the prompt that was recorded first and rename it to ACMEWelcome.wav and then click Apply. Choose the prompt that was recorded second and rename it to ACMEMenu.wav and then click Apply. Choose the prompt that was recorded third and rename it to ACMEProblems.wav and then click Apply. Choose the prompt that was recorded fourth and rename it to ACMEClosed.wav and then click Apply. 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
The instructor will instruct you on the location of the CUEEditor.2.1.1.exe. Run the CUEEditor.2.1.1.exe application to install the CUE Auto Attendant Editor. Click Next to start the install. Click Yes to the licensing agreement. Click Next to accept the default installation path.
Lab Guide 89
Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20 Step 21 Step 22 Step 23 Step 24 Step 25 Step 26
When the installation completes, click Finish. To start the CUE Auto Attendant Editor, click the Start button in MSWindows on your PC and go to the Program Files. From Program Files, move to the Cisco CUE Developer object and then start the Cisco CUE Editor. Press CTRL-N to start a new script. A page will appear with a Start flag on it. Expand all of the folders on the left pane to view all of the steps. In the variable pane (bottom left pane), click the blue arrow icon to add a new variable. The Edit Variable window will appear. Give the variable a case-sensitive name of welcomeGreetingACM. For the Type field, choose Prompt. Leave the value blank, check the Parameter box, and click OK. In the variable pane (bottom-left pane), click the blue arrow icon to add a new variable. The Edit Variable window will appear. Give the variable a (case-sensitive) name of menuACME. For the Type field, choose Prompt. Leave the value blank, click the Parameter checkbox, and click OK. In the variable pane (bottom-left pane), click the blue arrow icon to add a new variable. The Edit Variable window will appear, give the variable a (case-sensitive) name of systemProblemsACME. For the Type field, choose Prompt. Leave the value blank, click the Parameter checkbox, and click OK. In the variable pane (bottom-left pane), click the blue arrow icon to add a new variable. The Edit Variable window appears. Give the variable a (case-sensitive) name of systemSchedule. For the Type field, choose Schedule. Leave the value null, click the Parameter checkbox, and click OK. In the variable pane (bottom-left pane), click the blue arrow icon to add a new variable. The Edit Variable window appears. Give the variable a (case-sensitive) name of systemClosedACME. For the Type field, choose Prompt. Leave the value blank, click the Parameter checkbox, and click OK.
In the variable pane (bottom-left pane), click the blue arrow icon to add a new variable. The Edit Variable window appears. Give the variable a (case-sensitive) name of systemBusyACME. For the Type field, choose Prompt. Leave the value blank, click the Parameter checkbox, and click OK. In the variable pane (bottom-left pane), click the blue arrow icon to add a new variable. The Edit Variable window appears. Give the variable a (case-sensitive) name of operatorExtensionACME. For the Type field, choose String. Set the value to 0 (quotes must be included here), click the Parameter checkbox, and click OK. In the variable pane (bottom-left pane), select the blue arrow icon to add a new variable. The Edit Variable window appears. Give the variable a (case-sensitive) name of salesSharedDNACME. 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!. In the variable pane (bottom-left pane), click the blue arrow icon to add a new variable. The Edit Variable window appears. Give the variable a (case-sensitive) name of supportExtensionACME. 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!. Drag the Accept step from the Contact folder in the left pane and drop it on top of the Start step. From the Media folder, drag and drop the Play Prompt step on top of the Accept step. Right-click Play Prompt and choose Properties. Choose the Prompt tab and click the button with the ellipsis on it. From the drop-list of variables, choose the welcomeGreetingACME, then click OK. Click OK to close the properties page for the Play Prompts step. From the General folder, drag and drop the Label step on top of the Play Prompt step. Right-click the Label step and choose Properties. Change the name of the label to ACMECLOSED and click OK.
Lab Guide 91
Step 48 Step 49 Step 50 Step 51 Step 52 Step 53 Step 54 Step 55 Step 56 Step 57 Step 58 Step 59 Step 60 Step 61 Step 62 Step 63 Step 64 Step 65 Step 66 Step 67 Step 68 Step 69 Step 70
From the General folder, drag and drop another Label step on top of the ACMECLOSEDLabel step. Right-click the Label step and choose Properties. Change the name of the label to ACMEMENU and click OK. 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. Expand the plus in front for the Is Holiday step to reveal the Yes and No logic branches. From the General folder, drag and drop the Goto step on top of the Yes branch of the Is Holiday step. Right-click the Goto step and choose Properties. Select the ACMECLOSED label from the drop down. From the General folder, drag and drop the Business Hours step on top of the No icon under the Is Holiday step. Right-click the Business Hours step and choose Properties. Select the systemSchedule variable and click OK. Expand the plus in front of the Business Hours step to reveal the Open and Closed logic branches. From the General folder, drag and drop the Goto step on top of the Closed branch of the Business Hours step. Right-click the Goto step and choose Properties. Select the ACMECLOSED label from the drop down. From the General folder, drag and drop the Goto step on top of the Open branch of the Business Hours step. Right-click the Goto step and choose Properties. Select the ACMECMENU label from the drop down. From the Media folder, drag and drop the Menu step on top of the ACMEMENU label step. Right-click Menu and choose Properties. On the General tab, highlight Output 1 and notice the 1 is checked. Click Modify, rename it to Sales, and then click OK. On the General tab, highlight Output 2 and notice the 2 is checked. Click Modify and rename it to Support, then click OK. 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. On the Prompt tab, click the button with the ellipsis on it.
Step 71
Choose the list of variables and choose menuACME, then click OK. From the Input tab, notice the setting for timeouts and retries. Click OK to close the properties page for the Menu step. Drag and drop a Call Redirect step from the Call Contact folder onto the Sales branch of the Menu step. Right-click the Call Redirect step and choose Properties. For the Extension field, choose salesSharedDNACME, then click OK to save and close the Properties page. Drag and drop an End step from the General folder onto the Successful branch of the Call Redirect step. Drag and drop a Play Prompt step from the Media folder onto the Busy branch of the Call Redirect step. Right-click the Play Prompt step and choose Properties. On the Prompt tab, click the button with the ellipsis on it. Choose the variables menu and choose the systemBusyACME variable. Then click OK. Click OK to exit the Properties pages. Drag and drop a Terminate step from the Contact folder onto the Play Prompt in the Busy branch of the Call Redirect step. Drag and drop an End step from the General folder onto the Terminate in the Busy branch of the Call Redirect step. Drag and drop a PlayPrompt step from the Media folder onto the Invalid branch of the Call Redirect step. Right-click the PlayPrompt step and choose Properties. On the Prompt tab, click the button with the ellipsis on it. Choose the Variables menu and choose the systemProblemsACME variable. Click OK. Click OK to exit the Properties pages. Drag and drop a Terminate step from the Contact folder onto the Play Prompt in the Invalid branch of the Call Redirect step. Drag and drop an End step from the General folder onto the Terminate in the Invalid branch of the Call Redirect step. Drag and drop a Play Prompt step from the Media folder onto the Unsuccessful branch of the Call Redirect step. Right-click the PlayPrompt step and choose Properties. On the Prompt tab, click the button with the ellipsis on it.
Lab Guide 93
Choose the Variables menu and select the systemProblemsACME variable. Click OK. Click OK to exit the properties pages. Drag and drop a Terminate step from the Contact folder onto the Play Prompt in the Unsuccessful branch of the Call Redirect step. Drag and drop an End step from the General folder onto the Unsuccessful branch of the Call Redirect step. Highlight the CallRedirect step under the Menu, right-click it, and choose Copy. Highlight the Support folder under the Menu step, right-click it, and paste the Call Redirect step onto it. Highlight the Operator folder under the Menu step, right-click it, and paste the Call Redirect step onto it. Right-click the new Call Redirect under the Support folder and choose Properties. For the Extensions setting, change the variable to supportExtension. Click OK to exit the Properties pages. Right-click the new Call Redirect under the Operator folder and choose Properties. For the Extensions setting, change the variable to operatorExtension . Press OK to exit the Properties pages. For the Timeout branch of the Menu step, drag and drop Goto from the General folder. Right-click Goto and choose the Properties menu item. Choose the ACMEMENU label from the drop-down menu on the Properties page. Click OK. For the Unsuccessful branch of the Menu step, drag and drop Goto from the General folder. Right-click Goto and choose the Properties menu item. Choose ACMEMENU label from the drop-down menu on the Properties page. Click OK. Drag and drop a Play Prompt step from the Media folder onto the Label step called ACMECLOSED. Right-click the Play Prompt step and choose Properties. Select the variable named systemClosedACME from the prompt tab. Drag and drop a Terminate step from the Contact folder onto the Play Prompt under the ACMECLOSED Label step. Drag and drop an End step from the General folder onto the Play Prompt under the ACMECLOSED Label step.
Step 120 Step 121 Step 122 Step 123 Step 124 Step 125 Step 126 Step 127 Step 128 Step 129 Step 130 Step 131 Step 132 Step 133 Step 134 Step 135 Step 136 Step 137 Step 138 Step 139 Step 140 Step 141 Step 142
Validate the script by pulling down the Tools menu and choosing Validate . If validation succeeds, save by choosing the File>Save As menu. Save the file to the desktop as acmeaa.aef. Open the administrative web interface and choose the VoiceMail>Auto Attendant menu. On the Auto Attendant page, click Add to add a new automated attendant. This will start a three-step process. In the first step, click Upload. This will open an Upload page. Click Browse Click Upload to upload the file. Fill in the application name with acmeaa. Click Next to go to the second step. For the systemClosedACME prompt, choose ACMEClosed.wav. For the welcomeGreetingACME prompt, choose ACMEWelcome.wav. For the salesSharedDNACME prompt, choose X201 (where X is the pod number). For the SupportExtensionACME prompt, choose X000 (where X is the pod number). For the menuACME prompt, choose ACMEMenu.wav. For the systemProblemsACME prompt, choose ACMEProblems.wav . For the systemBusyACME prompt, choose ACMEBusy.wav. For the systemSchedule choose systemschedule. For the operatorExtensionACME prompt, choose X001 (where X is the pod number). Click Next to move to the third step. Define a pilot number of X903 for this new automated attendant and leave the other settings to defaults. Click Finish to complete the addition of a custom automated attendant. From the analog phone, call the number X903 and test all three options to verify functionality. to choose acmeaa.aef.
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
From the console of the Cisco CallManager Express router, enter enable to enter privileged EXEC mode. Enter the command debug ccsip calls. Place a call to voice mail. Notice the output. 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 Cisco CallManager Express router.
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 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11
Go to the CLI of the CUE module by entering the command #service-module service-engine mod/port session. Enter enable to go to privileged EXEC mode. Enter the command show logging to view the current level of console logging. Enter global configuration mode by entering the command configure terminal. From global configuration mode, enter the command log console errors and log console warning to enable all syslog messages to the console. Enter exit to return to privileged EXEC mode. Enter the command show logging to verify which levels of logging are turned on. Attempt to check the voice mail on one of your IP Phones. Enter an incorrect PIN three times in a row. Note the output. Hang up the call. Minimize the terminal window. Go to the GUI web interface as the administrator, choose the Administration> Trace menu.
Step 12 Step 13 Step 14 Step 15 Step 16 Step 17 Step 18 Step 19 Step 20 Step 21 Step 22 Step 23 Step 24 Step 25 Step 26
Notice the default level of tracing that is enabled (if an AIM-CUE is used, all tracing will be disabled). Disable all tracing if using the NM-CUE. Enter a checkmark enabling tracing for the root level Voicemail folder, which will enable all tracing underneath it for voice mail. Click Apply to commit the tracing changes. Minimize the web interface. Go back to the CLI of the CUE module and enter the command clear trace. Enter the show trace command to view the tracing that is enabled. Call one of the IP Phones and leave a message. Enter the command show trace buffer to view the output. Note the details in the output. Use the web interface to disable all tracing. In the ccn folder, check the box for all subfolders that start with Step % . Click Apply to commit the tracing changes. Go back to the CLI of the CUE module and enter the command clear trace. Call the custom automated attendant at X903 (where X is the pod number) and choose one of the options. Back at the CLI, use the show trace buffer command to view the output.
You have completed this task when you attain these results: 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

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

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

- - - -- - -- - -- - - - - - - - - -
-- - - -
Example Configuration of the Unity Express module

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

- ---- - - --- -- ---- -- - --- --- - - - ---- - - - - - ---- - - ---- - - ---- --- --- -- --- --- - -- --- - ---- - ---- - ----
- - - -- - - - - -- - - - - -
- - - - - - - -
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
Visual Objective for Lab 6-1: Configuring AutoQos

VoIP over Frame Relay
PSTN
Pod 1
Pod 2 Pod 3-6 202-555-9000
Pod 7
Pod 8
...
207-555-9000
201-555-9000208-555-9000
DLCI = 100DLCI = 200DLCI = 700DLCI = 800

2005 Cisco Systems, Inc. All rights reserved. IPTX v2.0 8
Lab Guide 105
Required Resources
These are the resources and equipment required to complete this activity: 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
Display and examine the running configuration of your CMERouterX. Enable CEF on your CMERouterX. Enable the AutoQoS for VoIP feature for traffic on the Sx/x interface. Do not configure AutoQoS to trust DSCP markings. Display and examine the resulting AutoQoS configuration after enabling AutoQoS. The following is an example output:
--- --- -- - -- -- - -- -- - - - - - -- - - - -- - - - -- - - -- -- --
- -- -- - -- -- - - 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
Display and examine the running configuration of your CMESwitchX switch. Enable the AutoQoS for VoIP feature for traffic on the Fa0/1 interface of CMESwitchX and trust the CoS markings from the core switch. 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 2 1001 DN Ephone 2 button 1 Dual 3 1002 DN Ephone 1 button 2 Dual 4 1010 DN Ephone 1 button 3 5 1011 DN Ephone 2 button 2 6 1400 Park N/A Timeout 10 seconds with 3 7 D3333 Non Dialable Intercom Ephone 1 button 4 Intercom to D4444 8 D4444 Non Dialable Intercom Ephone 2 button 3 Intercom to D3333 9 1500 Dialable Intercom Ephone 1 button 5 Intercom to 1550 10 1550 Dialable Intercom Ephone 2 button 4 Intercom to 1500 11 1600 Page Ephone 1 12 1700 Page Ephone 2 13 1800 Page N/A Page to 1600 and 1700 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 groups, multicast to 239.1.1.1 notifications
Lab Guide 109

Tag # Destination Pattern Incoming Called-number Port or Session Target Settings
1 1100 Lowest FXS 2 120.5550... Lowest FXO Forward all digits 3 120.5559... Lowest T1 port 4 120.5559... Lowest T1 port 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 port:23 Forward all digits port:23 Direct inward dial
Pod 1 Identity
Username IPTX First Name Last Name Ephone Comments
CUEAdmin IPTXCust
FPrefect Ford Prefect Ephone 1 Import to Unity from CME ADent Arthur Dent Ephone 2 Create in Unity
Pod 1 CUE Numbers

Number 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

1 2000 DN Ephone 1 button 1 Dual 2 2001 DN Ephone 2 button 1 Dual 3 2002 DN Ephone 1 button 2 Dual 4 2010 DN Ephone 1 button 3 5 2011 DN Ephone 2 button 2 6 2400 Park N/A Timeout 10 seconds with 3 7 D3333 Non Dialable Intercom Ephone 1 button 4 Intercom to D4444 8 D4444 Non Dialable Intercom Ephone 2 button 3 Intercom to D3333 9 2500 Dialable Intercom Ephone 1 button 5 Intercom to 2550 10 2550 Dialable Intercom Ephone 2 button 4 Intercom to 2500 11 2600 Page Ephone 1 12 2700 Page Ephone 2 13 2800 Page N/A Page to 2600 and 2700 groups, 14 9001.... MWI on N/A mwi on 15 9000.... MWI off N/A mwi off 16 2150 Group DN Ephone 1 button 6 Ephone 2 button 6 Applied to two ephones multicast to 239.1.1.1 notifications

Lab Guide 111
Pod 2 Identity
CUEAdmin IPTXCust
DAdams Douglas Adams Ephone 1 Import to Unity from CME Random Dent RDent Ephone 2 Create in Unity
Pod 2 CUE Numbers

Number 2900 Voice mail pilot number 2901 Default automated attendant 2902 Administrator TUI 9001.... MWI on 9000.... MWI off 2903 Custom automated attendant boston.cisco.com Domain Name Comments


Lab Guide 113
Pod 3 Identity
CUEAdmin IPTXCust
HHurtenflurst Hig Hurtenflurst Ephone 1 Import to Unity from CME HKavula Humma Kavula Ephone 2 Create in Unity
Pod 3 CUE Numbers

Number 3900 Voice mail pilot number 3901 Default automated attendant 3902 Administrator TUI 9001.... MWI on 9000.... MWI off 3903 Custom automated attendant atlanta.cisco.com Domain Name Comments


Lab Guide 115
Pod 4 Identity
CUEAdmin IPTXCust
CFitzmelton Cynthia Fitzmelton Ephone 1 Import to Unity from CME OColluphid Oolon Colluphid Ephone 2 Create in Unity
Pod 4 CUE Numbers

Number 4900 Voice mail pilot number 4901 Default automated attendant 4902 Administrator TUI 9001.... MWI on 9000.... MWI off 4903 Custom automated attendant dallas.cisco.com Domain Name Comments


Lab Guide 117
Pod 5 Identity
CUEAdmin IPTXCust
RMckenna Rob McKenna Ephone 1 Import to Unity from CME YVranx Yooden Vranx Ephone 2 Create in Unity
Pod 5 CUE Numbers

Number 5900 Voice mail pilot number 5901 Default automated attendant 5902 Administrator TUI 9001.... MWI on 9000.... MWI off 5903 Custom automated attendant portland.cisco.com Domain Name Comments


Lab Guide 119
Pod 6 Identity
CUEAdmin IPTXCust
ZBeetlebrox Zaphod Beetlebrox Ephone 1 Import to Unity from CME MProsser Marvin Prosser Ephone 2 Create in Unity
Pod 6 CUE Numbers

Number 6900 Voice mail pilot number 6901 Default automated attendant 6902 Administrator TUI 9001.... MWI on 9000.... MWI off 6903 Custom automated attendant raleigh.cisco.com Domain Name Comments


Lab Guide 121
Pod 7 Identity
CUEAdmin IPTXCust
HFrootmig Hurling Frootmig Ephone 1 Import to Unity from CME MQuordlepleen Max Quordlepleen Ephone 2 Create in Unity
Pod 7 CUE Numbers

Number 7900 Voice mail pilot number 7901 Default automated attendant 7902 Administrator TUI 9001.... MWI on 9000.... MWI off 7903 Custom automated attendant phoenix.cisco.com Domain Name Comments


Lab Guide 123
Pod 8 Identity
CUEAdmin IPTXCust
QRontok Questular Rontak Ephone 1 Import to Unity from CME FPrak Frank Prak Ephone 2 Create in Unity
Pod 8 CUE Numbers

Number 8900 Voice mail pilot number 8901 Default automated attendant 8902 Administrator TUI 9001.... MWI on 9000.... MWI off 8903 Custom automated attendant miami.cisco.com Domain Name Comments

IPTX v2.0

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

IPTX v2.0

Caricato da

Copyright:

Formati disponibili

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

2-132 2-135 2-136 2-137 2-137 2-139 2-159

Understanding Initial Phone Setup 2-137

ii IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.

References Module Self-Check Module Self-Check Answer Key 2-179

Volume 2 Configuring PSTN Interfaces and Voice Dial Peers 3-1

Understanding Analog and Digital Voice Interfaces 3-3

3-13 3-14 3-15 3-16

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

3-66 3-68 3-72 3-74 3-76 3-77 3-77 3-78

Understanding Class of Restriction 3-77

3-90 3-91 3-91

Describing H.450.x Protocols 3-91

3-106 3-116 3-117 3-117 3-118

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 Timer Settings Music on Hold Summary

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

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.

296 316 317 317 318

Volume 4 Introducing IP Quality of Service 6-1

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

6-70 6-73 6-75 6-75 6-76 6-83 6-85

Implementing AutoQoS 6-75

6-92 6-99 6-101 6-101 6-101 6-102 6-102

Case Study: QoS Mechanisms 6-101

Describing Deployment Scenarios and Design Considerations 7-3

7-26 7-27 7-27

Deploying Voice Mail with Cisco CallManager Express 7-27

7-38 7-39 7-39 7-40

2005, Cisco Systems, Inc. IP Telephony Express (IPTX) v2.0 ix

x IP Telephony Express (IPTX) v2.0 Copyright 2005, Cisco Systems, Inc.

Learner Skills and Knowledge

Prerequisite Learner Skills and Knowledge

2005 Cisco Systems, Inc. All rights reserved.

Course Goal and Objectives