CCIE Collaboration Quick Reference

From the Library of YAOBIN NDNF
CCIE Collaboration Quick

Reference
Akhil Behl, CCIE No. 19564
Cisco Press
800 East 96th Street
Indianapolis, IN 46240

ii CCIE Collaboration Quick Reference
CCIE Collaboration Quick Reference

Akhil Behl, CCIE No. 19564 (Voice and Security)
Copyright© 2014 Pearson Education, Inc.
Published by:
Cisco Press
800 East 96th Street
Indianapolis, IN 46240 USA
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording, or by any information stor-
age and retrieval system, without written permission from the publisher, except for the inclusion of
brief quotations in a review.
ISBN-13: 978-0-13-384596-9
ISBN-10: 0-13-384596-6
First Edition: May 2014 with corrections June 2014
Warning and Disclaimer

This book is designed to provide information about the Cisco CCIE Collaboration exam. Every
effort has been made to make this book as complete and as accurate as possible, but no warranty or
fitness is implied.
The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc.
shall have neither liability nor responsibility to any person or entity with respect to any loss or dam-
ages arising from the information contained in this book or from the use of the discs or programs
that may accompany it.
The opinions expressed in this book belong to the author and are not necessarily those of Cisco
Systems, Inc.
000_9780133845969_frontm.indd ii 6/24/14 3:40 PM

iii
Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have been
appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this
information. Use of a term in this book should not be regarded as affecting the validity of any
trademark or service mark.
Special Sales
For information about buying this title in bulk quantities, or for special sales opportunities (which
may include electronic versions; custom cover designs; and content particular to your business,
training goals, marketing focus, or branding interests), please contact our corporate sales depart-
ment at [email protected] or (800) 382-3419.
For government sales inquiries, please contact [email protected].
For questions about sales outside the U.S., please contact [email protected].
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each
book is crafted with care and precision, undergoing rigorous development that involves the unique
expertise of members from the professional technical community.
Readers’ feedback is a natural continuation of this process. If you have any comments regarding
how we could improve the quality of this book, or otherwise alter it to better suit your needs, you
can contact us through email at [email protected]. Please make sure to include the book
title and ISBN in your message.
We greatly appreciate your assistance.
Publisher: Paul Boger Senior Project Editor: Tonya Simpson
Editor-in-Chief: David Dusthimer Copy Editor: Bill McManus
Business Operation Manager, Cisco Press: Jan Cornelssen Technical Editor: Paulo Lopes
Executive Editor: Brett Bartow Editorial Assistant: Vanessa Evans
Managing Editor: Sandra Schroeder Designer: Mark Shirar
Development Editor: Marianne Bartow Composition: Jake McFarland

iv CCIE Collaboration Quick Reference
About the Author

Akhil Behl, CCIE No. 19564, is a solutions architect with Cisco Advanced Services,
focusing on Cisco Collaboration and Security architectures. He leads Collaboration
and Security projects and service delivery worldwide for Cisco Services and the
Collaborative Professional Services (CPS) portfolio. He has played a major role in service
conception and creation for various services within Cisco Advanced Services. Akhil has
a wide range of experience, from presales to sales to professional services to delivery to
post sales, with expertise in consulting, advisory, and guidance services. Prior to his cur-
rent role, Akhil spent 10+ years working in various roles at Linksys as a technical support
lead, as an escalation engineer at the Cisco Technical Assistance Center (TAC), and as a
network consulting engineer in Cisco Advanced Services.
Akhil has a bachelor of technology degree in electronics and telecommunications from

IP University and a master’s degree in business administration from Symbiosis Institute.
He is a dual Cisco Certified Internetwork Expert in Voice and Security. He also holds
many other industry certifications, such as PMP, ITIL, VCP, CCNA, CCSP, CCVP,
ISO/IEC 27002, TOGAF, and CEH.
Over the course of his career, Akhil has presented and contributed at various industry
forums such as Enterprise Connect, Cloud Connect, Cloud Summit, Interop, Cisco
Networkers, and SecCon. He has several research papers published in various national
and international journals, including IEEE journals, and is the author of the Cisco Press
title Securing Cisco IP Telephony Networks.

v
About the Technical Reviewer

Paulo Lopes is a network consulting engineer at the Advanced Services Center of
Excellence of Cisco Unified Communications for Cisco. He has been working at Cisco
supporting and deploying Cisco Unified Communications solutions for more than 10
years. Paulo is currently the tech lead of the Unified Communications virtual team for
the Americas.

vi CCIE Collaboration Quick Reference
Dedication
This book is dedicated first to my family, my dear wife Kanika and my lovely sons
Shivansh and Shaurya, for without their support, encouragement, and patience, it would
not exist. Secondly, to my parents, Vijay Behl and Ravi Behl, and my brothers, Nikhil
Behl and Ankit Behl, who have always been there to support me and guide me in all my
endeavors.
Acknowledgments
I would like to thank the following amazing people and teams for helping me create this
book:
My wife, Kanika, and my kids, Shivansh and Shaurya, for sacrificing many days and
weekends over the past year so that I could work on this book. Without their patience
and support, this book would not have been possible.
The technical reviewer, Paulo Lopes, for his invaluable feedback and for providing
exceptional technical coverage.
The Cisco Press editorial team: Brett Bartow, the executive editor, for seeing the value
and vision in the proposed title and providing me the opportunity to build this title; and
Marianne Bartow, development editor, and Christopher Cleveland, senior development
editor, for their support and guidance all throughout. It is my sincere hope to work again
with them in the near future.
Everyone else in the Cisco Press production team, for their support and commitment.

vii
Contents at a Glance
Chapter 1 Cisco Collaboration Infrastructure 1
Chapter 2 Quality of Service (QoS) 31
Chapter 3 Telephony Standards and Protocols 55
Chapter 4 Cisco Unified Communications Manager 95
Chapter 5 Cisco Unified Communications Security 145
Chapter 6 Cisco Unity Connection 167
Chapter 7 Cisco Unified IM and Presence 191
Chapter 8 Cisco Unified Contact Center Express 209
Chapter 9 Cisco IOS Unified Communications Applications 225
Chapter 10 Cisco Collaboration Network Management 283

viii CCIE Collaboration Quick Reference
Contents
Chapter 1 Cisco Collaboration Infrastructure 1
Cisco Unified Communications Deployment Models 1
Single-Site Deployment Model 2
Multisite WAN with Centralized Call Processing Deployment Model 3
Multisite WAN with Distributed Call Processing Deployment Model 4
Clustering over WAN Call Processing Deployment Model 5
Network Services 6
Dynamic Host Configuration Protocol 6
Domain Name System 7
Trivial File Transfer Protocol 8
Network Time Protocol 11
Cisco Discovery Protocol 12
Link Layer Discovery Protocol 14
Power over Ethernet 15
Voice and Data VLANs 16
IP Routing in Cisco Collaboration Campus Environments 17
Campus Infrastructure Design 17
Campus Access Layer 18
Campus Distribution Layer 18
Campus Core Layer 18
Campus Routed Access Layer Design 19
IPv6 in Cisco Collaboration Networks 20
IPv6 Address Types 21
IPv6 Addressing Model 21
Virtualization in Cisco Collaboration Solutions 23
Cisco UCS Servers 24
VMware ESXi for Cisco Collaboration Virtualization 26
UC Application Install Answer File 26
IP Multicast 27
Wireless in Cisco Collaboration Solutions 28
Chapter 2 Quality of Service (QoS) 31

QoS Requirements for Voice and Video 32
QoS Deployment Architectures 33
Classification and Marking 34

ix
Layer 2 Marking 34
Layer 3 Marking 35
Network-Based Application Recognition 36
Classification Service Classes 37
Classification and Marking for Softclients 37
Classification and Marking for Video Traffic 38
Queuing 38
Cisco Queuing Toolset 39
Weighted Random Early Detection 40
WAN QoS Considerations 41
Traffic Policing and Shaping 41
Link Efficiency Mechanisms 43
Compressed RTP 43
Link Fragmentation and Interleaving 43
Multilink PPP 44
Frame Relay Forum 12 44
Voice Activity Detection 45
LAN QoS Considerations 46
QoS Trust Boundary 46
QoS Considerations for WLAN Endpoints 47
QoS Considerations for Virtual Unified Communications with Cisco UCS 48
Medianet 49
Medianet QoS Classes of Service 52
Chapter 3 Telephony Standards and Protocols 55

Voice and Video Codecs 55
VoIP Media Transmission Protocols 57
VoIP Signaling Protocols 58
Skinny Client Control Protocol 58
Media Gateway Control Protocol 61
Session Initiation Protocol 65
SIP Session Description Protocol 71
SIP Binary Floor Control Protocol 72
H.323 Gateway, Gatekeeper, and RAS 73
H.323 Gateway 75
H.323 Gatekeeper 76
H.225 and RAS Signaling 77

x CCIE Collaboration Quick Reference
H.239-Based Dual Video Channels and Cisco Video Equipment Support 82

Analog Telephony 83
Foreign Exchange Office 83
FXO Disconnect 83
Foreign Exchange Station 84
E&M 84
Digital Telephony 85
Integrated Services Digital Network 85
Q Signaling Protocol 87
Channel Associated Signaling 87
T1 CAS 87
E1 R2 88
Non-Facility Associated Signaling 88
Analog and Digital Telephony Call Signaling Elements 89
Direct Inward Dial 89
Caller ID 89
Echo 90
Trans Hybrid Loss 90
Fax and Modem Protocols 91
Fax Services over IP Network 91
Modem Services over IP Network 93
Chapter 4 Cisco Unified Communications Manager 95

CUCM Redundancy and Device Registration 95
CUCM Device Pool 96
Common Device Configuration 98
Codec Selection 99
CUCM Features 100
Call Park and Directed Call Park 100
Call Pickup and Group Pickup 101
Meet-Me Conference 102
Busy Lamp Field Speed Dials 102
CUCM Native Call Queuing 102
Call Hunting 103
CUCM Media Resources 104
Annunciator 104
Conference Bridge 104

xi
Media Termination Point 105

Transcoder 105
Music on Hold 105
Media Resource Group and Media Resource Group List 106
Trusted Relay Point 107
CUCM Dial Plan 107
Partitions and Calling Search Spaces 108
Translation Patterns 109
Route Patterns 109
Route List 109
Route Group 110
Globalized Call Routing 110
Local Route Group 111
Time-of-Day Routing 112
Application Dial Rules 112
Directory Dial Rules 113
SIP Dial Rules 113
CUCM Digit Manipulation 114
CUCM H.323 and SIP Trunks 116
SIP Uniform Resource Identifier Dialing 117
Intercluster Lookup Service 119
Blended Addressing 122
CUCM Call Admission Control 122
Locations-Based CAC 123
Enhanced LCAC 124
Resource Reservation Protocol 126
RSVP SIP Preconditions 128
CUCM-Based Call Recording and Silent Monitoring 129
CUCM Mobility 133
Extension Mobility and Extension Mobility Cross Cluster 133
Device Mobility 135
Mobile Connect 136
Mobile Voice Access 138
Service Advertisement Framework and Call Control Discovery 140
SAF Architecture 140
Call Control Discovery Service 142

xii CCIE Collaboration Quick Reference
Chapter 5 Cisco Unified Communications Security 145

Security Policy 145
Threats to Cisco Collaboration Networks 146
Layer 1 Security 146
Port Security 147
DHCP Snooping 148
Root Guard and BPDU Guard 149
Dynamic ARP Inspection 149
802.1x 149
RFC 2827 Filtering 151
IP Source Guard 151
Unicast Reverse Path Forwarding 152
Routing Protocols Security 152
Router Hardening 152
(Firewall) Security for Layers 4 Through 7 152
Firewall Traversal Mechanisms 153
NAT Traversal 153
IPsec Tunnels 154
IP-Based ACLs 154
Port-Based ACLs 154
Cisco ASA Proxy Features 155
Cisco VPN Phone 156
Application Layer Security 157
CUCM Security By Default 158
CUCM Security Modes 158
CTL Client and CTL File 159
Cisco Unified IP Phone Certificates 161
SRTP and TLS 161
Preventing Toll Fraud 162
CUCM Class of Service 162
Cisco Voice Gateway Toll-Fraud Prevention Application 163
Voice Gateway Class of Restriction 164
Cisco Unity Connection Restriction Rules 165

xiii
Chapter 6 Cisco Unity Connection 167

Cisco Unity Connection High Availability 167
Cisco Unity Connection Integration with CUCM and CUCME 168
Cisco Unity Connection SCCP Voicemail Integration with CUCM 169
Cisco Unity Connection SIP Voicemail Integration with CUCM 171
Cisco Unity Connection SCCP Voicemail Integration with CUCME 172
Cisco Unity Connection SIP Voicemail Integration with CUCME 174
Cisco Unity Connection Dial Plan 175
Call Handlers 176
Cisco Unity Connection System Call Handlers 176
Cisco Unity Connection Directory Handlers 178
Cisco Unity Connection Interview Handlers 179
Cisco Unity Connection Single Inbox 180
Cisco Unity Connection Visual Voicemail 183
Voice Mail for Cisco Jabber 184
Cisco Unity Connection Voicemail Networking 186
Intrasite Networking 187
Intersite Networking 188
Voice Profile for Internet Email (VPIM) Networking 189
Chapter 7 Cisco Unified IM and Presence 191

Cisco Unified Communications Manager IM and Presence Components 191
Cisco Unified CM IM and Presence Cluster 192
Cisco Unified CM IM and Presence Server Integration with CUCM 193
Cisco Jabber 197
Presence Federation 198
Intradomain Federation 199
Interdomain Federation 201
Presence Cloud Solutions 202
Group Chat and Compliance 204
Group Chat 204
Logging and Compliance 205
Client-Side IM Logging (History) 205
Server-Side IM Logging (Compliance) 206

xiv CCIE Collaboration Quick Reference
Chapter 8 Cisco Unified Contact Center Express 209

Cisco UCCX Architecture 209
Cisco UCCX Components and Subsystems 210
UCCX ACD/ICD, IVR, and CTI Functions 211
UCCX ACD Functions 211
UCCX CTI Functions 213
UCCX IVR Functions 213
UCCX Deployment Models 214
UCCX Call Flow 215
UCCX Integration with CUCM 216
UCCX Scripting Components 218
Chapter 9 Cisco IOS Unified Communications Applications 225

Cisco Unified Communications Manager Express 225
Basic Cisco Unified CME Setup 226
Cisco Unified CME–Based SCCP Phone Registration 227
Cisco Unified CME–Based SIP Phone Registration 229
Cisco Unified CME Single Number Reach 230
Survivable Remote Site Telephony 232
MGCP Fallback 236
Multicast Music on Hold in SRST 237
Cisco IOS Dial Plan 238
Voice Translation Rules and Profiles 239
Cisco IOS Dial-Peer Matching Logic 242
Cisco IOS Media Resources 244
Cisco IOS DSP Management 244
Cisco IOS Conferencing Resources 245
Cisco IOS Transcoding Resources 246
Cisco Unified CME–Based Media Resources 246
Cisco Unified CME Conferencing and Transcoding 246
Cisco IOS–Based Call Queuing 249
Cisco Unified CME Basic Automatic Call Distribution 249
Voice Hunt Groups 252
Call Blast 253
Cisco Unity Express 254

xv
Cisco Unified CME and CUE Integration 254

CUE Message Waiting Indicator 256
Outcalling 256
(SIP) Subscribe Notify 257
Unsolicited Notify 257
CUE Web Inbox 258
CUE VoiceView Express 258
CUE Auto-Attendant 259
CUE Scripting 261
CUE Voice Profile for Internet Email 263
Cisco IOS Call Admission Control 266
Local CAC 267
Reservation-Based CAC 267
Measurement-Based CAC 268
Cisco IOS CDR Accounting 268
File Accounting 269
Syslog-Based CDR Accounting 269
RADIUS-Based CDR Accounting 269
Cisco Service Advertisement Framework and Call Control Discovery 270
Cisco Unified Border Element 272
CUBE Redundancy 273
CUBE SIP Profiles 277
CUBE Early Offer and Delayed Offer 278
CUBE DTMF Interworking 279
CUBE Mid-Call Signaling 281
Chapter 10 Cisco Collaboration Network Management 283

CUCM Serviceability and OS Administration 283
CUCM Database Replication 283
CUCM Service Activation 284
CUCM Call Detail Records and Call Management Records 288
CUCM Disaster Recovery 289
User Management 290
Cisco EnergyWise 292

xvi CCIE Collaboration Quick Reference
Icons Used in This Book
Communication PC PC with Sun Macintosh Access ISDN/Frame Relay

Server Software Workstation Server Switch
Token
Ring
Token Ring Terminal File Web Ciscoworks ATM Modem

Server Server Workstation Switch
Printer Laptop IBM Front End Cluster Multilayer

Mainframe Processor Controller Switch
FDDI
DSU/CSU
Gateway Router Bridge Hub DSU/CSU FDDI Catalyst
Switch
Network Cloud Line: Ethernet Line: Serial Line: Switched Serial

Cisco ASA

xvii
Command Syntax Conventions

The conventions used to present command syntax in this book are the same conventions
used in the IOS Command Reference. The Command Reference describes these conven-
tions as follows:
■ Boldface indicates commands and keywords that are entered literally as shown.
In actual configuration examples and output (not general command syntax),
boldface indicates commands that are manually input by the user (such as a
show command).
■ Italics indicate arguments for which you supply actual values.

■ Vertical bars (|) separate alternative, mutually exclusive elements.
■ Square brackets ([ ]) indicate optional elements.
■ Braces ({ }) indicate a required choice.
■ Braces within brackets ([{ }]) indicate a required choice within an optional
element.

This page intentionally left blank

Chapter 1
Cisco Collaboration
Infrastructure
Cisco Unified Communications (UC) is a way of creating collective and adaptive

workspaces by incorporating communications and collaboration products with
associated applications. Cisco UC helps people to work together more effectively
and efficiently by leveraging various unified applications and services such as voice
calls, voice messaging, presence, mobility, and video to people within and outside the
organization. This begins with building the underlying infrastructure to support Cisco
Collaboration applications, servers, devices, endpoints, and services.
Cisco Unified Communications Deployment Models

Cisco Unified Communications Manager (CUCM) is the brain of the Cisco UC solution
and provides a single interface to all other UC features and functions. CUCM supports
various deployment models. Each of these models is based on certain requirements of
the organization that deploys a Cisco UC network. The Cisco UC deployment models are
broadly classified as follows:
■ Campus deployment model: The Cisco UC and Collaboration services, which

include call control, media resources, endpoints, and other applications, are all
located on a single high-speed local-area network (LAN) or metropolitan-area
network (MAN).
■ Centralized deployment model: The Cisco UC and Collaboration services are

located in a central campus site or data center. However, the endpoints, applica-
tions, media resources, gateways, and other components are dispersed across several
remote sites. These sites may be interconnected to a central campus site and to each
other by a quality of service (QoS)-enabled WAN.
■ Distributed deployment model: The call control is dispersed across multiple remote
sites and multiple campus and/or centralized deployments that are interconnected
over a QoS-enabled WAN.

2 Chapter 1: Cisco Collaboration Infrastructure
These three broad deployment models can be further classified into the following cat-
egories of UC deployment models, which are described in more detail in the following
subsections:
■ Single-site
■ Multisite WAN with centralized call processing
■ Multisite WAN with distributed call processing
■ Clustering over WAN call processing
Apart from the preceding on-premises models, Cisco offers cloud-based (managed)
Collaboration solutions such as Cisco Hosted Collaboration Solution (HCS) and Cisco
Hosted Unified Communications Services.
Single-Site Deployment Model

In a single-site deployment model, all CUCM servers in a cluster, all UC applications, and
other media resources reside at the same location. All call processing is accomplished
at the designated site with gateway trunks that connect directly to the public switched
telephone network (PSTN) and handle external calls. As shown in Figure 1-1, this model
is ideal for small enterprises where call control should remain within a site (for example,
headquarters).
Applications Media Resources Infrastructure
V
Internet
CUCM
Cluster
CC
PSTN
Endpoints
Figure 1-1 Single-Site Deployment Model

The following are some best practices associated with the single-site deployment model:
■ Ensure that the infrastructure is highly available, enabled for QoS, and configured to
offer resiliency, fast convergence, and inline power.
■ Deploy QoS from IP Phone (user access layer) to CUCM (data center access layer) to
gateways for optimum voice quality.
■ Use a high-quality, low-compression codec such as G.711 for highest audio quality.
This also allows digital signal processor (DSP) resources to be allocated for confer-
encing or media termination point (MTP).
■ Deploy voice gateways or Session Border Controller (SBC) for Session Initiation
Protocol (SIP) trunks to the IT service provider (ITSP) for off-net calls to the PSTN
or a legacy PBX. All on-net calls should be limited to a central site based on calling
patterns for your enterprise.
Multisite WAN with Centralized Call Processing Deployment Model

In a multisite WAN with a centralized call processing deployment model, all CUCM
servers in a cluster reside at the same location. Optionally, applications and other media
resources may be deployed at the same location as well. If the applications and media
resources are at remote locations, it is beneficial to have a consolidated administration
of all resources. The remote sites rely on the centralized CUCM cluster for call process-
ing and other telephony functions. The centralized CUCM cluster connects with end-
points and applications at remote sites through a QoS-enabled IP WAN. Remote sites
are deployed with Cisco Unified Survivable Remote Site Telephony (SRST) on Cisco IOS
voice gateways that allow endpoints and applications to function when the connection
to the campus site is unavailable or disrupted. As shown in Figure 1-2, this deployment
model is ideal for small to medium enterprises.
Media and Conference Resources

Internet
CUCM
Cluster
IP WAN
V V
CC
PSTN
V
Endpoints
V
Endpoints
Figure 1-2 Multisite WAN with Centralized Call Processing Deployment Model

The following are some best practices associated with the multisite WAN with central-
ized call processing deployment model:
■ Use CUCM locations-based Call Admission Control (CAC) or Cisco IOS Resource
Reservation Protocol (RSVP)-based CAC. This prevents oversubscription of the IP
WAN as a result of voice calls.
■ Deploy Automated Alternate Routing (AAR) if the WAN bandwidth is full and CAC
doesn’t allow for new calls via the IP WAN.
■ Deploy SRST for remote sites to ensure that the branch router has the capacity for
handling IP Phone registration in case of a WAN failure. The voice gateway also
provides local PSTN connectivity for remote site endpoints so that emergency calls,
toll-free calls, and calls local to a region use the local gateway instead of the IP
WAN to the campus PSTN SBC or router.
■ Deploy a low-bandwidth audio codec (for example, G.729) between remote sites and
the central site and deploy G.711 within a site for optimum voice quality.
■ Deploy DSP resources at remote sites for conferencing, transcoding, or MTP resources.
Multisite WAN with Distributed Call Processing Deployment Model

In a multisite WAN with a distributed call processing deployment model, each site has
its own call control, such as a CUCM cluster, Cisco Business Edition 6000, or Cisco
Unified Communications Manager Express (CUCME). The remote sites can either have
their own media resources and applications or employ them from the campus site. The
dial plan can be aggregated using individual intercluster trunks (ICT) or Cisco Unified
Communications Manager Session Management Edition (SME) cluster(s). As shown in
Figure 1-3, this deployment model is ideal for medium to large enterprises.
Media and Conference Resources

Internet
CUCM
CUCM Cluster
Cluster
IP WAN
V V
CC
PSTN
V V
Endpoints
V
Endpoints
Figure 1-3 Multisite WAN with Distributed Call Processing Deployment Model
001_9780133845969_ch01.indd 4 6/24/14 4:23 PM

The following are some best practices associated with the multisite WAN with distrib-
uted call processing deployment model:
■ Deploy SIP proxies such as the Cisco Unified SIP Proxy (CUSP) to provide call rout-
ing and SIP signaling normalization.
■ In addition to other specific best practices for this model, follow general guidelines
for the single-site and multisite WAN with centralized call processing models.
Clustering over WAN Call Processing Deployment Model

In this deployment model, the call control (CUCM and Cisco Business Edition 6000)
CUCM is deployed across two or more data centers/sites over the IP WAN to provide
redundancy, both within the region and overall. This model is particularly useful where
multiple large sites have to be encompassed and dial-plan consistency must be main-
tained. Clustering over WAN can be either a local failover deployment model, where the
active and backup servers are at the same physical site, or a remote failover deployment
model, where the active and backup servers are at different sites/data centers. Figure 1-4
depicts the clustering over WAN call processing deployment model.
Media and Conference Resources Media Resources Infrastructure
Internet Internet
IP WAN
V V
CUCM
PSTN
Cluster Over WAN
V
PSTN
V V
V
Endpoints
Endpoints
Figure 1-4 Clustering over WAN Call Processing Deployment Model

The following are some best practices associated with the clustering over WAN call pro-
cessing deployment model:
■ The round-trip time (RTT) for cluster over WAN call processing should not be more
than 80 ms.
■ End-to-end QoS along with appropriate bandwidth provisioning specifically for

Intra-Cluster Communication Signaling (ICCS) is required. Overprovisioning and
undersubscription of bandwidth is recommended.
■ Minimize jitter, congestion, and packet loss for ICCS.

Network Services
This section covers the various network services essential for a functional Cisco
Collaboration solution:
■ Dynamic Host Configuration Protocol (DHCP)
■ Domain Name System (DNS)
■ Trivial File Transfer Protocol (TFTP)
■ Network Time Protocol (NTP)
■ Cisco Discovery Protocol (CDP)

■ Link Layer Discovery Protocol (LLDP)
Dynamic Host Configuration Protocol

DHCP is recommended for the successful deployment of UC endpoints such as Cisco
Unified IP Phones, Jabber clients, and so on. Although endpoints can be configured
with a static IP address, DHCP is particularly helpful in assigning IP address and other
important parameters in bulk to IP Phones. Individual DHCP scopes must be created
for each of the voice virtual LANs (VLAN), with sufficient addresses to support the
maximum number of phones likely to be deployed in that VLAN. The DHCP service can
be provided by CUCM, a Cisco IOS router or switch, or a third-party server (any RFC
2131–compliant DHCP server may be used to provide configuration information to IP
Communications network devices).
In addition to specifying the common DHCP options such as subnet mask, default router,
DNS servers, and so forth, each scope supporting Cisco Unified IP Phones should include
the specification of DHCP option 150. This option should contain the IP address of
TFTP servers. Because TFTP is crucial to the correct operation of a telephony network,
it is recommended that DHCP option 150 be used so that TFTP server redundancy can
be achieved by providing multiple differently ordered lists of TFTP server addresses to
hosts.
The DHCP lease time controls the duration for which an IP Phone retains an IP address
from a DHCP scope. Cisco Unified IP Phones request a new IP address after half the
lease time has expired since the last successful DHCP server acknowledgment. After the
request is acknowledged by the DHCP server, the IP Phone retains its IP scope.
For remote sites, DHCP service can be provided by local or remote DHCP servers.
Remote DHCP requests can be relayed by Cisco IOS routers/switches on behalf of the
requesting endpoint. DHCP relay is configured with the ip helper-address command.
The following example outlines the configuration of a Cisco IOS router to relay a DHCP
request to a DHCP server at a central site.
UCRouter(config)# interface GigabitEthernet 1/1
UCRouter (config-if)# ip helper-address 10.10.10.100

Network Services 7
Example 1-1 shows configuration of a DHCP server on a Cisco IOS router.
Example 1-1 Cisco IOS Router–based DHCP Server Configuration
UCRouter (config)# service dhcp

!
UCRouter (config)# ip dhcp excluded-address 10.10.0.1 10.10.0.10
!
UCRouter (config)# ip dhcp pool VOICE
UCRouter (config-dhcp)# network 10.10.0.0 255.255.255.0
UCRouter (config-dhcp)# default-router 10.10.0.1
UCRouter (config-dhcp)# domain-name mydomain.local
UCRouter (config-dhcp)# option 150 ip 10.76.108.146
UCRouter (config-dhcp)# lease 7
UCRouter (config-dhcp)# dns-server 10.10.0.2
In Example 1-1, the ip dhcp excluded-address command helps segregate addresses from
the assignment pool so they are not assigned to any endpoint. The DHCP pool defines a
network from which the endpoints can get their IP address, option 150, and other param-
eters, as explained earlier.
Domain Name System

DNS is used for name resolution and is particularly useful for management purposes and
load-balancing requirements. A Cisco Collaboration network and applications such as
CUCM, Cisco Unity Connection, Cisco Unified IP Phones, Cisco IOS routers, and other
devices can leverage DNS to resolve names to IP addresses.
However, Cisco strongly recommends that DNS not be used for critical communications
in the Collaboration network, such as IP Phone to CUCM, voice gateway to CUCM, and
intra-cluster communication. Cisco suggests using IP addresses, when possible, between
call control and endpoints to avoid any risk of registration failure, because endpoints
won’t be able to resolve the name of the CUCM server(s) when DNS service is unavail-
able. Because a DNS server can be a single point of failure in a Cisco UC network, Cisco
recommends deploying redundant DNS servers or using IP addresses.
During the initial installation of a CUCM cluster, the servers are referenced in the local
server table by their hostnames. Before you install and configure any endpoints on the
system, you should change this table to include the IP addresses of the servers instead of
their hostnames. To change the name of a CUCM server (which defaults to the hostname
during installation), go to the Cisco Unified CM Administration page, choose System >
Server, and replace the server name with its respective IP address, as shown in Figure 1-5.
001_9780133845969_ch01.indd 7 6/24/14 4:24 PM

Figure 1-5 CUCM Server Hostname to IP Address Substitution
This should be performed even if the system is configured to use DNS (that is, the DNS
client is enabled on the cluster servers).
Trivial File Transfer Protocol

TFTP is a crucial component of a Cisco Collaboration network as Cisco Unified IP
Phones require a TFTP server to retrieve their firmware, configuration files, phone but-
ton template, and other information. This only confirms that having TFTP redundancy is
paramount in a critical UC setup. As discussed earlier, DHCP option 150 can be used to
enable TFTP redundancy in a Cisco Collaboration network.
A TFTP server has various files that can be used by different types of endpoints (phones,
gateways, and so forth), such as the following:
■ Phone firmware files (Cisco-signed files, which are not modifiable)
■ Phone configuration files (XMLDefault.cnf.xml or SEP<MAC address>.cnf.xml)
■ Certificate Trust List (CTL) files (only if the cluster is in mixed mode)
■ Identity Trust List (ITL) files (for all endpoints that register with CUCM)
■ Tone localization files
■ User interface (UI) localization and dictionary files
■ Ring List files

Network Services 9
■ Softkey and Phone Button Template files
■ Background images
The Cisco Unified IP Phone to TFTP interaction process can be best illustrated by going
through the IP Phone bootup cycle, as shown in the following steps:
Step 1. Assuming that the IP Phone is connected to a Cisco Catalyst switch that is
capable of providing Power over Ethernet (PoE), using Fast Link Pulse (FLP),
the switch detects an unpowered IP Phone and powers it up using Cisco pro-
prietary standard (provides .48 V DC at up to 6.3 to 7.7 W per port over data
pins 1, 2, 3, and 6).
Step 2. Every IP Phone has nonvolatile flash memory in which it stores firmware
image(s). At startup, the IP Phone runs a bootstrap loader that loads an avail-
able phone image stored in flash memory. Using this image, the IP Phone ini-
tializes its software and hardware.
Step 3. As the IP Phone receives power and boots, the switch sends a Cisco
Discovery Protocol (CDP) packet to the IP Phone. This CDP packet provides
the IP Phone with voice VLAN (also known as auxiliary VLAN) information
so that the IP Phone can reach the appropriate VLAN and initiate a DHCP
request.
Step 4. The IP Phone sends a broadcast request such as a DHCP discover message
to the DHCP server in the voice VLAN. The DHCP server replies with an IP
address, a subnet mask, a default gateway, and the IP address of the Cisco
TFTP server. There could be additional optional parameters as well. However,
at a minimum, these steps are required for IP Phone connection.
Step 5. The IP Phone contacts the Cisco TFTP server or external TFTP server to
request firmware and files. The TFTP server sends the configuration informa-
tion for that IP Phone, which contains an ordered list of up to three CUCM
servers or two CUCM servers and an SRST reference. If the IP Phone was
manually preconfigured in CUCM, the SEP<MAC address>.cnf.xml file is
downloaded for that phone. Otherwise, the XMLDefault.cnf.xml configura-
tion file is used for IP Phones that request auto-registration.
Step 6. The .cnf.xml file indicates the firmware load that the IP Phone should be run-
ning. If this image load differs from the one that is currently on the IP Phone,
the phone contacts the TFTP server to request the new firmware load file,
which has a .bin file extension. The IP Phone installs the firmware in its non-
volatile RAM and reboots.
Step 7. After rebooting, the IP Phone downloads other information such as the soft-
key template and phone button template. The IP Phone attempts to make a
TCP connection to a CUCM server that is considered the highest priority in
its list. The phone registers to the CUCM server and obtains a directory num-
ber (DN).

Cisco TFTP service can be supported in multiple ways to serve local and remote-site
Cisco Unified IP Phones:
■ Cisco TFTP Server: The default method of using one or more CUCM servers in
the cluster as TFTP servers that allows IP Phones to download the firmware, con-
figuration, and other files. This is an ideal model for an enterprise environment with
high-speed WAN links because the Cisco Unified IP Phones at a remote site will
download firmware during initial setup or firmware upgrade via centralized TFTP
servers. In case of the multisite WAN with distributed call processing deployment
model or the clustering over WAN call processing deployment model, CUCM TFTP
servers can be deployed at larger remote sites to serve local phones. Cisco CUCM
also supports proxy TFTP that enables phones to sync with a proxy TFTP server
that forwards the requests to their respective clusters. This is especially useful in the
case of multiple phones tied to multiple clusters at remote sites. It saves the overhead
of manually defining multiple option 150 for IP Phone subnets to the correct TFTP
servers.
■ Load Server: A CUCM administrator can assign a TFTP server to each individual
phone record using the Load Server parameter. Assigning the Load Server parameter
is particularly useful for remote sites where downloading firmware to the phone
is difficult due to lower WAN speeds. In such cases, a CUCM administrator can
deploy local TFTP servers (Windows- or IOS-based TFTP) to allow the phones to
operate at remote sites without having to traverse the WAN for firmware download.
To enable the Load Server parameters on a per-phone basis, go to the Cisco Unified
CM Administration page, choose Device > Phone, and select the phone for which
a particular load server is to be defined. Browse to Product Specific Configuration
Layout, define the Load Server IP address/hostname, and enable the same.
■ Peer Firmware Sharing (PFS): PFS is a feature that allows phones participating in
this firmware distribution model to form a peering relationship in a tree-based hier-
archy. One phone peers with two other phones. The administrator, however, does
not need to designate parents (phones initiating PFS) and hosts (phones accepting
PFS). All the peer-enabled Cisco Unified IP Phones on a given IP subnet form a tree
structure to distribute the firmware. After the peering relationship is established, the
root phone retrieves the firmware files from the Cisco TFTP server and distributes
them to the associated peers. This helps to reduce the load on the WAN during firm-
ware upgrades and minimize the overall time needed to upgrade remote-site phones.
PFS is supported with Cisco Unified IP Phone firmware 8.3(1) and later. To ensure
that the phones are participating in a PFS distribution, go to the Cisco Unified CM
Administration page, choose Device > Phone, and select the phone that should be
enabled for PFS. Browse to Product Specific Configuration Layout and ensure that
the Peer Firmware Sharing option is enabled.

Network Services 11
Network Time Protocol

NTP enables network devices to synchronize their clocks to a network time server
or a network-capable clock. NTP is critical for ensuring that all devices in a Cisco
Collaboration network have the same time. Time synchronization is especially critical
on CUCM servers. In addition to ensuring that call detail records (CDR) are accurate and
that log/trace files are synchronized, an accurate time source is necessary for any future
(IPsec) features to be enabled within the cluster and for communication with any external
entity.
NTP should be configured across the network to allow for the synchronization of log
files between multiple devices. Keeping the time accurate on all systems in the infrastruc-
ture helps administrators to troubleshoot and correlate events in a Cisco Collaboration
network. Devices in a Cisco Collaboration network can receive the time from an authori-
tative time source, such as a Cisco router or an atomic clock.
Example 1-2 outlines the configuration of a router to receive the time from an authorita-
tive time source.
Example 1-2 Cisco IOS NTP Client Configuration
UCRouter(config)# ntp authentication-key 1 md5 C1sc0123

UCRouter(config)# ntp trusted-key 1
UCRouter(config)# ntp source FastEthernet0/1
UCRouter(config)# ntp server 10.10.200.200 key 1 prefer source FastEthernet0/1
version 3
UCRouter(config)# ntp authenticate
CUCM automatically synchronizes the NTP time of all subscribers in the cluster to the
publisher. During installation, each subscriber is automatically configured to point to an
NTP server running on the publisher. Cisco recommends using an NTP time source with
NTP stratum 3 or better (the lower the better). An NTP time source can be added to the
CUCM publisher by navigating to the Cisco Unified Operating System Administration
page and choosing Settings > NTP Servers, as shown in Figure 1-6.
Skinny Call Control Protocol (SCCP) endpoints leverage the CUCM publisher’s NTP
source implicitly. You can add a phone NTP reference for SIP endpoints. To add a phone
NTP reference in CUCM, go to the Cisco Unified CM Administration page and choose
System > Phone NTP Reference. You must assign this NTP reference to a date/time
group, which in turn is assigned to a device pool.

Figure 1-6 NTP Server Configuration
Cisco Discovery Protocol

CDP is a Cisco-proprietary Layer 2 protocol that was developed for discovering neighbor
devices. It is a media- and protocol-independent device-discovery protocol that runs on
Cisco equipment, including Cisco Unified IP Phones, routers, access servers, and switch-
es. A device can advertise its existence to other devices using CDP and can also receive
information about other devices on the network. There are two versions of CDP, Version
1 and Version 2. All modern Cisco gear runs CDPv2 by default.
CDP operates on all media that supports Sub-Network Access Protocol (SNAP), includ-
ing LAN, Frame Relay, and ATM. CDP messages are multicast advertisements sent with
the multicast destination address 01:00:0C:CC:CC:CC on each CDP-enabled interface.
CDP advertisements contain information such as the following:
■ Device ID
■ Port ID
■ Address
■ Capabilities
■ Version
■ Platform
■ Native VLAN
CDP messages are made up of Version, Time to Live (TTL), and Checksum fields, fol-
lowed by a number of Type, Length, and Value (TLV) fields. Table 1-1 illustrates various
CDP TLV fields.

Network Services 13
Table 1-1 CDP TLV Fields

CDP TLV Field Description
Device ID Identifies the sending device’s hostname
Address Provides the address of the interface (physical, loopback, VLAN)
that is sending the CDP update
Port ID Specifies the port from which the CDP update is sent (outgoing
port)
Capabilities Identifies the device’s functional capabilities (e.g., router, switch,
host)
Version Specifies the Cisco IOS or firmware version running on the device
advertising the updates
Platform Identifies the hardware or virtual platform
Full/Half Duplex Indicates the duplex mode of the advertising device’s connected
interface
VTP Domain Identifies the VTP domain of the advertising device (if any)
Management Address Identifies the management address of the advertising device (if any)
Example 1-3 illustrates how to access CDP timer, holdtime, and version information as
well as CDP discovery information.
Example 1-3 CDP Information
UCSwitch# show cdp

Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Sending CDPv2 advertisements is enabled
!
UCSwitch# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID

CM91PUB Fas 0/30 135 H VMware eth0
CUPS91 Fas 0/26 169 H VMware eth0
UCRouter Fas 0/24 163 R S I CISCO3945-Gig 0/0

CDP can be disabled globally or on a per-interface basis, as shown in Example 1-4.
Example 1-4 Disabling CDP at Global and Interface Level
UCRouter(config)# no cdp run

!
UCRouter(config)# int FastEthernet 0/1
UCRouter(config-if)# no cdp enable
Disabling CDP is useful when phones are not connected to switch ports, and for security
reasons, such as hiding device details that you may not want to share with other infra-
structure components.
Link Layer Discovery Protocol

LLDP is a vendor-neutral Layer 2 protocol and is analogous to CDP. LLDP is the stan-
dards-based IEEE 802.1AB protocol for vendor-neutral interoperability. Similar to CDP,
it is used by network devices to advertise their identity, capabilities, and neighbors, but
primarily for non-Cisco equipment or endpoints. If the switches are non-Cisco switches,
LLDP for Media Endpoint Devices (LLDP-MED) can be used to detect power and voice
VLAN, provided the switch is capable of delivering Power over Ethernet. Also, if the
endpoints are non-Cisco devices, LLDP-MED can be used on Cisco switches to support
third-party phones.
LLDP information is sent by devices from each of their interfaces at a fixed interval of
30 seconds with the holdtime of 120 seconds. This takes place in the form of an Ethernet
frame, where each frame contains one LLDP Data Unit (LLDPDU). Each LLDPDU is a
sequence of TLV structures. By default, LLDP is disabled on Cisco routers and switches.
Table 1-2 provides the TLV fields that are advertised by LLDP.
Table 1-2 LLDP TLV Fields

LLDP TLV Field Description
Port Description Identifies the port from which the LLDP update is sent
System Name Identifies the sending device’s hostname
System Description Provides details about the advertising device’s OS/firmware
System Capabilities Identifies the device’s functional capabilities (e.g., router, switch,
host)
Management Address Provides the management IP address (if any)
Port VLAN ID Identifies the native VLAN ID of the advertising port
MAC/PHY Provides the MAC address and other physical characteristics
Configuration/Status

Power over Ethernet 15
Example 1-5 illustrates LLDP configuration on a Cisco switch at a global level and an
individual interface level.
Example 1-5 LLDP Information
UCSwitch# show lldp

% LLDP is not enabled
!
UCSwitch(config)# lldp run
!
UCSwitch(config)# interface FastEthernet 0/1
UCSwitch(config-if)# lldp transmit
UCSwitch(config-if)# lldp receive
Power over Ethernet

There are three ways to power up a Cisco Unified IP Phone:
■ Inline power: Power over Ethernet, derived from switch port
■ Power supply: Using power supply from a wall jack
■ Midspan power injector: Sits between a switch port and the IP Phone and supplies
power to the IP Phone
Cisco supports two types of inline power delivery as PoE: the Cisco original implementa-
tion (Cisco proprietary) and the IEEE 802.3af standards-based PoE. The original Cisco
implementation has the following features:
■ Uses a Cisco proprietary method to determine whether an attached device requires

power. Power is delivered only to devices that require power.
■ Provides .48 V DC at up to 6.3 to 7.7 W per port over data pins 1, 2, 3, and 6.
■ Supports most Cisco devices such as Cisco Unified IP Phones.
After first developing (pre-standard) PoE, Cisco worked with IEEE to create a standards-
based PoE delivery mechanism to develop what is currently known as the IEEE 802.3af
standard, which has the following features:
■ Specifies .48 V DC at up to 15.4 W per port over data pins 1, 2, 3, and 6 or over the
spare pins 4, 5, 7, and 8 (power sourcing equipment [PSE] can use one or the other,
but not both).
■ Enables a new range of Ethernet-powered devices that consume additional power.

The process via which PoE-enabled switches detect and power a Cisco Unified IP Phone
varies depending on whether you are using the Cisco original standard or the IEEE stan-
dards-based implementation. If you employ the Cisco-proprietary method, a switch sends
a Fast Link Pulse (FLP) to the connected device. When the connected device loops the
FLP back to the switch, the switch starts supplying power over the Ethernet connection
to the device. If you use IEEE 802.3af, the switch applies a voltage in the order of –2.8 to
–10 V, and if a resistance of 25K ohm is detected, the switch supplies power to the con-
nected device.
It is recommended to deploy PoE-capable switches at the campus access layer within wir-
ing closets to provide inline-powered Ethernet ports for IP phones, thus eliminating the
need for wall power. If the switches are non-Cisco switches, LLDP-MED can be used to
detect power and voice VLAN.
Voice and Data VLANs

Virtual LANs (VLAN) enable a network administrator to break up a switching domain
into multiple broadcast domains. Think of a VLAN as virtually fragmenting a Cisco
switch into multiple sub-switches, with each VLAN/subswitch being a broadcast domain
and having a unique IP subnet.
A Cisco Catalyst/Nexus switch has multiple physical ports, all of which belong to VLAN
1 by default (out of the box). A set of ports can be assigned to, say, VLAN 100 and
another set of ports can be assigned to VLAN 200. This helps break up (logically) a large
physical switch with a single broadcast domain and a single IP subnet into multiple small
virtual switches, with each virtual switch having its own broadcast domain and IP subnet.
Some of the benefits of this process include increased security, increased performance,
and a physical topology–independent network.
When a switch is configured for data and voice VLANs, Cisco Unified IP Phones con-
nect to the user-facing access layer ports on the switch, followed by a PC or a data device
connecting to the IP Phone’s PC port. IP Phones come with a built-in switch that inter-
faces between the PC port and switch port. IP Phones support 802.1Q tagging, and the
incoming switch port receives and sends 802.1Q-tagged packets. Voice packets are 802.1Q
tagged, and the switch understands the tagging on the access port, thereby assigning
these packets to voice VLAN. The data packets, on the other hand, pass through the IP
Phone to the switch as untagged packets, and the switch assigns these untagged packets
to the data VLAN.
Cisco strongly recommends separating voice and data traffic by using VLANs for the fol-
lowing reasons:
■ To provide clear segregation of voice and data traffic
■ To provide QoS marking and classification for real-time voice traffic vis-à-vis data
traffic
■ To prevent data applications from directly interacting with voice traffic

Example 1-6 illustrates configuration of voice and data VLANs on a Cisco Catalyst
switch.
Example 1-6 Voice and Data VLAN Configuration
UCSWITCH(config)# vlan 100

UCSWITCH(config-vlan)# name Data-VLAN
!
UCSWITCH(config)# vlan 200
UCSWITCH(config-vlan)# name Voice-VLAN
!
UCSWITCH(config)# interface range FastEthernet 0/1 - 10
UCSWITCH(config-if-range)# switchport mode access
UCSWITCH(config-if-range)# switchport access vlan 100
UCSWITCH(config-if-range)# switchport voice vlan 200
UCSWITCH(config-if-range)# spanning-tree portfast
IP Routing in Cisco Collaboration Campus

Environments
IP routing is used for many functions in Cisco Collaboration networks and forms the
backbone of any successful deployment. IP routing is employed for the following:
■ Inter-VLAN routing
■ Static or dynamic routing
■ Cisco Service Advertisement Framework (SAF)
■ Cisco Unified IP Phone to UC/application server communication
■ UC/application server or IP Phone to gateway communication
For optimum performance of the Cisco Collaboration solution, the network should be
modeled after Cisco’s recommended core, distribution, and access (CDA) layer approach.
Layer 3 routing protocols such as Routing Information Protocol (RIP), Enhanced Interior
Gateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF) are commonly
employed in unified IP environments. Routing protocol parameters such as timers,
path/link costs, and route summaries can be used to optimize and control convergence
times and distribute traffic across multiple paths. Cisco recommends using the passive-
interface command to prevent routing neighbor adjacencies via the access layer.
Campus Infrastructure Design

Before examining the specifics of IP routing in a campus environment, it’s important to
understand the design basics. One of the most important principles of campus network

design is to introduce and enable a hierarchy in the network infrastructure. This allows
each network layer to play a specific role, thus ensuring scalability, reliability, and better
management.
Campus-wide VLANs are based on the flat design model, meaning they avoid the logical,
hierarchical structure and the route summarization provided by routers. Layer 3 switching
provides the same advantages as routing in campus network design with the added per-
formance boost from packet forwarding handled by specialized hardware. Layer 3 switch-
ing in the distribution layer and core of the campus segments the campus into smaller,
more manageable pieces. A multilayer approach combines Layer 2 switching with Layer 3
switching to achieve robust, highly available campus networks.
Campus Access Layer

The campus access layer is where the user-facing devices connect to the LAN (wiring
closet switches) and leverage network services. Typically, at the user access layer, Layer 2
is maintained because it can limit broadcast domains within VLANs. More importantly,
it has voice and data endpoints that connect to the same switch ports. The access layer is
also known as the network edge. A number of feature sets can be used at this layer
to implement network policies around areas such as security, high availability, QoS, and
so on.
Campus Distribution Layer

The campus LAN distribution layer consists of the section of the network from the wir-
ing closet switches to the next-hop switch. It’s the focal point at which network policies
are created and enforced. This layer is responsible for aggregating incoming user traffic
from wiring closet access switches and then aggregating it to the core. At the distribution
layer, it is important to provide redundancy to ensure high availability, including redun-
dant links between the distribution layer switches and redundant links to access layer
switches. Various first-hop redundancy mechanisms are available, including Hot Standby
Router Protocol (HSRP), Gateway Load Balancing Protocol (GLBP), and Virtual Router
Redundancy Protocol (VRRP).
Campus Core Layer

The campus core layer serves as the backbone of the entire network infrastructure of a
campus, where all the traffic from the distribution layer aggregates. It is at this layer that
ingress and egress of traffic in a network occurs. The core layer provides high-speed
transport and interconnectivity of various building blocks within the campus. The core
layer is usually made up of high-speed links that can aggregate all the traffic from points
in the distribution layer. It is again vital to provide redundancy to ensure high availability.
This can be achieved by redundant link or cable paths, redundant devices, and redun-
dant subsystems (such as Catalyst Supervisor Engine modules). Cisco Catalyst switches

with Virtual Switching System (VSS) can be used to aggregate two Catalyst Supervisor
Engines to act as one.
Campus Routed Access Layer Design

As previously mentioned, Cisco-recommended CDA architecture should be followed
while designing a campus network. There are two options for access layer design perti-
nent to campus network design, as shown in Figure 1-7:
■ Traditional Cisco campus design: Traditional design with Layer 2 at the access layer
and Layer 3 at the distribution and core layers
■ Routed access campus design: Modification of the traditional design to extend

Layer 3 to the access layer
Core
Traditional Cisco Campus Design
Routed Access Campus Design

Layer 3 Layer 3
Distribution
Layer 2
Access
Layer 2
Figure 1-7 Traditional Cisco Campus Design Versus Routed Access Campus Design
Compared to the traditional Cisco campus design, the routed access campus design
(combining Layer 3 switching at the access and distribution layers) provides the fast-
est convergence of voice and data traffic flows. Other advantages over the traditional
approach include a single control plane, dynamic traffic load balancing, and use of a
single set of tools for troubleshooting.

The following best practice recommendations apply to the L2/L3 campus network
design:
■ The infrastructure topology should adhere to the Cisco-recommended campus CDA

design approach.
■ Use Layer 3 links beginning with the access layer connecting to the distribution and
core layers for maximum redundancy and fastest convergence time in case of link or
device failure.
■ The access layer switches should have dual connectivity to distribution switches and
support the required QoS features.
■ VLANs should not span multiple switches.
■ All Cisco Collaboration device switch ports (e.g., IP phones) should be put in
spanning-tree PortFast so that they can move to a fully operational state as fast as
possible.
■ Spanning tree should be limited to access switches, and Layer 3 links should be used
between access, distribution, and core switches.
IPv6 in Cisco Collaboration Networks

An IPv6 address contains 128 bits, compared to 32 bits for an IPv4 address. This gives
IPv6 a much larger address space, to the order of 2^128 = 3.4 × 10^38 addresses, com-
pared to the IPv4 address space of 2^32 = 4.3 billion addresses.
IPv6 addresses are represented as a series of eight 16-bit fields of (hexadecimal) char-
acters and numbers separated by colons. The format used is X:X:X:X:X:X:X:X. An
example of an IPv6 address is fe80:0:0:0:0:0:a0a:64c8, which is equivalent to IPv4 address
10.10.100.200. The IPv6 address fe80:0:0:0:0:0:a0a:64c8 can be shortened by following
some simple rules:
■ Two colons (::) can be used to compress successive hexadecimal fields of 0s at the
beginning, middle, or end of an IPv6 address. However, this can be done only once
in an address; that is, one instance of :: is allowed per address.
■ The leading 0s in a field are optional.
Following these rules, IPv6 address fe80:0:0:0:0:0:a0a:64c8 can be shortened to

fe80::a0a:64c8.

IPv6 in Cisco Collaboration Networks 21
IPv6 Address Types

IPv6 supports the following address types:
■ Unicast: Synonymous to IPv4, an IPv6 unicast address entails sending of messages

to a single network destination identified by a unique address.
■ Anycast: An IPv6 anycast address is an address that is assigned to a set of interfaces

that typically belong to different nodes. A packet sent to an anycast address is deliv-
ered to the closest interface, as defined by the routing protocols.
■ Multicast: Similar to IPv4, IPv6 multicast allows a host to send a single data stream
to a subset of all hosts simultaneously.
IPv6 Addressing Model

Figure 1-8 depicts the IPv6 addressing model.
Link-local Unique-local Global
Figure 1-8 IPv6 Addressing Model
An IPv6 addressing model pertinent to a Cisco Collaboration network can be defined as

follows:
■ Link-local address: An IPv6 unicast address that can be automatically or manually

configured on an IPv6 interface. Link-local addresses are used exclusively for com-
munication between two IPv6 devices on the same link (as well as for Neighbor
Discovery Protocol and stateless auto-configuration process); that is, with local
routability scope. On automatic configuration, the address uses the link-local prefix
FE80::/10 (1111 111010) and interface ID.
■ Unique-local address: IPv6 unicast address that uses the prefix FEC0::/10 (1111
111011) and concatenates the subnet identifier (the 16-bit field) with the interface
identifier. Unique-local addresses are analogous to RFC 1918 private addresses in
IPv4 and are not advertised beyond the local site. They are used for local communi-
cations, inter-site VPNs, and so forth. Subnet IDs are typically defined using a hierar-
chical addressing plan to allow for route summarization.

■ Global address: Address that is routable across the Internet. Global addresses consti-
tute IPv6 addresses for widespread generic use and are structured as a hierarchy to
allow address aggregation. Global addresses are identified by their three high-level
bits set to 001 (2000::/3). These are the unique addresses assigned by service provid-
ers or regional registries for participation in the public network.
In context of IPv6, CUCM supports one link-local address, one unique-local address or a
global address, and an IPv4 address.
Cisco Unified IP Phones can support one link-local address, multiple unique-local
addresses, multiple global addresses, and an IPv4 address. If the phone has both unique-
local and global addresses, the global addresses take precedence over unique-local
addresses. If multiple unique-local addresses or multiple global addresses exist, the first
address configured is used as the signaling and media address sent to CUCM. Cisco
Unified IP Phones use one IPv6 address (global or unique-local) for CUCM signaling and
media.
When configured for receiving an IPv6 address, Cisco Unified IP Phone IPv6 address
selection priority is as follows:
1. If configured, use the address that has been manually configured via the IP
Phone’s UI.
2. If an address has not been manually configured, use DHCPv6 to assign an address.
3. If neither a DHCPv6 address nor a manually configured address is available, and

Stateless Address Autoconfiguration (SLAAC, RFC 2462) is enabled for the IP Phone
(CUCM default is on), the IP Phone uses SLAAC to create an IPv6 address. The
router RA “O” bit should be set.
Cisco IOS devices support one link-local address, multiple unique-local addresses, mul-
tiple global addresses, and multiple IPv4 addresses. Cisco IOS routers use link-local
addresses for routing protocols and use the address selection algorithm (RFC 3484) for
applications running on routers—for example, Telnet, Secure Shell (SSH), and so on. For
responses to devices, routers attempt to use the same network prefix as the device that is
initiating communication.
To allow IPv6-based call processing, IPv6 must first be enabled throughout a CUCM
cluster. This involves the following steps:
Step 1. Configure IPv6 via the Cisco Unified CM Administration page by choosing
System > Server Configuration. IPv6 must be configured via the OS CLI or
Cisco Unified Operating System page on each server in the cluster.
Step 2. Enable IPv6 cluster-wide via the Cisco Unified CM Administration page by
choosing System > Enterprise Parameters; and setting Enable IPv6 to True,
set IP Addressing Mode Preference for Media to IPv6, IP Addressing Mode
Preference for Signaling to IPv6, and Allow Auto-Configuration for Phones
(SLAAC) to On.

Step 3. Configure Common Device Configuration for IP Phone Profile and SIP
Trunks to enable IPv4 and IPv6 addressing mode, Signaling Preference, and
Phone Auto Configuration settings. Device setting takes precedence over
global settings.
The following are IPv6 deployment guidelines for Cisco Collaboration infrastructure:
■ LAN and WAN environments must be considered when deploying IPv6, as most
applications and infrastructure components may be configured for or support IPv4.
■ Dual-stack deployments offer the best approach when introducing IPv6 into any
network environment, as both IPv4 devices and dual-stack IPv4/v6 devices can inter-
operate. Disruption to the existing network is minimal.
Virtualization in Cisco Collaboration Solutions

Cisco Unified Computing System (Cisco UCS) combined with VMware vSphere provides
virtualization for Cisco UC applications. Virtualizing UC applications has many benefits,
such as
■ Infrastructure can be simplified and consolidated using virtualized computing plat-

forms to reduce server count, network ports, cabling, and power consumption.
■ Cisco UC applications can be deployed and scaled rapidly on a virtualized platform

compared to Media Convergence Server (MCS)-based installations.
■ A virtual environment supports simplified upgrade and migration, thereby providing

elasticity in deployment and service enablement.
Cisco offers many virtualization solutions for Cisco Collaboration environments, ranging
from desktop to data center. Some of the virtual solutions for Cisco Collaboration are
listed in Table 1-3.
Table 1-3 Cisco Collaboration Virtual Solutions

Virtual Solution Description
Cisco UCS Blade server for bare metal or hypervisor-based installation in
data centers.
Cisco Virtualization Delivers integrated Unified Communications platform, is device
Experience Infrastructure agnostic, and delivers enterprise voice, video, mobility, presence,
(VXI) and session management with security.
Cisco Virtualization Enables Jabber to run in virtualized environments. This is a sub-
Experience Media Engine component of Cisco VXI.
(VXME)
Cisco Virtualization A thin client designed to easily integrate into a virtualized infra-
Experience Client (VXC) structure. This is a subcomponent of the Cisco VXI solution.

Virtual Solution Description

Cisco VXC Manager Used for managing and deploying VXC thin client. This is a sub-
component of the Cisco VXI solution.
Cisco Virtual Desktop Solution to deliver virtualized desktops and applications by
Infrastructure (VDI) means of simplicity, scalability, and superior user experience.
Cisco VDI solutions are built on Cisco Unified Data Center
architectures. The Cisco VDI solution is available as a Citrix or
VMware workload.
Cisco UCS Servers

Cisco UCS servers are an x86-based architecture data center server platform encompass-
ing computing, virtualization, switching fabric, and management software.
The computing component of Cisco UCS is available in two versions:
■ B-Series: Modular packages consisting of a chassis and half-width or full-width

blades. B-Series servers require a storage area network (SAN) for application data
storage.
■ C-Series: Rack-mount servers with built-in direct-attached storage (DAS).

Compute hardware is managed by the UCS Manager software running on Fabric
Interconnects (FI).
UCS Manager can be used to manage both B-Series and C-Series servers. Integration
between VMware vCenter and Cisco UCS Manager provides unparalleled control over
physical and virtual assets.
For virtualization, Cisco UCS supports hypervisors, including VMware ESXi and Citrix
XenServer. Cisco UCS interacts with Fabric Extenders or Fabric Interconnects to commu-
nicate with other data center infrastructure, including SAN switches, storage, and Cisco
Nexus. Cisco UCS supports Fibre Channel over Ethernet (FCoE). Figure 1-9 depicts a
Cisco UCS–based virtualized UC application and network architecture.
Cisco UCS leverages the concept of service profiles for statelessness. This allows for any
damaged hardware (blade) to be changed without affecting the virtual machines (VM)
running on it. The VMs can be moved to another blade by disassociating the service pro-
file from a nonfunctional blade to a functional one.
Cisco UC application configuration templates are available in Open Virtualization

Archive (OVA) format, which allows administrators to build and configure UC applica-
tions. For most supported UC applications, preconfigured OVA templates are available
on Cisco.com. If an OVA template is not available for an application, the administrator
must manually build OVA files that meet the indicated requirements. Cisco has stringent
requirements for co-residency of UC applications with non-Cisco or non-UC applications.
The Cisco-recommended guidelines for co-residency can be found at http://
docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines.

UC Applications
(Guest Virtual Machines)
VMware
Hypervisor
B-Series Blade
Cisco UCS 5100 Series

Chassis
6200 Series Fabric

Interconnect
Fibre Channel over

V Ethernet (FCoE)
Ethernet Fibre Channel
LAN Switch Nexus 5000 SAN Switch Storage Array

Series Switch (MDS 9000 Series)
Figure 1-9 Cisco UCS–based UC Application and Network Virtualization Architecture
Moreover, Cisco supports UC on UCS deployments in three support models:
■ UC on UCS Tested Reference Configuration (TRC): Tested and approved by Cisco

UC and UCS BUs/teams
■ UC on UCS Specs-based: Generic server hardware validation by UCS BU/team
■ Third-party Server Specs-based: No hardware validation by UCS BU/team
While virtual machine (OVA) definitions, VMware product, version, and feature support,
VMware configuration requirements for UC, and application/VM co-residency policy
remain consistent across all three support models, there are a few things to consider when
going with one model or another. For example, a TRC model is configuration based,
whereas UCS Specs-based and Third-party Server Specs-based models are rules based.
For details and updated information, refer to http://docwiki.cisco.com/wiki/
UC_Virtualization_Supported_Hardware.

VMware ESXi for Cisco Collaboration Virtualization

Cisco UCS requires a hypervisor to support a guest OS and virtual machines. VMware
vSphere (ESXi) is the hypervisor that sits between the hardware abstraction layer and the
guest OS. VMware ESXi runs directly on the UCS B-Series or C-Series server hardware
without the need for any additional software in bare-metal mode. It provides the neces-
sary hypervisor functions to host several guest OSs, such as Windows and Linux, on the
physical server.
UC Application Install Answer File

While installing UC applications on a physical or virtual platform, answer files can be
very helpful because they save time and prevent typological or omission errors. UC
applications can be installed on UCS using the platformConfig.xml file where the virtual
machine requires the use of a virtual floppy drive.
To install a Cisco Unified Communications application such as CUCM, Cisco Unity

Connection, Cisco Presence, and so on, using the answer files generated by Cisco Unified
Communications Answer File Generator (http://www.cisco.com/web/cuc_afg/index.html)
is recommended. This web application also generates the virtual License MAC address
that is used for obtaining the license.
The answer file generator has the following areas to complete in the Clusterwide
Configuration section:
■ Hardware: Physical Server or Virtual Machine
■ Product: CUCM, Cisco Unity Connection, Cisco Unified Presence, and so on
■ Administrator Credentials: OS Administrator username and password
■ Security Password: Cluster security password
■ Application User Credentials: Administrator GUI username and password
■ Certificate Information: Organization, Unit, Location, State, and Country

■ SMTP: SMTP Location
The answer file generator also has the following areas to complete in the Primary Node
Configuration and Secondary Node Configuration sections:
■ NIC Interface Settings: Use Auto Negotiation, NIC Speed, NIC Duplex, MTU Size
■ Network Information: Use DHCP for IP Address Resolution, Host Name, IP

Address, IP Mask, Gateway Address
■ DNS: Configure Client DNS, Primary DNS, Secondary DNS, Domain
■ Time Zone: Region, Time Zone
■ Network Time Protocol: NTP Server(s) information (only for primary node)

IP Multicast 27
After the platformConfig.xml file is generated, you can use it to install primary and sec-
ondary nodes in a UC application cluster by following these steps:
Step 1. Create a virtual floppy image using a virtual floppy program (for example,
WinImage or RawWrite).
Step 2. Insert the platformConfig.xml file into the virtual floppy image and save the
resulting image with a .vmd or .flp extension.
Step 3. Upload the virtual floppy image to a datastore accessible from VSphere. For
SAN storage, go to View > Inventory > Datastores. For local storage (such as
an internal hard drive), select the host and click the Summary tab. Browse the
datastore and upload the virtual floppy image to it.
Step 4. From the VSphere client, go to Inventory > Virtual Machine > Edit Settings.
In the dialog box that opens, select Floppy Drive on the Hardware tab. Click
the Use Existing Floppy Image in Datastore radio button, click Browse,
browse to and choose the virtual floppy image, and click OK.
Step 5. In the Device Status area of the Hardware tab, check the Connected and
Connect at Power On check boxes. Click OK in the lower-right corner.
Step 6. Proceed with installation of the UC application using the ISO file from the
datastore.
Step 7. In the Platform Installation Wizard window, choose Skip to configure the
platform later using the auto-answer file from the mounted virtual floppy
image.
Step 8. After the system restarts, the Preexisting Installation Configuration window
displays and the install process automatically reads the configuration informa-
tion file copied onto the virtual floppy image mounted on the UCS.
IP Multicast
IP multicast can be used for various functions in a Cisco Collaboration network. The
most common services that leverage IPv4 or IPv6 multicast are
■ Multicast Music on Hold (MoH) for branch sites. (Cisco Unified IP Phones support
only IPv4 multicast MoH. IPv6 multicast MoH is not supported.)
■ AutoDiscovery of Gatekeeper (GRQ) messages.
■ DHCPv6 discovery by IPv6-compatible endpoints.
■ Cisco SAF forwarder automatic discovery and communication with other SAF
forwarders.
To allow the use of multicast for all the preceding services, the underlying network infra-
structure must support the forwarding of multicast IP traffic from the CUCM servers or

endpoints or gateways to respective VLANs across the campus and extended network
(inter-domain).
Protocols commonly used to enable multicast in a campus environment include the

following:
■ Internet Group Management Protocol (IGMP)
■ Protocol Independent Multicast Sparse Mode (PIM-SM)
■ Protocol Independent Multicast Dense Mode (PIM-DM)
■ Cisco Group Management Protocol (CGMP)
Protocols commonly used to enable multicast in an interdomain environment include the

following:
■ Multicast Source Discovery Protocol (MSDP)
■ PIM Source-Specific Multicast (PIM-SSM)
IPv6 multicast is based on the same basic principles as IPv4 multicast. The major differ-
ences being that IPv6 relies on multicast for more functions, such as neighbor discovery
and node autoconfiguration. Moreover, Mobile IPv6 relies heavily on IPv6 multicast for
their operations. IGMP is replaced by Multicast Listener Discovery (MLD) in IPv6.
Wireless in Cisco Collaboration Solutions

Today’s dynamic environments and organizations demand more than just regular wired
IP Phones—they demand mobility. Wi-Fi is an important aspect because being mobile
yet connected within an enterprise is paramount in today’s connected world. Cisco offers
on-campus mobility using Voice over Wireless LAN (VoWLAN) with Cisco Unified
Wireless IP Phone 7925G. From an infrastructure perspective, Cisco offers two wireless
network infrastructure solutions: Cisco Unified Wireless LAN Controller (WLC) and
Cisco Autonomous Access Points (AP). A VoWLAN architecture encompasses multiple
components, as shown in Figure 1-10.
Cisco VoWLAN solution has many components, including the following:
■ Cisco WLC
■ Lightweight access points
■ Directory server (LDAP) for endpoint authentication
■ Wi-Fi endpoints, including PCs or laptops with Jabber
■ Wi-Fi–capable Cisco Unified IP Phones
The interaction between endpoints and wireless APs is where Wi-Fi primarily comes into
play; the rest is an augmentation to existing wired infrastructure.

Wireless in Cisco Collaboration Solutions 29
Cisco WLC CUCM
Lightweight AP
Switch Switch LDAP
Cisco Unified IP Laptop with Cisco Unified IP

Phone (Wireless) Softphone (Jabber) Phone (Wired)
Figure 1-10 Cisco VoWLAN Architecture
For a successful VoWLAN solution deployment, certain conditions must be met. They
are as follows:
■ Noise levels should not exceed —92 dBm with a signal-to-noise ratio (SNR) of
25 dB.
■ Signal strength should be −67 dBm.
■ Minimum 20 to 30 percent overlap of adjacent access points with nonoverlapping

channels must be considered during site survey.
■ Packet error rate (PER) should not exceed 1 percent and Jitter should be less than
100 ms.
■ To avoid one-way audio issues resulting from different power settings between Wi-Fi
IP phones and access points, World mode (IEEE 802.11d) should be configured.
■ Traffic Specification (TSPEC) must be enabled for CAC on APs.
■ QoS for voice VLAN must be enabled on Cisco WLC and APs such that the mark-
ings match those on wired infrastructure. IEEE 802.11e UP markings should be
matched to Voice, Video, and Signaling DSCP markings (Voice EF = 6, Video AF41
= 5, and Signaling AF31 = 4).
■ Channel utilization levels should be kept below 50 percent.
■ Cisco Compatible Extensions (CCX) should be enabled on wireless infrastructure

where possible to save battery life on the IP phone to increase the Delivery Traffic
Indication Message (DTIM) period.


Chapter 2
Quality of Service (QoS)
Voice and video over IP traffic consists of two parts: media/bearer traffic and signaling
traffic. Media traffic is based on the Real-time Transport Protocol (RTP), which runs
on top of the User Datagram Protocol (UDP). Signaling traffic is based on a number
of protocols, such as Session Initiation Protocol (SIP), Skinny Call Control Protocol
(SCCP), H.323 protocol, and Media Gateway Control Protocol (MGCP), all of which are
TCP/UDP based. When an RTP packet is lost, re-creating or retransmitting it is neither
possible nor worthwhile. As its name indicates, RTP works in real time, so any attempt to
restore missing packets would not make sense because the packets would arrive out of
order/sequence during a live conversation.
In today’s converged networks where voice, video, and data coexist, it is important to
treat voice and video traffic differently from data traffic, which is mostly TCP based and
is easily retransmitted without loss of quality. Quality of service (QoS) enables network
administrators to leverage tools for providing special treatment for delay and time-
sensitive traffic such as voice. The network infrastructure must provide classification,
policing, and scheduling services for multiple traffic classes.
Voice quality is directly affected by the following three QoS factors:
■ Latency (delay): The unwarranted time required for a packet to traverse the network
from source to destination
■ Jitter (delay variation): Irregular time interval in the arrival of packets
■ Packet loss: Packets lost in transit from source to destination due to network con-
gestion, link flapping, or other reasons
Many sources of delay are introduced both during a packet formation and during transit
from source to destination, as outlined in Table 2-1. Moreover, the delay can be either
a fixed delay or a variable delay depending on where it is introduced. Fixed delay adds
to overall delay introduced from source to destination. Variable delay is a function of
queues and buffers.

32 Chapter 2: Quality of Service (QoS)
Table 2-1 Sources of Delay During Voice Packet Formation and Traversal from Source
to Destination
Delay Description
Coder delay The time taken by a digital signal processor (DSP) to compress a
block of pulse-code modulated (PCM) samples. This is a fixed delay
function for a certain endpoint with a certain codec.
Packetization delay The time it takes to put a payload (encoded voice) into a voice packet
and encapsulate it within IP, UDP, and RTP headers. It’s a fixed delay
function.
Queuing delay The delay experienced as a frame is queued waiting to be transmit-
ted on a link. It’s a variable delay function because it depends on link
speed.
Serialization delay The time taken to put a frame on the wire from a network interface.
It’s a fixed delay function.
Propagation delay The time taken for a bit to traverse a network link (from one end to
the other).
De-jitter delay The delay experienced as a result of a de-jitter buffer on a receiving
device (such as a Cisco IOS router) that eliminates any jitter between
packets before they are sent out to their destination. It’s a fixed delay
function.
QoS Requirements for Voice and Video

The key QoS requirements and recommendations for RTP traffic are
■ Voice bearer traffic should be marked to DSCP EF per the QoS baseline and
RFC 3246.
■ Packet loss should be no more than 1 percent.
■ One-way latency (mouth to ear) should be no more than 150 ms.
■ Average one-way jitter should be targeted under 30 ms.
Additionally, for voice calls, the following are recommended leading practices:
■ 17 to 106 kbps of guaranteed priority bandwidth should be provided per call for
media (depending on the sampling rate, codec, and Layer 2 overhead).
■ 150 bps + Layer 2 overhead guaranteed bandwidth should be provided for voice-
control traffic per call.
Additional requirements for video traffic are as follows:

QoS Deployment Architectures 33
■ The minimum priority bandwidth guarantee required is size of Video-stream + 10 to

20 percent.
■ Call Admission Control (CAC) must be enabled.
QoS Deployment Architectures

QoS can be implemented via Integrated Services (IntServ) or Differentiated Services
(DiffServ) architecture. IntServ architecture provides QoS by assuring treatment for a
specific traffic flow. Resource Reservation Protocol (RSVP) is an example of an IntServ
mechanism where each router on the path for packet transmission is informed of the
upcoming packet stream. DiffServ architecture, on the other hand, differentiates/classifies
various types of traffic and provides several levels of service based on that classification.
In other words, unlike IntServ, DiffServ labels packets with a particular priority marking
that can be referenced by other network devices/applications and hence classified in vari-
ous traffic classes to be treated accordingly.
To help deploy QoS for Collaboration (and converged) networks, Cisco provides a QoS
toolkit composed of the following tools:
■ Classification and marking
■ Queuing (congestion management)
■ Congestion avoidance
■ Traffic policing
■ Traffic shaping
■ Link efficiency mechanisms
■ Medianet
Figure 2-1 illustrates the QoS tools’ order of operation at a high level.
Classification/ Shaping/
Policing Queuing
Marking Fragmentation
IP Precedence Traffic Policing LLQ FRTS

DSCP Rate Limiting CBWFQ LFI
RSVP WRED FRF.12
ACLs MLP
Figure 2-1 QoS Tools’ Order of Operation
QoS operation largely depends on QoS policies provisioned in a network. It starts with
classification and marking, followed by policing, queuing, and, finally, shaping and frag-
mentation. It is essential to plan and deploy end-to-end QoS in LAN, WAN, and virtual-
ized environments to ensure that voice and video quality is acceptable. The sections that

follow discuss QoS tools and their application. The following QoS tools and applications,
as well as considerations for LAN, WAN, wireless, and virtualized environments, are cov-
ered in this chapter.
Classification and Marking

Classification is the process by which Cisco Collaboration infrastructure devices
and applications can identify packets or frames and sort traffic into different classes.
Classification can be done based on various criteria, such as IP address or protocol
and port. Once packet types are identified based on classification criteria, they can be
marked according to a policy such that other network devices and applications will rec-
ognize these packets and treat them as per the QoS policy being applied. Packets can
be marked using fields within packets and frames at Layer 3 and Layer 2 respectively. At
Layer 3, the Type of Service (ToS) or Differentiated Services (DS) fields in an IP header
can be used for marking. At Layer 2, the 802.1p field in the IEEE 802.1Q tag can be used
for marking traffic.
Layer 2 Marking
Class of service (CoS) markings are applied to frames that transit an 802.1Q trunk. An
IEEE 802.1Q tag consists of Tag Protocol ID (TPID) and Tag Control Information (TCI)
fields. Figure 2-2 depicts the Layer 2 frame with IEEE 802.1Q tag.
IEEE 802.1Q
VLAN Tag
802.1Q Frame
Destination Source Type/

Preamble TPID TCI Data FCS
Address Address Length
(8) (2) (2) (Payload) (2)
(6) (6) (2)
User Priority CFI VLAN ID

(3) (1) (12)
Used for CoS

Markings
Figure 2-2 IEEE 802.1Q Tag–based QoS (CoS) Marking
The TPID field is a 2-byte field and contains a fixed value of 0x8100 that indicates a
tagged (802.1Q) frame. The TCI field is a 2-byte field that contains three subfields:

■ User Priority: A 3-bit field used to reflect the QoS priority of the frame
■ Canonical Format Indicator (CFI): A 1-bit field that indicates whether the type of
information that a frame carrier is in a canonical (Ethernet) or noncanonical (Token
Ring) format
■ VLAN ID: A 12-bit field that indicates the VLAN from which the frame originated
CoS markings leverage the 3 bits from the User Priority field from within the TCI field
in a 802.1Q tagged frame. Because CoS markings use 3 bits, CoS values range from 0
through 7, with values 6 and 7 being reserved.
Layer 3 Marking
At Layer 3 (network layer), packet marking can be accomplished using the ToS byte in an
IPv4 header. Two predominant types of marking mechanisms leverage the ToS byte: IP
Precedence and Differentiated Services Code Point (DSCP).
IP Precedence is an old approach and has been successively replaced by DSCP for mark-
ing IP packets. IP Precedence uses the 3 leftmost bits in the ToS byte. With 3 bits to use,
IP Precedence values can range from 0 to 7, with 6 and 7 reserved. The fields in the ToS
byte are as follows:
■ (IP) Precedence: A 3-bit field used to specify the relative priority or importance of a
packet
■ Type of Service (ToS): A 4-bit field that defines how the network should make
trade-offs between throughput, delay, reliability, and cost
■ MBZ: Must be zero
DSCP, on the other hand, uses the 6 leftmost bits from the ToS byte in an IPv4 header as
the DiffServ (DS) field. With 6 bits, DiffServ has up to 64 DSCP values (0 to 63) that are
assigned to various classes of traffic. The Internet Engineering Task Force (IETF) recom-
mends selective DSCP values for use to maintain relative levels of priority. These selective
values are called Per-Hop Behaviors (PHB) and determine how packets are treated at each
hop along the path from the source to the destination. The subfields in the DS byte are as
follows:
■ DiffServ: A 6-bit field used to specify the DSCP value (and therefore PHB) of a
packet
■ CU: Currently unused
Figure 2-3 illustrates the relationship between the ToS byte, IP Precedence, and DSCP
fields.

IPv4 Packet
ToS
1 2 3 4 5 6 7 8
Precedence ToS MBZ
IP Precedence
DSCP CU
Figure 2-3 IPv4 ToS Byte: IP Precedence and DSCP Overview
When configuring a router to mark or recognize a DSCP value, decimal numbers or the
name of a specific DSCP value can be used. The four different DiffServ PHBs are as
follows:
■ Assured Forwarding (AF): Specifies four AF PHBs grouped into four classes. When
using AF, the first 3 bits of the DS field define the queuing class (1 to 4), and the last
3 bits define the drop precedence (1 to 3). AF therefore has 12 classes to it and pro-
vides assurance that a packet is forwarded as long as it doesn’t exceed the subscribed
rate.
■ Best Effort (BE): Specified when all 6 bits of the DS field are 0; that is, the packet
doesn’t need any specific QoS treatment or doesn’t meet the requirements of any of
the other defined classes. BE is also known as default PHB.
■ Class Selector (CS): Used for backward compatibility with network devices and
applications that use IP Precedence. When using this PHB, the last 3 bits of the
DSCP field are 0.
■ Expedited Forwarding (EF): States a low-delay, low-loss, and low-jitter QoS treat-
ment with guaranteed bandwidth.
Network-Based Application Recognition

Network-Based Application Recognition (NBAR) is one of the most powerful QoS
marking tools available with Cisco IOS. NBAR enables a router to look into the actual
content of the packet, including the application layer. This allows traffic to be marked
and classified based on payload rather than lower-layer information such as IP address,
frame information, or port numbers. NBAR depends on Cisco Express Forwarding (CEF)

and is deployed using the Cisco Modular Quality of Service Command-Line Interface
(MQC) framework. The following configuration example illustrates NBAR configuration
to match all RTP traffic (audio, video, payload type) based on protocol rather than UDP
port values:
UCRouter(config)# class-map match-any rtp
UCRouter(config-cmap)# match protocol rtp
NBAR can be deployed if you are using IPv4 addressing, whereas NBAR2 can be
deployed if you are using an IPv6 addressing scheme. NBAR is based on the Service
Control Engine (SCE) and is backward compatible.
Classification Service Classes

Cisco recommends applying classification/marking to all types of traffic, including voice
and video media, call signaling traffic, and different data traffic flows. This set of recom-
mendations is called the Cisco QoS baseline. Table 2-2 gives an insight to these service
classes.
Table 2-2 Service Classes Based on Cisco QoS Baseline

Network Service/Application Classification/Service Class
Network control traffic for switches and routers CS6 (DSCP 48)
IP voice media traffic (with LLQ) EF (DSCP 46)
IP interactive video traffic (videoconferencing) AF41 (DSCP 34)
IP streaming video traffic (live, prerecorded) CS4 (DSCP 32)
Priority data traffic (SQL, ecommerce) AF31 (DSCP 26)
Voice and video signaling traffic (SIP, H.323, MGCP, SCCP) CS3 (DSCP 24)
Transactional data (databases) AF21 (DSCP 18)
Network management (Telnet, SSH) CS2 (DSCP 16)
Bulk data (HTTP, FTP) AF11 (DSCP 10)
Scavenger traffic (P2P) CS1 (DSCP 8)
Best effort (HTTP) BE (DSCP 0)
Classification and Marking for Softclients

A common issue pertinent to softclients (softphones) such as Jabber and Cisco IP
Communicator is ambiguity in marking and classifying the media and signaling traffic
to and from PCs or laptops. A PC or a laptop connected via a data VLAN sends many
data packets along with voice packets, and unless the OS allows correct marking of these
002_9780133845969_ch02.indd 37 6/24/14 4:28 PM

packets by softclient applications, the packets are overridden by default OS-provided CoS
markings. The issue becomes even more obscure when a PC is connected to a switch via
the PC port on a Cisco Unified IP Phone. In such cases, the IP Phone by default re-marks
all CoS values received from the PC to 0, thereby disregarding any markings by Cisco
softclients.
For Cisco softclients, QoS classification and marking can be provided by a Trusted Relay
Point (TRP). A TRP is a software function that uses a Media Termination Point (MTP)
provider and is dynamically inserted in a call flow by CUCM. Media streams from
softclients can be bridged together, thereby facilitating the QoS markings and classifica-
tion to be applied for PC-to-PC softphone calls. For more information on TRP, refer to
Chapter 4, “Cisco Unified Communications Manager.”
Classification and Marking for Video Traffic

In addition to the previously discussed QoS requirements for video traffic, the following
are best practices associated with interactive video:
■ Interactive video traffic should be marked to DSCP AF41.
■ Excess videoconferencing traffic can be marked down (policing) to AF42 or AF43.
The following are best practices pertinent to streaming video:
■ Streaming video should be marked to DSCP CS4 (for both unicast and multicast
streams).
■ Guaranteed bandwidth requirements depend on the encoding format and rate of the
video stream.
■ Non-business-oriented streaming video applications, such as entertainment video

content, may be marked as Scavenger class DSCP CS1.
■ Latency should be no more than 4 to 5 seconds (depending on the video application’s

buffering capabilities).
■ Packet loss should be no more than 5 percent.
Queuing
Beginning with classification and marking, a packet needs to be treated as per the QoS
policy. QoS tools such as policing or queuing can make forwarding or dropping deci-
sions based on these markings. Queuing is a congestion management tool. It ensures that,
during temporary periods of congestion, traffic (packets) is buffered, prioritized, and, if
required, reordered before being transmitted to the destination.

Queuing 39
Cisco Queuing Toolset

A number of queuing tools are available in Cisco IOS Software and are listed in Table 2-3.
Table 2-3 Queuing Toolset

Queuing Tool Description
First-In, First-Out (FIFO) A default queuing mechanism for interfaces with speeds greater
than 2.048 Mbps. As the name suggests, the packets are treated
as they arrive and no reordering is done.
Priority Queuing (PQ) A legacy queuing method with four queues, where higher-
priority queues must be emptied before forwarding traffic from
lower-priority queues.
Custom Queuing (CQ) A legacy queuing method that entertains up to 16 queues in a
round-robin (RR) cycle, emptying a pre-specified number of
bytes from each queue during each iteration.
Weighted Fair Queuing A flow-based algorithm, derived from Fair Queuing (FQ), and a
(WFQ) default queuing method for low-speed interfaces. WFQ makes
forwarding decisions based on a packet’s size and Layer 3 pri-
ority marking.
IP RTP Priority A legacy queuing method that creates a strict PQ for voice
traffic for a range of UDP destination ports, with other packets
treated with the WFQ method.
Low-Latency Queuing (LLQ) The queuing method created specifically for voice and video
traffic. LLQ allows traffic to be categorized in up to 64 differ-
ent classes, with different amounts of bandwidth or priority
treatment for these classes.
Class-Based Weighted Fair Similar to LLQ, but without the PQ mechanism.
Queuing (CBWFQ)
Cisco recommends CBWFQ or LLQ methodologies for queuing with current versions of
Cisco IOS in Cisco Collaboration networks. Example 2-1 illustrates the MQC approach
to LLQ.
Example 2-1 MQC Approach to LLQ
UCRouter(config)# class-map RTP-Audio

UCRouter(config-cmap)# match protocol rtp audio
!
UCRouter(config)# class-map RTP-Video
UCRouter(config-cmap)# match protocol rtp video
!
UCRouter(config)# class-map match-any Signaling

UCRouter(config-cmap)# match ip dscp cs3

UCRouter(config-cmap)# match ip dscp af31
!
UCRouter(config)# policy-map Voice-Priority
UCRouter(config-pmap)# class RTP-Audio
UCRouter(config-pmap-c)# priority percent 20
UCRouter(config-pmap-c)# class RTP-Video
UCRouter(config-pmap-c)# priority percent 10
UCRouter(config-pmap-c)# class Signaling
UCRouter(config-pmap-c)# bandwidth 128
UCRouter(config-pmap-c)# class class-default
UCRouter(config-pmap-c)# fair-queue
!
UCRouter(config)# interface serial 0/0
UCRouter(config-if)# ip address 10.10.1.250 255.255.255.0
UCRouter(config-if)# service-policy output Voice-Priority
In Example 2-1, NBAR is used to recognize RTP audio and video traffic and DSCP mark-
ings (default markings by Cisco UC applications and the majority of endpoints) for sig-
naling that is matched. Voice audio is given priority treatment of guaranteed 20 percent
of the link’s bandwidth, whereas video traffic is given 10 percent of priority guaranteed
bandwidth. Signaling traffic is given up to 128 kbps of bandwidth, and the remaining traf-
fic is treated by class default via the fair queuing method (that is, this traffic is entertained
only when the priority queues have first been serviced up to their assigned bandwidth).
Weighted Random Early Detection

Queues can overfill. To prevent an interface’s output queue from filling to its capac-
ity, newly arriving packets can be discarded. Before queues are completely full, packets
can be tail dropped from the back of queues or selectively dropped. The problem with
randomly dropping packets is that some of them might be high priority (such as RTP
packets) and some might be low priority. Moreover, randomly dropping packets causes
issues such as multiple TCP retransmission requests, which further fill up the queues
with retransmitted packets. Weighted Random Early Detection (WRED) allows selective
packet dropping on Cisco routers.
WRED is a congestion-avoidance QoS tool. It supports drop thresholds defined for vari-
ous markings such as DSCP markings. These thresholds are the minimum threshold,
maximum threshold, and mark probability denominator. WRED can be configured on a
per-interface basis or as an MQC class. The interface configuration of WRED for DSCP
AF21 with a minimum threshold of 32 packets and a maximum threshold of 40 packets is
as follows:
UCRouter(config)# interface FastEthernet 0/0
UCRouter(config-if)# random-detect dscp-based
UCRouter(config-if)# random-detect dscp af21 32 40

WAN QoS Considerations 41
MQC-based WRED configuration is as follows:

UCRouter(config)# policy-map HTTPS
UCRouter(config-pmap)# class HTTP-Secure
UCRouter(config-pmap-c)# random-detect dscp-based
The command random-detect [dscp-based | prec-based] can be used to define either

DSCP-based marking or IP precedence–based marking for calculating drop probability.
The default is prec-based.
WAN QoS Considerations

WAN links typically require additional mechanisms such as traffic policing, traffic shap-
ing, and link efficiency tools to ensure that voice and video media and signaling packets
are sent without undue delay, jitter, and packet loss.
Traffic Policing and Shaping

Traffic policing and shaping help regulate bandwidth usage by limiting the amount of
traffic. Policing limits traffic rates by dropping, re-marking, or transmitting traffic if the
traffic conforms to a policy. Policing can occur within a network or at the network edge.
Shaping, on the other hand, involves regulating excessive traffic rates by delaying (buff-
ering) traffic. Shaping usually occurs at the edge of a network and can be applied to an
interface in an output direction. Because traffic policing limits traffic transmission by
dropping packets, it is more suitable for high-speed links such as LAN or Multiprotocol
Label Switching (MPLS) links. Traffic shaping is more suitable for lower-speed links such
as Multilink PPP (MLP) and Frame Relay, as it buffers excess traffic.
Both policing and shaping configurations can specify a committed information rate
(CIR), committed burst (Bc), and excess burst (Be). Both shaping and policing rely on
token-bucket algorithms where tokens influence how much traffic can be sent, with each
token allowing either 1 bit or 1 byte to be sent. There are three types of class-based
policers that can be configured using the MQC:
■ Single-rate two-color policer: A single token bucket is used and traffic either con-
forms to or exceeds the configured rate. Actions can be stated for traffic that con-
forms or exceeds the specified rate.
■ Single-rate three-color policer: Two token buckets are used, with tokens periodically
added to the first bucket and any overflowing tokens going to the second bucket.
Actions can be stated for traffic that conforms, exceeds, or violates the specified
rate.
■ Two-rate three-color policer (RFC 2698): Comparable to the single-rate three-color

policer, the difference being that tokens are periodically added to both buckets.
Actions can be stated for traffic that conforms, exceeds, or violates the specified
rate.

Example 2-2 illustrates a single-rate three-color policer using the MQC where the traffic
conforming to the policy is marked DSCP AF21. The traffic exceeding the policy-defined
rate is marked DSCP AF11, and the traffic violating the exceed action is dropped.
Example 2-2 Traffic Policer Configuration
UCRouter(config)# class-map HTTP-Secure

UCRouter(config-cmap)# match protocol secure-http
!
UCRouter(config-pmap-c)# police cir 512000 bc 64000 be 64000 conform-
action set-dscp-transmit af21 exceed-action set-dscp-transmit af11
violate-action drop
!
UCRouter(config-if)# service-policy output HTTPS
Traffic shaping is recommended by Cisco under the following conditions:
■ There is a mismatch between link speeds at a central site and remote sites (that is, the
central site link speed is greater than that of the remote sites).
■ The aggregate link speed at remote sites is greater than that at the central site.
Traffic shaping can also leverage the MQC framework, and when configuring MQC-
based shaping, traffic can be shaped to either average or peak. If shape average is speci-
fied, traffic is sent at the CIR, with bursting of Be bits per timing interval enabled. If
shape peak is specified, traffic is forwarded at the peak rate.
Example 2-3 shows the configuration of class-based Frame Relay traffic shaping for
HTTPS traffic at least 256 kbps but no more than 512 kbps.
Example 2-3 Frame Relay Traffic Shaping
UCRouter(config)# class-map HTTP-Secure

UCRouter(config-cmap)# match protocol secure-http
!
UCRouter(config-pmap-c)# shape average 512000
UCRouter(config-pmap-c)# bandwidth 256
!
UCRouter(config)# map-class frame-relay FRFMAP
UCRouter(config-map-class)# service-policy output HTTPS
UCRouter(config-map-class)# frame-relay fragment 640
!


UCRouter(config-if)# frame-relay traffic-shaping
!
UCRouter(config-if)# interface serial 0/0.1 point-to-point
UCRouter(config-subif)# ip address 10.10.1.250 255.255.255.0
UCRouter(config-subif)# frame-relay interface-dlci 100
UCRouter(config-fr-dlci)# class FRFMAP
Link Efficiency Mechanisms

Because WAN links have limited bandwidth, QoS tools such as link efficiency mecha-
nisms are helpful for ensuring QoS for voice media and signaling packets/frames travers-
ing WAN connections. Link efficiency tools include
■ Compressed RTP (cRTP)
■ Link Fragmentation and Interleaving (LFI)
■ Multilink PPP (MLP)
■ Frame Relay Forum 12 (FRF.12)
■ Voice Activity Detection (VAD)
Compressed RTP
Real-time Transport Protocol (voice media) is encapsulated inside UDP datagrams, which
are further encapsulated in IP packets. The IP, UDP, and RTP headers on voice packets
total approximately 40 bytes. RTP Header Compression (cRTP) compresses IP/UDP/
RTP headers of packets, reducing the header size to approximately 2 to 4 bytes, thereby
saving bandwidth on WAN links. Cisco recommends enabling cRTP on low-speed WAN
links that have a speed of less than or equal to 768 Kbps.
To enable cRTP for Point-to-Point Protocol (PPP) or High-Level Data Link Control
(HDLC) on an interface, use the ip rtp header-compression command. For a Frame Relay
circuit, use the command frame-relay ip rtp header-compression to enable cRTP on an
interface. An optional passive keyword can be input along with the preceding commands.
When it’s specified, the PPP, HDLC, or Frame Relay interfaces send compressed headers
only if they receive compressed headers. cRTP can be configured via the MQC and by
using the command compression header ip rtp.
Link Fragmentation and Interleaving

LFI helps to ensure that short-length, fixed-size (versus variable-length) voice packets are
not excessively delayed by data packets when being transmitted across low-bandwidth
links such as a Frame Relay link with bandwidth of 768 Kbps or less. LFI enables

disseminating larger data packets into smaller fragments and thereby allows interleaving
smaller voice packets as the packets are queued for transmission on a WAN interface. LFI
can be provisioned for MLP and FRF.12.
Multilink PPP
MLP can be run for several physical links or a single link. Because MLP configuration
is performed under a virtual multilink interface, one or more physical interfaces can be
assigned to a multilink group. The virtual multilink interface has an IP address assigned
to it. Moreover, MLP fragments traffic by default, which is advantageous pertinent to
QoS configuration. Cisco recommends using MLP on links with bandwidth less than or
equal to 768 Kbps. Example 2-4 shows configuration for MLP LFI.
Example 2-4 MLP LFI Configuration
UCRouter(config)# interface multilink 1

UCRouter(config-if)# ip address 10.10.1.250 255.255.255.0
UCRouter(config-if)# ppp multilink
UCRouter(config-if)# ppp multilink interleave
UCRouter(config-if)# ppp fragment delay 10
UCRouter(config-if)# ppp multilink group 1
!
UCRouter(config-if)# no ip address
UCRouter(config-if)# encapsulation ppp
UCRouter(config-if)# ppp multilink
UCRouter(config-if)# ppp multilink group 1
Frame Relay Forum 12

LFI can be enabled for Frame Relay (FRF.12) links with speed less than or equal to 768
Kbps. Example 2-5 illustrates the configuration of FRF.12 LFI for a 64-Kbps circuit.
Example 2-5 FRF.12 LFI Configuration
UCRouter(config)# map-class frame-relay FRF-LFI

UCRouter(config-map-class)# frame-relay cir 64000
UCRouter(config-map-class)# frame-relay bc 640
UCRouter(config-map-class)# frame-relay fragment 80
!
UCRouter(config-if)# frame-relay traffic-shaping
!

UCRouter(config-if)# interface serial 0/0.1 point-to-point

UCRouter(config-subif)# ip address 10.10.1.250 255.255.255.0
UCRouter(config-subif)# frame-relay interface-dlci 100
UCRouter(config-fr-dlci)# class FRF-LFI
The fragment value can be derived from the following formula, keeping in mind that
Cisco recommends maximum jitter of no more than 10 ms:
Fragment Size (bytes) = PVC Speed / 800
In this case, the speed is 64 Kbps, which works out to 64000 / 800 = 80 bytes for frag-
ment size.
Cisco recommends the following for Voice over Frame Relay (VoFR):
■ Enable FRF.12 (fragment size for 10 ms) for circuits less than or equal to 768 Kbps.
■ CIR should be considered as 95 percent of the PVC speed.
■ The committed burst (Bc) should be considered as CIR/100.
■ The excess burst (Be) should always be considered as 0.
Voice Activity Detection

On voice calls (including conference calls), normally only one party speaks at a time, and
there are moments of silence when no party participating in the call is speaking. When
these periods of silence occur, a VAD-enabled network (gateway, endpoints) suppresses
sending packetized silence (blank RTP payload packets) across the network. This saves
bandwidth on a call. VAD can be enabled on a per-dial-peer basis using the vad com-
mand as shown in the following configuration snippet.
UCRouter(config)# dial-peer voice 100 voip
UCRouter(config-dial-peer)# vad
An option to VAD is available for multicast-enabled dial peers: vad aggressive reduces
the noise threshold from –78 to –62 dBm. However, VAD has a small issue associated
with it. Because of the complete silence during quiet periods, the call seems to be dis-
connected for the parties participating in the call. Comfort noise generation (CNG) elimi-
nates this situation by providing white noise. CNG is generated local to a site by the voice
router and can be configured via the comfort-noise command in voice-port configuration
mode, as shown here:
UCRouter(config)# voice-port 0/3/0:23
UCRouter(config-voiceport)# comfort-noise

LAN QoS Considerations

Although it’s normal to think of bandwidth as being infinitely available within a LAN,
it is important to configure LAN switches to ensure that voice and video traffic receive
required QoS treatment. This further helps marking and classifying traffic closest to the
source so that the data center and WAN edge devices trust the marking from the user
access layer—Cisco Unified IP Phones, TelePresence endpoints, and so on. It is important
to establish a trust boundary to classify and mark traffic as close to its source as possible.
QoS Trust Boundary

When deploying QoS, a trust boundary must be defined so that the QoS marking can be
trusted from the devices connected at that boundary. The definition of a trust boundary
depends on what types of devices are connected at the access layer in a LAN and their
trust level. The connected endpoints/devices can be considered as one of the following:
■ Untrusted endpoints: Devices from which QoS marking cannot be trusted when tra-
versing to the switch port, such as workstations, PCs, and servers.
■ Trusted endpoints: Devices that can be trusted from a Cisco Collaboration network
point of view, such as Cisco Unified Wireless IP Phones, Cisco IOS gateways, wire-
less access points, and that mark traffic (media and signaling) and can also re-mark
traffic that has been marked by any connected untrusted devices.
■ Conditionally trusted endpoints: Cisco Unified IP Phones are categorized as con-

ditionally trusted endpoints because they have untrusted endpoints, such as PCs or
laptops connected via a PC port. Because the switch must extend its trust boundary
to a Cisco Unified IP Phone (based on Cisco Discovery Protocol exchange), the IP
Phone transits from a potentially untrusted device to a trusted device, and hence is
conditionally trusted.
Because Cisco Unified IP Phones can exchange CDP messages with the Cisco switch, the
switch can extend trust to the IP Phones and trust traffic received from the IP Phones.
The Cisco IP Phones can re-mark any traffic received from a connected PC on the PC
port to CoS 0. This process is illustrated in the following steps:
Step 1. The switch and Cisco Unified IP Phone exchange CDP messages.
Step 2. The switch extends the trust boundary to the IP Phone.
Step 3. The IP Phone sets CoS to 5 for media traffic and to 3 for signaling traffic.
Additionally, the IP Phone sets CoS to 0 for traffic from the PC port.
Step 4. The switch trusts CoS values from the IP Phone and maps CoS to DSCP for
output queuing. The result is CoS 5 = DSCP EF and CoS 3 = DSCP AF31/CS3.
The command to configure trust boundary and CoS/DSCP values up to or beyond

an IP Phone is mls qos trust. The possible QoS trust policies for ports connected to
conditionally trusted Cisco Unified IP Phones are listed in Table 2-4.

QoS Considerations for WLAN Endpoints 47
Table 2-4 Switch CoS Trust Policies

QoS Trust Policy Description
mls qos trust cos The switch trusts the CoS value of all frames enter-
ing an interface.
mls qos trust cos pass-through The switch does not overwrite the CoS value.
mls qos trust dscp The switch trusts DSCP value of the packets enter-
ing an interface.
mls qos trust device cisco-phone The switch trusts all CoS values that it receives
from a Cisco Unified IP Phone.
switchport priority extend cos The switch overwrites CoS value of Ethernet
frames received from the computer connected to
the PC port of the Cisco Unified IP Phone.
switchport priority extend trust The switch trusts all CoS values on the Ethernet
frames received from the computer connected to
the PC port of the Cisco Unified IP Phone.
QoS Considerations for WLAN Endpoints

Wireless endpoints (such as Cisco Unified IP Phone model 7925), like their wired coun-
terparts, require QoS for voice and video traffic. However, unlike wired networks, wire-
less networks are a shared medium and wireless endpoints do not have committed band-
width for sending or receiving traffic. In case of WLAN infrastructure, QoS is defined
as User Priorities (UP) defined by the IEEE 802.11e standard, and UP markings do not
match the packet markings of 802.1p CoS, ToS, DSCP, or PHB. Hence, the UP markings
have to be mapped to appropriate DSCP (preferably) or other markings recognizable by
wired infrastructure, as shown in Table 2-5.
Table 2-5 WLAN UP to DSCP Mapping for Voice and Video Traffic
Network Service/ IEEE 802.11e UP Marking PHB/DSCP
Application
IP voice media traffic (with 6 EF (DSCP 46)
LLQ)
IP interactive video traffic 5 AF41 (DSCP 34)
(videoconferencing)
IP streaming video traffic 5 CS4 (DSCP 32)
(live, prerecorded)

Network Service/ IEEE 802.11e UP Marking PHB/DSCP

Application
Voice and video signaling 4 CS3 (DSCP 24)
traffic (SIP, H.323, MGCP,
SCCP)
Queuing on the WLAN occurs in two directions, upstream and downstream. For
upstream queuing, devices that support Wi-Fi Multimedia (WMM) can take advantage
of queuing mechanisms that include PQ. For downstream traffic, Cisco Wireless Access
Points (WAP) can provide up to eight queues.
Lightweight APs (LAP) and autonomous APs both offer queuing; however, LAPs have
a built-in platinum-class queuing for voice traffic, whereas for autonomous WAPs, QoS
policies for voice and video have to be created manually. To implement QoS on a WLAN
AP, it is important to apply appropriate settings for WLAN (SSID) for voice to specify
how the Wireless LAN Controller (WLC) and LAP treat the DSCP values and CAC. This
can be done by browsing to the QoS tab on LAP’s WLAN GUI > Edit. For autonomous
WAPs, CAC can be enabled from the CLI by entering the dot11 ssid voice command
followed by the admit-traffic command. Beyond the wireless realm, the QoS for wired
infrastructure helps ensure that voice and video signaling and media traffic go from
source to destination within the expected time and with minimal packet loss and jitter.
QoS Considerations for Virtual Unified

Communications with Cisco UCS
In a virtualized environment, Unified Communications applications connect to a vir-
tual software switch, which can be either VMware vSphere Standard Switch, VMware
vSphere Distributed Switch, or Cisco Nexus 1000V Switch. By default within the UCS
Fabric Interconnect, a priority QoS class is automatically created for all Fibre Channel
(FC) traffic going to a storage area network (SAN) switch. All the FC traffic is marked
with a Layer 2 CoS value of 3, and all non-FC traffic (that is, Ethernet traffic from Cisco
Collaboration applications, including voice media and signaling) defaults to Best Effort
(BE) class. However, the L2 CoS value for FC traffic can be changed from its default value
of 3 to another value, and CoS 3 can be reserved exclusively for the voice signaling traf-
fic. This approach is not recommended by Cisco because some converged network adapt-
ers (CNA) cause problems when the FCoE CoS value is not set to a value of 3. The overall
issue is further aggravated as VMware local vSwitch, VMware distributed vSwitch, and
UCS Fabric Interconnect (FI) cannot map L3 DSCP values to L2 CoS values, and Cisco
Collaboration applications only mark traffic at L3 DSCP for media and signaling (ignor-
ing L2 CoS values).
The Cisco Nexus 1000V software (virtual) switch has the ability to map L3 DSCP values
to L2 CoS values and vice versa. This is advantageous as UC application traffic leaving a
virtual machine enters the Nexus 1000V switch and its L3 DSCP values are mapped to

Medianet 49
corresponding L2 CoS values that can be interpreted by FIs. This traffic can then be pri-
oritized or de-prioritized based on the L2 CoS value inside the UCS FI. Hence, sending
all UC application traffic to Nexus 1000V ensures that the DSCP markings are mapped
to relevant CoS values, or vice versa, and the traffic reaches the intended destination—
that is, the endpoint with proper QoS markings.
Example 2-6 describes the configuration of Nexus 1000V to map L3 DSCP values to L2
CoS values. In this instance, L3 DSCP EF (media) is mapped to CoS 5 and DSCP CS3/AF31
(signaling) is mapped to CoS 3. Finally, the service policy is applied to the port profile.
Example 2-6 Nexus 1000V L3 DSCP to L2 CoS Mapping
n1000v(config)# class-map type qos match-all DSCP-COS5

n1000v(config-cmap-qos)# match dscp EF
!
n1000v(config)# class-map type qos match-any DSCP-COS3
n1000v(config-cmap-qos)# match dscp CS3
n1000v(config-cmap-qos)# match dscp AF31
!
n1000v(config)# policy-map type qos DSCP-COS
n1000v(config-pmap-qos)# class DSCP-COS5
n1000v(config-pmap-c-qos)# set cos 5
n1000v(config-pmap-c-qos)# class DSCP-COS3
n1000v(config-pmap-c-qos)# set cos 3
!
n1000v(config)# port-profile type vethernet accessprofile
n1000v(config-port-prof)# vmware port-group
n1000v(config-port-prof)# switchport mode access
n1000v(config-port-prof)# switchport access vlan 100
n1000v(config-port-prof)# service-policy type qos input DSCP-COS
n1000v(config-port-prof)# no shutdown
n1000v(config-port-prof)# state enabled
UC on UCS applications, when deployed on B-Series servers, store data on one or more
hard drives (SAN storage) that are remote and accessed via FC SAN. Hence, there is a
potential for FC SAN traffic to compete for bandwidth with the Ethernet traffic in the
UCS FI switch. This congestion or oversubscription scenario is very unlikely because the
UCS FI switch provides a high-capacity switching fabric with the usable bandwidth per
server blade far exceeding the possible maximum traffic requirements of a typical UC
application/co-resident configuration.
Medianet
With a host of Cisco Collaboration applications and endpoints at their disposal,
organizations prefer video conferencing to facilitate business communication and

hasten decision making. To facilitate anywhere, anytime immersive or pervasive video,

the underlying network has to be tuned accordingly. Because video traffic is bursty and
unpredictable, fine-tuning existing network infrastructure for video traffic is challenging.
Medianet is the architecture for successful deployment of multiple media and Cisco
Collaboration applications with special focus on video. It requires Media Services
Interface (MSI)-equipped products and features in both smart endpoints/applications
and smart network infrastructure, as shown in Figure 2-4. However, Medianet does not
require an entirely end-to-end network with Medianet enabled in every hop.
Medianet
Mediatrace
IP SLA Video Operations
Performance Monitor
Media Service Proxy
Flow Metadata/
Meta Databases
Media Services Interface
Figure 2-4 Medianet Architecture
Medianet has the following components:
■ Media monitoring tools/components, which give insight into a network’s capacity,

performance, and readiness to support rich-media content. These tools include
■ Mediatrace
■ IP SLA Video Operation
■ Performance Monitor
■ Medianet is supported by the following endpoints (not an all-inclusive list):
■ Cisco TelePresence

Medianet 51
■ WebEx Meeting Client for Windows
■ Jabber for Windows
■ EX Series endpoints
■ Cisco Catalyst switches
■ Cisco IOS routers
■ Media awareness tools/components, which enable Medianet to become aware of

various applications and rich-media content. These tools include
■ Media Services Interface (MSI)
■ Media Services Proxy (MSP)
■ Flow Metadata (Meta Databases)
The various Medianet architecture components are listed and described in Table 2-6.
Table 2-6 Cisco Medianet Components

Medianet Component Description
Mediatrace A Medianet component that helps discover Layer 2 and Layer 3
devices along the flow path and can provide information rang-
ing from device-specific, such as CPU or memory, to interface-
specific, such as input interface speed, to flow-specific, such as
DSCP values or jitter. Mediatrace collects information from net-
work nodes along the traffic flow path and presents this informa-
tion for easy analysis. Infrastructure devices such as routers must
have Mediatrace enabled for discovery and information sharing.
It leverages RSVP as the transport protocol.
IP Service Level A readiness assessment tool for gauging a network’s capacity to
Agreement Video carry rich-media traffic. It is used for network-based IP SLAs for
Operation (IP SLA VO) synthetic traffic generation, pre-deployment assessment, pre-
event testing, and post-event troubleshooting and measurements.
It allows tracking video-critical statistics using the network,
where each element becomes a “Probe.”
Performance Monitor A Cisco tool that discovers and validates RTP traffic on a hop-
by-hop basis. It is used to determine jitter, packet loss, and multi-
plexed media streams. Performance Monitor also recognizes TCP
flows and IP constant bit rate (CBR) traffic. For TCP, Performance
Monitor reports on round-trip time (RTT) and packet loss, where-
as for IP CBR traffic, Performance Monitor reports packet loss
and media rate variation (MRV). It also helps isolate faults in the
network quickly because of its ability to discover and report on a
per-hop basis.

Medianet Component Description

Media Services Proxy Provides a subset of Medianet services on behalf of non-Cisco
(MSP) and legacy endpoints. The primary function of MSP is to evolve
Medianet from Cisco only to include third-party endpoints by
leveraging standards-based signaling protocols such as SIP and
H.323. This enables a Medianet-enabled network to learn about
the characteristics of endpoints and applications from legacy
systems or third-party devices. MSP should be positioned at the
user (access) edge and resource (enterprise) edge.
Flow Metadata/Meta Enables the application to convey information about itself to the
Databases underlying network via MSI-enabled endpoints as well as MSP-
or NBAR-enabled infrastructure on behalf of non-MSI endpoints
(such as smart phones and tablets). This information comprises
Flow Metadata and builds Meta Databases. Different Metadata
identifies different media flows. It uses RSVP as the transport
protocol. Metadata can be enabled at MSI-compliant endpoints,
routers with NBAR, and softclients.
Media Services Interface A software package that resides on the endpoints. MSI comes
(MSI) with multiple application programming interfaces (API) to enable
endpoints and media applications to take advantage of the
Medianet services. MIS enables a media application to identify
itself and its media flow to the network. MSI also enables net-
work management to have better visibility into the application
and its media flow. For PCs, MSI is available for download from
Cisco.com as MSI.msi and runs as a Windows service. MSI ser-
vice is shared by all MSI-aware applications such as WebEx and
Jabber for Windows.
Medianet QoS Classes of Service

As multiple endpoints and applications can leverage Medianet, each group of devices,
endpoints, and media applications has unique traffic patterns and service level require-
ments that necessitate a dedicated QoS class to meet that service level. RFC 4594
presents configuration guidelines for DiffServ service classes to meet specific business
requirements. Cisco has made a minor modification to its adoption of RFC 4594 for
Medianet. Table 2-7 describes the various network applications and respective QoS
(DiffServ) service classes.

Medianet 53
Table 2-7 Medianet Service Classes, Based on Cisco QoS Recommendation

Network Service/Application Service Class (DSCP) Queuing and Dropping
VoIP Telephony EF PQ
Broadcast Video CS5 Optional PQ
Real-Time Interactive CS4 Optional PQ
Multimedia Conferencing AF4 Bandwidth Queue +
WRED
Multimedia Streaming AF3 Bandwidth Queue +
WRED
Network Control CS6 Bandwidth Queue
Voice/Video Signaling CS3 Bandwidth Queue
Ops, Admin, Management (OAM) CS2 Bandwidth Queue
Transactional Data AF2 Bandwidth Queue + DSCP
WRED
Bulk Data AF1 Bandwidth Queue + DSCP
WRED
Best Effort DF Default Queue + RED
Scavenger CS1 Minimum Bandwidth
Queue
Table 2-8 lists the various service classes defined by Cisco for Medianet and describes
their respective services.
Table 2-8 Medianet QoS Service Classes

Class Service
VoIP Telephony For VoIP telephony media/bearer traffic. Applicable to RTP
streams leveraging various codecs such as G.711 and G.729.
Broadcast Video For broadcast TV or live events. Applicable to live video traffic
from Cisco Digital Media System (DMS) streams to desktops,
Cisco IP Video Surveillance, or live Cisco Enterprise TV (ETV)
streams.
Real-Time Interactive For high-definition interactive video applications including
voice and video content such as Cisco TelePresence.
Multimedia Conferencing For desktop software–based multimedia Cisco Collaboration
applications such as Cisco Unified Personal Communicator and
Cisco Unified Video Advantage. It focuses primarily on voice
and video components of these applications.

Class Service
Multimedia Streaming For Video-on-Demand (VoD) streaming video flows. Applicable
to applications such as Cisco Digital Media System VoD
streams.
Network Control For network control plane traffic such as routing protocols (for
example, EIGRP, OSPF, BGP, HSRP).
Signaling For voice and video signaling traffic that supports IP voice
and video telephony. Applicable to signaling protocols such as
SCCP, SIP, H.323, and MGCP.
Operations/Administration/ For network operations, administration, and management traf-
Management (OAM) fic, such as SSH and SNMP.
Transactional Data For interactive data applications such as Enterprise Resource
Planning (ERP) and Customer Relationship Management (CRM)
applications.
Bulk Data For non-interactive data applications such as email, FTP/SFTP
transfers, backup operations, and so on.
Best Effort Acts as the default class for applications that do not require a
specific level of service and can be assigned to this class.
Scavenger For low-priority data and non-business-related traffic such as
P2P and gaming-oriented applications.

Chapter 3
Telephony Standards and

Protocols
Cisco Collaboration networks build on various standards and protocols that enable
organizations and people to harness the power of Voice over IP (VoIP). This chapter
describes telephony protocols and criteria, including
■ Voice and video codecs
■ Real-time Transport Protocol (RTP)
■ Secure RTP (SRTP)
■ Real-time Transport Control Protocol (RTCP)
■ Skinny Client Control Protocol (SCCP)
■ Media Gateway Control Protocol (MGCP)
■ Session Initiation Protocol (SIP)
■ H.323 (H.225, H.245, RAS)
■ Analog signaling protocols

■ Digital signaling protocols
■ Fax and modem protocols
Voice and Video Codecs

Codec is an abbreviated form of coder-decoder. Codecs perform encoding and decoding
on a digital data stream or signal and translate VoIP media streams into another format
such as analog to digital, digital to analog, and digital to digital. A digital signal proces-
sor (DSP) is required to process voice signals from one format to another. Various codec
standards define the compression rate of the voice payload. Table 3-1 lists the most com-
monly used codecs in a Cisco Collaboration network.

56 Chapter 3: Telephony Standards and Protocols
Table 3-1 Voice and Video Codecs

Codec Description
H.264 Also known as MPEG-4 Part 10 and Advanced Video Coding
(AVC). It is one of the most commonly used formats for the
recording, compression, and distribution of video content. H.264
allows the compression of video much more effectively, enabling
it to provide good quality video at much lower rates compared
with previous standards such as H.263.
Internet Low Bitrate Codec A narrowband, high-complexity speech codec that was developed
(iLBC) by Global IP Solutions. iLBC has built-in error correction func-
tionality. iLBC is supported by SIP, SCCP, MGCP, and H.323 end-
points. iLBC results in a payload bit rate of 13.33 kbps for 30-ms
frames and 15.20 kbps for 20-ms frames.
Internet Speech Audio A robust, bandwidth-adaptive, wideband and super-wideband
Codec (iSAC) voice codec developed by Global IP Solutions. iSAC is used in
many VoIP and streaming audio applications. iSAC is supported
for SCCP and SIP endpoints. iSAC has a sampling frequency of
16 kHz and supports an adaptive bit rate from 10 to 32 kbps.
Low Overhead Audio An Advanced Audio Coding-Low Delay (AAC-LD) MPEG-4 Part
Transport Multiplex 3 media type. It is a super-wideband audio codec that provides
(LATM) superior sound quality for voice and music. LATM codec pro-
vides equal or improved sound quality, even at lower bit rates. It
can operate at variable bit rates of 48, 56, 64, or 128 kbps. LATM
is supported for SIP endpoints and Tandberg endpoints.
G.722 An ITU-T standard wideband audio codec. Compared to G.711,
which has a sampling rate of 8 kHz and maximum frequency
range of 3.44 kHz, G.722 has a sampling rate of 16 kHz and a fre-
quency range of approximately 7 kHz. It can operate at variable
bit rates of 48, 56, or 64 kbps. G.722 is supported for SCCP and
SIP endpoints.
Wideband codecs G.722.1 and G.722.2 are a few other wideband codecs used in
IP telephony. G.722.1 is a licensed (royalty-free) ITU-T standard
audio codec that provides high-quality speech. G.722.1 operates
at a bit rate of 24 or 32 kbps and has a frequency range of up to
7 kHz with 16 kilo samples per second (ksps) audio coding.
G.722.1 is supported for SIP and H.323 endpoints only. G.722.2,
on the other hand, is based on Adaptive Multi-Rate Wideband
(AMR-WB) speech coding standard, AMR-WB being the same
codec as the 3GPP (mobile). G.722.2 is licensed by VoiceAge
Corporation and is based on patent. G.722.2 operates at a bit rate
of 16 kbps with a frequency range of 16 kHz (using 14-bit resolu-
tion) and is processed at 12.8 kHz.
003_9780133845969_ch03.indd 56 6/25/14 8:28 AM

VoIP Media Transmission Protocols 57
VoIP Media Transmission Protocols

A VoIP network requires media transmission protocols to carry packetized voice
samples. This section highlights the various media transmission protocols used in Cisco
Collaboration networks: RTP, RTCP, SRTP, and SRTCP.
Real-time Transport Protocol (RTP) provides end-to-end network functions and delivery
services for delay-sensitive, real-time traffic such as voice and video. RTP runs on top
of UDP and is a connectionless protocol. It provides a number of services, including
Payload-type identification, sequence numbering, and time stamping. RTP is used con-
currently with Real-time Transport Control Protocol (RTCP), used for monitoring traffic
statistics of voice streams. An RTP session is established for each voice/video stream
with source and destination IP addresses and UDP ports (that are defined during signal-
ing phase). RTP uses even UDP port numbers, while RTCP uses next-higher odd port
numbers.
RTCP provides out-of-band control information for an RTP flow. RTCP is used for traffic
statistics reporting such as QoS reporting, quality of the data distribution, control infor-
mation, and feedback on current network conditions (that is, jitter and delay).
Secure Real-time Transport Protocol (SRTP), as the name suggests, is the secure form of
RTP, with authentication and encryption enabled for voice/video payloads. It leverages
an AES 128-bit cipher for enabling encrypted RTP streams. For authentication, SRTP
uses the HMAC-SHA1 hashing algorithm. SRTP also has a sister protocol, called Secure
RTCP (or SRTCP), which provides to RTCP the same security-related features that SRTP
provides to RTP.
Figure 3-1 demonstrates the media (RTP or SRTP) streams along with statistics reporting
signaling (RTCP or SRTCP) setup between two IP Phones and a call-control agent.
Call Control Server
Signaling Protocol
RTP/SRTP
RTCP/SRTCP
IP Phone IP Phone
Figure 3-1 RTP/SRTP and RTCP/SRTCP Flow

VoIP Signaling Protocols

This section provides an insight to various signaling protocols used for VoIP.
Skinny Client Control Protocol

SCCP is a Cisco-proprietary signaling protocol that is based on a master/slave model. In a
Cisco Collaboration network, SCCP is used by Cisco Unified Communications Manager
(CUCM), CUCM Express (CUCME), and Cisco Business Edition 6000/7000 to commu-
nicate with devices such as Cisco IOS analog gateways, endpoints such as Cisco Unified
IP Phones, and applications such as Cisco Unity Connection. SCCP is available both in its
native nonsecure form and as Secure SCCP (SCCPS), where the latter provides TLS-based
signaling. SCCP uses TCP ports 2000–2003 and SCCPS uses TCP port 2443.
CUCM uses SCCP to control analog ports on VGXXX gateways and ATA18X, FXS
ports on Cisco IOS router modules, Cisco Unified IP Phones, Cisco roundtable confer-
ence phones, media resources such as annunciator resources, conferencing resources,
transcoding resources, Music on Hold (MoH) resources, and Media Termination Point
(MTP). SCCP is also used by IOS routers running Cisco Unified Survivable Remote Site
Telephony (SRST), H.323 proxy servers, or Tandberg video endpoints. SCCP sends dual-
tone multifrequency (DTMF) digits out-of-band.
With SCCP as the signaling protocol, CUCM collects each digit that the user
enters on the keypad of the phone via the StationInit message sent by the endpoint.
Simultaneously, digit analysis takes place on CUCM in real time. This occurs until the
user dials digits or CUCM comes to the conclusion that there is only one potential
match. Then the call is routed to the destination device or translation/route pattern. The
call is routed immediately after the caller dials the final digit, provided the dial plan does
not have any overlapping directory numbers/patterns or the call is not intended for an
international route pattern. If the call is intended for an international route pattern, callers
must wait for the inter-digit timeout (which can be avoided by pressing the # sign at the
end of dial string).
The following are various call states that CUCM can send to SCCP endpoints such as
Cisco Unified IP Phones in SCCP:
1—Off Hook
2—On Hook
3—Ring Out
4—Ring In
5—Connected
6—Busy
7—Line In Use
8—Hold
9—Call Waiting

10—Call Transfer
11—Call Park
12—Call Proceed
13—In Use Remotely
14—Invalid Number
Figure 3-2 illustrates the SCCP call flow between a CUCM server and SCCP endpoints
registered to it.
The following events occur during the SCCP call flow illustrated in Figure 3-2:
1. IP Phone A goes off-hook and signals this event to CUCM.
2. CUCM sends messages to IP Phone A to play the dial tone, display text, and set its
lamp state to on.
3. IP Phone A starts sending digits dialed by the user, with the first digit dialed and
sent to CUCM leading CUCM to specify to IP Phone A to stop playing the dial
tone.
4. The user continues dialing the number, and these digits are sent to CUCM. CUCM
performs digit analysis and finds a match for the dialed number that corresponds to
the directory number (DN) of IP Phone B.
5. CUCM indicates to IP Phone B that it should blink its lamp and ring to inform the
user of an incoming call. CUCM also sends information about the calling party (IP
Phone A) to IP Phone B. This information contains calling party name, calling party
number, and so on.
6. CUCM sends an alerting (ringback) message to IP Phone A at the same time as it

rings IP Phone B. CUCM also sends information about the called party (IP Phone B)
to IP Phone A.
7. The user of IP Phone B answers the call and goes off-hook. An off-hook message is
sent to CUCM.
8. CUCM instructs IP Phone B to stop blinking the lamp (set to a steady state) and to
stop the ring tone. At the same time, CUCM also informs IP Phone A to stop the
alerting tone.
9. CUCM requests information such as the to/from IP addresses and the UDP ports
for RTP exchange between IP Phone A and IP Phone B. Both phones respond, and
CUCM informs IP Phone A of IP Phone B’s RTP information and vice versa. CUCM
notifies the IP Phones to open the media channel and start media transmission.
10. RTP traffic flow is set up between the two IP Phones as the users begin their
conversation.
11. The user of IP Phone B decides to end the call, thereby sending an on-hook message
to CUCM.

IP Phone A CUCM IP Phone B
Station Off Hook
Station Display Text
Station Set Lamp (Steady)
Station Start Tone (Dial Tone)
Station Keypad Button
Station Stop Tone (Dial Tone)
Station Keypad Button Station Call Information
Station Set Lamp (Blink)
Station Set Ringer (Ring)

Station Call Information
Station Start Tone (Alerting)

Station Off Hook
Station Set Ringer (Off)

Station Stop Tone
Station Set Lamp (Steady)
Station Open Receive Channel
Station Open Receive Channel
Station Cell Information
Station Open Receive Channel Ack Station Start Media Transmission
Station Start Media Transmission Station Open Receive Channel Ack
RTP RTP
Station Close Receive Channel Station On Hook

Station Set Lamp (Off)
Station Stop Media Transmission
Station Close Receive Channel
Station Set Lamp (Off)
Station Stop Media Transmission
Station On Hook
Figure 3-2 SCCP Call Flow Between Two IP Phones Registered to Same CUCM

12. CUCM notifies the IP Phones to close the media channel and end media
transmission.
13. CUCM informs the IP Phones to set their lamp states to off.
14. IP Phone A sends an on-hook message to CUCM as the user goes on-hook.
Media Gateway Control Protocol

Media Gateway Control Protocol (MGCP), a successor to Simple Gateway Control
Protocol (SGCP), is an implementation of the MGCP architecture for controlling media
gateways on IP networks connected to the plain old telephone service (POTS). MGCP is
defined in RFC 3435 and is a text-based master/slave protocol, with a call-control agent
as master and a controlled gateway as slave. MGCP uses Session Description Protocol
(SDP) for specifying and negotiating the media streams. MGCP leverages UDP port 2427
for control traffic and TCP port 2428 for backhaul (explained later in this section). Due to
its master/slave nature, MGCP allows the centralization of dial plans because the dial plan
intelligence is with CUCM.
The MGCP architecture defines MGCP Media Gateway Control (MGC) and Media
Gateway (MG). MGC is a call-control agent such as CUCM and has the call-control intel-
ligence, thus it controls the MG’s analog (FXS/FXO) or digital (T1-PRI/T1-CAS) port/
endpoint/trunk.
MGCP architecture defines nine call states, as shown in Table 3-2.
Table 3-2 MGCP Call States

MGCP Call State Description
CreateConnection Command from a call-control agent to an MGCP-controlled gate-
(CRCX) way for creating a new connection between two MGCP endpoints.
The connection creation is based on parameters such as codec,
allowable bandwidth, gain control, silence suppression, and so on.
ModifyConnection Command from a call-control agent to an MGCP-controlled
(MDCX) gateway that modifies the parameters associated with an existing
connection.
DeleteConnection Bidirectional command that is used by a call-control agent to inform
(DLCX) the gateway that it should terminate a connection. A gateway can
also send this command to indicate that a connection needs to be
terminated. The gateway also sends statistics associated with the
connection when contacting the call-control agent.
EndpointConfiguration Configuration command from a call-control agent to an MGCP-
(EPCF) controlled gateway. It configures the gateway with the bearer infor-
mation, which specifies whether audio calls will be encoded using
mu-law or A-law.

MGCP Call State Description

NotificationRequest Command from a call-control agent to an MGCP-controlled gate-
(RQNT) way to instruct the gateway to inform the call-control agent when
specific events such as on-hook/off-hook actions or DTMF tones
occur on a specified endpoint.
AuditEndpoint (AUEP) Command from a call-control agent to an MGCP-controlled gate-
way to audit the status of an endpoint (port), such as bearer infor-
mation, signal status, and event status.
AuditConnection Command from a call-control agent to an MGCP-controlled gate-
(AUCX) way to discover the status of a connection, such as connection
mode, call ID, and connection parameters.
Notify (NTFY) Command from a gateway to a call-control agent to inform the
call-control agent when requested events occur such as on-hook/off-
hook and digit reception.
RestartInProgress (RSIP) Command from a gateway to a call-control agent to inform the call-
control agent that the gateway is taking an endpoint or group of
endpoints out of service or returning an endpoint or group of end-
points to service. There are three types of restart: Restart (endpoint
in service), Graceful (wait until call clearing), and Forced (endpoint
out of service).
MGCP also uses certain return codes that reflect different events occurring on the gate-
way and, accordingly, enables the gateway to update the call-control agent. Following are
the types of MGCP return codes defined in RFC 3661:
■ 000: Response acknowledgement message
■ 1XX: Transaction execution-related messages
■ 2XX: Transaction successful messages
■ 4XX: Transient error messages
■ 5XX: Permanent error messages
MGCP messages are sent on UDP port 2427, and TCP port 2428 is used to exchange kee-
palive packets between an MGCP-controlled gateway and CUCM. This allows for MGCP
PRI/BRI backhaul between an MGCP gateway and CUCM wherein the backhaul is used
to transport ISDN Q.931 (D channel signaling) information from the gateway to CUCM.
This allows CUCM to recognize the status of ISDN Layer 3 for the port/endpoint/trunk
being controlled on the MGCP gateway.
Example 3-1 shows the MGCP configuration for a voice gateway.

Example 3-1 MGCP Gateway Configuration
MGCPRouter(config)# ccm-manager fallback-mgcp

MGCPRouter(config)# ccm-manager switchback graceful
MGCPRouter(config)# ccm-manager redundant-host 10.76.108.146 10.76.108.147
MGCPRouter(config)# ccm-manager music−on-hold
MGCPRouter(config)# ccm-manager mgcp
!
MGCPRouter(config)# mgcp
MGCPRouter(config)# mgcp call-agent 10.76.108.146 2427 service-type mgcp version 0.1
MGCPRouter(config)# mgcp bind control source-interface loopback 0
MGCPRouter(config)# mgcp bind media source-interface loopback 0/0
MGCPRouter(config)# mgcp dtmf-relay codec all mode out-of-band
!
MGCPRouter(config)# dial-peer voice 999 pots
MGCPRouter(config-dial-peer)# service mgcpapp
MGCPRouter(config-dial-peer)# port 1/0/1:23
In Example 3-1, the ccm-manager fallback-mgcp command enables CUCM fallback

when a CUCM server is unavailable. The command ccm-manager switchback graceful
enables graceful switchback from one CUCM server to another in case of a CUCM server
failure. Other options are immediate, never, schedule-time, and uptime-delay. The com-
mand ccm-manager redundant-host defines redundant hosts (CUCM servers) for the
MGCP gateway to connect with. The command ccm-manager music-on-hold enables
MoH.
The command mgcp call-agent defines call-control agents for the MGCP gateway. The
commands mgcp bind control source-interface and mgcp bind media source-interface
bind signaling and media, respectively, to the desired interface (physical, logical, or loop-
back). The command mgcp dtmf-relay codec defines DTMF-related parameters. Finally,
mgcpapp associates a dial peer with an MGCP application.
Optionally, the MGCP gateway can download the configuration from CUCM and auto-
configure per the parameters defined on CUCM:
UCRouter(config)# ccm-manager config server 10.76.108.146
UCRouter(config)# ccm-manager config
In the previous configuration, the command ccm-manager config server defines the
server that the gateway should contact for downloading the XML config file, and
ccm-manager config enables the download.
003_9780133845969_ch03.indd 63 6/25/14 8:28 AM

To add an MGCP gateway in CUCM, follow these steps:
1. Go to the Cisco Unified CM Administration page and choose Device > Gateway.
2. Click Add New.
3. From the Gateway Type drop-down menu, choose the MGCP gateway type that you
want to add, followed by MGCP as the protocol.
4. Enter the gateway Domain Name (such as MGCPRouter.corp.com), enter a descrip-

tion, and select the appropriate CUCM Group.
5. Configure the Slot/VIC/Endpoint. Click Save.
6. Select the subunit (depending on the router model number) and configure the same.
An MGCP gateway registers to its preferred CUCM server (as defined in CUCM Group
and on the gateway itself). Figure 3-3 illustrates the MGCP call flow between a CUCM
server and MGCP endpoints registered to it.
MGCP Gateway A CUCM MGCP Gateway B
V V
Notification Request (RQNT) Notification Request (RQNT)
RQNT Response RQNT Response
Notify (NTFY) (Off Hook and Dial)
Create Connection (CRCX)
CRCX Response
CRCX with RQNT
CRCX Response
Modify Connection (MDCX)
MDCX Response
RTP RTP
NTFY (On Hook)
DLCX DLCX
DLCX Response DLCX Response
Figure 3-3 MGCP Call Flow Between Two Gateways Registered to Same CUCM Server

The following events occur during the MGCP call flow illustrated in Figure 3-3:
1. The call-control agent (CUCM) sends a notification request (RQNT) to each gateway.
The request instructs the gateways to wait for an off-hook transition (event). When
the off-hook transition event occurs, the call-control agent instructs the gateways to
supply a dial tone (signal).
2. The gateways respond to the request (RQNT). The gateways and the call-control
agent wait for a triggering event.
3. An endpoint/user on Gateway A goes off-hook. The gateway provides a dial tone.
4. Gateway A sends a notify (NTFY) to CUCM to advise that a requested event has
occurred, followed by identifying the endpoint and the event (that is, the dialed
digits).
5. CUCM does digit analysis and, after confirming that a call is possible based on the
dialed digits, instructs Gateway A to create a connection (CRCX) with its endpoint
(port/trunk).
6. The gateway responds with a session description if it is able to accommodate the

connection. The session description identifies (at least) an IP address and UDP port
for use in a subsequent RTP session.
7. CUCM sends a connection request to Gateway B. In the request, CUCM provides

the session description obtained from Gateway A. CUCM also sends a notification
request that instructs Gateway B about the signals and events that it should now con-
sider relevant, such as ringing and the endpoint’s off-hook transition.
8. Gateway B responds to the request with its session description to CUCM.
9. CUCM relays the session description received from Gateway B to Gateway A in a

modify connection request (MDCX). This request might contain an encapsulated
notify request that describes the relevant signals and events at this stage of the call
setup. Gateway A responds to the request.
10. Now that Gateway A and Gateway B have the required session descriptions to estab-
lish the RTP session, they open an RTP stream over pre-negotiated (CUCM relayed)
IP addresses and UDP ports.
11. The endpoint/user on Gateway A terminates the call and goes on-hook. CUCM
requested a notification of such an event, so Gateway A notifies CUCM.
12. CUCM sends a delete connection (DLCX) request to each gateway so the session
can be terminated.
13. The gateways delete the connection and respond to CUCM.
Session Initiation Protocol

Session Initiation Protocol (SIP) is an IETF standards-based signaling protocol widely
used for multimedia (voice and video) communications. SIP is an application layer

protocol and can leverage TCP or UDP for transmission. It is a text-based protocol and
has many elements of HTTP. SIP can also operate in its secure form with TLS for signal-
ing, known as Secure SIP (SIPS). SIP uses TCP/UDP port 5060 and SIPS uses TCP port
5061.
Analogous to MGCP, SIP uses SDP for negotiating media type and format such as audio
and video codecs, transport protocol parameters, ports, and so on. SDP operates in an
offer-answer approach such that the session-initiating endpoint (UA) specifies desired
session parameters (such as supported codecs), and the receiving endpoint (UA) replies
with matching session parameters. Each resource in a SIP network is identified by a
Uniform Resource Identifier (URI). A typical SIP URI is in the following format:
sip:username:password@host:port.
SIP sends DTMF digits in-band. However, it can use out-of-band DTMF as well. In a SIP
session, DTMF can be transported as KeyPad Markup Language (KPML), Unsolicited
Notify (UN), or Network Termination Equipment (NTE) (RFC 2833). KPML and UN are
out-of-band DTMF transportation mechanisms, whereas NTE is an in-band mechanism
for DTMF delivery. KPML and NTE are standards based, whereas UN is a non-standard
protocol.
SIP phones can leverage either KPML or SIP dial rules for dialing a number to a destina-
tion phone/route pattern. SIP (Type-A) phones leverage SIP dial rules and use a different
method compared to SIP KPML (Type-B) phones.
KPML is similar to SCCP in terms of the process used to collect each digit. The caller
enters digits on the keypad of the phone, and digit analysis occurs in real time, after
which CUCM routes the call to the destination device or translation/route pattern. SIP
KPML uses SIP NOTIFY messages to carry the dialed digits from the phone to CUCM.
As indicated, devices that use KPML are known as Type-B SIP phones. The phones that
support KPML are automatically enabled for KPML. No configuration on CUCM is
necessary for these devices to support KPML. KPML is configured under the SIP Profile
applied to the IP Phone.
SIP dial rules on CUCM can be configured to allow the SIP phone to download a dial
plan file (dialplan.xml) from the CUCM TFTP server when the phone boots. When a caller
enters digits on the phone keypad, the phone analyzes the dialed digits and compares
them with the strings contained within the dialplan.xml file stored locally on the phone.
When there is a match to the dialed number and the timeout is set to 0, the phone sends to
CUCM a SIP INVITE message that contains the entire called number. If the dialed number
does not match any of the strings contained within the diaplan.xml file, the call will only
be routed when the inter-digit timeout expires (or the caller presses “#” or “Dial”).
If a dialplan.xml file is downloaded to a phone that supports KPML, KPML is disabled

and the phone behaves in the same way as a Type-A SIP phone. A hybrid of using KPML
and dial rules is not supported, and SIP dial rules/dial plan always take priority over
KPML. The exception to this statement is when CUCME is used and the last statement
within the dial plan contains a dial pattern with a single wildcard character (.) as the last
pattern in the dial plan.

A SIP network includes many elements for establishing, terminating, and managing SIP
sessions, as listed and described in Table 3-3.
Table 3-3 SIP Network Elements

Network Element Description
SIP user agent (UA) Manages send and receive SIP messages and manages a session. A SIP
endpoint can act as both a user agent client (UAC) and a user agent
server (UAS).
SIP user agent client Initiates and sends requests and gets a response from a SIP UAS or
(UAC) SIP proxy server. UAC, however, is a logical role and lasts only for the
duration of a SIP transaction.
SIP user agent server Responds to SIP requests by accepting, rejecting, or redirecting the
(UAS) request. Analogous to UAC, UAS is also a logical role that lasts only
for the duration of a SIP transaction.
SIP proxy server Provides routing, enforces policies, provides features, and authenti-
cates and authorizes users.
SIP redirect server UAS server that provides address translation and that generates 3XX
(Redirection) responses to requests it receives, thereby directing the
client to contact an alternate set of URIs. It allows SIP proxy servers
to redirect invites to external domains as well.
SIP registrar server A SIP endpoint that accepts REGISTER requests from SIP UAs and
places the information received in those requests into a location ser-
vice for the domain it handles. This allows users to register their cur-
rent locations.
SIP back-to-back user Receives requests from UAs. However, it generates a new request on
agent (B2BUA) their path to the destination.
There are two SIP message types: request and response. A request message is sent by a
client to a server and is used to invoke certain methods (functions). A response message is
sent by a server to a client in answer to the request and indicates the status of the request
received.
Table 3-4 lists the methods available for SIP requests.
Table 3-4 SIP Request Methods

Method Description
INVITE Used by a UA to initiate a session with a UAC. When this arrives at
a UAS, the UAS processes it and sends a suitable type of response
message.

Method Description
REGISTER Method used by a UA to indicate its current IP address and the
URLs for which it would like to receive calls to register its contact
information. Cisco SIP phones send their MAC addresses and regis-
ter their lines with the primary CUCM using REGISTER messages.
ACK Confirms reliable message exchange and is sent in reply to a final
response message from a server.
BYE Terminates a session between users.
CANCEL Terminates a pending request (a request for which a final response
has not yet been received).
OPTIONS Requests information about the capabilities of a caller, without set-
ting up a call.
Provisional Response Adds an acknowledgement system to the Provisional response (1XX).
Acknowledgement PRACK is sent in response to a Provisional response.
(PRACK)
Table 3-5 lists the types of SIP responses.
Table 3-5 SIP Responses

SIP Response Description
Provisional (1XX) Indicates that a request has been received and is being processed. It
is informational in nature.
Success (2XX) Indicates success (the action was successfully received, understood,
and accepted).
Redirection (3XX) Indicates that further action needs to be taken by the sender to
complete the request, perhaps in case of a redirection in response
to a UA by SIP proxy.
Server Error (5XX) Indicates a server’s failure to fulfill a valid request by client.
Global Failure (6XX) Indicates a global failure and that the request cannot be fulfilled at
any server.
Figure 3-4 depicts a SIP call flow between UAs (Cisco Unified IP Phones) and a UAS/
B2BUA (CUCM).

IP Phone A CUCM IP Phone B
REGISTER REGISTER
200 OK 200 OK
INVITE (SDP)
INVITE (SDP)
100 Trying
100 Trying
180 Ringing
180 Ringing
200 OK
200 OK
ACK
ACK
RTP RTP
BYE
BYE
200 OK
200 OK
Figure 3-4 SIP Call Flow Between Two Endpoints Registered to Same CUCM
The following events occur during the SIP call flow illustrated in Figure 3-4:
1. Cisco Unified IP Phones (SIP UAs) send REGISTER requests to CUCM (SIP UAS).
CUCM sends the response 200 OK after authenticating the UAs.
2. IP Phone A goes off-hook and sends an INVITE to CUCM. In response, CUCM
sends a TRYING 100. At the same time, using the digits dialed by the user, CUCM
reroutes the request to IP Phone B. The INVITE contains SDP information for capa-
bilities negotiation.
3. IP Phone B sends a Ringing 180 response to CUCM when the phone begins to ring.
CUCM sends 180 ringing (alerting) to IP Phone A.
4. The response 200 OK message corresponds to the user at IP Phone B answering the
call, at which time IP Phone A gets 200 OK from CUCM as well.
5. IP Phone A sends an ACK to CUCM, and CUCM sends an ACK to IP Phone B in
reply to 200 OK messages followed by opening the media channel. RTP starts with
the parameters (ports, addresses, codecs, etc.) of the SDP protocol (negotiated dur-
ing INVITE).
6. The user at IP Phone A decides to terminate the call, and the phone sends BYE to
CUCM. Consecutively CUCM sends BYE to IP Phone B.
003_9780133845969_ch03.indd 69 6/25/14 8:28 AM

7. Both phones reply with an OK 200 message to confirm that the final message has
been received correctly.
SIP supports Early Offer (EO) and Delayed Offer (DO) for capability negotiation. In case
of an Early Offer, the SDP message is sent from the calling party to the called party in
the initial INVITE message. The called party responds with the negotiated capability in
the 200 OK to the calling party. In case of Delayed Offer, the called party sends the SDP
message in the 200 OK message to the calling party. The calling party responds with the
negotiated parameter in the ACK message to the called party.
SIP also supports Early Media and Delayed Media for media channel negotiation. In the
case of Early Media, the media between the called and calling party is established before
the session establishment. The called party sends 183 instead of 180 and allows the call-
ing party to establish a bearer channel between the two. With Delayed Media, the media
is established once the SIP session negotiation is complete.
On Cisco IOS, voice gateway SIP configuration/options such as transport type (TCP/
UDP), registrar server configuration, binding all traffic to a certain interface, and so on
can be configured under voice services voip. Example 3-2 shows a configuration of the
SIP voice service where the session transport protocol is set to TCP (default is UDP) and
SIP EO is forced for all SIP sessions.
Example 3-2 SIP Global Parameter Configuration
SIPRouter(config)# voice service voip

SIPRouter(conf-voi-serv)# sip
SIPRouter(conf-serv-sip)# session transport tcp
SIPRouter(conf-serv-sip)# bind all source-interface loopback 0
SIPRouter(conf-serv-sip)# early-offer forced
Example 3-3 illustrates the SIP UA configuration for defining a remote registrar server (a
local registrar server can be defined in voice service voip).
Example 3-3 SIP UA Configuration
SIPRouter(config)# sip-ua
SIPRouter(config-sip-ua)# registrar ipv4: 10.76.108.146 tcp
SIPRouter(config-sip-ua)# registrar ipv4: 10.76.108.147 tcp secondary
SIPRouter(config-sip-ua)# authentication username registrar password C1sc0123
Consecutively at least one VoIP dial peer is required on the gateway so it can send calls
to and receive calls from CUCM. Example 3-4 illustrates the configuration of a SIP dial
peer.

SIP Session Description Protocol 71
Example 3-4 SIP Dial Peer Configuration
SIPRouter(config)# dial-peer voice 10 voip

SIPRouter(config-dial-peer)# session protocol sipv2
SIPRouter(config-dial-peer)# session target ipv4:10.76.108.146
SIPRouter(config-dial-peer)# destination-pattern 1...$
SIPRouter(config-dial-peer)# dtmf-relay rtp-nte sip-notify
SIPRouter(config-dial-peer)# codec g711ulaw
To configure a SIP gateway for communication with CUCM, a SIP trunk is required.
Unlike an MGCP gateway, a SIP gateway does not register with a call-control agent. The
following steps show how to add a SIP trunk in CUCM:
Step 1. Go to the Cisco Unified CM Administration page and choose Device >
Trunk.
Step 2. Click Add New.
Step 3. From the Trunk Type menu, choose SIP Trunk.
Step 4. From the Device Protocol menu, choose SIP.
Step 5. Enter the Trunk Name, description, CUCM Device Pool, and other param-
eters.
Step 6. In the SIP Information section, you can add either an IP address for the SIP
router or a DNS Service (SRV) record. After entering the other mandatory
parameters, click Save.
SIP Session Description Protocol

SIP SDP, as defined in RFC 4566, is a method of conveying the name and purpose of the
session, the media, protocols, codec format, session active time, transport information,
and so on. SDP format can be broadly expressed as <type> = <value>, where <type>
defines a unique session parameter and <value> provides a specific value for that param-
eter. The various types and values are defined as follows:
Session description:
■ v = Protocol version
■ o = Owner/creator and session identifier
■ s = Session name
■ i = Session information (optional)
■ u = URI of description (optional)
■ e = Email address (optional)

■ p = Phone number (optional)
■ c = Connection information (optional)
■ b = Bandwidth information (optional)
■ z = Time zone adjustments (optional)
■ k = Encryption key (optional)
■ a = Zero or more session attribute lines (optional)
Media description:
■ m = Media name and transport address
■ i = Media title (optional)
■ c = Connection information (optional)
■ b = Bandwidth information (optional)
■ k = Encryption key (optional)
■ a = Zero or more media attribute lines (optional)
Time description:
■ t = Time the session is active
■ r = Zero or more repeat times (optional)
For an example of SDP format, see the next section. SIP SDP messages are specifically
useful in certain events such as early media exchange (183 with SDP), ENAT for SIP
trunks, mid-call parameter changes, and so on.
SIP Binary Floor Control Protocol

Binary Floor Control Protocol (BFCP) is used to coordinate access to shared resources in
a conference. Floor Control is a mechanism that enables applications or users to gain safe
and mutually exclusive (or nonexclusive) input access to the shared object or resource,
such as video desktop sharing.
There are various components involved in BFCP call flow:
■ Floor: A permission to temporarily access or manipulate a specific shared resource

or set of resources
■ Floor chair: A logical entity that manages one floor and can grant, deny, or revoke a
floor
■ Floor participant: A logical entity that requests floors from a floor control server

■ Floor control server: A logical entity that maintains the state of the floor(s)—which
floors exists, who the floor chairs are, who holds a floor, and so on
BFCP is designed to rely on the capabilities of the underlying signaling and transport
protocols to set up each stream that is being managed, whether it is voice, video, or media
content that is being transported in the RTP stream. BFCP supports use of Transport
Layer Security (TLS) to provide encryption of floor information concerning each
resource that is being controlled and the participants using and viewing each resource.
TLS also provides the capability to support anonymous users for sessions where anonym-
ity is desired.
SIP BFCP is an application-sharing mechanism that leverages the BFCP protocol. For
instance, a user participating in a Cisco WebEx–enabled TelePresence conference call
can share content from his or her desktop. SIP BFCP works with Cisco TelePresence, EX
Series endpoints, and Cisco Jabber with video desktop sharing. Example 3-5 shows SDP
output from a video conference where one of the participants is sharing PowerPoint slides
during the call.
Example 3-5 SDP Output from BFCP-Enabled Call
v=0
o=Sam 2890844526 2890842807 IN IP4 10.10.200.100
s=meeting
c=IN 10.10.200.100
t=0 0
m=video 49680 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides
m=video 49680 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:main
In Example 3-5, “slides” is the presentation stream and “main” is the main video stream.
The streams are controlled by both SIP and BFCP, where BFCP is used for “asking per-
mission” to send the second stream, and the SIP offer-answer model (i.e., sending SDP
messages over INVITE or UPDATE) is used for opening the stream. If a participant wish-
es to start sharing a slide with other participants, the sharing participant begins by asking
for permission by sending a BFCP “floor request” and then opens the stream by sending a
Re-INVITE with a new SDP message adding the second “m=video” line.
H.323 Gateway, Gatekeeper, and RAS

H.323 is an ITU framework developed for interactive multimedia communications. H.323
is a suite of protocols, codecs, and standards that includes

■ H.225: H.225 (also known as H.255.0) is a call-control and signaling protocol used
to establish, control, and terminate calls between H.323 endpoints.
■ H.245: H.245 is a control channel protocol to transmit non-telephone signals such
as information related to capabilities, jitter management, and flow control, establish
logical channels for the transmission of media, and so on. In certain cases, H.245 can
be tunneled within H.225.
■ H.225 RAS (Registration, Admission, and Status): RAS is used for communica-
tion between H.323 endpoints (such as Cisco Unified IP Phones, CUCM) and the
gatekeeper and between the gatekeeper and a peer gatekeeper. RAS has a number of
messages for registration, admission, and status, most of which have a response of
Confirmation or Reject.
■ H.235: H.235 provides security within the H.323 suite, for both signaling and
media.
■ H.239: H.239 is a standard for multiple video channels within a single H.323 session.
H.239 enables dual streams for use in videoconferencing, one for live video and the
other for presentation/still images.
■ H.450: The H.450 series of protocols describes various supplementary services such
as call transfer, call hold, and so on.
■ H.460: The H.460 series of protocols defines optional extensions that may be imple-
mented by an endpoint or a gatekeeper Network Address Translation (NAT)/firewall
(FW) traversal.
H.323 endpoints use H.225 RAS UDP port 1718 for gatekeeper discovery and UDP port
1719 for gatekeeper H.225 RAS communication. H.323 endpoints can also use multicast
for gatekeeper discovery (the multicast IPv4 address is 224.0.1.41). H.323 voice gateways
can send DTMF digits in a number of ways, such as H.245 alphanumeric, RTP-NTE,
Cisco-proprietary, or H.245 signaling. In H.245 alphanumeric signaling, alphanumeric
digit tones are sent out-of-band via H.245, but H.245 alphanumeric signaling does not
include tone duration. H.245 signaling is like H.245 alphanumeric signaling but with
tone duration. Both RTP-NTE and Cisco-proprietary methods send DTMF tones within
an RTP stream. It’s important to note that H.323 call signaling is based on the ITU-T
Recommendation Q.931 protocol.
An H.323 ecosystem has many elements to it:
■ H.323 terminals/endpoints: Devices such as call-control agents (CUCM, CUCME),

multipoint control units (MCU), third-party IP Phones, and so on. Cisco Unified IP
Phones cannot process H.323 directly and can only work with SCCP or SIP.
■ H.323 gateways: Fundamental units of an H.323 ecosystem that enable the IP and
POTS worlds to come together. H.323 gateways can connect to call-control agents,
gatekeepers, session border controllers, and so on.

■ H.323 gatekeeper: Vital element of an H.323 ecosystem as it can provide multiple

voice services to endpoints and gateways. A gatekeeper can have a centralized (or
decentralized) dial plan, can control bandwidth across WAN links for H.323 voice
calls, and can perform user authentication, endpoint registration, admission and
request (RAS), and so on.
■ Session border controller (SBC): Known as Cisco Unified Border Element (CUBE)
in Cisco terminology, an SBC can process H.323 messages and can help interconnect
multiple organizations leveraging the H.323 suite for voice and video calls, either
directly or via an IT service provider (ITSP).
H.323 Gateway
An H.323 gateway is a device that can interface with the public switched telephone net-
work (PSTN), IP networks, call-control agents, H.323 gatekeepers, H.323 endpoints, and
so on. To configure an H.323 gateway to communicate with a call-control agent such as
CUCM, the gateway can be configured as shown in Example 3-6.
Example 3-6 H.323 Gateway Configuration
H323Router(config)# voice service voip

H323Router(conf-voi-serv)# h323
H323Router(conf-voi-h323)# ccm-compatible
!
H323Router(config)# interface loopback 0
H323Router(config-if)# ip address 10.10.1.250 255.255.255.0
H323Router(config-if)# h323-gateway voip interface
H323Router(config-if)# h323-gateway voip h323-id H323Router
H323Router(config-if)# h323-gateway voip bind srcaddr 10.10.1.250
!
H323router(config)# dial-peer voice 1001 voip
H323router(config-dial-peer)# destination-pattern 1...
H323router(config-dial-peer)# session target ipv4:10.76.108.146
H323router(config-dial-peer)# dtmf-relay h245-alphanumeric
H323router(config-dial-peer)# codec g711ulaw
H323router(config-dial-peer)# no vad
In Example 3-6, under the voice service voip command, the subcommand h323 enters
the H.323 submode. The command ccm-compatible enables CUCM-compatible signal-
ing. The interface-specific command h323-gateway voip h323-id is used to identify the
ID of the gateway. The command h323-gateway voip bind srcaddr is employed to con-
figure the IP address used as a source IP address for messages sent to CUCM server(s).
Consecutively, an H.323 gateway must be defined in CUCM so that CUCM servers can
communicate with the same. To add an H.323 gateway in CUCM, follow these steps:

Gateway.
Step 3. From the Gateway Type drop-down menu, choose H.323 Gateway.
Step 4. Enter the Device Name (IP address or DNS name of the gateway), descrip-
tion, CUCM Device Pool, and other parameters.
Step 5. After entering the other mandatory parameters, click Save.
H.323 gateways initiate an H.323 session in two ways: fast start and slow start. Fast-start
(also known as fast connect) is a newer method (available in H.323 version 2) of call setup
that allows the media channels to be operational before the CONNECT message is sent.
Essentially, H.245 is still negotiated later. However, the actual media channels can be
established by tunneling H.245 within H.225 messages. The following snippet states the
fast-start configuration:
H323Router(config)# voice service voip
H323Router(conf-voi-serv)# h323
H323Router(conf-serv-h323)# call start fast
Compared to fast start, slow-start implementations require that the media channels wait
until after the CONNECT message to negotiate IP addresses, ports, and codecs. In slow
start, many H.245 messages are exchanged over a separate TCP connection.
An H.323 gateway can also interface with a gatekeeper using RAS. For configuration of
an H.323 gateway, the following configuration is required under the interface, with the
remaining configuration being the same as in the earlier configuration:
H323Router(config)# interface loopback 0
H323Router(config-if)# h323-gateway voip id CUCMGK ipaddr 10.10.1.180
The command h323-gateway voip id identifies the ID and IP address of the gatekeeper
with which the gateway should register. The configuration of a gatekeeper to support an
H.323 gateway is covered in the next section.
H.323 Gatekeeper
H.323 gatekeepers are devices that can provide functions such as the following:
■ Address resolution (directory number to IP mapping)
■ Call Admission Control (CAC) and bandwidth control (gatekeeper-based CAC)
■ Zone management (intra- and interzone communication)

Gatekeeper-controlled communication can be implemented by configuring either of the

following:
■ H.225 trunk (gatekeeper controlled): Provides connectivity of a CUCM server/

cluster to H.323 network(s)
■ Intercluster trunk (gatekeeper controlled): Provides connectivity between a CUCM

server/cluster in a distributed call-processing network in H.323 network
To configure a gatekeeper-controlled trunk, first a gatekeeper must be added in

CUCM by going to the Cisco Unified CM Administration page and choosing Device >
Gatekeeper. To configure a gatekeeper-controlled trunk, choose Device > Trunk and add
the appropriate gatekeeper trunk type (H.225 or intercluster).
Example 3-7 shows basic configuration for a Cisco IOS gatekeeper (for CUCM and
H.323 gateway RAS).
Example 3-7 H.323 Gatekeeper Configuration
GKRouter(config)# gatekeeper
GKRouter(config-gk)# zone local CUCMGK corp.local 10.10.1.180
GKRouter(config-gk)# zone prefix CUCMGK 1*
GKRouter(config-gk)# gw-type-prefix 1#* default-technology
GKRouter(config-gk)# bandwidth session zone CUCMGK 256
GKRouter(config-gk)# bandwidth total zone CUCMGK 2048
GKRouter(config-gk)# no shutdown
The zone local CUCMGK corp.local 10.10.1.180 command defines the local zone con-
trolled by the gatekeeper, domain name, and the IP address (for RAS) for one of the
interfaces on the gatekeeper router. A gatekeeper can also work with another gatekeeper,
in which case the remote zone command is used. The zone prefix CUCMGK 1* com-
mand is employed to specify the gatekeeper’s name and add a prefix to the local zone
list. In this case, all prefixes beginning with digit 1 are associated with the gatekeeper
CUCMGK. The gw-type-prefix 1#*default-technology command specifies a default
technology prefix 1#*, which is used to route calls if the called number does not cor-
respond with a registered E.164 address. Next, the bandwidth commands are employed
to specify the per-session maximum bandwidth (256 Kbps) and total bandwidth (2048
Kbps) assigned to the zone CUCMGK. The no shutdown command activates the gate-
keeper function on the Cisco IOS router.
H.225 and RAS Signaling

Table 3-6 lists the H.225 call signaling messages.
003_9780133845969_ch03.indd 77 6/25/14 8:28 AM

Table 3-6 H.225 Signaling Messages

Call Signaling Message Description
Setup Sent by the H.323 gateway to initiate an H.323 session.
Setup Acknowledge Sent by the destination device to the initiating device.
Call Proceeding Sent by the destination endpoint to indicate that it has received
all the information and is trying to reach out to the called
endpoint.
Connect Sent by the destination endpoint to the calling endpoint to indi-
cate that the call has been accepted/answered.
Alerting Sent by the destination endpoint to the originating endpoint to
indicate that the called phone is ringing.
Information Used to send additional information for a call. For example,
when using overlap sending, each digit is sent one at a time in an
Information message.
Release Complete Sent by a device to indicate the call’s release.
Progress Sent by an H.323 gateway to indicate a call’s progress. You
typically see Progress messages when internetworking with a
non-ISDN network, because audio cut-through must be treated
differently in this case.
Status Used to respond to an unknown call signaling message or to a
Status Inquiry message.
Status Inquiry Used to request call status. Normally the device receiving this
message responds with a Status message indicating the current
call state for the specific call reference.
Notify Used to notify a device of a change that has occurred in the call.
Table 3-7 lists the RAS signaling messages.
Table 3-7 H.323 RAS Messages

RAS Signaling Message Description
Gatekeeper Request (GRQ) Sent from an endpoint/gateway for gatekeeper discov-
ery. A GRQ message can be a unicast or multicast
message.
Gatekeeper Confirmation (GCF) Acceptance message from the gatekeeper to an end-
point/gateway so that the endpoint/gateway can work
with a gatekeeper.


Gatekeeper Reject (GRJ) Rejection message from the gatekeeper to an endpoint/
gateway, thereby disallowing it to select a gatekeeper to
work with.
Registration Request (RRQ) Sent by the endpoint/gateway to attempt to register
with the gatekeeper.
Registration Confirmation (RCF) Sent by a gatekeeper to an endpoint/gateway to con-
firm it can now register itself to the gatekeeper, after
which it can make or receive calls.
Registration Reject (RRJ) Sent by the gatekeeper to an endpoint/gateway to reject
the request for registration.
Unregistration Request (URQ) Sent by an endpoint/gateway to the gatekeeper to
unregister itself from the gatekeeper.
Unregistration Confirmation (UCF) Sent by the gatekeeper to an endpoint/gateway if the
URQ is accepted by the gatekeeper.
Unregistration Reject (URJ) Sent by the gatekeeper to an endpoint/gateway if the
URQ is declined by the gatekeeper.
Location Request (LRQ) Message commonly used between interzone gatekeep-
ers to obtain the IP of a different zone’s endpoint.
Location Confirmation (LCF) Sent by the gatekeeper in response to an LRQ to pass
on the information about an endpoint in its zone to a
querying gatekeeper.
Location Reject (LRJ) Sent by the gatekeeper in response to an LRQ by the
originating gatekeeper if the resource doesn’t exist in
its zone.
Admission Request (ARQ) Sent by an endpoint/gateway when it receives a call
from an endpoint (FXS analog phone or from an IP
Phone registered with CUCM).
Admission Confirmation (ACF) Sent by the gatekeeper if the remote endpoint is avail-
able and starts bandwidth monitoring at this time.
Admission Reject (ARJ) Sent by the gatekeeper if the remote endpoint is not
available or the bandwidth required for the call is not
sufficient.
Disengage Request (DRQ) Sent by the endpoint/gateway to the gatekeeper to
inform it about the call being terminated (user or end-
point terminates the call).
Disengage Confirmation (DCF) Sent by the gatekeeper in response to a DRQ confirm-
ing it has disengaged the call and released the associ-
ated bandwidth.


Disengage Rejection (DRJ) Sent by the gatekeeper when a call cannot be
disengaged.
Bandwidth Request (BRQ) Sent by an endpoint/gateway to the gatekeeper to ask
for a change in bandwidth for an ongoing call.
Bandwidth Confirmation (BCF) Sent by the gatekeeper if the BRQ is accepted.
Bandwidth Reject (BRJ) Sent by the gatekeeper when the BRQ is rejected.
Request in Progress (RIP) Informs the requester that the request is being pro-
cessed; is particularly useful to avoid multiple instances
of the same request.
Info Request (IRQ) A status request sent from the gatekeeper to endpoint.
Info Request Response (IRR) Sent from the endpoint to the gatekeeper in response
to an IRQ. IRR is used by gateways to inform the gate-
keeper about the active calls.
Resource Availability Indicator (RAI) Used by gateways to inform the gatekeeper whether
resources are available in the gateway to take on addi-
tional calls.
Resource Availability Confirmation A notification from the gatekeeper to the endpoint/
(RAC) gateway that acknowledges the reception of the RAI
message.
Figure 3-5 depicts the H.323 RAS call setup between two H.323 gateways and a
gatekeeper.
The following events occur during the H.323 RAS call flow as illustrated in Figure 3-5:
1. H.323 Gateways A and B send a GRQ message to the H.323 gatekeeper to see if any
gatekeepers are available for registration.
2. The H.323 gatekeeper returns a GCF message indicating that the responding gate-
keeper is able to register new endpoints/gateways.
3. Both gateways send an RRQ message to the H.323 gatekeeper in an attempt to regis-
ter as part of that gatekeeper’s zone.
4. The H.323 gatekeeper returns an RCF indicating that the gatekeeper will add
Gateways A and B to its zone.
5. Gateway A sends a local ARQ message to the H.323 gatekeeper seeking authoriza-
tion to place a call over the H.323 network.
6. The gatekeeper returns an ACF indicating that the gatekeeper is going to allow
Gateway A access to the network.

H.323 Gateway A Gatekeeper H.323 Gateway B
V V
GRQ GRQ
GCF GCF
RRQ RRQ
RCF RCF
H.225 ARQ
H.225 ACF
Call Setup
Call Processing
H.225 ARQ
H.225 ACF
Alerting
Connect
H.245 Terminal Capabilities
H.245 Terminal Capabilities
H.245 Master-Slave Determination
H.245 Open Audio Logical Channel
H.245 Open Audio Logical Channel ACK
H.245 Open Audio Logical Channel
H.245 Open Audio Logical Channel ACK
RTP RTP
End Session
End Session
Release Complete
DRQ DRQ
DCF DCF
Figure 3-5 H.323 RAS Call Flow

7. Call setup initiates from Gateway A. Remote Gateway B acknowledges call setup
initiation.
8. Remote Gateway B contacts the common H.323 gatekeeper, seeking authorization to

complete the two-way H.323 network call.
9. The gatekeeper returns ACF, indicating that it is going to allow Gateway B access to
the network.
10. Various endpoint transmission and reception capabilities defining operation of voice,
video, and data are exchanged and acknowledged to ensure consistent, reliable two-
way communication between endpoints.
11. Gateways A and B determine master and slave assignments between themselves.
12. Before actual transmission or reception of voice or video, Gateway A opens a logi-
cal channel for RTP transmission, ensuring clear two-way communication. Remote
Gateway B acknowledges the notification.
13. Gateway B also opens a logical channel for RTP transmission, ensuring two-way
communication. Gateway A acknowledges the notification.
14. Two-way communication ensues between endpoints over the H.323 network. At this
time RTP and RTCP streams are established between Gateways A and B (or between
the endpoints leveraging Gateways A and B for H.323 session).
15. A user at Gateway A goes on-hook and the gateway sends an End Session message
to remote Gateway B. Gateway B replies with an End Session message as well.
16. Both gateways inform the gatekeeper that the call has ended and request disengage-
ment via DRQ.
17. The gatekeeper sends a response as DCF, meaning the gateways are released from the
session and the bandwidth used for the conversation is returned to the gatekeeper’s
bandwidth pool.
H.239-Based Dual Video Channels and Cisco Video

Equipment Support
As mentioned earlier in this chapter, H.239 is the ITU standard for a second video chan-
nel that can be used for sharing content (analogous to SIP BFCP). H.239 is the only con-
tent channel standard supported by the Cisco-acquired Codian product portfolio and the
Cisco TelePresence Serial Gateway Series products for H.323 video calls.
To enable H.239 for conferences on a Cisco TelePresence MCU, you first must go to
Settings > Content and enable Content Status on the MCU device-wide settings. While
configuring the conference, ensure it is enabled for H.239 by setting H.239 Content
Channel Video to Enabled.

Analog Telephony 83
Analog Telephony
When you speak into a microphone (MIC) of a phone, your voice generates sound waves
and traditional telephone converts the sound waves into electrical signals in analog form.
In an IP world, interoperability with analog devices is important. Cisco analog/digital
voice gateways and Cisco Analog Telephone Adaptor (ATA) help connect to the PSTN
and analog devices using a variety of interfaces and signaling types. The most common
analog interfaces are the following:
■ Foreign Exchange Office (FXO)
■ Foreign Exchange Station (FXS)

■ Ear & Mouth (E&M)
Foreign Exchange Office

An FXO interface allows a Cisco Collaboration network to connect with a central office
(CO)/PSTN network using analog signaling. An FXO interface on a Cisco router leverages
an RJ-11 connector to link with CO. From a CO’s perspective, an FXO device is a regular
telephone and should be able to accept on-hook and off-hook, ringing, and send-receive
voice frequency signals. An FXO interface can use loop-start or ground-start signaling.
Loop-start signaling is a type of supervisory signaling provided by a telephone exchange

that allows the indication of on-hook and off-hook states. When in idle state, a loop
potential is maintained by direct current (DC) voltage of –48 V provided by the tele-
phone exchange. Upon close of the loop, the current flows (indicating off-hook). Loop-
start signaling can sometimes lead to a condition known as call collision or glare wherein
the CO switch and FXO module end up seizing a trunk at the same time. Glare is a com-
mon problem when using loop-start signaling from an FXO interface to the CO switch.
This problem can be circumvented by use of ground-start signaling.
Ground-start signaling is also a supervisory signaling type similar to loop-start signaling.

Ground-start signaling, however, works by grounding the tip lead and trying to seize the
line, thereby avoiding glare. In ground-start signaling, the CO initiates a call by grounding
the tip and putting the ringing signal on the line. In an idle circuit, the CO supplies –48
V on the ring lead (when the tip is grounded) and open on the tip. An idle circuit can be
seized by an FXO port or CO by connecting of the ring lead to ground with maximum
local resistance of 550 ohms.
FXO Disconnect
As discussed earlier, loop-start signaling can introduce issues such as glare with FXO to
CO switch signaling. Because the CO switch always provides –48 V, there is no discon-
nect supervision from the switch side, thus a CO switch expects a phone (in this case,
FXO port) to hang up when the call is terminated on either side. However, the FXO port
expects the CO switch to tell it when to hang up, and this is where the disconnect issue

between the calling side and called side can occur. The most common symptom of this
problem is either that phones continue to ring when the caller has cleared the call or that
FXO ports remain busy after the previous call is supposed to be cleared.
This issue can be rectified by using the FXO Answer and Disconnect Supervision feature
that enables analog FXO ports to monitor call-progress tones and voice and fax transmis-
sions returned from a PBX or from the PSTN. Answer Supervision can be accomplished
by detecting battery reversal or by detecting voice, fax, or modem tones.
Foreign Exchange Station

An FXS interface allows a Cisco Collaboration network to connect with analog endpoints
such as analog phones, modems, and fax machines. At certain times, FXS interfaces may
be used to connect to a private branch exchange (PBX) or a key telephone system (KTS, a
leaner version of a PBX). An FXS interface also uses an RJ-11 connector that links to end-
user station equipment. By contrast to an FXO, an FXS interface provides battery power
and a dial tone and generates ringing voltage for the endpoints. FXS interfaces can also be
configured to use loop-start or ground-start signaling. For connecting to endpoints, loop-
start signaling is usually employed. However, in case of a connection to a PBX or a KTS,
ground start may be used.
E&M
E&M is a supervisory line signaling that uses DC signals on separate leads, called the
E lead and the M lead. E&M can be interpreted as “Ear and Mouth” or “Earth and
Magneto.” The E&M standard defines two sides to the interface (8-line, using RJ-48 con-
nector): Trunk Circuit and Signaling Unit. The Signaling Unit and Trunk Circuit commu-
nicate their status over the E and M leads, using a combination of Signal Battery (SB) and
Signal Ground (SG), where the battery used is standard –48 V. E&M trunks are frequent-
ly used for tie-line (private analog circuit) connectivity for PBXs. There are five variants
of E&M types I, II, III, IV, and V. Their main features are described in Table 3-8.
Table 3-8 E&M Variants

E&M Type Description
E&M type I Uses E and M leads for signaling, but it doesn’t offer ground isolation
and cannot be used in a back-to-back configuration. This variant is com-
mon in North America.
E&M type II Uses E, M, SB, and SG leads for signaling, offers ground isolation, and
can be used in a back-to-back configuration.
E&M type III Uses E, M, SB, and SG leads for signaling and offers ground isolation,
but cannot be used in a back-to-back configuration.

E&M Type Description

E&M type IV Uses E, M, SB, and SG leads for signaling, offers ground isolation, and
can be used in a back-to-back configuration. This E&M variant type is
not supported on Cisco devices.
E&M type V Uses E and M leads for signaling and can be used in a back-to-back con-
figuration, but doesn’t offer ground isolation. This E&M variant is com-
mon outside North America.
E&M defines three mechanisms for address (start) signaling:
■ Wink Start: As the call initiator goes off-hook, the other end transmits a short (140–
290 ms) off-hook signal and returns to on-hook. The initiator detects the wink and
then sends the dialed digits. At this time, the other end goes permanently off-hook
(seized) as the call is answered.
■ Delay Start: As the initiator goes off-hook, it waits for a predefined delay and then
checks for on-hook from the other end before sending the digits.
■ Immediate Start: Similar to Delay Start but the initiator doesn’t wait for the on-hook
at the receiver side. The initiator goes off-hook and waits for 150 ms and then sends
the dialed digits.
Digital Telephony
Similar to analog telephony, digital telephony also transmits human voice from one point
to another. However, the major distinction is that digital telephony leverages digitization
of signaling and audio transmissions. This is accomplished by transforming analog signals
into digital signals by use of digital electronics. Digitization of voice has many benefits,
including quality improvement, more channels to transmit voice, and overall lower cost of
operation (compared to individual FXO trunks). Digital interfaces/circuits come in many
flavors, such as T1, E1, Basic Rate Interface (BRI), Primary Rate Interface (PRI), and so on.
Integrated Services Digital Network

ISDN is a circuit-switched telephone network system designed to allow digital transmis-
sion of voice and data over conventional telephone copper wires. ISDN is an ITU-T stan-
dard protocol that is defined by various network layers (ISDN Q.911, Q.921, and Q931):
■ ISDN Q.911 is a physical layer protocol, equivalent to the physical layer of the Open
Systems Interconnection (OSI) model.
■ At Layer 2, ISDN signaling is provided by the Link Access Procedure on the D (sig-
naling) channel (LAPD), as specified in ITU-T Q.921. The LAPD protocol is similar
to High-Level Data Link Control (HDLC) and is the Layer 2 ISDN signaling protocol.

Terminal Endpoint Identifier (TEI) identifies end devices and can either be statically
configured at the end device or dynamically allocated by the PSTN.
■ ISDN call-control signaling and access to services is specified by ITU-T Q.931,

which allows call setup, maintenance, and teardown. Q.931 supports user-to-user,
circuit-switched, and packet-switched connections in addition to several call estab-
lishment, termination, and information messages
There are two ISDN access methods:
■ Basic Rate Interface (BRI): Provides two 64-Kbps bearer channels and a 16-Kbps
signaling channel, also known as 2B+D. A BRI interface has an aggregate bit rate of
144 kbps.
■ Primary Rate Interface (PRI): Provides 23 (T1) or 30 (E1) channels each with
64-Kbps bearer channels and a single 64-Kbps signaling channel, also known as
23B+D or 30B+D. A T1 has an aggregate bit rate of 1.544 Mbps, whereas an E1 has a
bit rate of 2.048 Mbps
Example 3-8 illustrates the BRI interface configuration.
Example 3-8 BRI Interface Configuration
BRIRouter(config)# interface bri 0/0

BRIRouter(config)# network-clock-participate wic 0
BRIRouter(config-if)# isdn switch-type basic-net3
BRIRouter(config-if)# isdn overlap-receiving
BRIRouter(config-if)# isdn incoming-voice voice
BRIRouter(config-if)# isdn protocol-emulate user
Example 3-9 outlines a PRI interface configuration for an E1 circuit.
Example 3-9 PRI Interface Configuration
PRIRouter(config)# network-clock-participate wic 0

PRIRouter(config)# isdn switch-type primary-net5
PRIRouter(config)# controller e1 0/0/0
PRIRouter(config-controller)# framing crc
PRIRouter(config-controller)# linecode ami
PRIRouter(config-controller)# pri-group timeslots 1-31
!
PRIRouter(config)# interface Serial0/0/0:15
PRIRouter(config-if)# isdn switch-type primary-net5
PRIRouter(config-if)# isdn incoming-voice voice

Q Signaling Protocol
QSIG is an ISDN-based signaling protocol, based on Q.931 signaling. It is primarily used
for feature transparency between different vendor PBXs. QSIG has two layers of signaling
procedures:
■ Basic call: Defines the signaling procedures and protocol for the purpose of circuit-
switched call control at the Q reference point between Private Integrated Services
Network Exchanges (PINX) and is explained in Standard ECMA-143.
■ Generic function: Defines the signaling protocol for the control of supplementary
services and additional network features and is explained in Standard ECMA-165.
QSIG features can support the following:
■ Basic call features: call completion, diversion, and transfer

■ Call identification services
■ Message waiting indication service
■ Path replacement
■ Do not disturb and override
Example 3-10 illustrates ISDN-QSIG configuration for a T1 controller.
Example 3-10 ISDN-QSIG Configuration
QSIGRouter(config)# controller t1 0/1

QSIGRouter(config-controller)# pri-group timeslots 1-24
!
QSIGRouter(config)# interface serial 0/1:23
QSIGRouter(config-if)# isdn switch-type primary-qsig
QSIGRouter(config-if)# isdn protocol-emulate [user | network]
Channel Associated Signaling

Channel associated signaling (CAS) is a variant of digital signaling wherein the signaling
uses the channels themselves instead of reserving a dedicated channel for signaling as in
ISDN. CAS is also known as robbed-bit signaling because its signaling operates by “rob-
bing” the least significant bit of information from voice channels (every sixth sample of
every channel) and using this to send clocking and framing information.
T1 CAS
T1 CAS uses in-band robbed-bit signaling. Signaling for a particular traffic circuit is per-
manently associated with that circuit. Signaling is based on analog signaling: loop-start,

ground-start, and E&M variants. E&M supports feature groups such as feature groups D
and FGD. Example 3-11 describes the configuration of a T1 CAS circuit.
Example 3-11 T1 CAS Configuration
CASRouter(config)# controller T1 0/0/0

CASRouter(config-controller)# framing esf
CASRouter(config-controller)# linecode b8zs
CASRouter(config-controller)# ds0-group 0 timeslots 1-12 type e&m-fgd
CASRouter(config-controller)# ds0-group 1 timeslots 13-24 type fgd-eana
!
CASRouter(config)# dial-peer voice 90 pots
CASRouter(config-dialpeer)# destination-pattern 9T
CASRouter(config-dialpeer)# direct-inward-dial
CASRouter(config-dialpeer)# port 0/0/0:1
E1 R2
E1 R2 is an equivalent of T1 CAS for E1 systems. E1 R2 signaling specifications are
defined in ITU-T Recommendations Q.400 to Q.490. E1 R2 supports inbound and
outbound Digital Number Identification Service (DNIS) and Automatic Number
Identification (ANI). The channel in timeslot 0 is used for framing, syncing, and alarms.
The channel in timeslot 16 is reserved for signaling. However, there is no LAPD. Example
3-12 describes the configuration of an E1 R2 circuit.
Example 3-12 E1 R2 Configuration
CASRouter(config)# controller E1 0/0/0

CASRouter(config-controller)# framing no-crc4
CASRouter(config-controller)# linecode ami
CASRouter(config-controller)# ds0-group 0 timeslots 1-31 type r2-digital
r2-compelled ani
!
CASRouter(config)# dial-peer voice 99 pots
CASRouter(config-dialpeer)# destination-pattern 9T
CASRouter(config-dialpeer)# direct-inward-dial
CASRouter(config-dialpeer)# port 0/0/0:0
Non-Facility Associated Signaling

The NFAS protocol allows a single D channel to control multiple PRI interfaces. In other
words, instead of giving away a D channel on, say, four PRI T1 trunks, NFAS can be used
to tie together all trunks’ D channels, thereby using a single D channel on one of the four
003_9780133845969_ch03.indd 88 6/25/14 8:28 AM

Analog and Digital Telephony Call Signaling Elements 89
trunks. A backup D channel can be configured on a T1 trunk other than the primary
trunk for resiliency. Hence, a sample configuration will be (for four T1 trunks) 94B + D +
D. NFAS is only supported with a channelized T1 controller.
Example 3-13 shows the configuration of NFAS for 2 PRI trunks.
Example 3-13 NFAS Configuration
NFASRouter(config)# controller t1 1
NFASRouter(config-controller)# pri-group timeslots 1-24 nfas_d primary
nfas_interface 1 nfas_group 1
NFASRouter(config-controller)# pri-group timeslots 1-24 nfas_d backup nfas_interface
2 nfas_group 1
!
NFASRouter(config)# dial-peer voice 199 pots
NFASRouter(config-dialpeer)# destination-pattern 9T
NFASRouter(config-dialpeer)# direct-inward-dial
NFASRouter(config-dialpeer)# port 1:D
Analog and Digital Telephony Call Signaling Elements

The following sections describe some of the elements that are part of almost every ana-
log and digital voice call.
Direct Inward Dial

When calling to a voice port, the call is first answered by the gateway itself, and then the
matching dial peer expects further digits to be dialed so the call can be routed to the des-
tination extension. This is known as two-stage dialing behavior. This is common for any
voice port, be it analog or digital. To avoid two-stage dialing and connect directly with
the destination number (extension), you can implement Direct Inward Dial (DID), which
allows calls from the PSTN to be routed directly to extensions on the call-control agent.
Thus, DID removes the hassle of operator-assisted dialing/multistage dialing.
Caller ID
Caller ID can be sent via FXO and FXS ports so that the called party can receive the call-
ing party’s information, such as number and calling name (where supported). With Cisco
voice gateways, Caller ID has certain restrictions with certain protocols. Caller ID works
for FXS ports with all supported protocols such as MGCP, H.323, SIP, and SCCP. Caller
ID, however, does not work on FXO ports with the MGCP protocol because it is not sup-
ported with FXO ports when configured for MGCP. To ensure Caller ID works with FXO
ports on Cisco IOS gateways, it is recommended to configure the gateway with H.323,
SCCP, or SIP support (depending on the model of the gateway and module type).
003_9780133845969_ch03.indd 89 6/25/14 8:28 AM

Echo
Echo is defined as the sound of your own voice reflected back to you on the telephone
receiver while you are talking. In the POTS world, echo is usually caused by an imped-
ance mismatch when the four-wire network is converted to the two-wire local loop. It can
be controlled by echo suppression or echo cancellation. The latter is more effective and
is used in most traditional and packet-switched networks. In a Cisco Collaboration net-
work, echo cancellation (ECAN) can be achieved by echo cancellers built into low-bitrate
codecs operated on a DSP (DSP firmware). In Cisco IOS voice gateways, echo cancella-
tion is enabled using the echo-cancel enable command, and echo trail (time to wait for
reflected voice) can be configured using the echo-cancel coverage command. Example
3-14 illustrates configuration of a Cisco IOS voice gateway to enable echo cancellation.
Example 3-14 Echo Cancellation Configuration
UCRouter(config)# voice-port 1/0/1

UCRouter(config-voiceport)# echo-cancel enable
UCRouter(config-voiceport)# echo-cancel coverage 16
UCRouter(config-voiceport)# non-linear
In Example 3-14, echo-cancel coverage is set to 16 ms (default value) for echo trail, fol-
lowed by the non-linear command that enables nonlinear processing in case no near-end
speech is detected.
Trans Hybrid Loss

Users can report audio problems on FXO, FXS, or DID ports, including clicking or hiss-
ing sounds, chopping of audio, one-way audio, echo, and so on. These problems can
occur on voice gateways with either digital or analog voice port connectivity, with the
latter being more susceptible. Most audio quality issues on analog circuits are due to
mismatch in impedance settings. With careful choice of the impedance setting for a voice
port, you can improve ECAN performance and mitigate any audible voice quality prob-
lems on the trunk.
The best match impedance setting for an analog FXO, FXS, or DID voice port can be
found by performing tests such as the Trans Hybrid Loss (THL) Tone Sweep test method.
This test feature allows the assessment of all available impedances for a single test call to
a quiet termination point out in the PSTN. The test feature switches impedances auto-
matically so that manual intervention is not required, as it was for its predecessor, the
Original Tone Sweep method. The test calculates arithmetic mean echo return loss (ERL)
and reports the mean for each channel profile at each impedance setting, and at the end
of the test specifies the best match impedance setting.
To initiate a THL sweep, follow these steps:
Step 1. Place a call over the FXS/FXO/DID voice port for which impedance setting is
to be determined.

Step 2. Execute the Tone Sweep test for this voice port by issuing the command test
voice port <port number> thl-sweep verbose.
Fax and Modem Protocols

Like voice and video, fax and modem communication is supported over an IP network.
However, the DSPs are not designed to support fax or modem tones. Thus, faxes
and modems are deployed with certain mechanisms such as relay, store-forward, or
pass-through.
Fax Services over IP Network

There are three major mechanisms that enable fax transmission over IP networks. These
are as follows:
■ Fax pass-through
■ Fax relay
■ Store-and-forward
In fax pass-through mode, voice gateways do not distinguish a fax call from a voice call.
Modulated fax information from the PSTN is passed in-band, end to end over a voice
speech path in an IP network. Incoming T.30 fax data is not demodulated or compressed,
and the fax machines (or modems) communicate directly with each other over a trans-
parent IP network so the fax traffic is carried between the two gateways in RTP packets
(tunneled). Fax pass-through supports only G.711 mu-law and a-law and requires Voice
Activity Detection (VAD) to be disabled. It is supported by H.323, MGCP, and SIP pro-
tocols. T.30 fax pass-through can be configured globally under voice service voip or per
dial-peer basis using the fax protocol pass-through command. Figure 3-6 depicts fax
pass-through call flow.
Fax (Analog) Data G.711 64 kbps Analog Fax Data Tunneled G.711 64 kbps Fax (Analog) Data
1100101101 Encoding Through 64 kbps IP Channel Decoding 1100101101
IP Network
V V
Fax Machine A Voice Gateway A Voice Gateway B Fax Machine B
End-to-End Fax Connection
Figure 3-6 Fax Pass-through Call Flow
In contrast to fax pass-through, fax relay demodulates the T.30 fax at the originating
gateway and sends the information across the IP network enveloped into packets, using
the fax relay protocol. The receiving gateway re-modulates the bits back into tones and
003_9780133845969_ch03.indd 91 6/25/14 8:28 AM

sends the same to the receiving fax machine. Cisco IOS gateways support two types of
fax relay mechanisms: T.38 fax relay and Cisco Fax Relay.
Cisco Fax Relay is a Cisco-proprietary method and is the default fax transmission mecha-
nism on Cisco voice gateways. T.38 fax relay is based on the ITU-T T.38 standard. T.38
is a real-time fax transmission method, which means that having two fax machines com-
municating with each using T.38 fax relay is like having a direct phone line between them.
Both fax relay mechanisms are supported by the H.323, SCCP, MGCP, and SIP protocols.
T.38 fax relay can be configured globally under voice service voip or per dial-peer basis
using the fax protocol t.38 command. Figure 3-7 illustrates the fax relay call flow.
Fax (Analog) Data DSP Demodulates Fax Data Sent as DSP Modulates Fax (Analog) Data
1100101101 Fax Data Data Packets Fax Data 1100101101
IP Network
V V
Fax Machine A Voice Gateway A Voice Gateway B Fax Machine B
Fax Machine A to Voice Voice Gateway to Voice Gateway Voice Gateway B to Fax
Gateway A Connection Connection Machine B Connection
Figure 3-7 Fax Relay Call Flow
Also known as on-ramp and off-ramp faxing, store-and-forward fax is based on the
ITU-T T.37 standard. It converts a traditional G3 fax incoming call from a fax machine
to an email message with a Tagged Image File Format (TIFF) attachment. The fax email
message and TIFF image (attachment) are handled by an email server while traversing
the IP network. This email and attachment can be stored for later delivery or delivered
immediately to a PC (with an email client) or to an off-ramp gateway. An off-ramp gate-
way handles calls coming from an on-ramp gateway and going out to a fax machine or
PSTN and converts a fax email with a TIFF attachment into a traditional fax format. The
functionality of store-and-forward fax can be facilitated through Simple Mail Transfer
Protocol (SMTP) or Extended SMTP (ESMTP). Figure 3-8 illustrates store-and-forward
fax call flow.
Fax (Analog) Data On-Ramp Fax Data Sent as Email with TIFF
1100101101 Gateway Email Attachment
IP Network
V
Fax Machine A Voice Gateway A PC
Fax Machine A to Voice Voice Gateway to PC (Email)

Gateway A Connection
Figure 3-8 Store-and-Forward Fax Call Flow

Modem Services over IP Network

Similar to fax transmission, modem transmission can be accomplished in the following
two ways over an IP network:
■ Modem pass-through
■ Modem relay
Modem pass-through over VoIP provides the transport of modem signals through a
packet network by using PCM-encoded packets. It is based on the same logic as fax pass-
through—the analog voice stream is encoded into G.711 and passed through the network
tunneled in an RTP stream and decoded back to analog signals at the far end. Modem
pass-through can be configured globally in voice service voip or per dial-peer basis
using the modem passthrough command.
Modem relay supports modem connections across traditional TDM networks. Similar to
fax relay, modem relay demodulates a modem signal at one voice gateway and passes it as
packet data to the receiving voice gateway, where the signal is re-modulated and sent to
the receiving modem. Cisco voice gateways, upon detection of the modem answer tone,
switch into modem pass-through mode. If the Call Menu (CM) signal is detected, the
gateways switch into modem relay mode. Modem relay supports V.34 modulation and
V.42 error correction. Signaling support includes SIP, MGCP, SCCP, and H.323. Modem
relay can be configured globally in voice service voip or per dial-peer basis using the
modem relay command.
003_9780133845969_ch03.indd 93 6/25/14 8:28 AM


Chapter 4
Cisco Unified
Communications Manager
Cisco Unified Communications Manager (CUCM) is an IP PBX that delivers enterprise-

class telephony features and functions. CUCM offers interfaces that include Cisco
Unified IP Phones, voice messaging (Cisco Unity Connection), presence (Cisco Unified
IM Presence), interactive voice response (IVR), voice gateways, and other multimedia
applications.
CUCM is the core of almost every Cisco Collaboration solution.
CUCM Redundancy and Device Registration

CUCM supports device redundancy via a CUCM Group. CUCM Groups can specify a
prioritized list of up to three CUCM servers. Cisco Unified IP Phones can register with
the primary CUCM defined in a CUCM Group. A CUCM Group cannot be directly
assigned to an endpoint and must be designated to a device pool that can be assigned
to an endpoint. Figure 4-1 illustrates the CUCM Group concept for call-control agent
redundancy.
When a Cisco Unified IP Phone requests its configuration file from a TFTP server, the list
of CUCM servers assigned to the IP Phone’s device pool’s CUCM Group is passed on to
the IP Phone. The IP Phone then attempts to register with the primary CUCM in the list,
and if it fails, it attempts to register with the next CUCM server, and so on until all server
references are exhausted. Upon registration with the primary CUCM server, the IP Phone
creates a backup TCP connection with the next server in the CUCM Group list so that
the failover is almost instant, without the user being aware. If an IP Phone is on a call, the
active call is preserved and the IP Phone re-registers with the next CUCM in the CUCM
Group when the existing call is complete. To configure a CUCM Group, navigate to the
Cisco Unified CM Administration page and choose System > Cisco Unified CM Group.
Enter a name for the CUCM Group and add the desired (and available) servers in order of
preference as applicable.

96 Chapter 4: Cisco Unified Communications Manager
Cisco Unified CM Group
CUCM CUCM
Subscriber 1 Subscriber 2
Signaling with Backup Connection

Primary CUCM with Secondary CUCM
Figure 4-1 CUCM Call Control Redundancy Using CUCM Group
Endpoints/devices, such as Cisco Unified IP Phones, can be provisioned manually by

creating an IP Phone using its MAC address and providing other required parameters in
CUCM. Alternatively, devices can be auto-registered with CUCM using the auto-registra-
tion device pool and device number (DN) range. Auto-registration is beneficial for initial
roll out. However, for ongoing Cisco Collaboration network operations and management,
it is recommended that you create devices manually either on a per-device basis or by
using the Bulk Administration Tool (BAT) to ensure that rogue devices cannot access
enterprise resources.
CUCM Device Pool

A device pool is essentially a set of rules that can be configured for a set of devices. In
other words, a device pool is a collection of resources that can be used and are common
to multiple devices that are part of the device pool. Once you assign an endpoint/device
to a device pool, it inherits all defined parameters configured for the device pool. You
can configure device pools within Cisco CUCM Administration by navigating to System
> Device Pool.
There are a number of settings that can be configured within a device pool that apply to
the device associated with it. They are listed in Table 4-1.
Table 4-1 CUCM Device Pool Settings

Device Pool Parameter Description
Device Pool Name Name of the device pool.
Cisco CUCM Group List of CUCM servers in order of preference (as explained in
the previous section).

CUCM Device Pool 97

Calling Search Space for Calling restrictions for phones that auto-register with CUCM.
Auto-Registration
Adjunct CSS Enables emergency dialing support with Extension Mobility
Cross Cluster (EMCC).
Revert Call Focus Priority Determines whether reverted or incoming calls are answered.
Local Route Group Helps in consolidating multiple sites to PSTN route patterns.
Intercompany Media Used with Intercompany Media Engine (IME).
Services Enrolled Group
Date/Time Group States the time zone in which a device is located.
Region Defines codecs used for traffic transiting between different
physical/logical sites.
Media Resource Group List Consolidates media resources that are available to a device.
Location Used for Call Admission Control (CAC, covered later in this
chapter).
Network Locale Specifies tones and cadences pertinent to a device.
Survivable Remote Site Specifies a gateway that provides call-control functionality
Telephony (SRST) Reference if phones are unable to communicate with CUCM in case of
WAN failure.
Connection Monitor Time period before a phone using Cisco Unified Survivable
Duration Remote Site Telephony (SRST) fails back to CUCM.
Single Button Barge Controls whether Barge/cBarge is enabled when a button is
pressed.
Join Across Lines Controls whether a user can add call(s) on distinct lines to an ad
hoc conference.
Physical Location Helps determines physical location of a device (phone).
Device Mobility Group Identifies the device mobility group to which a device belongs.
Device Mobility Calling Used when a device is roaming.
Search Space
AAR Calling Search Space Defines an Automatic Alternate Routing (AAR) calling search
space (CSS) for calls redirected to the PSTN in event of WAN
bandwidth depletion.
AAR Group AAR group to which a device belongs.
Calling Party Transformation Modifies the number used as the caller ID.
CSS


Called Party Transformation Allows changing the number dialed.
CSS
Geolocation Specifies a geolocation (used for logical partitioning).
Geolocation Filter Helps filter fields used to create a geolocation identifier.
Incoming Calling Party Allows addition or stripping of digits for national, international,
Settings and subscriber numbers for calling party.
Incoming Called Party Allows addition or stripping of digits for national, international,
Settings and subscriber numbers for called party.
Calling Party Transformation Allows modification of the number used as the caller ID to, for
CSS example, E.164 format.
Connected Party Allows modification of the connected party number to E.164
Transformation CSS or Direct Inward Dial (DID) format.
Redirecting Party Allows modification of the redirecting party number.
Transformation CSS
Common Device Configuration

In addition to configuring CUCM device pools, you can configure user-specific services
and feature parameters by using the CUCM Common Device Configuration feature.
To configure Common Device Configuration, browse to Device > Device Settings >
Common Device Configuration. The additional parameters (in augmentation to device
pool) that can be configured under Common Device Configuration are listed in Table 4-2.
Table 4-2 CUCM Common Device Parameters

Common Device Parameter Description
Network Hold MoH Audio Source Specifies MoH that the caller hears upon network
hold events such as call transfer/call conference.
User Hold MoH Audio Source Specifies MoH that the caller hears upon a user hold
event.
User Locale Defines the language/fonts pertinent to a device.
IP Addressing Mode Specifies whether IPv4 only, IPv6 only, or a combi-
nation can be used for system addressing.
IP Addressing Mode Preference for Specifies whether IPv4 only, IPv6 only, or a combi-
Signaling nation can be used for signaling.
Allow Auto-Configuration for Phones Allows DHCPv6 auto-configuration for IP Phones.

Codec Selection 99
Common Device Parameter Description

Use Trusted Relay Point Defines whether the endpoint (to which Common
Device Configuration is applied) will use a TRP.
Use Intercompany Media Engine (IME) Used when IME is deployed.
for Outbound Calls
MLPP Indication Specifies whether a tone is played when a device
makes or receives a precedence call.
MLPP Preemption Specifies whether a higher-precedence call is allowed
to preempt a lower-precedence call.
MLPP Domain MLPP domain associated with the device pool.
Codec Selection
CUCM offers a system default codec preference. However, since CUCM version 9.x, the
administrator has the ability to deterministically specify the order of the default codec
preference. This allows codec selection based on received offer at a global level or a gate-
way/trunk level. Codec selection/preference can be applied to the following:
■ SIP
■ MGCP
■ SCCP
■ H.323
■ EMCC-capable endpoints
To configure codec preference, browse to Cisco Unified CM Administration, navigate to

System > Region Information > Audio Codec Preference List. You can set codec pref-
erence based on the built-in Factory Default Lossy option or Factory Default Low Loss
option (shown in Figure 4-2) or you can create a new category to define the codec selec-
tion criteria.
It is important to understand that codec preference is still determined by the region that
a device is assigned to, such as an Audio Codec Preference List. The list can then be
applied to a region, which in turn is applied to endpoints/devices via device pools.

Figure 4-2 Codec Selection/Preference for Factory Default Low Loss Option
CUCM Features
This section covers the commonly used CUCM features.
Call Park and Directed Call Park

CUCM offers a Call Park feature that enables a user to place a call on hold on one phone
(extension) and retrieve the same call from a different phone (extension). Call Park places
the call on hold and parks it on a virtual directory number (DN) chosen automatically
from a range of Call Park numbers predefined by the administrator. Once a call is parked,
a number is displayed that the user can dial from a different phone (both phones should
be registered with the same CUCM cluster) and retrieve the call. The following steps con-
figure Call Park configuration in Cisco Unified CM Administration:
Step 1. Choose Call Routing > Call Park.
Step 3. In the Call Park Number/Range field, enter a number or pattern (wildcard).
Step 4. Enter other required details and click Save.

CUCM Features 101
More often than not, users prefer to select a number that the call will be parked on. This
feature, known as Directed Call Park, enables the user to transfer a call to the directed
call park number by pressing the Transfer softkey and then entering the directed call park
number. To configure Directed Call Park, follow these steps:
Step 1. Navigate to Call Routing > Call Directed Park.
Step 3. Enter the number/pattern in the Number field. Enter other required details.
Step 4. In the Reversion Number field, enter an extension that the parked call should
be forwarded to if it is not retrieved.
Step 5. In the Retrieval Prefix field, enter the prefix that will be dialed by the user fol-
lowed by the number to retrieve the call. Click Save.
Call Pickup and Group Pickup

The Call Pickup feature enables users to answer a line ringing on another phone from
their own phone. For example, if DN 9000 rings, the call can be answered from a differ-
ent IP Phone that does not have 9000 as shared line appearance (shared line appearance
implies two or more phones sharing the same DN). This process can be set up in either of
two ways: Call Pickup or Group Call Pickup. Call Pickup enables a call to be picked up
from another phone by pressing the Pickup softkey if both ringing and answering phones
are in the same Call Pickup group. Group Call Pickup enables a call to be picked up from
another phone by pressing the GPickUp softkey even if both phones are not in the same
Call Pickup group.
For a phone to leverage Call Pickup, the user has to go off-hook and press the Pickup
softkey. As the answering phone is in the same Call Pickup group as the ringing phone,
the call is automatically switched to the requesting phone. However, in case of Group
Call Pickup, the user has to go off-hook, press the GPickUp softkey, and dial the ring-
ing phone’s Call Pickup group number. The following steps show how to configure a Call
Pickup group in Cisco Unified CM Administration:
Step 1. Choose Call Routing > Call Pickup Group.
Step 3. In the Call Pickup Group Number field, enter the number to be used. Enter
the other details.
Step 4. Choose options from the Call Pickup Group Notification Policy and Call
Pickup Group Notification Timer drop-down lists. Click Save.
Step 5. Navigate to Device > Phone. Select the phone for which Call Pickup is to be
configured. Choose the line and select the preferred Call Pickup group. Click
Save.

Meet-Me Conference
CUCM supports two types of conference calls: ad-hoc conference calls and Meet-Me
conference calls. As the name suggests, an ad hoc conference call can be initiated by
either of two parties already on a voice call. Meet-Me, on the other hand, requires the
initiating party to start a conference call by pressing the Meet-Me softkey, after which
other participants can join by dialing a predetermined Meet-Me number. Each Meet-Me
conference can host up to 16 participants, and each conference call requires a unique
Meet-Me number. Follow these steps to configure Meet-Me patterns in Cisco Unified
CM Administration:
Step 1. Choose Call Routing > Meet-Me Number/Pattern.
Step 3. Enter the number/pattern to be used as the Meet-Me number. Enter other
details as required. Click Save.
Busy Lamp Field Speed Dials

Apart from CUCM IM and Presence integration, CUCM supports a native Presence fea-
ture that enables a user with special Busy Lamp Field (BLF) speed dials to another user
to monitor their Presence status. BLF speed dials is a native Presence CUCM feature
that enables a user, by configuring BLF buttons on a device, to view the On-hook and
Off-hook states of a DN. The following steps show how to configure BLF speed dials in
Cisco Unified CM Administration:
Step 1. Choose Device > Device Settings > Phone Button Template.
Step 2. Select the appropriate phone’s Phone Button Template, click Copy, and
instead of regular Speed Dials, select Speed Dial BLF (for the number of BLF
speed dials required).
Step 3. Go to Device > Phone and select the phone for which BLF needs to be
enabled. Select the new Phone Button Template and click Save.
Step 4. Add a remote phone’s DN that needs to be monitored and provide other
required details. Click Save.
CUCM Native Call Queuing

In addition to Cisco Unified Contact Center Express (UCCX)-based call queuing, CUCM
now has a native call-queuing mechanism wherein CUCM enables Hunt Pilot to queue
callers and allow for redirection of calls based on different queue criteria. Any users
enabled for Hunt Group login can participate in multiple queues. Calls with the longest
waiting time in all queues are delivered first to the logged-in users/agents. Moreover, a
user/agent also sees the current on-phone Queue Status display. CUCM native queuing is
configured in Cisco Unified CM Administration by browsing to Call Routing > Route/
Hunt > Hunt Pilot and configuring the parameters under Queuing as shown in Figure 4-3.

CUCM Features 103
Figure 4-3 CUCM (Hunt Pilot) Native Queuing
Queue announcements can be set up by going to Media Resources > Music on Hold
Audio Source, under Announcement Settings.
Call Hunting
Call Hunting is a mechanism wherein a call is placed to a Hunt Pilot and the number
hunts (dials) among the group of lines in a predefined manner. If a line member is avail-
able, the call is answered. Otherwise, it hunts to the next line or moves to the next avail-
able hunt member in the Hunt Group, or the call can be sent to voice mail. A Hunt Group
consists of various components such as Line Group, Hunt List, and Hunt Pilot. A Line
Group can consist of Line Group members such as SCCP/SIP endpoints, voice-mail ports,
and FXS ports. A Line Group is assigned to a Hunt List that contains an ordered list of
one or more Line Groups. In turn, a Hunt List is assigned to a Hunt Pilot that is the point
where call hunting starts. Hunt Pilot has the DN at which an incoming call can be for-
warded, and as a result, the call goes to Hunt List > Line Group > Line Members in that
order.
Line Group members can process an incoming call by using various hunting options
such as Ring No Answer, Busy, and Not Available. Moreover, the Distribution Algorithm
defines how the call hunting takes place, such as Top Down, Circular, Longest Idle Time,
or Broadcast. The Hunt List, as described, contains one or more Line Groups in order
of preference. Hunt Pilot allows assigning a DN to the hunting mechanism and provides
enhanced options like call queuing (discussed earlier).
To add a Line Group, go to Call Routing > Route/Hunt > Line Group. Add the Line
Group members and define the distribution algorithm, hunting conditions, and other
details. To add a Hunt List, navigate to Call Routing > Route/Hunt > Hunt List. Select a
CUCM Group and Line Groups that should be part of the Hunt List.

CUCM Media Resources

This section covers the various media resources offered by CUCM for functions such as
voice prompts/announcements, transcoding, conferencing, and so on. It also covers their
management mechanisms.
Annunciator
Annunciator is a Cisco IP Voice Media Streaming (IPVMS) application service process
that runs on a CUCM node that has the IPVMS service activated. Annunciator plays
recorded announcements to devices on specific events, such as a user dialing an invalid
number. An annunciator is automatically created when IPVMS service is activated on
one or more nodes in a cluster. No configuration is needed except to change the device
pool to a specific device pool—for example, changing to Datacenter-DP a device pool
that contains all media resources. To change the device pool, go to Media Resources
> Annunciator and select the annunciator for which the device pool is to be changed.
Choose the appropriate device pool and click Save.
Conference Bridge
As discussed in a previous section, CUCM supports two types of conferences, ad-hoc
and Meet-Me. For either conference type, a conference bridge resource is required, either
a hardware conference bridge or a software conference bridge. Similar to Annunciator,
a software conference bridge runs on CUCM and is automatically created when IPVMS
service is activated on a node. Where possible, use of hardware conference bridge(s)
is recommended because software conference bridges have an impact on CUCM CPU
and memory, and only support G.711 calls. Hardware conference bridges can be config-
ured on Cisco IOS gateways leveraging DSPs on Packet Voice Digital Signal Processor
Modules (PVDM). Follow these steps to configure a hardware conference bridge in Cisco
Unified CM Administration:
Step 1. Choose Media Resources > Conference Bridge.
Step 3. Select Cisco IOS Enhanced Conference Bridge. Enter the name matching the
associated DSP Profile name in the Cisco IOS router.
Step 4. Enter other required details. Ensure that the security mode matches what is
configured on the Cisco IOS router. Click Save.
The Cisco IOS configuration for conference bridges is covered in Chapter 9, “Cisco IOS
UC Applications.”

CUCM Media Resources 105
Media Termination Point

A Media Termination Point (MTP) is a software process that runs as part of Cisco IPVMS
service on CUCM. Analogous to conference bridges, MTPs can also be software or hard-
ware devices. MTPs serve two major functions:
■ Provide supplementary services (hold, transfer, conferencing, and so on) for the
H.323 version 1 endpoint/gateway
■ Provide SIP trunk codec interworking (G.711 ulaw to alaw and vice versa) as well as
conversion of dual-tone multifrequency (DTMF) tones from SCCP to SIP and vice
versa
Software MTPs are created when IPVMS service is activated on a CUCM server. For a
software MTP, the only configuration required is to change the device pool. To change
the MTP’s device pool, go to Media Resources > MTP and select the MTP for which
the device pool is to be changed. Choose the appropriate device pool and click Save. For
hardware MTP configuration, refer to the “Resource Reservation Protocol” section later
in this chapter.
Transcoder
Sometimes it is required to have one codec converted to another; for example, G.729
calls traversing over a WAN from a remote site might need to be converted to G.711 at
the data center. Transcoders are the hardware resources that enable a Cisco Collaboration
network to convert calls from one codec to another. Transcoders can be enabled on Cisco
IOS gateways and, like hardware conference bridges, they also leverage DSPs off PVDMs.
To configure a transcoder, follow these steps in Cisco Unified CM Administration:
Step 1. Choose Media Resources > Transcoder.
Step 3. For Transcoder Type, select Cisco IOS Enhanced Media Termination Point
and enter the name matching the associated DSP profile name in the Cisco
IOS router. Enter other required details. Click Save.
The Cisco IOS transcoder configuration is covered in Chapter 9.
Music on Hold
MoH is played to a caller when the remote party in the call puts the caller on hold. MoH
requires an MoH server to be configured and an audio file that will be played during
the hold event. MoH is also part of Cisco IPVMS and is automatically created when
IPVMS is activated on a CUCM server. To configure/fine-tune an MoH server, go to
Media Resources > Music On Hold Server and select the server you wish to configure.
MoH audio can be played as unicast (default) or multicast streams. When multicast sup-
port is enabled, the multicast stream can increase, based on port number or IP address.
004_9780133845969_ch04.indd 105 6/25/14 10:15 AM

Multicast MoH is especially useful for remote sites to conserve bandwidth over WAN.
The concept of multicast MoH was briefly covered in Chapter 1, “Cisco Collaboration
Infrastructure.”
For the MoH audio source, additional audio files can be added to the MoH server.
Endpoints/devices can be configured to play different audio files as required. An MoH
audio source file can be assigned as User Hold Audio Source and/or Network Hold Audio
Source to the phones. If an audio source file is defined at the device level, it overrides the
device pool audio source preference. To upload an MoH audio file (the file must first be
uploaded to the CUCM that is functioning as the MoH server), go to the Cisco Unified
CM Administration page and choose Media Resources > Music on Hold Audio Source,
click Add New > Upload File, select an audio file you wish to upload as the MoH file,
and click Upload.
Media Resource Group and Media Resource Group List

After various media resources are defined, they need to be managed and assigned to
intended devices/endpoints/device pools. Media resource management is accomplished
by creating Media Resource Groups (MRG) and Media Resource Group Lists (MRGL).
Media resources are assigned to MRGs, which in turn are assigned to MRGLs. MRGLs
can be assigned to endpoints/devices directly or to device pools. An MRG can contain
one or more media resources and can be used to aggregate all similar type of media
resources into one MRG; for example, an MRG for Annunciators, another MRG for
MTPs, and so on. An MRGL can aggregate multiple MRGs and forms a single point of
contact for endpoints/devices to leverage various media resources. In an MRGL, the order
in which the MRGs are added determines which MRG is queried first for a requested
resource.
To configure an MRG and an MRGL, follow these steps in Cisco Unified CM

Administration:
Step 1. Choose Media Resources > Media Resource Group.
Step 3. Provide a name for the MRG and add a media resource from the Available
Media Resources list to the Selected Media Resources list. Click Save.
Step 4. To add an MRGL, go to Media Resources > Media Resource Group List and
click Add New.
Step 5. Enter the MRGL name and add one or more MRGs from the Available Media
Resource Groups list to the Selected Media Resources Groups list.
Step 6. You can change the order in which an MRG is queried by highlighting the
name and clicking the up and down arrows located to the right of Selected
Media Resource Groups box.
Step 7. Click Save.
004_9780133845969_ch04.indd 106 6/25/14 10:15 AM

CUCM Dial Plan 107
Trusted Relay Point

A TRP is a CUCM media resource function that leverages an MTP or transcoder to
anchor Real-time Transport Protocol (RTP) streams to itself so that the endpoints no
longer send or receive RTP packets between themselves but via the TRP. Figure 4-4 illus-
trates the concept of an MTP used as a TRP.
Signaling to
TRP (MTP) CUCM
Media Anchored Media Anchored

to TRP to TRP
Cisco Unified Jabber Jabber Cisco Unified

IP Phone Softphone Softphone IP Phone
Figure 4-4 MTP Used as a TRP
After a TRP is defined and provisioned, it is dynamically inserted in a call flow by

CUCM. Two major applications of TRPs are QoS enforcement and trusted VLAN tra-
versal. By anchoring media to a TRP, a network administrator can ensure that the media
conforms to organizational policies because it will be sourced from devices that have
access to the TRP, and the TRP becomes the single point of control.
CUCM Dial Plan

A CUCM dial plan allows calls to be made, received, or manipulated by the following:
■ Call control
■ Gateways

■ Trunks
■ Endpoints
■ Other ecosystem applications
Figure 4-5 depicts a high-level CUCM dial plan.
Calling Search
Class of Service Partitions Route Patterns
Spaces
INTERNAL, INTERNAL 8XXXXXXX

EMERGENCY INTERNAL-CSS
EMERGENCY 911, 9.911
INTERNAL,
LOCAL-CSS
EMERGENCY, LOCAL LOCAL 9.[2-9]XXXXXX
INTERNAL, NATIONAL-CSS NATIONAL 91.[2-9]XX[2-9]XXXXXX

EMERGENCY, LOCAL,
NATIONAL
Gateway/Trunks Route Group Route Lists
SIP-Trunk-Internal RG-SIP-Trunk RL-SIP-Trunk
Gateway 1 RG-Gateway-Trunk RL-Gateway Trunk
Gateway 2
Figure 4-5 CUCM Dial Plan Concept
The many components of a CUCM dial plan are discussed in this section.
Partitions and Calling Search Spaces

In CUCM, partitions and calling search spaces (CSS) form the basic elements of class of
service (CoS). A partition is a logical entity assigned to a device/endpoint that defines its
domain. A CSS, on the other hand, is the logical entity that defines which domains are
accessible by a device with a certain CSS. In other words, an IP Phone with partition A
can be reached by an IP Phone with CSS C if CSS C has access to partition A.
Partitions apply to many dial plan constructs, such as
■ Directory numbers
■ Route patterns
■ Translation patterns
■ Transformation patterns
004_9780133845969_ch04.indd 108 6/25/14 10:15 AM

CUCM Dial Plan 109
CSSs can be applied to anything that is required to call entities, such as
■ Devices
■ Directory numbers
■ Gateways
■ Trunks
■ Translation patterns
From a user perspective, when the user dials digits, they’re processed by CUCM (digit
analysis/manipulation) and the device’s (phone’s) CSS determines if the digits dialed have
access to the destination resource, which may be another phone, a route pattern, a gate-
way, and so on.
Translation Patterns
CUCM translation patterns allow digits to be manipulated before forwarding a call to a
local device or to a route pattern for further processing. Translation patterns can use both
pattern masks and transformation masks to perform digit manipulation. The output pat-
tern after the translation pattern is applied is rerouted by CUCM or blocked as a result
of a second round of digit analysis. Translation patterns can only be used to route calls
within a system (on-net calling). To route an off-net call, the call must go to a route
pattern.
Route Patterns
CUCM route patterns are similar to translation patterns, with one major distinction:
route patterns can be used to route calls outside of a CUCM cluster, such as off-net
calls. Route patterns can point either to specific gateways/trunks directly or to route lists
(which further contain route groups, as shown in Figure 4-5). The call routing (off-net or
on-net leveraging trunks) uses the following flow: route pattern > route list > route group
> gateway/trunk. However, the order of configuration is the reverse; that is, a gateway
endpoint or a trunk must be configured before it can be assigned to a route group, which
in turn can be assigned to a route list, which can then be assigned to a route pattern.
Route List
A route list helps specify various route groups. For example, in a case where a call path
is unavailable, such as an IP WAN-based SIP trunk, the call can still be completed using
an alternative call path, such as the PSTN, without the user being aware that a certain call
path was unavailable. If a number dialed is an internal number, it must be expanded to an
E.164 format so that it can be routed over a PSTN network, and this can be achieved with

route list–based digit manipulation (digit manipulation is covered later in this chapter).
Hence, route lists serve a twofold purpose: providing alternate call path(s), and amending
a dialed number so that the call goes successfully through the first available call path.
Route Group
Route groups are logical entities that allow multiple gateways/trunks to be placed in one
or more route groups. This offers a level of redundancy when a certain endpoint or trunk
is not available. Also, route groups offer load balancing of calls. Route groups offer two
distribution algorithms: circular and top down. In the circular algorithm, all gateway
endpoints/trunks assigned to a route group are used, starting from the first entity, and
then the cycle begins again from the top. In the top-down algorithm, the first member of
a route group is used until it is unavailable, at which point CUCM call routing logic uses
the next-in-order gateway endpoint or trunk.
Globalized Call Routing

Globalization of a CUCM dial plan allows a simplified approach to dial numbers for off-
net calls from within an organization. Globalized call routing requires use of +E.164 dial-
ing via use of the + sign prepended to international access codes. You should avoid over-
lapping between globalized numbers and other ranges; for example, calls to India may be
represented as +91XXXXXXXXX, whereas North American Numbering Plan (NANP)
toll calls may be represented as 91212XXXXXXX. The + sign allows CUCM to route
calls based on a universal, non-site (country) specific format and can be used with all
dialable patterns such as DN, route pattern, translation pattern, and so on. Globalization
of calling party number to +E.164 is recommended via a Session Manager Edition (SME)
cluster for calls from leaf clusters. In the case that a leaf cluster does not support normal-
ization, SME can be set up to do the normalization on ingress.
When an E.164 number is dialed, CUCM matches it against the route patterns and
CUCM sends the call to a local gateway or trunk where number normalization occurs.
For example, the pattern \+[^1] matches any E.164 number that does not start with a 1.
The benefit of a +E.164 dial plan is that it requires only a single route pattern (for exam-
ple, \+.!) for all globalized calls, although additional route patterns may still be required to
allow users to dial using traditional dialing and Tail End Hop Off (TEHO).
The following is an example of globalized call routing to help you grasp the con-
cept. The calling party is 13138880000 with an external phone number mask set as
+1313XXXXXXX, and the called party number is 914082220000. The call is routed to
translation pattern 9.1[2-9]XX[2-9]XXXXXX with digit manipulation set to discard pre-
dot and prefix +. The translated number is \+1[2-9]XX[2-9]XXXXXX, which matches the
appropriate route pattern (also set to keep the external phone number mask as is), and
goes out a local route group (covered in the next section) such as a PSTN gateway or a
SIP trunk to an IT service provider (ITSP, also known as a SIP provider) or to another
cluster within the same organization or to a partner organization. While the calling

CUCM Dial Plan 111
and called numbers are kept as +13138880000 and +14082220000, respectively, on

the SIP trunk(s), on the PSTN trunk/gateway they are changed to 13138880000 and
14082220000.
Here are some things to consider when deploying globalized call routing plan:
■ First-generation phones (such as 7940/60) do not support + dialing from phone

directories.
■ Alternate extensions can be +E.164 DNs.
■ Unified Contact Center Enterprise/Express cannot monitor +E.164 DNs.
Local Route Group

CUCM call routing can be simplified by the use of the local route group (LRG) feature.
An LRG helps reduce the complexity of provisioning a dial plan in a centralized CUCM
deployment model with IP Phones and users scattered across multiple sites.
For example, if an organization has ten sites (including a main site or headquarters), then
using a traditional call routing model requires ten route patterns for, say, emergency calls
to 911, ten route lists, and ten route groups (assuming each site has a local PSTN gate-
way). With an LRG, only one route list is required that has access to (as its first member)
a special route group that is called Standard Local Route Group (SLRG). SLRG specifies a
virtual local route group. Only one route pattern is required, which is used by all the sites
to route their 911 calls. Now, you need only one route pattern for 911, one route list,
and ten route groups. So when a user at any site dials 911, the route pattern points to the
route list that has SLRG as the only member, and CUCM checks the LRG value specified
in the device pool of the calling phone. It then selects that route group to route the call
to that site’s gateway. Essentially, the decision making happens at the device pool level,
which defines the LRG, which in turn has access to the local gateway for the site from
which the call originated. This concept is illustrated in Figure 4-6.
Device-Pool Site A
Site-A-RG
Site-A IP Phone Site-A-Gateway
Device-Pool Site A Route List (PSTN)
Route Pattern
Route Group Site-A-Gateway
911
(Standard Local RG)
Site-B-RG
Site-B-Gateway
Site-B Gateway
Site-B IP Phone
Device-Pool Site B Device-Pool Site B
Figure 4-6 Local Route Group–Based Call Routing
004_9780133845969_ch04.indd 111 6/25/14 10:15 AM

An LRG allows site specificity of call routing to be established by the calling device’s
location as derived from the device pool. In this case, and as shown in Figure 4-6,
Device-Pool Sites A and B assign the LRG and inform CUCM that for Site A calls, Site-A-
RG is to be used, and for Site B calls, Site-B-RG must be used. Hence, different endpoints
in various sites are associated with different LRGs derived from the phone’s device pool.
However, they can all call the same route pattern(s), and the calls are routed differently
based on the caller’s currently associated LRG.
Time-of-Day Routing
CUCM offers Time-of-Day routing to help administrators and organizations apply certain
rules pertinent to dialing of long distance or international numbers (or stop dialing of any
numbers except emergency calls, depending on an organization’s policy) post business
hours.
The following example illustrates the Time-of-Day routing concept. A phone in an orga-
nization’s U.S. office is used to call an international number +91XXXXXXXXXX during
business hours. The CSS of the phone has access to a partition that allows calls to access
the (international) route pattern as the partition is active during those hours. Post busi-
ness hours, the partition is rendered inactive, thereby disregarding calls to that partition
and in turn leaving the same phone unable to make international calls.
The following components are required to build Time-of-Day routing logic:
■ Time period: A range of time slots, such as 8:00 a.m. to 5:00 p.m. Monday through
Friday. If the time slots cannot be grouped into one time period, multiple time peri-
ods can be defined.
■ Time schedule: A group of time periods. By grouping time periods together into a
time schedule, noncontiguous time range(s) can be created, as required. For example,
if an organization’s office is open 8:00 a.m. to 5:00 p.m. Monday through Friday
and 10:00 a.m. to 5:00 p.m. on Saturday, then two time periods can be defined and
assigned to the same time schedule.
■ Partitions: Once a time schedule is defined, it must be assigned to a partition for the
partition to be active/inactive during a specific time period.
After Time-of-Day routing is enabled, before routing a call, CUCM filters partitions in
the calling device’s CSS. This is based on the time and time zone of the calling device and
the time schedules assigned to partitions. Then the active partition is used to route the
call. If there are no active partitions (for the dialed number destination) the caller gets a
fast-busy tone.
Application Dial Rules

CUCM application dial rules help modify the dial string on outbound calls to adapt to
the route plan on CUCM. Any number dialed by a user that is not routable as dialed must

CUCM Dial Plan 113
have an application dial rule to resolve the number to the route plan. An application dial
rule helps automatically strip numbers from, or add numbers to, a telephone number that
a user dials. For example, an application dial rule can automatically prefix a digit to a
telephone number to provide access to an outside line. The following is an example of an
outline for an application dial plan:
■ For seven-digit dialing where the number begins with 222 and the number of digits
is seven, prefix 9.
■ For ten-digit local dialing where the number begins with 408 and the number of dig-
its is ten, strip the first three digits and prefix 9.
■ For ten-digit national dialing where the number of digits is ten, prefix 91.
■ For eleven-digit national dialing where the number of digits is eleven, prefix 9.
■ For international dialing where the number begins with +, strip the first digit and
prefix 9011.
To configure application dial rules on CUCM, go to the Cisco Unified CM

Administration page and choose Call Routing > Dial Rules > Application Dial Rules.
Directory Dial Rules

In addition to configuring application dial rules, you can configure directory lookup dial
rules that transform the number a user dials into a directory number, such as inbound
calls to a number that can be resolved in LDAP. For example, if CUCM receives a call
from 89631000, that number needs to be transformed into +14085671000 as stored in
LDAP, provided globalized call routing is in effect. Directory dial rules are especially use-
ful in case of IM (intra/inter domain) federation (covered in Chapter 7, “Cisco Unified IM
and Presence”) between Microsoft OCS/LCS/Lync and Jabber. To configure the directory
lookup/dial rules, navigate to the Cisco Unity CM Administration page and choose Call
Routing > Dial Rules > Directory Lookup Dial Rules.
SIP Dial Rules

As discussed briefly in Chapter 3, “Telephony Standards and Protocols,” SIP phones can
leverage SIP dial rules that use the dialplan.xml file on a SIP endpoint when a caller enters
digits and the call is routed to CUCM once a pattern is matched on the phone as SIP
INVITE. SIP dial rules can be configured in Cisco Unified CM Administration by choos-
ing Call Routing > Dial Rules > SIP Dial Rules. The following are some examples of SIP
dial rules:
■ 1t7>#..........t1-: This pattern implies that the user must enter at least one digit. Then
the send occurs after 7 seconds. The terminating character # can also be applied
after the first digit is entered. After ten digits are entered, the timeout changes to 1
second.

■ 0t2>#.t7-: This pattern implies that after a 0 is entered, if no other digit is entered,
the send occurs after 2 seconds. If another digit is entered, the send occurs after 7
seconds.
CUCM Digit Manipulation

Digit manipulation occurs when a called (dialed) or calling (caller ID) number is changed.
At times, changing the called party number is required; for example, appending 9 to it
so that the number dialed is understood by the PSTN service provider. Also, the call-
ing party number (CLID) may be changed to either help the PSTN network to route the
call and show the right CLID or to hide the CLID (private numbers). Digit manipulation
can be accomplished in many ways and at various stages in CUCM. Digit manipulation
occurs via
■ Stripping digits
■ Adding digits (appending)
■ Transformation
■ Masking a number
Subsequently, digit manipulation occurs at translation patterns, route patterns, route

groups, and so on.
Figure 4-7 outlines a simple example of digit manipulation for a call originating from an
IP Phone out to PSTN.
Route Pattern Gateway/Trunk

Calling Party Transformation: Calling Party: 14083331000
Prefix Digits 1408333 Called Number: 914082221000
Calling Party: 1000

Called number: 914082221000
Figure 4-7 Digit Manipulation
In this case, the digit transformation prefixes the required number of digits to the call-
ing number. Various digit manipulation mechanisms and their specifics are listed and
described in Table 4-3.

CUCM Digit Manipulation 115
Table 4-3 CUCM Digit Manipulation Options

Digit Manipulation Description Configuration Approach
Mechanism
External Phone Allows setting an E.164 address for the Navigate to Device >
Number Mask user extension part of Calling/Called Phone and select the
Party Transformation settings and helps phone, select the appro-
format caller ID for PSTN outbound calls priate line, and set the
made from phones. The route pattern External Phone Number
must honor the External Phone Number Mask.
Mask option (check box) so that the same
can be carried from the endpoint over to
the PSTN.
Translation Pattern When user-dialed digits match a Navigate to Call Routing >
translation pattern, CUCM performs the Translation Pattern.
translation first and then routes the call
again based on CoS. Translation patterns
make use of the Calling/Called Party
Transformation settings for digit
manipulation.
Transformation Help manipulate the dialed digits (DNIS) Can be configured under
Masks or calling party number (ANI), as part of translation patterns, route
Calling/Called Party Transformation set- patterns, or route list set-
tings. A transformation mask can contain tings (applying to route
digits 0–9, *, #, and X and can be applied groups). Transformation
to a number to extend or masks configured at the
truncate it. route group level have
priority over those config-
ured at the route pattern
level.
Digit Prefix and Digit Prefix digits to or strip dialed digits from
Stripping a route or translation pattern for out-
bound calls. Part of Calling/Called Party
Transformation settings. Digit Prefix helps
prepend digits to the pattern, such as digits
0– 9, *, and # as part of Calling/Called Party
Transformation settings. Digit stripping
instructions help strip digits from a pat-
tern as part of Called Party Transformation
settings (Discard Digits field). Maximum
digit discard instructions are available with
@ sign i.e. CUCM built-in numbering plan
(default NANP) is used in the route pat-
tern. Valid digit discard instructions include
PreDot, PreAt, Trailing#, and so on.
004_9780133845969_ch04.indd 115 6/25/14 10:15 AM

Digit Manipulation Description Configuration Approach

Mechanism
Significant Digits Enables CUCM to manage only the least- Navigate to Device
significant N digits of the called number > Gateway/Trunk
for incoming calls (from PSTN gateway/ Configuration > Call
trunk or from another CUCM cluster) and Routing Information –
is available as part of the Gateway/Trunk Inbound Calls.
Configuration settings.
Calling and Called Calling Party Transformation Patterns Navigate to Call Routing
Party Transformation control the adaptation of calling party > Transformation >
Patterns numbers from enterprise to PSTN E.164 Transformation Pattern.
format. Called Party Transformation
Patterns manipulate the dialed digits,
Number Type, and Numbering Plan.
CUCM H.323 and SIP Trunks

CUCM trunks enable communication with gateways, CUBE, other CUCM clusters, and
third-party applications. CUCM has four major trunk types that can be configured for
various purposes (introduced previously):
■ Intercluster trunk (not gatekeeper controlled)
■ Intercluster trunk (gatekeeper controlled)
■ H.225 trunk (gatekeeper controlled)
■ SIP trunk
An intercluster trunk (ICT) that is not controlled by a gatekeeper is used in distributed

call-processing networks where there is no centralized source of dial plan (gatekeepers or
SME). The ICT involves N – 1 (N = number of sites) trunk connections between a CUCM
cluster and each remote CUCM cluster. This trunk type is suitable for organizations that
have just a few sites. With an increased number of sites, each cluster will need more
trunks, and the management of trunks and the dial plan can become an administrative
overhead.
A gatekeeper-controlled ICT is a more scalable method of provisioning intercluster com-

munication compared to ICTs that are not gatekeeper controlled. These trunks allow
CUCM clusters to communicate with a gatekeeper that has a centralized call routing plan
(as discussed in Chapter 3). Each CUCM cluster needs only one gatekeeper-controlled
ICT per gatekeeper, thereby reducing the number of trunks from N – 1 to 1.
A gatekeeper-controlled H.225 trunk can be looked upon as an augmentation for the

gatekeeper-controlled ICT and allows a CUCM cluster to route calls to an H.323
004_9780133845969_ch04.indd 116 6/25/14 10:15 AM

SIP Uniform Resource Identifier Dialing 117
gatekeeper or an H.323 gateway. Moreover, H.225 trunks are a preferred way of routing
calls to and from Cisco Unified Communications Manager Express (CUCME).
A SIP trunk is based on RFC 3261 and allows a CUCM cluster to route calls to a SIP
endpoint such as a SIP UA, SIP UAS, SIP proxy, and so on (as discussed in Chapter 3).
CUCM SIP trunks may be used for various purposes, depending on which of the follow-
ing options you choose for Trunk Service Type at Device > Trunk > Add New:
■ None: Non-function-specific SIP trunk, used for communication between CUCM

and any other SIP entity such as SIP UA, UAS, Proxy, and so on
■ Call Control Discovery: Used for CUCM Service Advertisement Framework (SAF)
and Call Control Discovery (CCD) service (discussed later in this chapter)
■ Extension Mobility Cross Cluster: Used for Extension Mobility Cross Cluster
(EMCC) service (discussed later in this chapter)
■ Cisco Intercompany Media Engine: Used with Cisco Intercompany Media

Engine (IME) for joining a Cisco IME network to route calls on-net within partner
organizations
■ IP Multimedia Subsystem Service Control (ISC): Used for integration with 3GPP
and fixed mobile convergence
Depending on the chosen trunk type and protocol, enter the required details such as
trunk name, destination IP address (or SRV in case of a SIP trunk), and so on. Click Save.
SIP Uniform Resource Identifier Dialing

A SIP URI is the SIP addressing schema that is used in a SIP-based call-control system. A
SIP URI resembles an email address and is represented in the following format:
sip:<xyz>@<corp.local:port>;<uri-parameters>?<headers>
where, xyz = the username, corp.local = the hostname (domain or IP address), port =
5060 (default unless specified explicitly), and the URI parameters and headers are option-
al. SIP URIs identify communications resources. CUCM does not support URIs without a
username. Also, CUCM supports a hostname as either FQDN or IPv4 and does not sup-
port IPv6.
The Organization Top Domain (OTD) and Cluster Fully Qualified Domain Name
(CFQDN) can be configured at System > Enterprise Parameters to allow a call control
agent to distinguish between a local DN/URI and a remote URI. If the CFQDN, OTD, or
IP address of any cluster member matches the domain part of a URI, it is a local DN/URI.
SIP URI dialing offers multiple benefits, such as:
■ It is the native dialing method in SIP-based video equipment such as VCS.
■ It offers extended support for SIP video endpoints registered with CUCM.

■ It offers unambiguous dialing from directories and enables easier B2B video call
routing.
In CUCM, the SIP URI concept is realized by the DN being aliased by a SIP/alphanumeric
(alpha) URI. All endpoints still have a DN, and phones always register via the DN and do
not necessarily even know if there is an associated SIP URI. An alpha URI can be associ-
ated with the DN on any device (not only SIP). Up to five URIs can be associated with
any DN, though only one alpha URI is marked as primary, as shown in Figure 4-8. It is the
primary URI that is used when blending identity for that DN (blended addressing is covered
later in this chapter). Directory URIs can be defined by an administrator or an end user.
Figure 4-8 Directory URI
A SIP URI call can be represented by the call flow overview shown in Figure 4-9.
CUCM Cluster
Routestring: corp.local
[email protected] [email protected]
DN 99901 DN 99902
Figure 4-9 Directory URI-based SIP Call
Currently, URI dialing is supported only by a subset of IP Phones (including 99XX and
8961 IP Phones, except transfer, conferencing, and forwarding in the latter case), Jabber
clients, and video endpoints. In the context of URI-based call routing, the following spe-
cifics come into play:
■ Directory lookup based on the end-user directory on CUCM always returns a

number.

■ Dialing from an enterprise directory based on CUCM always goes to a number and
not a URI.
■ An endpoint using other data sources (e.g., LDAP) might dial the alpha URI instead.
■ All phones can be called via a SIP URI because the URI is mapped to a DN.
■ Intrasite dialing is a two-step process (normalize and route). A normalization transla-

tion pattern might impose calling party transformations (in addition to called party
transformations).
■ Calling a URI takes a different path as the only option for calling party transforma-
tion is the calling party transformation CSS on calling endpoint or calling endpoint’s
device pool.
■ The default “Directory URI” partition will have all auto-generated user-based URIs.
Intercluster Lookup Service

In the case of intercluster (multicluster) dialing, the host part of URIs might identify
the home cluster. Reachability is established through SIP route patterns for host parts.
However, it requires a hierarchical URI schema, such as [email protected] and xyz@
siteB.corp.local, instead of a flat schema, such as [email protected] and [email protected].
Moreover, the remote clusters may not be aware of the local cluster’s route strings (SIP
route patterns). In this instance, Intercluster Lookup Service (ILS) comes to the rescue.
It enables clusters to exchange URIs and create a URI to route string mapping table, as
shown in Figure 4-10.
[email protected]
ILS Learned URIs

to Route String Mapping
CUCM Cluster Site A [email protected] > SiteB.corp.local
Route String: siteA.corp.local [email protected] > SiteC.corp.local
l si
ca te
A.
p.lo l si co
or a te
.c l oc C rp
.lo
eA p. .c
or
si
t or p.
ca
.c lo l
t eB ca
si l
CUCM Cluster Site B CUCM Cluster Site C
Route String: siteB.corp.local ILS Exchange Route String: siteC.corp.local
ILS Learned URIs ILS Learned URIs
to Route String Mapping to Route String Mapping
[email protected] > SiteA.corp.local [email protected] > SiteA.corp.local
siteB.corp.local [email protected] > SiteB.corp.local
[email protected] > SiteC.corp.local
siteC.corp.local
[email protected] [email protected]
Figure 4-10 ILS URI to Route String Mapping Between CUCM Clusters
ILS allows propagation of individual alpha URIs between call-control agents (clusters) and
helps bind an alpha URI with attributes that allow routing to the URI’s home cluster. Each
call-control agent replicates its alpha URIs to its neighbors and also announces a SIP route

string together with the alpha URIs. A SIP route string can be routed based on SIP route
patterns for intercluster call routing of alpha URIs, not based on the URIs’ host part, but
on the SIP route string.
The following are the components of end-to-end URI dialing/routing:
■ ILS networking
■ URI propagation
■ SIP trunk
■ SIP route pattern
There are three important points to consider. SIP connectivity is the foundation for call
routing based on SIP route patterns, ILS networking is the foundation for exchange of URI
reachability information, and URI propagation is enabled independently of ILS networking.
For ILS networking and URI propagation, the following must be considered:
■ Call-control agents participating in an ILS network form a hub-and-spoke topology.
■ Each call-control agent is a hub or spoke. All hubs need to be full-mesh.
■ Each call-control agent keeps a local copy of all URIs advertised by all other nodes
in the ILS network.
■ Each call-control agent periodically pulls in all changes in all URI catalogs advertised
into ILS from directly connected call-control agents (with an interval of 1 to 1440
minutes).
■ URI catalog updates propagate through the ILS network hop by hop (maximum
diameter is three hops).
Figure 4-11 illustrates ILS networking and the relationships between the call-control
agents acting as hubs and spokes.
ILS Spoke ILS Spoke
ILS Hub ILS Hub
ILS Spoke ILS Spoke
Figure 4-11 ILS Networking

To configure ILS, follow these steps:
Step 1. Ensure that a unique Cluster ID is defined for each cluster that is going to par-
ticipate in ILS networking. The Cluster ID can be changed from the default by
browsing to the Cisco Unified CM Administration page and choosing System
> Enterprise Parameters.
Step 2. Select a node in a cluster that will communicate with other nodes in other
call-control agents (clusters). This node is known as XNode and needs
to exchange Cisco Tomcat certificates with other XNodes. Using the
Bulk Certificate Management option in Cisco Unified Operating System
Administration (Security > Certificates), exchange the Cisco Tomcat certifi-
cates of an XNode with other XNodes.
Step 3. In Cisco Unified CM Administration, choose Advanced Features > ILS

Configuration. Set the Role option for the first (full-mesh connected) cluster
to Hub Cluster (others can be set as Hub or Spoke as per the topology of the
network) as shown in Figure 4-12. Hub Cluster can be the Session Manager
Edition (SME) cluster. Don’t set the Registration Server.
Figure 4-12 ILS Configuration
Step 4. On other clusters, to join an ILS network, set the Role to Spoke Cluster and
configure Registration Server as the SME IP address/hostname (in the win-
dow that pops up when saving the configuration for spoke cluster).
Step 5. To define the unique SIP route string to be advertised for local alpha URIs, go
to Call Routing > Intercluster Directory URI > Intercluster Directory URI
Configuration. Check the Exchange Directory URI Catalogs with Remote
Clusters check box and provide the route string that should be exchanged
with ILS neighbors.
Step 6. Configure SIP route patterns on leaf nodes and SME. SME needs specific SIP
route patterns for each SIP route string pointing to the respective leaf cluster,
such as siteA.corp.local or siteB.corp.local, whereas leaf clusters only need a
“catch all” SIP route pattern that matches on all SIP route strings and points
up to SME, such as *.corp.local.

At this time, ILS configuration is complete. Remote cluster information and services pro-
vided can be viewed by navigating to Advanced Features > Cluster View. Also, the ILS
Configuration menu enables you to monitor the sync state of URI data.
Blended Addressing
In CUCM, alpha URIs are assigned to DNs, and DNs are the primary identity with which
a device registers to CUCM. While electing between a DN or alpha URI, it becomes
ambiguous as to what is the correct identity to be presented during calls. While this may
depend largely on the devices involved in the call, a solution to overcome the ambiguity
is to use “blended identity,” which is a combination of the DN and alpha URI.
CUCM can build missing pieces, such as building the DN from the alpha URI by look-
ing at the primary URI configured on the DN, or building the alpha URI from the DN by
searching for the DN that has the alpha URI as its primary URI. In blended addressing,
Remote-Party-ID (RPID) carries both the alpha URI and number in the following format:
Remote-Party-ID:<sip:[email protected];x-cisco-number=+919999900000>
CUCM supports blended addressing that can be enabled as a policy on SIP trunks for
outbound calls, as shown in Figure 4-13. The default setting is Deliver DN Only in
Connected Party (for backward compatibility). The recommended setting is Deliver URI
and DN in Connected Party, If Available between clusters using URI dialing.
Figure 4-13 Blended Addressing on SIP Trunk
CUCM Call Admission Control

CUCM CAC preserves call quality and prevents WAN bandwidth oversubscription by
limiting the number of calls over the WAN. CUCM-based CAC can be divided into three
major categories:

■ Locations-based CAC (LCAC)
■ Enhanced LCAC (E-LCAC)
■ Resource Reservation Protocol (RSVP)
Locations-Based CAC
A CUCM location protects a WAN link at a remote site from being oversubscribed by
defining the maximum audio/video bandwidth allowed within a location. Locations work
in conjunction with regions to define the characteristics of a network link. Locations can
be associated to device pools and to devices themselves, such as a phone, trunk, gateway,
conference bridge, or MoH server—basically, any device that sources media. Locations
can be dynamically associated to endpoints via device mobility groups (IP subnets).
Figure 4-14 depicts location configuration between a hub site and a remote site.
Figure 4-14 Location-based CAC Configuration
LCAC has a new option for immersive video: TelePresence. Now, you can establish sepa-
rate immersive bandwidth settings on locations and links (links are explained in the next
section). Desktop video and TelePresence can reside in the same location, and the band-
width can be deducted separately for either.
SIP trunks are used to classify a device or system as one of the following:
■ Desktop: Standard desktop video
■ Immersive: High-definition immersive video
■ Mixed: A mix of immersive and desktop video
This is achieved by configuring a SIP profile to set a specific video class and assigning
that profile to a SIP trunk. However, LCAC has some restrictions:
■ LCAC isn’t supported in real-world network models where customer networks are
multitier and multihop instead of simple hub-and-spoke topology.
■ It has no intercluster bandwidth management support.

These shortcomings are addressed by Enhanced LCAC (E-LCAC).

Enhanced LCAC
E-LCAC enables network administrators to perform network modeling such as applying
locations and links to determine the best path(s) for a call to proceed between different
sites. The following are fundamentals of E-LCAC network modeling:
■ Location: Represents a LAN. It could contain endpoints or simply serve as a transit

location between links for a WAN network modeling.
■ Links: Interconnect locations (to build the topology) and are used to define band-
width available between locations. Links logically represent the WAN link.
■ Weights: Used on links to provide a “cost” to the “effective path.” Weights are perti-
nent only when there is more than one path between any two locations.
■ Effective path: The path with the “least cumulative weight.”
CUCM calculates shortest paths (least cost) from all locations to all locations and builds
the effective paths. CUCM tracks bandwidth across any link that the network model indi-
cates from the originating location to the terminating location.
Figure 4-15 illustrates the network modeling with locations, links, and effective paths.
Location
Link Link
Effective Path
Effective Path
Location Link Link Location
Location
Figure 4-15 E-LCAC-based Network Modeling
Intra-location bandwidth limits are assigned to a location to apply CAC to all calls made
“To/From/Within” the location. Intra-location bandwidth values are unlimited by default.

The Location Bandwidth Manager (LBM) service computes the effective path from the
source location to the destination location based on the following:
■ The sum weight of links across each possible path from source to destination. The
least-cost value of the path’s weight determines the effective path.
■ A tiebreak of equally weighted paths is determined by LBM based on location name.
■ After the effective path is determined, all subsequent calls that have the same source
and destination locations will use the same effective path.
LBM is a CUCM service that is activated by default for upgrades to CUCM 9.x from pre-
vious versions; however, it must be manually enabled for fresh installs by going to Cisco
Unified Serviceability > Tools > Service Activation. LBM can be enabled on multiple
servers in a cluster so that LBM groups can be configured to provide LBM redundancy.
Cisco CallManager service interacts with LBM service within a server, and LBM service
is replicated in a full mesh within a cluster. LBM groups can be configured within a single
site as well as within a cluster over the WAN. You can configure an LBM group by going
to System > Location Info > Location Bandwidth Manager Group, as shown in
Figure 4-16.
Figure 4-16 LBM Group Configuration
For intercluster CAC, each cluster manages its own topology. Each cluster then propa-
gates its topology to other clusters configured in the LBM intercluster replication net-
work. Each cluster then creates a Global Topology (also called Assembled Topology),
piecing together each cluster’s replicated topology. A single cluster, such as an SME clus-
ter, manages all locations and links for the entire location replication network. All other
clusters, such as leaf clusters, are required to configure only the locations that are neces-
sary to associate with endpoints and devices.
With E-LCAC there are two new location types:
■ Shadow location: A Shadow location is used to enable a SIP trunk to pass E-LCAC
information such as location name, location PKID, FateShareID, and traffic class. To

pass this location information across clusters, the SIP intercluster trunk (ICT) needs
to be assigned to the Shadow location. Similar to the “Phantom” location, a Shadow
location cannot have a link to other user/device locations, so no bandwidth can be
reserved between the Shadow location and other user/device locations. Any device
other than a SIP ICT that is assigned to the Shadow location is treated as if it were
associated to Hub_None.
■ Shared location: A Shared/Common location is configured with the same name

on clusters participating in an LBM replication network. It serves two purposes: it
enables clusters to propagate their respective configured topologies to one another,
and it provides the ability for multiple clusters to apply CAC to the same locations.
Resource Reservation Protocol

RSVP is a topology-aware CAC signaling protocol that has been designed to work with
any WAN topology. It runs as a software feature on Cisco IOS routers and as an RSVP
agent on CUCM. It has the following characteristics:
■ Uses existing routing protocols and dynamically adjusts to link failures/topology

changes.
■ Reservations are receiver-initiated and are on a per-stream basis.
■ Operates transparently across non-RSVP routers, allowing for partial or gradual

deployment.
■ Dynamically inserted (in pairs) by CUCM based on location policy.
■ Calls are accepted, re-marked, or rejected based on the outcome of RSVP reservation
and configured policy (optional, mandatory).
Figure 4-17 represents RSVP call flow including endpoints, CUCM RSVP agents, and
RSVP-enabled Cisco IOS routers.
CUCM uses two RSVP application IDs:
■ AudioStream: Used for audio streams of voice calls
■ VideoStream: Used for audio and video streams of video calls
These IDs allow you to limit the maximum number of audio or video calls across a link.
Voice calls are marked as EF (default) and video calls (both audio and video streams) are
marked AF41 (default).

IP Phone A RSVP Agent A CUCM RSVP Agent B IP Phone B
Call Setup to IP Phone B
Allocate RSVP Agent to Allocate RSVP Agent to

Phone A Phone B
Reserve Bandwidth from
RSVP Agent B to A
Reserve Bandwidth from
RSVP Agent A to B
Bandwidth Reservation Bandwidth Reservation
Successful Successful
Call Setup to IP Phone B

Alerting Tone
Answer
Connect Connect Connect Connect

Non-RSVP Protected RSVP Protected RSVP Protected Non-RSVP Protected
RTP Stream RTP Stream RTP Stream RTP Stream
Figure 4-17 RSVP Call Flow Overview
RSVP configuration is a twofold process wherein CUCM and the IOS router must be con-
figured for RSVP. Follow these steps to configure RSVP on CUCM:
Step 1. Configure clusterwide RSVP policy in Cisco Unified CM Administration by

choosing System > Service Parameters > Cisco CallManager. The policy
for new call setup should be configured as Mandatory (call fails or reverts to
AAR if RSVP reservation fails; equivalent to static location).
Step 2. Configure Mandatory RSVP mid call error handle option to Call Fails
Following Retry Counter Exceeded.
Step 3. Go to Media Resources > MTP and click Add New. Configure a Media
Termination Point (MTP) similar to Figure 4-18.
As the final step, configure the Cisco IOS gateway as an RSVP agent so it can be inserted
in the call between CUCM and a remote IP Phone (provided the MTP is assigned to the
IP Phone’s MRGL). Example 4-1 outlines the configuration of Cisco IOS router MTP as
the RSVP agent.

Figure 4-18 RSVP (CUCM) MTP
Example 4-1 Cisco IOS MTP (RSVP) Configuration
RSVPRouter(config)# sccp local Loopback0

RSVPRouter(config)# sccp ccm 10.76.108.239 identifier 1 priority 1 version 7.0+
RSVPRouter(config)# sccp ccm 10.76.108.240 identifier 2 priority 2 version 7.0+
RSVPRouter(config)# sccp
!
RSVPRouter(config)# sccp ccm group 10
RSVPRouter(config-sccp-ccm)# associate ccm 1 priority 1
RSVPRouter(config-sccp-ccm)# associate ccm 2 priority 2
RSVPRouter(config-sccp-ccm)# associate profile 10 register RSVPAgent
!
RSVPRouter(config)# dspfarm profile 10 mtp
RSVPRouter(config-dspfarm-profile)# codec pass-through
RSVPRouter(config-dspfarm-profile)# rsvp
RSVPRouter(config-dspfarm-profile)# maximum sessions software 100
RSVPRouter(config-dspfarm-profile)# associate application SCCP
RSVPRouter(config-dspfarm-profile)# no shut
RSVP SIP Preconditions

SIP preconditions (as defined by RFC 3312 and RFC 4032) allow Cisco call-control
agents to synchronize RSVP requirements with one another. The SIP Required header
includes a precondition option tag and QoS precondition as part of the media attributes
in the Session Description Protocol (SDP) description.
Before RSVP initiation, an SDP is as follows:

m=audio 20000 RTP/AVP 0

c=IN IP4 10.10.100.201
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
After exchange and handshake between RSVP agents, the SDP (result of UPDATE from
initiator) looks like this:
c=IN IP4 10.10.100.201
a=curr:qos e2e send
In reply, the other RSVP agent sends the following SDP (result of 200 OK UPDATE):
c=IN IP4 10.20.10.200
a=curr:qos e2e sendrecv
With SIP preconditions, only one RSVP agent per cluster is required, and a topology
design with multiple clusters in a single data center or multisite distributed model is
supported.
To configure RSVP SIP preconditions, follow these steps in Cisco Unified CM

Administration:
Step 1. Choose Device > Device Settings > SIP Profile.
Step 2. Copy the default standard SIP Profile and add Trunk Specific Configuration
as follows:
■ Set RSVP Over SIP to E2E.
■ Ensure that the check box Fall Back to Local RSVP is checked.
■ Set SIP Rel1XX Options to Send PRACK if 1XX Contains SDP.
Step 3. Apply the new SIP profile with SIP preconditions to a SIP trunk.
CUCM-Based Call Recording and Silent Monitoring

CUCM offers silent call monitoring and call recording as native features. CUCM’s Silent
Monitoring feature allows an authorized party to eavesdrop on a conversation between
two or more parties without either call participant knowing they are being monitored.
This allows Contact Centers to monitor the quality of service their agents provide to the

customers. CUCM’s Call Recording feature enables organizations to archive the con-
versation of two or more parties for review, analysis, and/or legal compliance. A Cisco
Unified IP Phone can simultaneously support one monitoring and one recording session.
It is important to note that Cisco Unified Contact Center Express (UCCX) does not sup-
port the CUCM Silent Monitoring and Recording feature as it uses its own built-in silent
monitoring and call recording mechanism.
Figure 4-19 illustrates the CUCM-based Call Recording and Silent Monitoring
architecture.
Caller
(Customer)
PSTN/WAN
CUCM
Voice MGCP/H.323/SIP TAPI/JTAPI

Gateway
Monitoring/Recording
Observed Caller’s Voice Enabled Desktop Application
Voice Stream Stream TAPI/JTAPI
SCCP/SIP
SIP Trunk
Voice-
Enabled Switch
Recording
Server
Monitored and Observer

Recorded User (Agent) (Supervisor)
Figure 4-19 CUCM-based Call Recording and Silent Monitoring Architecture
Silent Monitoring is invoked through a Computer Telephony Integration (CTI)-enabled

desktop (JTAPI/TAPI) or phone-based application (XML, Midlet). The agent’s IP Phone’s
internal DSP resources mix the media streams of the agent and caller and send them to
the supervisor. The following are features of Silent Monitoring:
■ Allows supervisors to monitor calls using their IP Phone. The media (RTP) plays
through the IP Phone and not the PC.
■ Monitoring sessions are managed as normal calls; calls can be transferred, held, or
conferenced.

■ CUCM-based Silent Monitoring does not require Switched Port Analyzer (SPAN)/
Remote SPAN (RSPAN).
■ Sessions can be subjected to CAC, bandwidth reservation, and codec negotiation.
■ Provides notification tones when legal compliance is required (an audible a periodic
tone can be played for agent or caller or both).
■ Supports Secure RTP (SRTP).
To enable Silent Monitoring on a Cisco Unified IP Phone, follow these steps in Cisco
Step 1. Choose Device > Phone and set the Built In Bridge option to On.
Step 2. From the Monitoring Calling Search Space drop-down list, choose the parti-
tion used to control who can monitor whom.
Step 3. Navigate to System > Service Parameters > Cisco CallManager and in the
Clusterwide Parameters (Feature - Monitoring) area, set both Play Monitoring
Notification Tone To Observed Target and Play Monitoring Notification
Tone To Observed Connected Parties to True (or False as per the legal/
compliance requirement).
Step 4. On an agent (monitored) IP Phone, place the monitoring partition (selected in

Step 2) in the normal Calling Search Space for the IP Phone.
For Call Recording, an agent’s IP Phone relays two independent media streams (agent and
caller) to the recording server via the SIP trunk. Two broad recording modes are available
with CUCM-based Call Recording:
■ Automatic silent recording: Records all calls automatically on a line appearance.

Automatic silent recording is invoked by CUCM. There’s no visual indication of the
recording session.
■ Selective recording: Allows calls to be recorded as needed. Selective recording can

be further classified into two types of recording:
■ Selective silent recording: Invoked by a supervisor via a CTI-enabled desktop

and/or Recording server based on business rules and events. There is no visual
indication of the recording session.
■ Selective user recording: Invoked by an agent via a CTI-enabled desktop and/or

softkey/programmable line key. Cisco Unified IP Phone displays recording session
messages.
The following are Call Recording features:
■ Call data is provided in the SIP header via CallID (RefCI), Directory Number (DN),
Device Name (MAC Address), Line Display Name, and Near-end/Far-end. Other call-
specific data is retrieved via CTI using CallID.
004_9780133845969_ch04.indd 131 6/25/14 10:15 AM

■ Redundancy can be configured using a CUCM route list and/or DNS SRV records.
■ Load-balancing to the recording server is usually vendor dependent.
■ The IP Phone sends recorder streams using a codec determined by the region set-
tings. If the codec required is different than the original call, a transcoder is auto-
matically inserted.
To configure CUCM-based Call Recording—that is, to connect a Recorder (Recording

Server) to CUCM and configure a phone for recording—follow these steps in Cisco
Step 1. Choose Device >Device Settings > Recording Profile.

Step 2. Click Add New. Provide the required details such as device name, CSS, and
destination address.
Step 3. Navigate to Device > Trunk and click Add New. Add a new SIP trunk. Fill in
the required information, and in the Destination Address field, enter the host-
name or IP address of the recorder. Select a partition to be used for recording.
Step 4. Go to Call Routing > Route/Hunt > Route Group and create a new Recorder
Route Group that contains the Recorder SIP Trunks. Consecutively add a new
Route List that contains the Recorder Route Group and a Route Pattern.
The Route Pattern should contain the DN for the Recorder and point to the
Recorder Route List.
Step 5. Navigate to System > Service Parameters > Cisco CallManager and in
the Clusterwide Parameters (Feature - Call Recording) area, set both Play
Recording Notification Tone To Observed Target and Play Recording
Notification Tone To Observed Connected Parties to True (or False as per
the legal/compliance requirement).
Step 6. Complete the vendor-specific guidelines for CUCM CTI connections with a
recording server.
Step 7. Go to Device > Phone and select the phone for which recording is to be
enabled. Set the Built In Bridge option to On and select a Recording Profile
for each line appearance.
Step 8. Choose the desired recording option for each line appearance: Automatic
Recording, Selective Recording, or Recording Disabled (default).
Step 9. Add the Record softkey or programmable line key to the device template
and associate this with the IP phone. Disable codecs such as G.722, iSAC,
and iLBC which the Recorder may not support either via CUCM Service
Parameters or via the Audio Codec Preference List.
004_9780133845969_ch04.indd 132 6/25/14 10:15 AM

CUCM Mobility 133
CUCM Mobility
CUCM offers a comprehensive set of mobility features and functions for enterprise
mobile workers and ensures that they have persistent reachability and access to enterprise
voice and video services regardless of location. CUCM-centric mobility features can be
categorized as follows:
■ Extension Mobility (EM)/Extension Mobility Cross Cluster (EMCC)
■ Device Mobility
■ Mobile Connect
■ Mobile Voice Access (MVA)
Extension Mobility and Extension Mobility Cross Cluster

Extension Mobility (EM) is also known as hot-desking and allows a user to move
between floors, sites, or geographic locations and utilize an available Cisco Unified IP
Phone as long as the user roams within the same cluster. EM device profile configuration
includes phone model information. Default device profiles can be configured such that if
a user logs in to a different phone model than the model configured at the device profile
of the user, EM login is still permitted.
The following events occur when a user attempts to log in to an EM-enabled IP Phone:
■ User presses the Services button on an IP Phone and selects the Cisco Extension
Mobility service. The user enters an user ID and PIN.
■ After successful authentication, Extension Mobility selects the device profile associ-
ated with the user (or prompts the user to select if multiple associations exist).
■ The IP Phone configuration is updated with the configuration parameters from the
device profile. The phone is reset and loads the updated configuration.
Follow these steps to configure Extension Mobility:
Step 1. Go to Cisco Unified Serviceability > Tools > Service Activation and activate
the Cisco Extension Mobility service.
Step 2. Navigate to the Cisco Unified CM Administration page, choose System >
Service Parameters > Cisco Extension Mobility, and set the service
parameters.
Step 3. Go to Device > Device Settings > Phone Services and add the Cisco
Extension Mobility phone service http://10.76.108.240:8080/emapp/
EMAppServlet?device=#DEVICENAME#. Create two services with the
same URL, one with the name EM Login and the other with the name
EM Logout. EM Login should be assigned to Phones and EM Logout should
be assigned to device profiles.
004_9780133845969_ch04.indd 133 6/25/14 10:15 AM

Step 4. Navigate to Device > Device Settings > Device Profile and create default
device profiles for all phone models used in your organization.
Step 5. Subscribe device profiles to the EM Login service.
Step 6. Go to User Management > End User and select the user(s) for which the EM
service is to be enabled. Associate end user(s) with device profiles.
Step 7. Navigate to Device > Phone and select the phone for which EM service
should be enabled. Ensure that under Extension Information, the check box
Enable Extension Mobility is checked. Subscribe the phone to the EM
Logout service.
Extension Mobility Cross Cluster (EMCC) takes EM one step further and enables a user
roaming between two or more clusters. Unlike EM, a user is no longer restricted to a sin-
gle cluster (intra-cluster) device roaming and can log in and log out on devices between
two or more clusters enabled for EMCC.
EMCC has the concept of a home cluster and a visiting (remote) cluster. A home cluster
is where the user is natively configured and usually leverages EM. A visiting cluster is the
nonnative cluster where the user can roam to and still leverage EM and access to all the
features available in the home cluster. EMCC supports the user’s home cluster’s dialing
behavior. EMCC supports secure phone registration.
The EMCC process works as follows:
■ The user from the home cluster logs in to a phone at a visiting cluster.
■ The login procedure brings the device information into the home cluster database.
■ The home cluster database builds a temporary device with the user’s device profile.
■ The home cluster TFTP server builds the phone configuration file.
■ After login, the visiting cluster directs the phone to the home cluster TFTP server.
■ The IP phone downloads its TFTP configuration from the home cluster TFTP server
and cross-registers with the home cluster CUCM.
To configure EMCC, first complete the EM configuration steps, and then follow these
steps:
Step 1. Go to the Cisco Unified CM Operating System Administration page and

choose Security > Bulk Certificate Management > Export and export the
home cluster’s Tomcat, TFTP, and CAPF certificates (assuming that you have
the SFTP server set up and functional).
Step 2. Consolidate and import certificates into all remote (visiting) clusters.
Step 3. Repeat Steps 1 and 2 to export, consolidate, and import certificates from vis-
iting clusters to the home cluster.

CUCM Mobility 135
Device Settings > Common Device Configuration. Click Add New and add
a new common device profile.
Step 5. Navigate to Bulk Administration > EMCC > EMCC Template. Click Add
New to create a new template and enter require details.
Step 6. Go to Bulk Administration > EMCC > Insert/Update EMCC and click
Update EMCC Devices. Choose the default template you configured earlier
and click Run Immediately.
Step 7. Repeat Step 6 with the Insert EMCC Devices option.
Step 8. Go to System > Geolocation Filter and click Add New. Create a new EMCC
Geolocation filter.
Step 9. Navigate to Advanced Features > EMCC > EMCC Feature Configuration
and enter the required parameters along with the Geolocation Filter from
Step 8.
Step 10. Configure a SIP trunk by navigating to Device > Trunk > Add New and
choosing SIP as the protocol. Set the Trunk Service Type field to Extension
Mobility Cross Clusters. Enter required details and check the Send
Geolocation check box.
Step 11. Go to Advanced Features > EMCC > EMCC Intercluster Service Profile
and check the Active check box for EMCC, PSTN Access, and RSVP Agent.
Ensure that the right SIP trunk is selected in the PSTN Access pane. Validate
the settings.
Step 12. Navigate to Advanced Features > EMCC > EMCC Remote Cluster and add
required details about the visiting cluster.
Step 13. Go to System > Service Parameters, choose the CUCM server where EM
is enabled, and activate Cisco Extension Mobility. Click Advanced and set
Inter-cluster Maximum Login Time and EMCC Allow Proxy to True.
At this time, the EMCC configuration is complete.
Device Mobility
Device mobility allows CUCM to apply site-specific configuration to roaming devices
such as Jabber clients. This helps ensure that a roaming device uses local-site gateways for
PSTN (where applicable) or is restricted to VoIP-only access. To enable device mobility,
CUCM is configured with IP subnets and matching device pools to identify sites. CUCM
compares the Physical Location parameter in the device’s device pool and the device pool
configured on the IP subnet. If the Physical Location is different, CUCM applies the IP
subnet’s device pool configuration to the endpoint, builds a new configuration file, and
resets the endpoint. The settings applied to roaming handsets include Date/Time Group,
Region, Location, SRST Reference, Physical Location, and MRGL.

To configure device mobility, follow these steps in Cisco Unified CM Administration:
Step 1. Choose System > Service Parameters > Cisco CallManager and set Device
Mobility Mode to On. Alternatively, this can be done on a per-endpoint basis
from within the Phone Configuration window.
Step 2. Navigate to System > Physical Location. Click Add New and enter required
information.
Step 3. Go to System > Device Mobility > Device Mobility Group. Click Add New
and enter required information.
Step 4. Navigate to System > Device Mobility > Device Mobility Info. Click Add
New. Enter the name, subnet (for which endpoints have to be tracked), and
subnet size, and choose device pools for which this device mobility informa-
tion is significant.
Step 5. Go to System > Device Pool and select the device pool for which device
mobility is to be enabled. Under Roaming Sensitive Settings, select options
in the Device Mobility Group and Physical Location drop-down lists. Under
Device Mobility Related Information, enter the respective information that
will apply to devices when roaming.
Mobile Connect
Mobile Connect is also known as Single Number Reach (SNR). SNR supports redirecting
incoming calls from CUCM to up to ten different remote (destinations) devices. When
there’s an incoming call, it rings the local IP Phone as well as any of the enabled remote
devices. If the call goes unanswered, it is routed to the local IP Phone. Figure 4-20 shows
the Mobile Connect call flows.
As shown in Figure 4-20, there are two call flows: one from the PSTN caller to a user’s
desk phone that is enabled for mobility, and the other from a user’s remote device to
an internal phone. For the first call flow, when the PSTN caller rings the desk phone
+15555559000, CUCM intercepts the call and, using the user’s configured remote
destination profile(s), rings all the remote devices (in this case the user’s mobile phone
at +14088888000) including the desk phone (DN 9000) with caller ID of PSTN caller
(+15558888000). At this time, the user has an option to pick up the call on any local and
reachable device, be it the desk phone or the mobile phone. For the second call flow,
the user dials an internal number (9001) using the E.164 number +15555559001, CUCM
intercepts the call and matches the dialed number to the remote destination(s) configured,
which in turn is mapped to an internal DN. After finding a match, CUCM directs the
call to the internal number (after digit striping/manipulation) with caller ID of internal
DN 9000.

CUCM Mobility 137
PSTN Caller Call from

+15558888000 +15558888000
Remote Phone
(of DN 9000)
+14088888000
Call to Call to
+15555559000 +15555559001
PSTN
Cisco Unified IP Phone

DN = 9001
Voice
Gateway
5555559XXX
Call From 9000
Voice Enabled
Switch
CUCM Cisco Unified IP Phone

(Mobile Connect) DN = 9000
Figure 4-20 Mobile Connect/SNR Call Flows
To configure Mobile Connect on CUCM, follow these steps:
Step 1. Go to Cisco Unified Serviceability > Tools > Service Activation and enable
Cisco Unified Mobile Voice Access Service.
Step 2. Navigate to System > Service Parameters > Cisco CallManager >
Clusterwide Parameters (Mobility) and set Matching Caller ID with Remote
Destination as Partial Match and Number of Digits for Caller ID Partial
Match.
004_9780133845969_ch04.indd 137 6/25/14 10:15 AM

Device Settings > Softkey Template. Copy Standard User (or another
template you wish to modify) and name it Standard Mobility User. Add a
Mobility Softkey to On Hook and Connected call states.
Step 4. Navigate to User Management > End User and select the user for which
SNR is required. Under Mobility Information, make sure the Enable Mobility
check box is checked.
Step 5. Go to Device > Phone and select the IP Phone for which mobility is to be
enabled. Assign the Standard Mobility User Softkey template to the phone.
Step 6. Navigate to Device > Device Settings > Remote Destination Profile. Enter
the required information, including a user ID for which the profile is to be
configured. Click Save. Create a new DN and ensure that the DN is the same
as the user’s desk phone.
Step 7. Add Remote Destination(s) number(s). This can be accomplished by CUCM

administrator by browsing to Remote Destination Profile page or by CUCM
users browsing to CCMUser > User Options > Mobility Settings > Remote
Destinations. Ensure that the Mobile Phone and Enable Mobile Connect
check boxes are checked. Select a Ring Schedule and Ringing option.
Mobile Voice Access

Mobile Voice Access (MVA) extends Mobile Connect capabilities that enable a system to
make enterprise calls from any location. MVA allows enterprises to leverage an integrated
voice response (IVR) system on an H.323 VXML gateway so that the IVR system can be
used to initiate Mobile Connect calls and activate or deactivate Mobile Connect. Figure
4-21 illustrates the MVA call flow.
As shown in Figure 4-21, a corporate user calls in to the MVA number +15555559999
that triggers the MVA application. The user then keys in the remote destination number
(+15558888000) followed by the PIN, both of which are relayed to CUCM by the voice
gateway. Once authenticated, the user is connected to the dialed remote destination
number. The following steps show how to configure CUCM for MVA (assuming Mobile
Connect is enabled on the cluster):
Step 1. Go to Cisco Unified Serviceability > Tools > Service Activation and enable
Cisco Unified Mobile Voice Access Service.
Step 2. Navigate to the Cisco Unified CM Administration page and choose System
> Services Parameter > CUCM > Clusterwide Parameters (Mobility). Set
Enterprise Feature Access to True, Enable Mobile Voice Access to True,
Mobile Voice Access Number (for example, 9999), and Matching Caller ID
with Remote Destination as Partial Match.
004_9780133845969_ch04.indd 138 6/25/14 10:15 AM

CUCM Mobility 139
PSTN Phone Remote Phone

+15558888000 (of DN 9000)
+14088888000
Call from Call to

+15555559000 +15555559999
PSTN
Remote Destination CUCM

Number and PIN (MVA)
H.323 VXML
Voice Gateway
9999
(IVR Application)
5555559XXX
Voice
Enabled Switch
Cisco Unified IP
Phone DN = 9000
Figure 4-21 CUCM MVA Call Flow
Step 3. Go to Media Resources > Mobile Voice Access and configure Mobile Voice
Access Directory Number (for example, 9999) and Mobile Voice Access
Partition.
Step 4. Navigate to User Management > End User and select the user to be config-
ured for mobility. Ensure that the Enable Mobile Voice Access check box is
checked and that Maximum Wait Time for Desk Pickup is configured (apart
from other mobility-related specifics). Also make sure that the user has the
appropriate roles assigned to it (Standard CCM End Users, Standard CCM
User Administration, Standard CTI Enabled, Standard CTI Allow Control of
All Devices).
Finally, configure an H.323 voice gateway to accept incoming calls on the POTS dial peer
for MVA and forward the same to CUCM, as shown in Example 4-2.
Example 4-2 MVA Configuration on Cisco IOS Router
MVARouter(config)# application
MVARouter(config-app)# service mva http://10.76.108.240:8080/ccmivr/pages/
IVRMainpage.vxml
!
004_9780133845969_ch04.indd 139 6/25/14 10:15 AM

MVARouter(config)# dial-peer voice 9999 pots

MVARouter(config-dial-peer)# incoming called number 9999
MVARouter(config-dial-peer)# service mva
MVARouter(config-dial-peer)# no digits-strip
MVARouter(config-dial-peer)# direct-inward-dial
!
MVARouter(config)# dial-peer voice 9001 voip
MVARouter(config-dial-peer)# destination-pattern 9999
MVARouter(config-dial-peer)# session target ipv4:10.76.108.240
MVARouter(config-dial-peer)# dtmf-relay h245-alphanumeric
MVARouter(config-dial-peer)# codec g711ulaw
MVARouter(config-dial-peer)# no vad
Service Advertisement Framework and Call Control

Discovery
In large, multisite Cisco Collaboration network deployments, it can be both adminis-
tratively difficult and time consuming to configure point-to-point (CUCM/CUCME to
CUCM/CUCME) or point-to-multipoint (CUCM/CUCME to GK/SME/CUBE/CUCME)
networks for the dial plan. Cisco Service Advertisement Framework (SAF) simplifies the
dial plan in large, multisite networks via auto-propagation and proliferation of the dial
plan through various network elements.
SAF is a network-based, scalable, bandwidth-efficient, real-time approach to service dial

plan advertisements and discovery of participating entities. SAF is based on Enhanced
Interior Gateway Routing Protocol (EIGRP) technology, but it is independent of the IP
routing protocol implemented in a network, such as static routing, Open Shortest Path
First (OSPF), or Border Gateway Protocol (BGP). SAF allows administrators to control
the scope of each service (currently limited to Call Control Discovery) through domains,
filtering, and Virtual Routing and Forwardings (VRF) and works with non-SAF-enabled/
supporting nodes (dark nets) for heterogeneous deployments.
Call Control Discovery (CCD) is a SAF service that enables call-control agents to dis-
cover each other through the SAF network by advertising their reachability information
(along with the DN ranges they own) and consecutively requesting to learn about other
call-control agents in the network. Call-control agents can then dynamically route calls to
remote destinations based on received advertisements.
SAF Architecture
A Cisco SAF network is composed of multiple entities and multiple protocols. Figure
4-22 depicts the Cisco SAF architecture.

CUCM Cluster CUBE CUCME IOS Gateway SME Cluster

(SAF Client) (SAF Client) (SAF Client) (SAF Client) (SAF Client)
CCD CCD CCD CCD CCD
SAF Client SAF Client

Protocol Protocol
SAF Forwarder SAF Forwarder SAF Forwarder SAF Forwarder
SAF Forwarding
Protocol
SAF Forwarder SAF Unaware Routers SAF Forwarder
Figure 4-22 Cisco SAF Architecture
Table 4-4 lists some of the SAF terms used to describe the role of each SAF entity in a
Cisco SAF network.
Table 4-4 Cisco SAF Network Components

SAF Component Description
SAF client An application that is capable of advertising a service to the net-
work or requesting a service from the network, or both. CUCM
is an example of a SAF client.
SAF Client Protocol SAF network interface layer inside CUCM for SAF applications.
SAF forwarder A Cisco IOS router feature that provides a relationship between
the SAF client and the SAF framework, stores service informa-
tion, and propagates that information to other forwarders.
SAF Forwarding Protocol Used by a SAF forwarder to communicate (share/receive) SAF
updates with other SAF forwarders.
Service Any information that a SAF client wishes to advertise and con-
sume, such as dial plans for CCD service.
SAF Advertisement Carries service information and consists of SAF Header and
Service Data.
Non-SAF node Any (SAF-unaware) router in a SAF network that does not run
SAF protocols.
A SAF forwarder learns dial plan information from a SAF client (leveraging CCD service).
Then the SAF forwarder exchanges learned call-routing information with other SAF for-
warders as well as SAF clients so that the SAF-enabled network is aware of all learned call

routes. This helps overcome the full-mesh, point-to-multipoint manual dial plan prolifera-
tion and solves the complexity of managing a full mesh of static trunks without a single
point of failure.
A SAF message consists of two parts: SAF header and SAF service data. The SAF header
is significant to SAF forwarders because it identifies the service type (such as CCD) and
includes information relevant for dynamic distribution of SAF services. SAF service data
is significant to SAF clients and includes the IP address and port of the advertising SAF
client. It also contains detailed client data describing the advertised service (for example,
CCD client data includes call-routing information such as directory numbers, the signal-
ing protocol used by call-control agent, PSTN prefixes, and so on).
Call Control Discovery Service

CCD service enables call agents to exchange dial plan, signaling protocols, corresponding
PSTN numbers, and reachability information through SAF. It is a function of call agents
and allows extending call-control logic to incorporate dynamic routing based on informa-
tion learned through a SAF-enabled network. CCD focuses on enterprise-owned DNs,
including information on DID rules in advertisements to simplify PSTN failover (if IP
routing fails). The following are characteristics of CCD service:
■ CCD Advertising Service: Responsible for advertising preconfigured hosted DN

ranges, PSTN failover rules, and trunk route information to the SAF network. It can
select up to two trunks, one SAF CCD SIP trunk and one SAF-enabled H.323 ICT,
and runs on the same nodes as its selected trunks. Upon any change in local configu-
ration, CCD Advertising Service sends a new advertisement to the SAF network.
■ CCD Requesting Service: Responsible for learning hosted DN routes from the SAF
network. It stores learned route information locally and registers it with CUCM
Digit Analysis. CCD Requesting Service performs load balancing for calls to learned
routes. If a call can’t go through via the IP network, CCD Requesting Service routes
the call via the PSTN network.
Figure 4-23 illustrates CCD advertised and learned routes (dial plan) across a SAF-
enabled network.
As shown in Figure 4-23, three locations are configured to advertise and learn their
respective hosted DNs: San Jose (CUCM Cluster), Delhi (Cisco Unified CME), and
Singapore (Cisco Unified CME). The SAF forwarders advertise the learned route(s) from
respective SAF clients to their peers and in turn acquire their routes and pass on the
information to SAF clients (CUCM and CUCME), thereby building the CCD dial plan.
Each SAF client builds a database, based on dynamic call routing, that has the route,
PSTN prefix, remote IP address, and protocol to be used for routing calls.

DN Pattern “to DID” Rule IP Address Protocol

8961XXXX +91114261 /4 10.86.108.230 SIP
8962XXXX +656585 /4 10.96.108.240 H.323

8963XXXX +1408567 /4 10.76.108.146 SIP
8962XXXX +656585 /4 10.96.108.240 H.323
PSTN
8963XXXX 10.76.108.146
San Jose
SAF Forwarder
SAF-Enabled 8961XXXX 10.86.108.230
Network Delhi
SAF Forwarder
Singapore
8962XXXX 10.96.108.240 SAF Forwarder

8963XXXX +1408567 /4 10.76.108.146 H.323
8961XXXX +91114261 /4 10.86.108.230 H.323
Figure 4-23 CCD Service Advertised and Learned Routes in a SAF Network
To configure SAF and CCD on a CUCM cluster, use the following steps in Cisco Unified
CM Administration:
Step 1. Choose Advanced Features > SAF > SAF Security Profile and create a New
Profile and enter the required information. Ensure that the username and
password entered match the credentials entered in IOS router’s external-client
configuration. Click Save.
Step 2. Navigate to Advanced Features > SAF > SAF Forwarder and create a new
SAF forwarder. Use the external client configuration parameters to complete
the Client Label, SAF Forwarder Address, and SAF Forwarder Port fields, and
from the SAF Security Profile drop-down list, select the security profile cre-
ated in Step 1. Click Save.
Step 3. Go to Call Routing > Call Control Discovery > Hosted DN Group and cre-
ate a group. Enter required information and click Save.

Step 4. Navigate to Call Routing > Call Control Discovery > Hosted DN Pattern
and add a route pattern as you expect from the PSTN (after digit manipula-
tion); for example, 8XXX. Assign it to Hosted DN Group and click Save.
Step 5. Go to Device > Trunk and create a new SIP trunk with Service Type as Call
Control Discovery. Configure this trunk as any other SIP trunk. Click Save.
Alternatively, an H.323 (H.225) trunk may be configured for a SAF client that
does not support SIP.
Step 6. Navigate to Call Routing > Call Control Discovery > Advertising Service
and add a new service. Select the SIP trunk (or H.323 trunk) and the Hosted
DN group configured earlier. Click Save.
Step 7. Go to Call Routing > Call Control Discovery > Requesting Service and add
a new service. Add the SIP/H.323 trunk and click Save.
For SAF and CCD configuration on Cisco IOS routers, see Chapter 9.
Additional CUCM service parameters can be fine-tuned for SAF and are listed in
Table 4-5.
Table 4-5 CUCM SAF Service Parameters

CUCM Service Parameter Description
CCD Maximum Numbers of Specifies the number of patterns that a CUCM cluster
Learned Patterns can learn from the SAF network.
CCD Learned Pattern IP Reachable Specifies the number of seconds that learned patterns
Duration stay active before CUCM marks them as unreachable.
CCD PSTN Failover Duration Specifies the number of minutes that calls to learned
patterns (marked as unreachable) are routed through
PSTN failover.
Issue Alarm for Duplicate Learned Specifies whether CUCM issues an alarm when it learns
Patterns duplicate patterns from different remote call-control
entities on the SAF network.
CCD Stop Routing On Unallocated Specifies whether CUCM continues to route calls to the
Unassigned Number next call-control entity when the current call-control
entity rejects the call with cause code Unallocated/
Unassigned Number.

Chapter 5
Cisco Unified
Communications Security
As discussed in the previous chapters, a Cisco Collaboration solution has many elements,
including infrastructure, endpoints, applications, gateways, and so on. While all of these
work together to deliver a seamless user experience, they need to be secured to ensure
that business continuity is maintained and the communication channels are operational.
The objective of securing a Cisco Collaboration solution is to secure a converged
communications network to protect its availability, the confidentiality of data that it
carries, and the integrity of this data.
Security Policy
The fundamental step to achieve a robust and secure converged network is to develop a
security policy that specifies an appropriate security plan, design, implementation, and
operations policy. A security policy gives direction to the efforts to deploy security
controls at the various layers of the OSI model, starting at the physical layer, Layer 1, up
through the application layer, Layer 7. At a high level, a security policy should at least
address the following from a Cisco Collaboration network perspective:
■ Acceptable usage and conduct pertinent to Cisco Collaboration network resources

■ Physical layer security
■ Network infrastructure security
■ Perimeter security
■ Server hardening
■ User endpoint security
■ Wireless infrastructure security
■ Backup and restore (including disaster recovery) security
■ Provision for lawful interception of calls

146 Chapter 5: Cisco Unified Communications Security
Threats to Cisco Collaboration Networks

The first step toward securing a Cisco Collaboration solution is to understand the pos-
sible threats to infrastructure, endpoints, devices, and applications. Security threats perti-
nent to Cisco Collaboration networks can be broadly categorized as listed in Table 5-1.
Table 5-1 Threats to a Cisco Collaboration (Unified IP) Network

Threat Category Description
Eavesdropping/ Aimed at voice and signaling sessions, leading to loss of confiden-
interception attacks tiality or integrity, or both.
Identity theft/ Used to exploit information in voice and video streams, leading to
impersonation attacks loss of confidentiality.
Toll fraud Occurs by means of unauthorized or fraudulent use of telephony
equipment or services.
Denial-of-service (DoS) Leads to degradation of voice and video services.
attacks
Intrusion attacks Targeted at services associated with or enabled by the telephony
implementation, such as servers in the same zone as UC servers.
There’s no single security control or tool/mechanism to thwart all the attack types listed
in Table 5-1. Defense-in-Depth, also known as a layered security approach, is required to
mitigate these threats. The following sections give insight into security measures at the
various layers of the OSI model.
Layer 1 Security
Physical security entails securing Cisco Collaboration assets from physical access by an
intruder and from potential damage by surrounding environmental factors. The major
physical security controls include
■ Guards at data center or facility periphery
■ Badged access to data center/facilities
■ CCTV, alarms, and sensors at data center/facility entry and exits
■ Cisco Collaboration equipment secured in racks in data center and in closets at user
access level
■ Uninterruptible power supply (UPS) for servers and network devices

Layer 2 Security
Layer 2 security can be deployed at the switching layer to prevent attacks originating
from the user access layer such as:
■ MAC address spoofing
■ DHCP spoofing
■ Spanning Tree Protocol (STP) manipulation
■ ARP poisoning
■ Identity spoofing
Port Security
Cisco Catalyst switches have a feature called port security that helps to reduce spoof-
ing and other attacks. Port security restricts the input to an interface by limiting and
identifying MAC addresses of end devices. The port security feature can leverage MAC
address learning in the following ways:
■ Static secure MAC address: Manually limits the MAC addresses to be allowed on
a switch port by statically configuring the MAC addresses on a per-port basis. This
feature allows MAC addresses learned to be saved in Content Addressable Memory
(CAM) table and running configuration.
■ Sticky secure MAC address: The switch port dynamically learns the MAC address-
es of connected devices (sticky) configured for sticky secure MAC addresses and
stores these in the CAM table and running configuration.
■ Dynamic secure MAC address: The MAC addresses learned from the switch port
set up for dynamic secure MAC addresses are stored only in a switch’s CAM table
and not in the running configuration.
Upon violation of the number of MAC addresses per port, you can configure violation
rules in one of following three ways:
■ Protect: When the switch port reaches its configured maximum number of secure
MAC addresses, it starts dropping frames with an unknown source MAC address.
■ Restrict: Similar to the protect option, the major difference being that the restrict
option can send an SNMP trap and a syslog message. It increments the violation
counter when a port security violation occurs.
■ Shutdown: After a port security violation occurs, the port is shut down and put in
err-disable state. This option also allows generation of the SNMP and syslog notifi-
cations, identical to the restrict option, and it will also increment a violation counter.

Example 5-1 illustrates enabling port security on a Cisco Catalyst switch for interface
FastEthernet 0/10 where the maximum number of MAC addresses is set to 3 on this
particular interface, and the port, upon exceeding the maximum count, will be put in err-
disable mode (shut down). The mac-address command is used to set a static MAC and
remember the MAC addresses connected to it (sticky).
Example 5-1 Cisco Catalyst Switch Port Security Configuration
UCSWITCH(config)# interface FastEthernet 0/10

UCSWITCH(config-if)# switchport port-security
UCSWITCH(config-if)# switchport port-security maximum 3
UCSWITCH(config-if)# switchport port-security violation shutdown
UCSWITCH(config-if)# switchport port-security mac-address 10BD.18DC.97F5
UCSWITCH(config-if)# switchport port-security mac-address sticky
DHCP Snooping
DHCP spoofing is used to launch Man-In-The-Middle (MITM), reconnaissance, and DoS
attacks. In the DHCP spoofing attack, the attacker enables a rogue DHCP server on a
network. When an endpoint (Cisco Unified IP Phone or softphone) sends a broadcast
request for the DHCP configuration information, the rogue DHCP server responds before
the original DHCP, thereby assigning the attacker-defined IP configuration information.
DHCP snooping is a Cisco Catalyst switch feature that helps prevent DHCP spoofing
attacks by enabling the switch ports to be set as either trusted (DHCP server-facing
interface) or untrusted (user facing). Trusted switch ports can send DHCP requests and
acknowledgements, whereas untrusted ports can only forward DHCP requests. DHCP
snooping enables the switch to build a DHCP binding table that maps a client MAC
address, IP address, VLAN, and port ID. Example 5-2 outlines DHCP snooping configu-
ration where FastEthernet 0/10 is set to trusted and FastEthernet 0/20 is set to untrusted.
Example 5-2 DHCP Snooping Configuration
UCSWITCH(config)# ip dhcp snooping VLAN 200 201

UCSWITCH(config)# no ip dhcp snooping information option
UCSWITCH(config)# ip dhcp snooping
!
UCSWITCH(config-if)# ip dhcp snooping trust
!
UCSWITCH(config-if)# no ip dhcp snooping trust
UCSWITCH(config-if)# ip dhcp snooping limit
DHCP snooping is also used for Dynamic ARP Inspection (DAI), as discussed later in this
chapter.

Root Guard and BPDU Guard

When a Cisco switch boots up, Spanning Tree Protocol (STP) identifies one switch as a
root bridge. STP uses bridge protocol data units (BPDU) to maintain a loop-free topol-
ogy by blocking redundant paths between switches. An attacker can send spoofed BPDU
packets to imitate a root bridge, thereby causing a reconvergence of the network traffic.
The attacker can capture traffic, launch DoS attacks, or initiate MITM attacks. BPDU
guard and Root Guard help prevent the DoS or MITM attacks originating as a result of
STP manipulation. BPDU Guard helps stop STP manipulation by enabling port(s) that
don’t accept any BPDUs. Root Guard ensures that when the root (or root bridge) is elect-
ed, a new BPDU on a designated port isn’t entertained.
The following is a configuration of BPDU Guard and Root Guard for thwarting STP
manipulation:
UCSWITCH(config)# spanning-tree portfast bpduguard
UCSWITCH(config)# spanning-tree guard root
Dynamic ARP Inspection

An attacker can poison the Address Resolution Protocol (ARP) table. The intent is to
conceal the identity so that the attacker’s switch/PC becomes the default gateway for
the telephony subnet. ARP poisoning can be implemented by replying to and poison-
ing the network so that the attacker’s MAC address seems to be mapped to the default
gateway IP address of the endpoints. An ARP attack can be mitigated by implementing
Dynamic ARP Inspection (DAI), wherein the switch checks the IP/MAC mappings in the
DHCP snooping binding table, thereby establishing the authenticity of packets before
forwarding the packets to the destination. DAI drops all ARP packets that do not pass the
inspection process. Example 5-3 outlines the process to enable DAI on a global and per-
interface basis.
Example 5-3 DAI Interface-Specific and Global Setup
UCSWITCH(config)# ip arp inspection vlan 300

!
UCSWITCH(config-if)# ip arp inspection trust
802.1x
802.1x is a standard set by the IEEE 802.1 working group. It’s a framework designed
to address and provide port-based access control using authentication, primarily using
Extensible Authentication Protocol (EAP) as the key protocol. 802.1x is a Layer 2 proto-
col for transporting authentication messages (EAP) between a supplicant (user/endpoint/
PC) and an authenticator (switch or access point) with an (optional) authentication server

(RADIUS) at the back end to authenticate the supplicant. For wired supplicants, EAP
over LAN (EAPoL) is used, and for wireless supplicants, EAP over Wireless (EAPoW) is
used. Figure 5-1 shows 802.1x via EAPoL and EAPoW for wired and wireless supplicants,
respectively, to a RADIUS (Cisco TACACS+) server.
Wireless AP RADIUS/TACACS+ LAN Switch

(Authenticator) (Authentication Server) (Authenticator)
EAPoL 802.1Q
EAPoW
PVID VVID
Wireless Client Wired Client IP Phone

(Supplicant) (Supplicant) (Supplicant)
Figure 5-1 802.1x in Cisco Collaboration Networks
Multidomain Authentication (MDA) helps define two domains on the same physical
switch port: Voice VLAN Identifier (VVID) and Port VLAN Identifier (PVID). The 802.1x
process for voice using an EAPoL and MDA approach is shown in the following steps:
Step 1. A Cisco Unified IP Phone learns VVID from Cisco Discovery Protocol (CDP).
Third-party phones use Link Layer Discovery Protocol (LLDP). 802.1x times
out.
Step 2. The switch initiates MAC Authentication Bypass (MAB).
Step 3. Cisco TACACS+ (RADIUS server) returns Access-Accept with the IP Phone’s
vendor-specific attribute (VSA).
Step 4. IP Phone traffic is initially allowed on either VLAN until it sends an 802.1Q
tagged packet. Then only voice VLAN is allowed for the IP Phone.
Step 5. The daisy-chained PC (connected to the PC port on the IP Phone) authenti-

cates using 802.1x or MAB. PC traffic is allowed on the data VLAN only.
Example 5-4 demonstrates the switch configuration for MDA.
Example 5-4 MDA Setup

UCSWITCH(config-if)# switchport mode access
UCSWITCH(config-if)# switchport access vlan 100
UCSWITCH(config-if)# switchport voice vlan 200
UCSWITCH(config-if)# spanning-tree portfast
UCSWITCH(config-if)# authentication event fail action next-method

UCSWITCH(config-if)# authentication host-mode multi-domain

UCSWITCH(config-if)# authentication order dot1x mab
UCSWITCH(config-if)# dot1x pae authenticator
UCSWITCH(config-if)# authentication port-control auto
UCSWITCH(config-if)# dot1x timeout tx-period 10
UCSWITCH(config-if)# dot1x max-req 2
UCSWITCH(config-if)# mab
Layer 3 Security
At Layer 3 of the OSI model, the following security mechanisms help restrain attacks
from within and outside of a network:
■ Deploying RFC 2827 filtering, uRPF, and IP source guard (prevents IP spoofing)
■ Using routing protocol authentication
■ Disabling unnecessary Cisco IOS services (hardening)
RFC 2827 Filtering

To prevent IP spoofing attacks emerging from outside your network, RFC 1918 addresses
should be filtered using IP access control lists (ACL). These addresses include the following:
■ 10.0.0.0/8
■ 172.16.0.0/12
■ 192.168.0.0/16
■ 0.0.0.0/8
■ 127.0.0.0/8
■ 169.254.0.0
In addition to these addresses, the multicast range of 224.0.0.0/4, 239.0.0.0/8, and

240.0.0.0/5 and the broadcast address of 255.255.255.255 should be blocked.
IP Source Guard
The IP source guard feature can be enabled on untrusted switch ports. This feature
blocks all IP traffic initially, except for DHCP packets captured by the DHCP snooping
process. When a client receives a valid IP address from the trusted DHCP server, a port
ACL (PACL) is applied to the port. This restricts the traffic only from known client source
IP addresses configured in the binding, disregarding any other IP traffic. The follow-
ing configuration enables IP source guard on the FastEthernet 0/10 interface of a Cisco
Catalyst switch:

UCSwitch(config)# interface FastEthernet 0/10

UCSwitch(config-if)# ip verify source
Unicast Reverse Path Forwarding

Unicast Reverse Path Forwarding (uRPF) is a Cisco IOS feature that can be employed on
Cisco IOS routers to prevent attempts to send packets with spoofed source IP addresses.
The uRPF feature looks for the source IP address of a packet arriving on the inbound
interface of a router in its routing table. If the source IP address exists in the network
behind the router, and the routing table contains an entry for the same, the packet is
allowed. uRPF requires Cisco Express Forwarding (CEF) to be enabled. The following
snippet outlines the configuration of uRPF on FastEthernet 1/1 of a Cisco IOS router:
UCRouter(config-if)# ip verify unicast reverse-path
Routing Protocols Security

An attacker can attempt to manipulate the routing tables of routers by injecting his own
malicious routes, thereby causing the router to send all voice and data network traffic to
his own PC/router or drop the traffic altogether. To protect against such an attack, rout-
ing protocols should be secured by using authentication via plain-text authentication or
MD5. MD5-based authentication creates a hash value from the key and sends it to the
neighbors, where the neighboring router recalculates the hash value with the configured
key to verify the integrity of the message. MD5 authentication is supported with the fol-
lowing routing protocols:
■ RIPv2
■ EIGRP
■ OSPF
■ BGP4
Router Hardening
Cisco IOS routers can be hardened by disabling services such as finger, TCP and UDP
small servers, BootP, and Proxy ARP.
(Firewall) Security for Layers 4 Through 7

Firewalls such as Cisco Adaptive Security Appliance (ASA) enable protection of a Cisco
Collaboration network by filtering traffic at Layer 3, Layer 4, and higher layers. In an
ideal design, the firewall intercepts the traffic coming from or going to remote sites and
the Internet to or from the internal network (data center) and consequently filters based
on certain criteria such as source/destination based on subnet, inspection, or ports.

Firewall Traversal Mechanisms 153
Cisco ASA works in routed mode, transparent mode, or multiple-context mode. In routed
mode Cisco ASA appears as a hop in the network—that is, it works at Layer 3. Routed
mode supports multiple interfaces and practically all Cisco Collaboration services/appli-
cations. For Cisco Collaboration network deployments, Cisco ASA should be configured
in a single (default) context as a routed firewall.
Cisco ASA, on the other hand, also works in transparent mode where it is a Layer 2 fire-
wall that acts like a bump in the wire. In transparent mode, Cisco ASA has some limita-
tions pertinent to voice and video traffic:
■ Limited to the use of two traffic forwarding interfaces
■ Lack of support for QoS or Network Address Translation (NAT)
■ Lack of support for multicast routing
■ No site-to-site VPN (except for management of the firewall itself)
Cisco ASA also supports multiple-context mode, also known as multimode. In multiple-
context mode, the firewall is regarded as multiple separate virtual firewalls on the same
physical hardware. However, multiple-mode also has some feature limitations (in addition
to those defined for transparent firewall):
■ Lack of support for VPN remote-access services
■ Lack of support for Phone Proxy
■ Lack of support for dynamic routing
Firewall Traversal Mechanisms

Any firewall, including Cisco ASA or an application layer gateway (ALG), is expected to
provide certain mechanisms so that voice and video traffic can traverse through the fire-
wall/ALG to reach the destination. Firewall traversal is provided in multiple ways, includ-
ing NAT traversal, IPsec tunnels, IP ACLs, or port-based ACLs.
NAT Traversal
Almost every firewall (including Cisco ASA) provides NAT services to enable manipulat-
ing the IP address or port number, or both, for traffic going out or coming into a net-
work. To ensure that voice traffic is unaltered by NAT, either it should be exempted from
NAT or appropriate inspection mechanisms should be applied to enable the firewall to
look at the contents of the packets. NAT control can be turned off on Cisco ASA, there-
by allowing packets to traverse Cisco ASA unaltered. Also, use of RFC 1918 addresses
on internal servers is recommended, where possible, such that globally routable (public)
network addresses do not pass through the firewall using a NAT mechanism. NAT/ALG
firewalls/devices can inspect signaling in normal mode (that is, TCP/UDP-based

signaling), but with encrypted signaling leveraging Transport Layer Security (TLS), a
NAT/ALG-aware firewall is unable to look into the content of packets.
IPsec Tunnels
Site-to-site or remote-access VPN IPsec tunnels can be used to enable NAT exemption.
Moreover, if the VPN gateway is placed behind a firewall, the firewall is unable to inspect
or modify the contents of the packet within the tunnel. This is an ideal solution when a
corporate firewall is required to filter all traffic except voice/video traffic.
IP-Based ACLs
Traffic from the Internet, remote sites, telecommuters, and remote workers can be filtered
based on IP ACLs. This allows a modest degree of control on the traffic that traverses
through the firewall. In such cases, inspections may still be required to handle voice and
video signaling and media traffic.
Port-Based ACLs
Synonymous to IP-based ACLs, port-based ACLs can be used for filtering traffic from/
to an external network to the data center. Port-based ACLs give an administrator or a
security engineer a greater degree of control and allow for the least permissive policy.
However, port-based ACLs are also the most tedious to configure because every port for
a Cisco Collaboration protocol or service needs to be looked at and allowed or denied as
per the organization’s policy.
In case of voice and video signaling and media traffic, quite a few protocols and ports
must be permitted to ensure that the Collaboration services operate appropriately. As
discussed in Chapter 3, “Telephony Standards and Protocols,” the most commonly used
voice and video protocols include SCCP, MGCP, H.323, SIP, RTP, and RTCP.
Moreover, there are other protocols that are used for administration and integration of
voice services, such as SSH, TAPI/JTAPI, HTTP, HTTPS, TFTP, DNS, and LDAP.
For a complete list of TCP/UDP ports that are required for firewall traversal for
CUCM, refer to “Cisco Unified Communications Manager TCP and UDP Port Usage”
at www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/port/9_1_1/CUCM_BK_
T2CA6EDE_00_tcp-port-usage-guide-91/CUCM_BK_T2CA6EDE_00_tcp-port-usage-
guide-91_chapter_01.html.
For video communications, Cisco Video Communications Server (VCS) can be deployed
as Cisco TelePresence VCS Control for use within an enterprise and as the Cisco VCS
Expressway for communication with external entities. VCS Expressway enables business-
to-business (B2B) communications and includes the features of the Cisco VCS Control
with highly secure firewall traversal capability. VCS Expressway can be implemented
either on the inside (secure zone) or in the demilitarized zone (DMZ). VCS Expressway
firewall traversal is shown in Figure 5-2.

Cisco ASA Proxy Features 155
Telepresence System
Data Center
Firewall Firewall SIP
SIP Video IP Phone
SIP
Internet
SIP SIP
SIP
CUCM Cluster VCS Control VCS Expressway Telepresence System

Video IP Phone
Figure 5-2 VCS Expressway Firewall Traversal
It’s important to note that SIP and H.323 protocol inspection on the firewall must be dis-
abled. Instead, the firewall should be configured for traversal leveraging requisite ports.
For details on the ports that are required for firewall traversal, refer to the deployment
guide Cisco VCS IP Port Usage for Firewall Traversal (PDF file) at www.cisco.com/c/
dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-1/Cisco-VCS-IP-Port-
Usage-for-Firewall-Traversal-Deployment-Guide-X8-1.pdf.
Cisco ASA Proxy Features

Cisco ASA Firewall allows signaling traffic decryption and re-encryption by virtue of
the TLS Proxy feature, which enables the inspection engine to look into the packet con-
tents. This alleviates the issue of NAT/ALG-aware firewalls not being able to look into the
encrypted (SRTP/TLS) voice and video streams. Cisco ASA supports two major proxy
modes:
■ TLS Proxy: Enables Cisco ASA to decrypt and inspect encrypted signaling before
Cisco ASA re-encrypts the signaling to the destination, thereby ensuring that all traf-
fic passing through the firewall is compliant with the organization’s security policy.
TLS Proxy requires encrypted endpoints on the outside and inside of an ASA-
brokered network, which implies that the CUCM cluster within the organization is
in mixed mode (a mixed-mode cluster is in secure mode, as explained later in this
chapter).
■ Phone Proxy: Secures remote access for encrypted Cisco Unified IP Phone end-
points and VLAN traversal for Cisco softphones. It enables a remote user to plug in
an IP Phone directly to a hotel/home network and make secure calls through the cen-
tralized CUCM cluster via the Internet. Moreover, unlike TLS Proxy, Phone Proxy
doesn’t require internal endpoints to be encrypted; hence, the CUCM cluster within
an organization’s data center can be in unsecure mode or mixed mode.
Cisco ASA Phone Proxy and TLS Proxy services are not supported with CUCM version
9.x. Instead, Cisco VPN Phone is recommended for secure remote endpoint connection
and traversal at the enterprise-edge firewall. Also, as an alternative to the ASA Phone
Proxy feature, Cisco Unified Border Element (CUBE) supports Phone Proxy with B2BUA
line-side support for CUCM. Phone Proxy is supported with Cisco IOS version 15.3(3)
M1 and later on the Cisco Integrated Services Routers Generation 2 (ISR G2) platform. It
allows organizations to have phones on the Internet connected to a CUBE at the edge of
the enterprise and securely set up signaling/media with phones in the enterprise premises.

Cisco VPN Phone

Cisco VPN Phone is a Cisco Unified IP Phone–based VPN solution that extends the
reach of your Cisco Collaboration solution to outside the logical perimeter of your orga-
nization. It enables telecommuters, remote workers, and branch office workers to leverage
corporate voice and video resources via a phone-based Secure Sockets Layer (SSL) VPN
client. Cisco VPN Phone enables remote connectivity with a CUCM cluster for signaling
via SSL on the Internet and RTP with an IP Phone within the enterprise premises without
extra hardware, as shown in Figure 5-3.
SSL Session
SCCP Data Center SCCP (AnyConnect)
SOHO, Telecommuter,
Enterprise Premises
Hotel Room
Internet
Cisco Unified IP Cisco Unified IP

Phone CUCM Cluster Cisco ASA Phone
RTP
Figure 5-3 Cisco VPN Phone
Cisco VPN Phone is supported on 7942G, 7945G, 7962G, 7965G, 7975G, and 99xx
series as well as 89xx series Cisco Unified IP Phones. For a complete list of supported
IP Phones in a certain CUCM version, go to Cisco Unified CM Administration and
choose Cisco Unified Reporting > System Reports > Unified CM Phone Feature List >
Generate a New Report > Feature: Virtual Private Network Client.
The minimum requirements for implementing Cisco VPN Phone are as follows:
■ IP Phone SCCP firmware version 9.0(2)SR1S or later
■ CUCM 8.0.1 or later
■ Cisco ASA IOS 8.0.4 or later
■ AnyConnect VPN Pkg 2.4.1012

■ AnyConnect premium license and AnyConnect for Cisco VPN Phone license
required for Cisco ASA
Example 5-5 outlines the configuration on Cisco ASA to support Cisco VPN Phone.
Example 5-5 Cisco ASA VPN Phone Configuration
UCASA(config)# group-policy GroupPolicy1 attributes

UCASA(config-group-policy)# vpn-tunnel-protocol WebVPN
!
UCASA(config)# ip local pool VPN-Phone 10.10.1.200-10.10.1.254 mask 255.255.255.0
!

Application Layer Security 157
UCASA(config)# tunnel-group VPNPhone type remote-access

!
UCASA(config)# tunnel-group VPNPhone webvpn-attributes
UCASA(config-tunnel-webvpn)# group-url https://UCASA.org.corp/PhoneVPN enable
!
UCASA(config)# tunnel-group VPNPhone general-attributes
UCASA(config-tunnel-general)# address-pool VPN-Phone
UCASA(config-tunnel-general)# default-group-policy GroupPolicy1
!
UCASA(config)# webvpn
UCASA(config-webvpn)# enable outside
UCASA(config-webvpn)# anyconnect image disk0:/anyconnect-win-3.1.00495-k9.pkg 1
UCASA(config-webvpn)# anyconnect enable
UCASA(config-webvpn)# tunnel-group-list enable
The following steps summarize the configuration required on CUCM to support the
Cisco VPN Phone feature:
Step 1. Upload VPN certificates from Cisco ASA to CUCM by going to Cisco
Unified CM Operating System Administration and choosing Security >
Certificate Management. Upload the Cisco ASA self-signed certificate as
Phone-VPN-Trust certificate.
Step 2. Configure the VPN gateway by browsing to Cisco Unified CM Administrator

and choosing Advanced Features > VPN > VPN Gateway.
Step 3. Create a VPN group under Advanced Features > VPN > VPN Group.
Step 4. Configure the VPN Profile under Advanced Features > VPN > VPN Profile.
Step 5. Assign the VPN group and profile to the Common Phone Profile by going to
Device > Device Settings > Common Phone Profile.
Step 6. Configure the Cisco Unified IP Phone with a TFTP server manually and regis-
ter the IP Phone internally to test and ensure that VPN works, before you give
it to a user.
Step 7. On the Cisco Unified IP Phone, go to Settings > Security Configuration

> VPN Configuration. Enable VPN and use your credentials/certificate to
establish a VPN connection.
Application Layer Security

The application layer is the layer at which Cisco Collaboration applications interact with
the network, other applications, and endpoints. CUCM, Cisco Unity Connection, and
Cisco Unified IM Presence are examples of applications that leverage the OSI model’s
application layer’s services. The following sections address the security mechanisms
offered by Cisco Unified CM.

CUCM Security By Default

Cisco has introduced the concept of Security By Default (SBD) from CUCM version 8.0
onward. SBD mandates that every endpoint obtain an Identity Trust List (ITL) file, which
is a leaner version of a Certificate Trust List (CTL) file.
Trust Verification Service (TVS) is the core component of the SBD feature. TVS runs on
all CUCM servers in the cluster and authenticates certificates on behalf of Cisco Unified
IP Phones. TVS certificates, along with a few other key certificates, are bundled in the
ITL file. Security By Default provides three basic functions for supported Cisco Unified
IP Phones:
■ Default authentication of the TFTP downloaded files (configuration, locale, and

so on)
■ Optional encryption of the TFTP configuration files
■ Certificate verification for the phone-initiated HTTPS connections using a remote

certificate trust store on CUCM and TVS
ITL is similar to CTL, but ITL does not need any security feature to be enabled explicitly.
Moreover, ITL is not a replacement for CTL; it is for initial security so that endpoints
can trust the CUCM. To encrypt signaling or media, CTL is still required. The ITL file is
created automatically when the cluster is installed. The CUCM TFTP server’s private key
is used to sign the ITL file. When a CUCM server/cluster is in non-secure mode, the ITL
file is downloaded on every supported Cisco Unified IP Phone; however, when a CUCM
server/cluster is in mixed mode, the CTL file is downloaded followed by the ITL file. The
contents of an ITL file can be viewed by using the CUCM OS CLI command
admin: show itl.
CUCM Security Modes

CUCM provides two security modes:
■ Non-secure mode (default mode)
■ Mixed mode (secure mode)
Non-secure mode is the default mode when a CUCM cluster (or server) is installed fresh.
In this mode, CUCM cannot provide secure signaling or media services. To enable secure
mode on a CUCM server/cluster, the Certificate Authority Proxy Function (CAPF) ser-
vice must be enabled on the publisher and the Certificate Trust List (CTL) service must
be enabled on the publisher and subscribers. Then the cluster can be changed from non-
secure mode to mixed mode. The reason it is known as mixed mode is that in this mode
CUCM can support both secured and non-secured endpoints. For endpoint security,
Transport Layer Security (TLS) is used for signaling and Secure RTP (SRTP) is used for
media.
To convert a CUCM cluster into mixed mode, follow these steps:

CUCM Security Modes 159
Step 1. In Cisco Unified CM Administration, choose Serviceability > Tools >

Service Activation and enable CAPF and CTL services on the CUCM pub-
lisher and CTL service on all CUCM subscribers.
Step 2. Restart CCM and TFTP services on every node where these services are
enabled.
Step 3. Return to CUCM Administration and choose Application > Plugins to down-
load and install the CTL Client plug-in for Windows.
Step 4. After the CTL client is installed, log in with the IP address of the publisher
and the CUCMAdministrator credentials. Follow the installation prompts.
Step 5. Click the Set Cisco Unified CallManager Cluster to Mixed Mode radio
button.
Step 6. Insert the USB eToken when prompted by the CTL client wizard, and
click OK.
Step 7. The CTL client wizard prompts for a second eToken, removes the first eToken,
and inserts the second USB eToken. Click OK. Click Finish. When prompted
for the password for the eToken, enter the default password Cisco123.
Step 8. After the CTL client wizard completes signing certificates on each server in
the cluster, it reminds you to restart the CCM and TFTP services on which-
ever servers they are configured. Click Done. Restart the CCM and TFTP
services on all servers where they are enabled and activated.
You can verify the cluster’s conversion to mixed mode by going to System > Enterprise
Parameters. The parameter Cluster Security Mode should be 1, which indicates that the
cluster is running in mixed mode.
CTL Client and CTL File

The CTL client, as discussed earlier, is a plug-in that can be downloaded from the CUCM
Administration GUI and that runs on a Windows PC to convert a CUCM cluster from
non-secure mode to mixed mode. A CTL client signs various certificates. A CTL file con-
tains the following:
■ Server Certificate
■ Public Key
■ Serial Number
■ Signature
■ Issuer Name
■ Subject Name
■ Server Function
005_9780133845969_ch05.indd 159 6/25/14 11:07 AM

■ DNS name
■ IP address for each server
A CTL file (downloaded to Cisco Unified IP Phones and softclients) consists of the fol-
lowing entries (server entries or security tokens):
■ CUCM
■ Cisco TFTP
■ Alternate Cisco TFTP Server (if any)
■ CAPF
■ System Administrator Security Token (SAST)
■ Cisco ASA Firewall
Figure 5-4 shows the contents of a typical CTL file.
CTL Client
CUCM Trusted TFTP Trusted

Certificate Certificate
CTL Client Trusted CAPF Trusted

CA Trusted Cisco ASA Trusted

Figure 5-4 CTL File Contents

SRTP and TLS 161
The contents of a CTL file can be viewed by issuing the CUCM OS CLI command
admin: show ctl.
Cisco Unified IP Phone Certificates

Cisco Unified IP Phone certificates come in two flavors:
■ Manufacturer Installed Certificate (MIC)
■ Locally Significant Certificate (LSC)
Cisco manufacturing is the source for the MIC. Cisco installs the MIC in nonerasable,
nonvolatile memory on a Cisco Unified IP Phone. It is available in all new phone mod-
els, and the root Certificate Authority (CA) is Cisco Certificate Authority. On the other
hand, the CAPF service is the source (root) of the LSC, which must be installed by the
UC administrator in erasable phone memory. The LSC can be signed by an organization’s
internal CA or an external trusted CA. Figure 5-5 depicts the difference between the MIC
and the LSC.
Cisco Manufacturing CA Cisco CUCM CAPF Server
MIC LSC
Cisco CAPF
(Cisco CA (CAPF
Manufacturing TLS
Public Key) Public Key)
Cisco Unified IP Phone Cisco Unified IP Phone
Figure 5-5 Cisco MIC vs. LSC
SRTP and TLS

After the endpoints (IP Phones) are secure, CUCM can establish TLS with the endpoints,
and the endpoints can negotiate SRTP among themselves. Cisco voice gateways also sup-
port encryption as follows:
■ MGCP gateway with SRTP package and IPsec tunnel to CUCM (or default gateway
device for CUCM). IPsec is for protection of signaling, which in the case of MGCP
is in clear text by default.

■ H.323 gateway with certificates exchanged with CUCM for SRTP and IPsec for pro-
tecting signaling.
■ SIP gateway with secure SIP trunk leveraging TLS to protect signaling.
Figure 5-6 gives insight to TLS signaling and SRTP media flow among CUCM, endpoints,
and gateways.
CUCM Voice Gateway
Secure SIP V
Trunk, IPsec for
MGCP/H.323
SCCPS or SIPS SRTP (Media)

(TLS Signaling)
IP Phone A SRTP (Media) IP Phone B
Figure 5-6 TLS and SRTP Call Flow Between CUCM, Endpoints, and Gateways
Preventing Toll Fraud

Toll fraud is a chronic issue that has impacted the PSTN and IP worlds alike. Toll fraud
can be summarized as the illicit use of a telephony system to make long-distance (inter-
national) calls without any accountability. To prevent toll fraud in a Cisco Collaboration
network, you can employ various tools:
■ CUCM class of service (CoS)
■ Voice gateway toll fraud prevention application
■ Voice gateway class of restriction (CoR)
■ Cisco Unity Connection restriction rules
CUCM Class of Service

CUCM CoS can be enabled via multiple tools, listed and described in Table 5-2.

Table 5-2 CUCM CoS Components

CUCM CoS Component Description
Partitions and calling search Provide segmentation and control to the number that
spaces (CSS) can be called, or vice versa. As a leading practice recom-
mendation, either disable Call Forward All or limit it to
an extension within your Collaboration network. Call
Forward Busy and Call Forward No Answer should also
be limited to internal partitions only. For phones with
extension mobility, a logged-out CSS should be restrict-
ed to internal and emergency partitions only.
Time-of-Day routing Allows certain partitions to be active during a preset
time period during a day and after this period; these par-
titions become inactive automatically. Helps restrain calls
made to national and international numbers after busi-
ness hours. See Chapter 4 for more details.
Forced Authorization Code (FAC) Used to control the access to international and long dis-
and Client Matter Code (CMC) tance calls. FAC/CMC forces a user to enter a predeter-
mined code to proceed with a call hitting a route pattern
that has FAC enabled. Both FAC- and CMC-processed
calls are logged to CUCM Call Detail Records (CDR).
Block off-net to off-net transfers Allows/disallows off-net to off-net transfers based on a
clusterwide service parameter Block OffNet to OffNet
Transfer. When enabled, CUCM blocks any off-net to
off-net call transfers from endpoints, thereby minimizing
the risk of anyone misusing the feature for transferring
local PSTN calls to international destinations.
Ad hoc conference restriction Ad hoc conference calls can be dropped when the origi-
nator hangs up. This is achieved by setting the Drop Ad
Hoc Conference service parameter to When Conference
Controller Leaves under Clusterwide Parameters
(Features-General) area. This ensures that the other
parties (such as external users) cannot initiate a call to
another external number.
Route filters Can be deployed to filter any unwanted area codes as
well as calls to known paid/premium numbers.
Cisco Voice Gateway Toll-Fraud Prevention Application

Cisco IOS voice gateways with Cisco IOS 15.1(2)T and later come (by default) enabled
with an application that helps stops toll-fraud attempts. This new feature is known as Call
Source Authentication, which is the default behavior of a toll-fraud prevention feature.
005_9780133845969_ch05.indd 163 6/25/14 11:07 AM

By virtue of this feature, the router automatically adds the destination IP address(es)
defined as an IPv4 target in a VoIP dial peer to the trusted source list. This feature is con-
figurable via the global voice service voip command:
UCRouter(config)# voice service voip
UCRouter(conf-voi-serv)# ip address trusted authenticate
Voice Gateway Class of Restriction

Class of restriction (CoR) is analogous to CUCM partitions and CSSs. CoR is implement-
ed at either dialpeers or ephone-dns on a voice gateway. The dial-peer cor custom com-
mand is equivalent to creating a CUCM partition, whereas dial-peer cor list is equivalent
to creating a CUCM CSS. CoR can be implemented on SIP and H.323 gateways and
while a gateway is in SRST mode. Example 5-6 illustrates CoR configuration on a Cisco
IOS gateway.
Example 5-6 Cisco IOS Gateway CoR Configuration
UCRouter(config)# dial-peer cor custom

UCRouter(config-dp-cor)# name emergency
UCRouter(config-dp-cor)# name local
UCRouter(config-dp-cor)# name national
!
UCRouter(config)# dial-peer cor list emergency
UCRouter(config-dp-corlist)# member emergency
!
UCRouter(config)# dial-peer cor list local
UCRouter(config-dp-corlist)# member local
!
UCRouter(config)# dial-peer cor list national
UCRouter(config-dp-corlist)# member local
UCRouter(config-dp-corlist)# member national
!
UCRouter(config)# dial-peer voice 911 pots
UCRouter(config-dial-peer)# corlist outgoing emergency
<output-omitted for brevity>
!
UCRouter(config-dial-peer)# corlist outgoing local
!


UCRouter(config-dial-peer)# corlist outgoing national
Cisco Unity Connection Restriction Rules

Cisco Unity Connection can transfer calls from voice mail to the PSTN. This feature can
be exploited for conducting toll fraud. To ensure that your Cisco Unity Connection sys-
tem denies outgoing calls and/or transfers, configuring the following restriction rules is
recommended:
■ Create a non-default call-restriction rule for calls and call transfers that denies every-
thing starting with the outside (PSTN) access code; for example, deny 9* transfers
from Cisco Unity Connection to PSTN in the United States and 0* in Europe.
■ Add restriction table patterns to match appropriate trunk access codes for all phone
system integrations.
■ Restrict the numbers that can be used for system transfers and for Audio Messaging
Interchange Specification (AMIS) message delivery.


Chapter 6
Cisco Unity Connection
Cisco Unity Connection (CUC) is an enterprise-grade voice messaging solution that

provides multiple interfaces for end users to manage their voice mails via Telephony
User Interface (TUI), user GUI, and Cisco Unity ViewMail for Outlook (VMO). From
an administrative point of view, interfaces range from CUC inbox to single inbox to
IMAP integrations. CUC is a highly scalable and redundant solution that is ideal for any
midsized to large enterprise environment. This chapter covers CUC integration with
Cisco Unified Communications Manager (CUCM) and CUCM Express (CUCME), CUC
features, and CUC networking.
Cisco Unity Connection High Availability

CUC servers can be deployed in an active-active cluster model, with a publisher/
subscriber configuration so that both servers can concurrently accept voicemail calls,
place outbound calls, and accept incoming administrative/user HTTP requests. If one
server goes down, the other active server preserves the majority of end-user functionality,
including voice calls and HTTP requests, but with lower port capacity. Similar to CUCM,
the publisher database has full read/write access, whereas the subscriber database is read
access only.
An active-active cluster pair supports up to 500 ports per CUC cluster or 250 ports per
server, and a single CUC cluster supports up to 20,000 voicemail users (subscribers). In
a CUC cluster, under ideal circumstances, the CUC publisher should handle the majority
of administration traffic, such as CUC administration tasks (GUI access, bulk administra-
tion, and so on), and client traffic, such as IMAP and HTTP/HTTPS. The CUC subscriber
should handle the majority of call processing traffic from Session Initiation Protocol
(SIP) trunk(s) and Skinny Call Control Protocol (SCCP) ports.
A CUC cluster can be implemented on the same site (for example, both servers are at
the same physical site) or split across a WAN. Clustering over a WAN has some stringent
requirements:

168 Chapter 6: Cisco Unity Connection
■ The maximum round-trip latency must be no more than 150 ms.
■ Firewalls must not block the required ports. For a list of all ports required by CUC
9.1, refer to www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/security/
guide/9xcucsec010.html.
■ Depending on the number of voice messaging ports on each CUC server, guaranteed
bandwidth must be available at all times with no steady-state congestion:
■ For 50 voice messaging ports on each server: 7 Mbps
Cisco Unity Connection Integration with CUCM and

CUCME
CUC supports SCCP voicemail and SIP voicemail integration with CUCM and CUCME,
as shown in Figure 6-1.
CUCM Cisco
Cluster Unified
CME
CUC
Cluster
WAN
CUCM
Cluster
Cisco
Unified
SCCP Voicemail Integration CME
SIP Voicemail Integration
Figure 6-1 CUC SCCP Voicemail and SIP Voicemail Integration with CUCM and
CUCME

The following sections cover these CUC integration scenarios:
■ CUC SCCP voicemail integration with CUCM
■ CUC SIP voicemail integration with CUCM
■ CUC SCCP voicemail integration with CUCME
■ CUC SIP voicemail integration with CUCME
Cisco Unity Connection SCCP Voicemail Integration with CUCM

CUC SCCP voicemail integration with CUCM leverages SCCP using SCCP voicemail
ports and a call-hunting mechanism (line group, hunt list, hunt pilot). The following steps
describe how to integrate SCCP voicemail between CUC and CUCM:
Step 1. Go to Cisco Unified CM Administration, choose Advanced Features > Voice

Mail > Cisco Voice Mail Port Wizard, click Create a New Cisco Voice Mail
Server, and add ports to it. Click Next.
Step 2. Type the SCCP port prefix and click Next.
Step 3. On the Cisco Voice Mail Ports page, define the number of ports to be added
(should match the licensed number of ports on CUC) and click Next.
Step 4. On the Cisco Voice Mail Device Information page, fill in the fields such as
Description, Device Pool, Calling Search Space, Location, Device Security
Mode (must match with CUC port security mode), and Use Trusted Relay
Point related information. Click Next.
Step 5. On the Cisco Voice Mail Directory Numbers page, configure the directory
number (DN) details such as Beginning Directory Number, Partition, Calling
Search Space, AAR Group, Internal Caller ID Display, Internal Caller ID
Display (ASCII Format), and External Number Mask. Each DN will increment
based upon the number of ports defined earlier. Click Next.
Step 6. On next wizard page, select the option Yes. Add directory numbers to a new
Line Group and click Next.
Step 7. On the Line Group page, define the name of the line group. Click Next.
Step 8. Review the Confirmation page and ensure that all settings are as expected.
Click Finish. Figure 6-2 represents the Confirmation page with VM Port
Wizard settings.

Figure 6-2 CUCM Voicemail Port Wizard Confirmation Page
Step 9. Navigate to Advanced Features > Voice Mail > Message Waiting and click
Add New. Enter a number in the Message Waiting Number field, and then
click the On radio button for the Message Waiting Indicator option. Click
Save, and then click Add New. Enter a second number and select the Off
radio button. Click Save.
Step 10. Go to Advanced Features > Voice Mail > Voice Mail Pilot and click Add
New. Enter a number in the Voice Mail Pilot Number field and provide the
required details. Click Save.
Step 11. Navigate to Advanced Features > Voice Mail > Voice Mail Profile and click
Add New. Provide a Voice Mail Profile Name and other required details.
Select the Voice Mail Pilot configured in Step 10. Provide the Voice Mail Box
Mask per your organization’s requirements, and optionally check the check
box to make the Voice Mail Profile the default for the system (useful when
you have only one CUC system integrated with CUCM).
Step 12. Go to Call Routing > Route/Hunt > Hunt List and click Add New. Provide
the required details. Ensure that the Enable This Hunt List and For Voice
Mail Usage check boxes are checked. Assign the Line Group created earlier
(during the Voice Mail Port Wizard) to this Hunt List.
Step 13. Navigate to Call Routing > Route/Hunt > Hunt Pilot and click Add New.
Enter the Hunt Pilot Number (should match the Voice Mail Pilot Number) and
provide other required details. Select the Hunt List configured earlier.
Step 14. Go to the Cisco Unity Connection Administration page, choose Telephony
Integrations > Phone System, and click Add New. Provide a name for the
Phone System and define other required parameters.
006_9780133845969_ch06.indd 170 6/25/14 11:11 AM

Step 15. Choose Telephony Integrations > Port Group and click Add New. Ensure
that the phone system defined in Step 14 is chosen and select the method
of integration as SCCP. Provide other required parameters. Ensure that the
Device Name Prefix matches the one configured in CUCM, that the MWI On
and Off extensions also correspond, and define the primary CUCM server
address. (You can add a secondary CUCM server address by clicking Edit and
adding it.) It’s important to note that the primary and backup CUCM address-
es must match the order in which they are defined in the CUCM Group
assigned to the device pool used for voicemail ports.
Step 16. Choose Telephony Integrations > Port and click Add New. Define the num-
ber of ports (must match the number of SCCP ports configured in CUCM),
select the phone system and port group defined earlier, and choose a CUC
server (if using a CUC cluster, choose between publisher and subscriber).
Under Port Behavior, define the port behavior by checking the corresponding
check boxes that apply: Answer Calls, Perform Message Notification, Send
MWI Requests, or Allow TRAP Connections. (This can be changed later when
ports are added to CUC; the leading practice is to have 80 percent of ports
reserved for CUC incoming calls and 20 percent of ports reserved for outcall-
ing such as MWI, notifications, and TRAP.)
At this time, the CUC SCCP voicemail integration with CUCM is complete. A user can
press the Message button on an IP Phone (or call the VM pilot from an analog endpoint)
to access voice mail.
Cisco Unity Connection SIP Voicemail Integration with CUCM

CUC SIP voicemail integration with CUCM leverages SIP using a SIP trunk between
CUCM and CUC and route patterns to route calls from CUCM to CUC. The following
steps describe how to integrate SIP voicemail between CUC and CUCM:
Step 1. Go to Cisco Unified CM Administration and choose System > Security >
SIP Trunk Security Profile. Click Add New (or copy the existing Non Secure
SIP Trunk Security profile) and create a SIP trunk security profile just for
CUC voicemail integration. Provide the required details and ensure that the
Accept Out-of-Dialog REFER, Accept Unsolicited Notification, and Accept
Replaces Header check boxes are checked.
Step 2. Navigate to Device > Trunk and click Add New. Add a SIP trunk (as
explained in Chapter 4, “Cisco Unified Communications Manager”) without
any service type. Provide the required details such as trunk name, device
pool, destination (CUC) IP address, SIP trunk security profile (defined in Step
1), and so on. For integration with a CUC cluster, configure two SIP trunks,
with the first SIP trunk pointing to the CUC subscriber, followed by the sec-
ond SIP trunk pointing to the CUC publisher (the leading practice recommen-
dation is to send traffic to the CUC subscriber followed by the publisher).

Step 3. Go to Call Routing > Route/Hunt > Route Pattern and click Add New. Add
a route pattern pointing to the CUC Voicemail SIP Trunk configured in Step
2. Make sure that the DN of the route pattern matches the voicemail pilot
number and that any PSTN-relevant settings are disregarded, such as outside
dial tone, off-net classification, FAC, CMC, and so on. If using multiple SIP
trunks to the CUC subscriber and publisher, add a route group, with the two
trunks assigned to it, followed by a route list, and assign the route list to the
route pattern (see Chapter 4 for detailed information on route groups and
route lists).
Step 4. Add a new Voice Mail Pilot by browsing to Advanced Features > Voice Mail
> Voice Mail Pilot as described in the preceding section on SCCP voicemail
integration. For CUC configuration, follow the steps described in that sec-
tion, with the exception that, instead of defining the Port Group as SCCP,
define it as SIP. The next two sections cover CUC integration with CUCME.
Cisco Unity Connection SCCP Voicemail Integration with CUCME

CUCME can be integrated with Cisco Unity Connection using either SCCP or SIP. This
section focuses on CUCME SCCP voicemail integration with CUC. Example 6-1 shows
how to integrate CUCME with CUC using SCCP.
Example 6-1 CUCME SCCP Voicemail Integration with CUC
CMERouter(config)# telephony-service
CMERouter(config-telephony)# voicemail 7000
!
CMERouter(config)# ephone-dn 10
CMERouter(config-ephone-dn)# number 7710
CMERouter(config-ephone-dn)# mwi on
!
CMERouter(config-ephone-dn)# mwi off
!
CMERouter(config-ephone-dn)# name "VM-Port 1"
CMERouter(config-ephone-dn)# preference 0
CMERouter(config-ephone-dn)# no huntstop
!

!
!
CMERouter(config)# number 7000
CMERouter(config-ephone-dn)# huntstop
!
CMERouter(config)# ephone 20
CMERouter(config-ephone)# vm-device-id CMEVM-VI1
CMERouter(config-ephone)# button 1:20
!
!
!
!
CMERouter(config-ephone-dn)# call-forward busy 7700
CMERouter(config-ephone-dn)# call-forward noan 7700 timeout 10
!
CMERouter(config-ephone)# type 7965
CMERouter(config-ephone)# mac-address 00C3.CF99.B188
!
CMERouter(config)# dial-peer voice 100 voip
CMERouter(config-dial-peer)# destination-pattern 7000
CMERouter(config-dial-peer)# session target ipv4:10.76.108.244
CMERouter(config-dial-peer)# dtmf-relay h245-alphanumeric
CMERouter(config-dial-peer)# codec g711ulaw
!


CMERouter(config-dial-peer)# preference 1
In Example 6-1, the voicemail number is defined under telephony-service followed by

the definition of MWI On and Off ephone-dns. Next, a set of ephone-dns is defined to
match calls to voicemail number. ephones are defined to register SCCP ports using the
command vm-device-id <>. Finally, the dial peers are configured that point to primary
(CUC subscriber) and secondary (CUC publisher) servers.
On CUC, configure a new phone system followed by defining a new port group and
port(s), similar to the process described in the prior section for SCCP integration.
Cisco Unity Connection SIP Voicemail Integration with CUCME

Cisco Unity Connection can also leverage SIP (trunk) to integrate with CUCME. Example
6-2 gives insight into the SIP integration between CUC and CUCME (the configuration
of CUCME and CUC remains the same as in SCCP integration except the dial peers).
Example 6-2 CUCME SIP Voicemail Integration with CUC

CMERouter(config-dial-peer)# description to CUC Subscriber
CMERouter(config-dial-peer)# session protocol sipv2
CMERouter(config-dial-peer)# dtmf-relay rtp-nte
CMERouter(config-dial-peer)# max-conn 15
CMERouter(config-dial-peer)# no huntstop
!
CMERouter(config-dial-peer)# description to CUC Publisher
CMERouter(config-dial-peer)# dtmf-relay rtp-nte
CMERouter(config-dial-peer)# max-conn 15
CMERouter(config-dial-peer)# preference 2
CMERouter(config-dial-peer)# huntstop
!

Cisco Unity Connection Dial Plan 175
CMERouter(config)# sip-ua
CMERouter(config-sip-ua)# mwi-server 10.76.108.244 unsolicited
In Example 6-2, the dial peers point to the CUC subscriber and publisher, respectively,
with the voicemail number as destination-pattern. The max-conn <> command specifies
the number of voicemail ports on each server.
Cisco Unity Connection Dial Plan

Similar to CUCM, CUC also has dial plan components that allow the implementation
of restrictions related to callers being able to send messages to other users (or system
entities) as defined by the organization’s messaging policy. For example, an organization
could have a requirement that users cannot leave voice messages for directors and above.
In such cases, partitions can be used to segregate the following objects:
■ Contacts
■ Call handlers (system, directory, and interview handlers)
■ Distribution lists
■ Users
Partitions define who or what can be reached, search spaces (equivalent to CUCM CSS),
and define by whom or what partitions are reachable.
Search spaces can be assigned to any object that can initiate a call or a user that can
address a message to another user or entity. Partitions can be assigned to various search
spaces to ensure that the call restrictions are in place for system entities and subscribers
(users). The following objects can be assigned to a search space:
■ Call handlers (system and directory handlers)
■ Routing rules
■ Users
To create a new partition or search space, go to the Cisco Unity Connection

Administration page and click Dial Plan in the navigation pane on the left. From there,
you can define new partitions and search spaces. The system default partition and search
space are created during CUC installation and must be replaced with appropriate parti-
tions or search spaces as required for call handlers, contacts, users, and so on. To set
up CUC to use any new defined partition and search space as a default partition, go to
System Settings > General Configuration and replace the default partition and search
space. Once configured, any user or entity created inherits the newly defined partition
and search space.

Call Handlers
Call handlers, as the name suggests, are call flow instructions that handle incoming calls
to CUC. These instructions can range from offering a caller a menu of options from
which to select (Auto Attendant), enabling the caller to locate a CUC subscriber (direc-
tory user), or presenting information. Call handlers allow users to leverage self-service
(IVR-like call flow) and perform other functions as discussed in this section.
Call handlers can be broadly classified as follows:
■ System call handlers
■ Directory handlers
■ Interview handlers
Cisco Unity Connection System Call Handlers

Three default system call handlers are available with a fresh install of CUC:
■ Opening Greeting: Plays the standard system opening greeting announcement. The
caller is presented with a number of options after the opening greeting, enabling the
caller to select a user’s (subscriber’s) extension, the system directory, or the operator.
In case a caller does not make a selection, the caller is directed to the operator.
■ Operator: Allows the caller to dial 0 to connect to the subscriber/extension defined

as an operator. If an operator extension is not defined or an operator is unavailable,
the Operator call handler default configuration takes a message.
■ Goodbye: Plays a goodbye announcement, after which it disconnects the call. This
call handler is invoked by default when a user has finished recording a message via
the Operator call handler.
Figure 6-3 shows the default system call handlers available with CUC.
Figure 6-3 CUC System Call Handlers

Call Handlers 177
The default system call handlers cannot be deleted, but they can be modified as required.
Table 6-1 lists the available options that can be used to modify any system call handler.
Table 6-1 CUC System Call Handler Options

System Call Handler Option Description
Transfer Rules Allow administrator(s) to configure a standard, closed, or
alternate transfer rule. While standard transfer is enabled by
default, it cannot be deleted and is without an end date. The
closed transfer rule, if enabled, overrides the standard trans-
fer rule as per the schedule. The alternate transfer rule, when
enabled, overrides the standard and closed transfer.
Caller Input Offers callers to provide dual-tone multifrequency (DTMF)
responses during the greeting (announcement) and allows
the call to be directed to an extension or mailbox as
necessary.
Greetings System call handlers can be configured with various greet-
ings such as:
■ Alternate (overrides all greetings if enabled)

■ Busy (overrides Standard, Closed, Holiday, and Internal
greetings)
■ Closed (overrides Standard greeting for off business or
closed hours)
■ Error, Holiday (overrides Standard and Closed
greetings)
■ Internal (overrides the Standard, Holiday, and Closed
greetings)
■ Standard greetings
Post Greeting Recordings Plays after the selected greeting as only an informational
greeting to the caller after the system or personal recording
and before the After Greeting actions.
Message Settings Applicable to call handlers that are enabled for recording
messages from callers and allow configuring message length,
urgency, security, and recipient (CUC user or distribution
list).
Call Handler Owners By default, only users that have a role of system administra-
tor can create or modify call handler greetings. This role can
be delegated to another user by defining the user as a call
handler owner such that the user is able to record the greet-
ings using Greeting Administrator.

To configure a new system call handler, browse to Call Management > System Call
Handlers > Add New. You can create call handlers that leverage the same functionality
by configuring a call handler template (Templates > Call Handler Templates) to allow
new call handlers to apply a desired/similar set of configuration in terms of Transfer
Rules, Caller Input, Greetings, Message Settings, and Post Greeting Recording.
Cisco Unity Connection Directory Handlers

Directory handlers are special call handlers in that they are employed to allow callers
to locate a user by first name, last name, or extension, and then permit a caller to leave
a message for the user. CUC by default has a system directory handler that has all CUC
users assigned to it by default. To configure a new directory handler or amend an exist-
ing one, browse to Call Management > Directory Handlers. You can modify the default
directory handler or add a new one. The configuration of a directory handler is split into
three major sections (available under edit option):
■ Basic Configuration: Defines basic properties of a directory handler such as name,

language, extension, voice-enabled directory handler, and so on as shown in
Figure 6-4.
Figure 6-4 Custom Directory Handler
■ Caller Input: Allows a caller to provide input and accordingly route the call to a
user’s extension, a call handler, another directory handler, or a conversation. If a
caller doesn’t provide any input, the previously stated actions can be repeated or the
caller can be sent to the Goodbye call handler. Finally, if a caller presses 0, the caller
is transferred to an operator.

Call Handlers 179
■ Greeting: Can be recorded as an opening prompt for a directory handler. If no greet-

ing is recorded, the system directory handler uses a default greeting that prompts the
user’s input.
Figure 6-4 represents a directory handler configuration.
Cisco Unity Connection Interview Handlers

CUC interview handlers are yet another special type of call handler. An interview handler
primarily allows a caller to answer a series of questions and subsequently records the
caller’s responses. These responses are delivered to a message recipient so that the recipi-
ent can understand the caller’s requirements/concerns or data in a better way. An inter-
view handler can be set up to ask questions such as the name of the caller, street address,
mobile number, city, ZIP code, and so on. To configure an interview handler, browse
to Call Management > Interview Handlers. CUC has no default interview handler; an
administrator must add interview handler(s) per the organization’s requirements. Figure
6-5 shows an interview handler.
Figure 6-5 CUC Interview Handler
The configuration of an interview handler has two major sections:
■ Basic Configuration: Defines basic properties of an interview handler such as name,

extension, language, recipient, after-interview action, and so on. After a response
is recorded, it is sent to the recipient user or distribution list. Consequently, the

response can be marked as urgent or normal, or a caller can choose from either
of these. The after-interview action can be set to send the caller to an extension, a
voicemail box, a directory handler, another interview handler, a call handler, or a
conversation.
■ Interview Questions: An administrator can set up a series of questions to which a

caller must respond. These questions can be associated with audio prompts, and the
responses can be recorded. A maximum of 20 questions can be set up.
Cisco Unity Connection Single Inbox

In CUC Single Inbox (Unified Messaging), voice messages are stored in CUC and are
synchronized with Microsoft Exchange mailboxes. While leveraging a single inbox solu-
tion, the message store is the CUC server and the messages are synchronized with the
Microsoft Exchange servers. In other words, voice messages are stored on CUC and are
copied to the Exchange server at the same time. This allows the Cisco clients to connect
via their APIs and permits the Exchange clients to connect via their APIs. As a conse-
quence, the dependency on Exchange is reduced so that if the Exchange server goes
down, CUC is still functional and voice mails are accessible. The following are highlights
of CUC single inbox:
■ Dual message stores with message synchronization (between CUC and Exchange)
■ Not dependent on Exchange/Active Directory infrastructure
■ Discoverability of voice mails from TUI/GUI/VMO
■ Text-to-speech (TTS) access to Exchange email
■ Transcription of CUC voice messages (SpeechView)
■ Access to Exchange Calendar and Contacts
Figure 6-6 depicts the CUC single inbox architecture.
Voice Voice
Messages Messages
Message Email
Synchronization Messages
Cisco Unity Connection Microsoft Exchange Microsoft Outlook

(Cluster) Server Client
Figure 6-6 CUC Single Inbox Architecture
When configured for single inbox, CUC doesn’t synchronize the following messages:
■ Sent messages
■ Draft messages

Cisco Unity Connection Single Inbox 181
■ Messages set for future delivery but not yet delivered
■ Broadcast messages
■ Unaccepted dispatch messages
Note To access voice messages from within the Outlook client, ViewMail for Outlook
(VMO) is required. VMO is a CUC plug-in that you can download from
http://software.cisco.com/download/release.html?mdfid=284532811&flowid=
45679&softwareid=282074348&release=VMO%209.0%282%29&relind=
AVAILABLE&rellifecycle=&reltype=latest.
If users want to use Outlook to send, reply to, or forward CUC voice messages, the
VMO client must be installed on user workstations. Without VMO installed, voice mes-
sages are sent by Outlook as emails with .wav file attachments, and are treated as emails
by CUC. If VMO is not installed, when a user replies to or forwards a voice message, the
reply or forward is also treated like an email and hence the message is never sent to the
CUC mailbox (as email routing is handled by Exchange). Moreover, without VMO, users
cannot listen to secure voice messages and must play them via TUI.
CUC synchronizes voice messages between Outlook folders and the CUC inbox folder
for a user as follows:
■ Subfolders under the Outlook Inbox folder
■ Subfolders under the Outlook Deleted Items folder
■ The Outlook Junk Email folder
Messages in Outlook and CUC deleted items folders are synced. So, if a user moves voice
messages (except secure voice messages) into Outlook folders that are not synced with
the CUC inbox folder, the messages are moved to the deleted items folder in CUC. On
the same note, CUC does not sync secure messages with Exchange; instead, it replicates a
decoy message that briefly describes a secure message. When a user plays a secure mes-
sage employing VMO, the secure message is retrieved from the CUC server and is played
without ever storing the message anywhere else (Exchange or user PC). For secure mes-
sages, the same rules apply as with non-secure messages for CUC inbox to Outlook sync.
Before CUC Single Inbox (Unified Messaging) can be configured on CUC, the CUC
administrator must know the following parameters:
■ Web-based authentication mode (Basic, Digest, NTLM)
■ Web-based protocol (HTTP/HTTPS)
■ Exchange server’s IP address
■ Exchange server type (2003/2007/2010)
■ Active Directory account to access Exchange

Moreover, if Secure Sockets Layer (SSL) is required for connectivity between Exchange
and CUC, Exchange certificates must be uploaded into the CUC server(s) Tomcat certifi-
cate store.
Assuming the parameters are known, follow these steps in Cisco Unified Connection
Administration to configure CUC Unified Messaging:
Step 1. Choose Class of Service > Class of Service and ensure that the Allow Users
to Access Voice Mail Using an IMAP Client and/or Single Inbox check box
is checked for Voice Mail User CoS. Also, if you plan to use TTS, check the
check boxes labeled Allow Access to Advanced Features and Allow Access
to Exchange Email by Using Text to Speech (TTS).
Step 2. Navigate to System Settings > SMTP Configuration > Smart Host and click
Add New. Add a SMART SMTP server that will relay messages between CUC
and other servers (including Exchange).
Step 3. Go to Unified Messaging > Unified Messaging Services and click Add
New. Provide the required details such as Type (Exchange, Office 360,
MeetingPlace 8.x), Display Name, Web-Based Authentication Mode, Web-
Based Protocol, Exchange server details (or, alternatively, set to auto-search
using DNS Domain Name), and so on as shown in Figure 6-7. Ensure that ser-
vice capabilities are defined and the message action for email (and optionally
for fax) are set as required.
Figure 6-7 CUC Single Inbox/Unified Messaging Configuration

Cisco Unity Connection Visual Voicemail 183
Step 4. Provision Unified Messaging for the end users on a user-by-user basis, by
using Bulk Administration Tool (BAT), or by using a user template. For all
Unified Messaging–enabled users, confirm that the Generate SMTP Proxy
Address from Corporate Email Address is checked (user-by-user basis or
via BAT or via user template). Users can be provisioned/edited by browsing
to Users > Users. Also ensure that after a user is configured, under the edit
option, choose Unified Messaging Accounts and define the user’s Unified
Messaging services as shown in Figure 6-8.
Figure 6-8 CUC User Unified Messaging Services
Cisco Unity Connection Visual Voicemail

Visual Voicemail is a CUC application (and a result of interaction between CUCM and
CUC) that provides an alternative method for CUC subscribers/users to work with voice-
mail messages on the screen of a Cisco Unified IP Phone rather than logging in to the
TUI or CUC user GUI. Users can view a list of messages, play messages from the list, and
compose, reply to, forward, and delete messages, all from the IP Phone’s screen. Visual
Voicemail is a combination of a MIDlet (a Java application that runs on IP Phones) and a
phone service that points to the MIDlet.
Follow these steps to configure Visual Voicemail:
Step 1. Ensure that all phones have Web Access set to Enabled. You can accomplish
this either via BAT, by browsing to Cisco Unified CM Administration >
System > Enterprise Phone Configuration, or by setting the Common Phone
Profile Configuration by browsing to Device > Device Settings > Common
Phone Profile.
Step 2. Create a new Voice Mail Pilot in addition to the standard Voice Mail Pilot.
Provide a unique pilot number (different from that of the regular Voice Mail
Pilot) and other required parameters.

Step 3. Create a new Hunt Pilot specifically for Visual Voicemail. Point it to an exist-
ing Hunt List used for regular voice mail.
Step 4. Go to Device > Device Settings > Phone Services and click Add New. Add
a new service with the name Visual Voicemail and with the service URL as
http://<IP address of CUC>/midlets/VisualVoicemail/VisualVoicemail.jad.
Select Java MIDlet for the Service Category, select Messages for the Service
Type, set Service Vendor to Cisco Systems, Inc., and check the Enable check
box. Set Visual Voicemail Service Parameters with the following:
■ Create a new parameter voicemail_server with a display name of

Voicemail Server, set the default value to the hostname/IP address of the
CUC server, and enter a description of Hostname of Voicemail server.
■ Create a new parameter call_connect_delay with a display name of Call

Connect Delay, set the default value to 1000, and enter a description of
Default call connect delay.
■ Create a new parameter log_level with a display name of Log Level, set
the default value to info, and enter a description of Level of logging.
Save the configuration.
Step 5. Go to Cisco Unity Connection Administration > System Settings >

Advanced > Connection Administration and ensure that the Applications
Can Cache the Cisco Unity Connection Password check box is checked. Set
the Session Timeout to 300, set the Pilot Number for Voice Mail to standard
voicemail pilot, and set the Pilot Number for TRAP Connections to Visual
voicemail pilot.
Step 6. Configure a Reverse TRAP Rule in Cisco Unity Connection by browsing to

Call Management > Call Routing > Direct Routing Rules and clicking Add
New. Provide the required details and set the Conversation to Reverse Trap.
Add a new routing rule as Dialed Number Equals <Visual Voicemail Pilot>.
Save the configuration.
Voice Mail for Cisco Jabber

Similar to Cisco Unified IP Phones, CUC can be employed by Cisco Jabber users for
voice messaging. Jabber Windows clients can leverage Visual Voicemail as shown in
Figure 6-9.
To configure voice mail for Jabber, follow these steps (assuming there is existing voicemail
integration with CUCM):
Step 1. Go to Cisco Unified CM Administration > User Management > User

Settings > UC Service. Click Add New. Select the UC Service Type
Voicemail. Click Next. Enter the required details for Cisco Unity Connection
server (voice messaging server) such as Product Type, Name, Host Name/IP
Address, Port, and Protocol, as shown in Figure 6-10. Click Save.

Voice Mail for Cisco Jabber 185
Figure 6-9 Cisco Jabber (Visual) Voice Mail
Figure 6-10 Voicemail UC Service Configuration
Step 2. Go to User Management > User Settings > UC Service. Click Add New.
Select the UC Service Type MailStore. Click Next. Enter the required details
for the Exchange server such as Name, Host Name/IP Address/FQDN, Port,
and Protocol. Click Save.
Step 3. Navigate to User Management > User Settings > Service Profile. Click Add
New. Enter service profile name as Jabber. Check the check box to make this
profile the default profile. Under Voicemail Profile, select the Voicemail UC

Service you configured earlier, and make sure that the Credentials Source for
Voicemail Service field is set to Unified CM - IM and Presence, as shown in
Figure 6-11. Under MailStore Profile, select the MailStore UC Service you
configured earlier and ensure that the Allow Dual Folder Mode check box is
checked, also shown in Figure 6-11.
Figure 6-11 CUCM Jabber Service Profile
Step 4. Go to Cisco Unity Connection Administration > Class of Service > Class
of Service and ensure that Voicemail user Class of Service has the check
box Allow Users to Access Voice Mail Using an IMAP Client and/or Single
Inbox checked and the radio button Allow IMAP Users to Access Message
Bodies selected.
Cisco Unity Connection Voicemail Networking

CUC voicemail networking allows network voice messaging services to be networked
with other voice messaging platforms. CUC voicemail networking can be broadly classi-
fied into the following categories:

■ Intrasite networking: Networking with other CUC servers/clusters within the same
connection site
■ Intersite networking: Networking with other CUC servers/clusters between two
connection sites
■ Voice Profile for Internet Email (VPIM) networking: Networking with voice mes-
saging platforms such as Cisco Unity Express and third-party voicemail systems
Intrasite Networking
Intrasite networking enables you to reach out to other (physical/logical) locations and
enables the administrator to network a CUC cluster or server with other CUC servers/
clusters. This enables an enterprise to increase the total number of users that can be pro-
visioned within the enterprise. CUC supports intrasite networking with other CUC clus-
ters/servers and allows expanding the number of voicemail users beyond the maximum
20,000 up to 200,000 (with the number of global directory users and contacts limited to
100,000). A maximum of ten CUC servers/clusters can be joined together to form a single
voice messaging network. This network is referred to as a connection site, and each
server/cluster participating in a connection site is known as a location. The links between
locations are known as intrasite links. SMTP is used for communication within a site.
Intrasite networking supports the replication of the following within a connection site:
■ Users
■ System distribution lists
■ Partitions
■ Search spaces
■ Locations
Figure 6-12 depicts intrasite networking topology.

To join an intrasite link (site), go to Networking > Links > Intrasite Links. You can either
automatically join a site (by providing required details such as Remote Location – IP
Address/FQDN, Remote Username, Remote Password) or manually join a site (by upload-
ing the remote location’s configuration file and downloading the local configuration file
and uploading it to the remote location).

CUC Cluster
(Location)
Intrasite Links
CUC Cluster CUC Cluster
(Location) (Location)
CUC Server CUC Server
(Location) (Location)
Figure 6-12 CUC Intrasite Networking Overview
Intersite Networking
Two connection sites can be linked together using an intersite link to form an intersite
network, as illustrated in Figure 6-13. An intersite network allows increasing the number
CUC servers/clusters to up to 20 servers/clusters to form a “voicemail organization.”
There can be only a single intersite link between sites participating in intersite network-
ing. A single location from each site acts as a gateway to the other site, and these gate-
ways use HTTP or HTTPS to exchange directory synchronization updates and use SMTP
for voice messages exchange. Similar to intrasite networking, intersite networking also
supports users, system distribution lists, partitions, search spaces, and locations replica-
tion between two sites.
To configure intersite links, go to Networking > Links > Intersite Links and provide
required details such as automatic or manual link information, transfer protocol, synchro-
nization settings and tasks, and intersite SMTP routing.

Directory Exchange
HTTP/HTTPS
Message
Exchange
SMTP Server SMTP Server
Connection Site Connection Site
Figure 6-13 CUC Intersite Networking Overview
Voice Profile for Internet Email (VPIM) Networking

VPIM networking allows messages to be exchanged with voicemail systems other than
CUC, such as Cisco Unity Express (CUE) or any third-party voicemail system that sup-
ports standards-based VPIM networking. The VPIM concept and networking with CUE
are discussed in Chapter 9, “Cisco IOS UC Applications.”


Chapter 7
Cisco Unified IM and

Presence
Cisco Unified Instant Messaging (IM) and Presence is now better known as Cisco Unified
Communications Manager IM and Presence (Cisco Unified CM IM and Presence).
This is due to the integration of Cisco Unified Presence technology with Cisco Unified
Communications Manager for Release 9.0 and later. Cisco Unified CM IM and Presence
offers presence, IM, group chat, desk-phone control, and many other enterprise-grade
features.
Cisco Unified Communications Manager IM and

Presence Components
A Cisco Unified CM IM and Presence solution has several components that work togeth-
er to provide an enterprise-grade presence and IM solution. The components necessary
to deliver a comprehensive Cisco solution are as follows:
■ Cisco IM and Presence Service (Presence Engine)
■ CUCM (call-control agent)
■ Cisco Jabber (Extensible Messaging and Presence Protocol [XMPP] soft client)
■ Cisco Unified MeetingPlace (audio, video, and web conferencing server)

■ Cisco Unity Connection (voice messaging server)
■ Cisco Unified Videoconferencing or Cisco Unified MeetingPlace Express VT
■ Lightweight Directory Access Protocol (LDAP)
■ Cisco Unified IP Phones (endpoints)
■ Third-party presence server (e.g., IBM Sametime or Microsoft Lync Server)

192 Chapter 7: Cisco Unified IM and Presence
■ Third-party XMPP clients (for example, Google Talk)
■ Third-party applications
Figure 7-1 gives an overview of the Cisco Unified CM IM and Presence architecture and
relationship with different components.
Cisco IBM Video Client

MeetingPlace Sametime On PC
SIP
Video XMPP XMPP
SIMPLE CUCM
Phone CTI/SIP/DB
SIP
SIMPLE
SIP
Jabber XMPP SIMPLE Cisco Unity
Client Connection
SIP Cisco CM IM
SIMPLE and Presence LDAP
Cisco Unified
LDAP
IP Phone CSTA over SIP/ XMPP XMPP/SIP
SIP SIMPLE SIMPLE
Microsoft Google Third-Party

Lync Talk API
Figure 7-1 Cisco CM Unified IM and Presence Solution Overview
Cisco Unified CM IM and Presence Cluster

A Cisco Unified CM IM and Presence cluster can have up to six servers in the cluster,
of which one server is the publisher and the others are subscribers. Within the cluster
there can be a maximum of three subclusters with two servers in each subcluster. The
Cisco CM Unified IM and Presence cluster’s publisher uses a database connection to
the CUCM publisher to synch user and device information. Multiple subclusters provide
higher capacity, and when a subcluster has two servers, it offers redundancy and high
availability. A Cisco Unified CM IM and Presence cluster can be integrated with only
one CUCM cluster. Figure 7-2 shows CUCM cluster integration with a Cisco Unified IM
Presence cluster.

Cisco Unified IM Presence Cluster
1A 2A 3A
DB Sync
IDS IDS
1B 2B 3B
CUCM Cluster
Subcluster 1 Subcluster 2 Subcluster 3
Figure 7-2 CUCM Integration with Cisco Unified IM Presence Cluster
Cisco Unified CM IM and Presence subclusters can be configured in Active-Active mode

or Active-Standby mode. Active-Active mode leads to a balanced mode where users are
equally distributed to each node in the subcluster; for example, 1A followed by 2A fol-
lowed by 3A, and then 1B followed by 2B followed by 3B, with the full cycle iterating
for each new user added. Active-Standby mode assigns all users to the first node of the
subcluster, leaving the secondary server as a backup; for example, 1A followed by 2A fol-
lowed by 3A, and then iterating the same cycle leaving 1B, 2B, and 3B as backup. None
mode results in no assignment of the users to the nodes in the cluster by the sync agent.
The next section describes the integration of CUCM with a Cisco Unified CM IM and
Presence server.
Cisco Unified CM IM and Presence Server Integration

with CUCM
To integrate a Cisco Unified CM IM and Presence server with CUCM, follow these steps:
Step 1. Go to the Cisco Unified CM IM and Presence Administration page and

choose the Cisco CM Unified IM and Presence Serviceability navigation
option in the upper-right corner. Choose Tools > Service Activation and
ensure that the following services are activated:
■ Cisco SIP Proxy
■ Cisco Presence Engine
■ Cisco Sync Agent
■ Cisco Unified Presence XCP Connection Manager
■ Cisco Unified Presence XCP Directory Service
■ Cisco Unified Presence XCP Authentication Service

Step 2. Go to the Cisco Unified CM Administration page and choose User

Management > Application User. Ensure that the Administrative XML
User that was created as part of the post-installation procedure of the Cisco
Unified CM IM and Presence server exists and has Standard AXL API
Access.
Step 3. Navigate to Cisco Unified CM IM and Presence Administration, choose

Application > Legacy Clients > Settings, and enter the IP address(es) of the
TFTP server(s). Click Save.
Step 4. Go to Cisco Unified CM Administration and choose Device > Trunk. Add a
new SIP trunk for integrating with the Cisco Unified CM IM and Presence
server. Enter the required details such as Device Name, Device Pool, and so
on. Ensure that the Cisco Unified CM IM and Presence server IP is entered
under SIP Information > Destination.
Step 5. Go to User Management > User Settings > UC Service. Click Add New.
Select the UC Service Type IM and Presence. Click Next. In the Product
Type field, enter Unified CM (IM and Presence) and enter other required
parameters as shown in Figure 7-3.
Figure 7-3 IM and Presence UC Service Configuration
Step 6. Go to User Management > User Settings > UC Service, click Add New, and
select the UC Service Type CTI. Click Next. Enter the required details for
CTI Manager (CUCM server running CTI service).
select the UC Service Type Voicemail. Click Next. Enter the required details
for the Cisco Unity Connection server (voice messaging server).

select the UC Service Type Directory. Click Next. Enter the required details
for the LDAP server (the organization’s LDAP server; for example, Microsoft
Active Directory).
Step 9. Navigate to User Management > User Settings > Service Profile. Click Add
New. Enter the service profile name as Jabber and enter a meaningful descrip-
tion such as Jabber Service Profile. Check the check box to make this profile
the default profile. Under Voicemail Profile, select the one you configured
earlier, followed by directory profile, IM and Presence profile, and CTI pro-
file. For LDAP, enter the required details such as username, password, search
base, and so on as shown in Figure 7-4.
Figure 7-4 Jabber Client Service Profile Configuration
Step 10. Go to Cisco Unified CM IM and Presence Administration and choose

Presence > Settings. In CUCM IM and Presence Publish Trunk, select the SIP
trunk you created earlier on CUCM.
Step 11. Navigate to Presence > Gateways and click Add New. Select CUCM as the
Presence Gateway Type and enter other required details as shown in
Figure 7-5.
Step 12. Navigate to Application > Legacy Clients > CCMCIP Profile and click Add
New. Enter the required information, ensuring that the primary and backup
Cisco Unified Communications Manager IP Phone (CCMCIP) hosts are

the CUCM subscribers that have access to the Cisco CM Unified IM and
Presence server trunk. Figure 7-6 depicts CCMCIP profile configuration.
Figure 7-5 Presence Gateway Configuration
Figure 7-6 CCMCIP Profile Configuration

Cisco Jabber 197
The integration of CUCM and the Cisco CM Unified IM and Presence server is com-
plete. You can now begin configuring users for IM and Presence.
Cisco Jabber
Cisco Jabber is an XMPP-based client-server architecture based on the open XML
protocol. Its deployment is available in two flavors: on-premises and cloud-based. The
Cisco Jabber client supports various platforms, including PC, Mac, iOS, Android, and
BlackBerry OS. The design of the client is such that it enables an all-in-one communica-
tion tool, giving end users features and functionality such as voice, video, desktop shar-
ing, calendar management, and so on.
The Jabber client supports the following features/services:
■ Presence and IM
■ 1:1 and group chat
■ Contact search capability
■ PC-to-PC desktop share
■ PC-to-PC audio and video
■ File transfer capability
■ Screen capture capability
■ Local chat history
■ Logging and archiving
■ XMPP federation with third-party XMPP clients
■ Calendar and email integration
■ UC integration for voice
■ Video
■ Voice messaging
■ Click-to-call features
Jabber architecture is illustrated in Figure 7-7.

Cisco Jabber
IM and Presence
Contact Management XMPP IP Phone Directory Visual
File Transfer Control Search Voicemail
User Data Sync Directory Search

Cisco
Authentication
Telephony
Presence
Cisco WebEx
Cisco IM CUCM LDAP Cisco Unity
and Presence Connection
Figure 7-7 Jabber Architecture
As previously mentioned, Jabber can be deployed in two major deployment models, on-
premises and cloud/hybrid. The various options for each model are as follows:
■ On-premises IM and Presence
■ On-premises IM and Presence with voice

■ On-premises IM and Presence with voice and video
■ On-premises IM and Presence with third-party integration (federation)
■ Hybrid cloud IM and Presence with voice
■ Hybrid cloud IM and Presence with voice and video
The Cisco Jabber client can be deployed in three main modes:
■ Soft Phone Mode: Audio uses sound devices on a workstation. Video is displayed
on a workstation; audio is via headset or PC speakers.
■ Desk Phone Mode: The Jabber client controls the Cisco IP Phone to make and
receive calls. Video phone control is supported.
■ Cisco Extend and Connect: Jabber extends the call to a remote destination that
enables the user to work from any location on any device.
Jabber for Windows supports Binary Floor Control Protocol (BFCP) for desktop shar-
ing. BFCP encodes a video stream of the sender’s desktop in addition to a camera video
stream. Video desktop sharing can link Jabber client and Cisco video endpoints.
Presence Federation
Federation facilitates IM and Presence collaboration between a Cisco Unified CM IM
and Presence server and a third-party vendor. This allows IM and Presence information

sharing not only within an organization but also between two (or more) organizations.
Federation can be classified into two broad categories:
■ Intradomain federation
■ Interdomain federation
Moreover, federation(s) can be based on a number of parameters. For example, a federa-

tion can be SIP based or XMPP based, can leverage TCP or TLS, and so on.
Intradomain Federation
Intradomain federation is the sharing of presence information and exchange of IM
between systems within the same domain. Intradomain federation can be SIP federation
between Cisco Unified CM IM and Presence and Microsoft Lync Server 2010, Microsoft
Office Communications Server (OCS) 2007 R1/R2, or Microsoft Live Communications
Server (LCS) 2005. In other words, an intradomain federation allows for communications
between other Cisco Jabber or Microsoft-based domains within an enterprise using SIP.
Figure 7-8 illustrates intradomain SIP federation between a Cisco Unified CM IM and
Presence server/cluster and a Microsoft Lync/OCS/LCS server.
CUCM Cluster Enterprise Domain

DomainA.com
Microsoft Lync/
Cisco Jabber OCS/LCS Client
Client
LDAP
SIP
Cisco Unified IM and Microsoft Lync/OCS/

Presence Cluster LCS Server
Figure 7-8 Intradomain SIP Federation
As shown in Figure 7-8, within a domain, the Cisco Unified CM IM and Presence server
and the Microsoft Lync/OCS/LCS server leverage the same corporate directory. Hence,
a user can exist either in Cisco Unified CM IM and Presence or in Microsoft Lync/OCS/
LCS, but not in both. For the Cisco Unified CM IM and Presence server, the Jabber ID is
in the form of sAMAccountName@domain. For Microsoft Lync/OCS/LCS, the SIP URI
can be in the form sAMAccountName@domain, First.Last@domain, or email address(es).

To enable intradomain federation, follow these steps in Cisco Unified CM IM and

Presence Administration (the steps with TLS/certificate configuration are exclusive to
Microsoft Lync Server, as Partitioned Intradomain Federation with Lync requires TLS and
is not supported on TCP):
Step 1. Enable Partitioned Intradomain Federation by choosing Presence > Settings

and checking the Enable Partitioned Intradomain Federation with LCS/
OCS/Lync check box.
Step 2. Configure Static Routes to Lync/OCS/LCS Front end Servers. Browse to

Presence > Routing > Static Routes. Enter the required information pertinent
to the Lync/OCS/LCS server.
Step 3. Go to System > Security to configure the incoming ACL and outgoing ACL
to allow incoming and outgoing address patterns from/to Lync/OCS/LCS. If
you do not know the address patterns, set it to All.
Step 4. Go to System > Application Listeners and ensure that Default Cisco SIP
Proxy TLS Listener - Peer Auth is configured to use port 5061.
Step 5. Proceed to System > Security > TLS Peer Subjects and add the Lync server
as a peer with FQDN.
Step 6. Navigate to System > Security > TLS Context Configuration and ensure
that Disable Empty TLS Fragments is checked. Move TLS Peer Subject (cre-
ated in Step 5) to Selected TLS Peer Subjects.
Step 7. Go to Cisco Unified CM IM and Presence OS > Certificates > Upload

Certificate/Certificate Chain and import the root certificate of the certifi-
cate authority (CA) in the cup-trust trust store.
Step 8. Request a signed certificate from the CA. Generate a Certificate Signing
Request from the cup trust store, and after it is signed by the CA, upload the
same to the cup trust store.
Step 9. Go to Cisco Unified CM IM and Presence Administration > System >

Security > Certificate Import Tool and under Peer Server and Peer Port,
enter Lync address (FQDN) and port (5061) information.
Under Peer Server Status, you can validate SSL connectivity with Lync (assuming the lat-
ter is configured for intradomain federation with CA signed certificates).
The following are some considerations while implementing intradomain federation:
■ Partitioned Intradomain Federation supports only point-to-point IM between Jabber

users and Microsoft Lync/OCS/LCS users.
■ User can only exist in either Cisco Unified CM IM and Presence or OCS/LCS, but
not both.
■ If the Lync/OCS/LCS SIP URI does not match the sAMAccountName@ domain for-
mat, it is recommended to use the Jabber XML file.

■ Domain Name System (DNS) “A” records must be published within the enterprise for
all Cisco Unified CM IM and Presence and Lync/OCS/LCS servers.
■ Partitioned Intradomain Federation with Microsoft Lync is supported only with TLS.
■ If TLS is required, use of the same CA to sign Lync/OCS/LCS and Cisco Unified
CM IM and Presence certificates is recommended.
Interdomain Federation
Interdomain federation enables business-to-business (B2B) and business-to-consumer
(B2C) collaboration between independent organizations, thereby providing IM and
Presence capabilities. Interdomain federation can also occur between two domains
within an enterprise. Interdomain federation can exist between Cisco Unified CM IM and
Presence and Lync/OCS/LCS over SIP or between Cisco Unified CM IM and Presence
and an XMPP server (for example, IBM Sametime or Google Talk). Cisco Unified CM IM
and Presence to Lync/OCS/LCS and to IBM Sametime is an example of B2B federation,
whereas Cisco Unified CM IM and Presence to Google Talk or to AOL interdomain fed-
eration is an example of B2C federation.
Figure 7-9 illustrates interdomain SIP federation between a Cisco Unified CM IM and
Presence server/cluster and a Microsoft Lync/OCS/LCS server.
Enterprise A Enterprise B
DomainA.com DomainB.com
Inside (Private) DMZ DMZ Inside (Private)
Cisco Unified IM and Microsoft Lync/

Presence Cluster OCS/LCS Server
SIP
Cisco Microsoft
ASA Edge
Cisco Jabber Microsoft Lync/

Client OCS/LCS Client
Figure 7-9 Interdomain SIP Federation
To enable interdomain SIP federation, go to Cisco Unified CM IM and Presence

Administration > Presence > Inter-Domain Federation > SIP Federation. Enter the
required information such as the domain name, a description, and the integration type.

You can optionally check the Direct Federation check box if Cisco ASA is not being
used for interdomain federation.
Figure 7-10 illustrates interdomain XMPP federation between a Cisco Unified CM IM

and Presence server/cluster and a third-party XMPP-compatible server.
Enterprise A Enterprise B
DomainA.com DomainB.com
Inside (Private) Inside (Private)
Cisco Unified IM and

Presence Cluster XMPP Server
XMPP
Cisco XMPP
ASA Gateway
XMPP Client
Cisco Jabber (Google Talk,
Client IBM Sametime)
Figure 7-10 Interdomain XMPP Federation
To enable interdomain XMPP federation, go to Cisco Unified CM IM and Presence

Administration > Presence > Inter-Domain Federation > XMPP Federation > Settings.
Enable the XMPP Federation Node Status and set the appropriate security settings and
dial back code as per the remote XMPP gateway/server. Also, ensure that the Cisco UP
XCP XMPP Federation Connection Manager service is activated from Cisco CM Unified
IM and Presence Serviceability.
Presence Cloud Solutions

As discussed earlier in this chapter, Jabber deployment is available as an on-premises
model and as a cloud-based (hybrid) model. Cisco WebEx is the core engine behind
Cisco’s cloud-based solution. The Collaboration Cloud (as shown in Figure 7-11) is a
shared platform that builds on the following:
■ XMPP IM service
■ Meeting (rich media conferencing) services
■ Single identity (database)

Presence Cloud Solutions 203
■ Central administration web-based interface
■ Directory
■ IM archiving
■ XMPP federation
WebEx
Inter-Domain
Administrator
Federation
HTTPS Cisco XMPP XMPP

WebEx XMPP
Contacts
TLS/SSL
(XMPP)
CUCM
SIP (Softphone)/HTTPS
LDAP TLS
(Directory)
CTI (Desk Phone)/HTTPS
Cisco Jabber
Clients
IMAP (Visual Voicemail)
IM Archiving Cisco Unity

Connection
Figure 7-11 Cisco Cloud-Based Presence and IM Solution
Cloud-based Presence and IM has the following feature set:
■ Standard and custom availability status
■ In a meeting (calendar integration) status
■ WebEx Meetings (in a WebEx meeting and presenting) status
■ On the phone status from the client framework (Jabber client framework)
■ Chat/group chat/federated chat
■ Chat history
■ Screen capture and file transfer
■ Escalation from an IM to an audio/video call and WebEx meeting
Other features include the following:
■ A user can be logged in to Jabber on more than one device. When an IM is sent, it
will “fork” to all the logged-in devices. Whichever Jabber responds, that device con-
tinues with the chat transmission.

■ Contacts are stored in a cloud database (including corporate and federated contacts)
and contact searches are performed in the cloud database.
■ Ad hoc desktop sharing is available in cloud mode by default. The sharing session is
hosted in the cloud.
■ An IM logging and archiving option is available for consumers to log/archive IM

chats, including group chats within and outside of their organization.
■ Federated single-sign on (SSO) using corporate credentials is available.
Note that cloud-based presence solutions support only interdomain federation.
Group Chat and Compliance

The Jabber client has the capability to provide group chat service. Moreover, the Jabber
client provides IM logging for organizational compliance (for example, for audits or legal
matters).
Group Chat
When multiple people need to have a chat conversation simultaneously, a group chat can
be established. Group chat can be either an ad hoc chat (temporary group chat) initiated
by a user when required or a permanent group chat.
A temporary group chat doesn’t require any special configuration. A permanent chat
room, however, requires an external database such as PostgreSQL. PostgreSQL can be
used for compliance features as well, as covered in the next section. The major differ-
ence is that for permanent group chat, each Cisco Unified CM IM and Presence server
in a cluster requires a unique logical database, whereas for compliance, only one external
database server is required (with support for more than one server).
Ad hoc chat rooms remain in existence only as long as one person is still connected to
the chat room. In contrast to ad hoc chat rooms, permanent chat rooms are group chat
sessions that remain in existence even when all users have left the room, enabling users to
return to persistent chat rooms over time to collaborate and participate in the discussion
of a topic in real time.
To initiate a group chat from within your Jabber client, follow these steps:
Step 1. Click the Add Participants button in the lower right corner of the window.
Step 2. Type the name of the additional participant. Jabber searches in your contact
list first, then in the corporate directory. Select the additional group member
and click Add.
Step 3. When you add members, the members appear on the right side of the chat
window, and the group chat icon appears on the left.

Group chat can be set to “persistent chat” where all messages among the users are
archived. This is accomplished by going to Cisco Unified CM IM and Presence
Administration > Messaging > Group Chat and Persistent Chat. For more information
on message logging and external databases, refer to the next section on logging and
compliance.
Logging and Compliance

Jabber and Cisco Unified CM IM and Presence can provide IM logging at both a client
side and the server side:
■ IM history (client side): Refers to logging of an IM going to and from a Jabber client
■ IM logging (compliance): Specifically refers to server-side IM logging
Client-Side IM Logging (History)

Client-side IM logging refers to the ability of a Jabber desktop client (Windows or OS X)
to log an IM in a data file that Jabber creates on the local desktop. This enables the Cisco
Jabber client to record the 100 most recent instant messages going to and from the Jabber
desktop client, including group chats. The following information is recorded:
■ Chat participants: The name of all chat participants and IM originators
■ IM date: The date the IM was sent
■ IM time: The time the IM was sent
■ Message body: The content of the message body
The capability of Jabber to log IMs on the client side is controlled via a policy setting
on the system backend (either CUP or WebEx Messenger) depending on which system
an organization has deployed. For on-premises deployment, it is enabled at a global level,
which means it can be either turned on or turned off for the entire organization. For
WebEx Messenger (cloud based), it can be set at the group level or at a global level. The
policy setting for on-premises deployment is set up by browsing to Cisco Unified CM
IM and Presence Administration > Messaging > Settings, as shown in Figure 7-12.
Client-side IM logging is also available in WebEx Messenger and can be enabled or dis-
abled in policy settings as Local Archive. By default, this value is set to TRUE.

Figure 7-12 Cisco CM Unified IM and Presence Client-Side IM Logging Setting
Server-Side IM Logging (Compliance)

Jabber also provides server-side IM logging that is completely transparent to the end
user. This provides organizations access to the IM history of everything that is being
exchanged over IM within their organization across all Jabber clients. The server-side log-
ging is an administratively controlled database of IMs. For on-premises deployments, an
off-board database is required to store IM logging. The administrator points the Cisco
Unified CM IM and Presence server to an external server that can be an external data-
base (such as PostgreSQL) or a third-party server. Figure 7-13 depicts the two options.
Figure 7-13 Cisco CM Unified IM and Presence Server-Side IM Logging Setting
After an external database or third-party server has been configured, it can be assigned
as a Message Archiver or a Compliance Server by browsing to Cisco Unified CM IM
and Presence Administration > Messaging > Compliance.

In the case of WebEx Messenger compliance, an end user always sees a disclaimer notice:
“All instant messages sent in this session to and from this account, as well as the ini-
tiation and termination of any other communication modes (e.g. voice call, video call)
will be logged and are subject to archival, monitoring, or review and/or disclosure to
someone other than the recipient.” If both participants are logged users, the disclaimer
notice appears once for each user. The same holds true for group chat; each participant
generates their own disclaimer and publishes it to the chat.
Customer’s archiving endpoints such as compliance servers need to be entered into the
Cisco WebEx Administration tool. The following parameters are required:
■ Endpoint name
■ Endpoint type
■ Endpoint parameters (vary depending on endpoint type)
After endpoints have been configured, users must be assigned for logging by creat-
ing users, employing CSV files, directory integration, or Security Assertion Markup
Language (SAML).


Chapter 8
Cisco Unified Contact Center

Express
Cisco Unified Contact Center Express (UCCX) is an all-in-one multichannel solution

for small and medium-sized help desks and contact centers with support for up to
400 agents. UCCX offers small to mid-enterprise level contact center features, such
as Interactive Voice Response (IVR), Automatic Call/Contact Distribution (ACD),
Outbound Dialer, Multi-Channel Communication (email, web chat), and Computer
Telephony Integration (CTI).
Cisco UCCX Architecture

Figure 8-1 illustrates the Cisco UCCX architecture and its interaction with the Cisco
Collaboration solution.
Cisco CUCM
Cluster View
UCCX Cluster Cluster
Daemon
Datastores
CC
Administration
CC
Secondary UC Manager
Engine
Primary
Cisco Agent CTI Manager
Desktop (CAD)
CAD Client
Cisco Voice
Cisco Unified IP V Gateway
Phone
Figure 8-1 Cisco UCCX Architecture and Interaction with Cisco Collaboration Network

210 Chapter 8: Cisco Unified Contact Center Express
As shown in Figure 8-1, the UCCX server/cluster is the core of the solution, providing
IVR treatment to incoming calls, queuing calls, and delivering calls to the appropriately
skilled agents. Cisco Agent Desktop (CAD) is client software that runs on an agent PC
used in conjunction with a Cisco Unified IP Phone. This allows agents to handle calls
while monitoring the data associated with that call (such as customer name, account
number, and so on). The CUCM cluster provides call-control functionality to UCCX. The
Engine on the UCCX server has a Java Telephony API (JTAPI) client and uses the JTAPI
protocol to connect to the CTI Manager on CUCM. It is able to monitor and control
devices such as agent IP Phones. The UCCX Administration module interacts with UC
Manager on CUCM while creating CTI devices such as triggers and CTI ports on UCCX,
and the Administration process interacts with the CUCM database to create these
devices on CUCM. The voice gateway (which can be MGCP, H.323, or SIP) is managed
by CUCM for all the communication for call setup and teardown. The only exception to
this is the IVR Outbound Dialer, in which case UCCX communicates directly with a SIP
gateway.
Cisco UCCX Components and Subsystems

Cisco UCCX consists of four major components and several subcomponents:
■ UCCX Engine: The UCCX Engine processes and executes applications using the
functionality of the following subsystems:
■ Script execution
■ Cisco Agent Desktop (CAD) communication
■ CUCM/CTI manager JTAPI communication
■ UCCX Administration interface
■ Resource Manager and Contact Manager (RMCM) subsystem (responsible for

tracking the state of the agents and contacts active in the system)
■ Database: The UCCX database component consists of four data stores:
■ Agent Data Store (ADS): Composed of statistics, logs, and pointers to recordings
■ Configuration Data Store (CDS): Contains information pertinent to resources

(agents), skills, teams, and queues
■ Historical Data Store (HDS): Contains Contact Call Detail Records (CCDR)
■ Repository Data Store (RDS): Contains prompts, grammar, and documents
■ Monitoring: Monitoring is used for remote monitoring, where a supervisor calls

into a script that allows monitoring of an agent’s call. It can be based on desktop-
based monitoring such as CAD to Cisco Supervisor Desktop (CSD) or Switched Port
Analyzer (SPAN) port monitoring.

■ Recording: Allows agent calls to be recorded by the supervisor. If desktop moni-

toring is being used, CAD sends the RTP streams to the recording component, and
if SPAN port monitoring is employed, the monitoring component sends the RTP
streams to the recording component.
In addition to the listed components, the Cluster View Daemon component is relevant
when a UCCX cluster is installed. It monitors the status of the local services on the other
node in the cluster. It is also responsible for dynamically electing components as master
or standby during failover scenarios.
UCCX ACD/ICD, IVR, and CTI Functions

This section examines the features/functions of UCCX subsystems: ACD/ICD, CTI,
and IVR.
UCCX ACD Functions

UCCX ACD, also known as Intelligent Call Distribution (ICD), systematically routes
inbound calls to the next scheduled, available, or logically selected agent. ACD now also
represents Automatic Contact Distribution in the context of contact centers demand-
ing multichannel capabilities such as web chat and email. Table 8-1 lists the basic and
advanced ACD/ICD functions available with UCCX.
Table 8-1 UCCX ACD Functions

UCCX ACD Function Functionality Description
(Basic/Advanced)
Call Routing and Queuing Basic Call routing and queuing functionality.
Cisco Agent Desktop Basic PC-based CTI solution that helps
increase agent and supervisor productiv-
ity. Agents see customer information
in an enterprise data window and an
optional screen pop.
Cisco IP Phone Agent (IPPA) Basic A service added to a Cisco Unified IP
Phone (as an alternative to CAD) that
allows an agent to log in and log out of
the ACD, view caller (enterprise) data
when receiving a call, change agent
state(s), view Contact Service Queue
(CSQ) statistics, and so on.

UCCX ACD Function Functionality Description

(Basic/Advanced)
Supervisor Desktop Basic Cisco Supervisor Desktop (CSD) is also
a CTI solution that provides supervisors
with powerful tools to increase produc-
tivity, with the ability to view real-time
statistics, monitor and coach agents, and
barge in on, intercept, and record active
agent calls when required.
Historical and Real Time Basic Historical and Real Time Reporting are
Reporting run in separate applications: Historical
Reporting through a Windows applica-
tion and Real Time Reporting through a
web-based Java app.
Call Routing and Queuing, CAD, and

other desktop components such as IPPA
and Supervisor Desktop are included
here.
Queue Prioritization Advanced Allows you to give callers priority in
queue based on menu selections, or
any other differentiating factor for the
customer.
Wrap-up Timer and Advanced Allows agents appropriate time to log
associated codes complete information regarding the call
they are currently dealing with, before
the next call is routed to them.
Agent Based Routing Advanced Exceeds a skills-based queue and routes
callers to a specific agent for more per-
sonalized or precise service.
Multi-Line ACD Monitoring Advanced Allows calls on all lines of the phone to
be reported on (compared to only the
primary agent line in earlier versions of
UCCX).
Outbound Campaigns Advanced Enables agent-based outbound cam-
paigns where ACD functionality selects
the agent(s) to handle the next outbound
contact.
Inbound Email Routing Advanced Agents can be assigned to email queues
the same way they are assigned to voice
queues.

UCCX CTI Functions

CTI is the link between the phone call and the applications that an agent is using; for
example, an interface between the agent desktop (PC) and the backend telephony applica-
tions/signaling/media. Table 8-2 lists both basic and advanced CTI functions.
Table 8-2 UCCX CTI Functions

UCCX CTI Function Functionality Description
Enterprise Data Basic Consists of enterprise data, or data that is con-
Window in CAD or nected to the call, being visible on the computer
IP Phone or phone screen of the agent who is accepting
the call. This data includes information about the
caller and statistics about the call itself.
Customized Workflows Advanced Enables third-party app integration and automat-
ically populates the information (agent display
data) in other applications.
Keystroke Macro- Advanced Keystrokes can be recorded to automatically
Enabled Screen Pops launch a certain page within an application (for
example, CAD) or even launch a new application.
Embedded Web Advanced CAD has a web browser integrated directly
Browser Integration into the application. Data can be passed to this
browser from the call, and the browser also con-
tains an email response pane (when CAD Agent
email is enabled).
UCCX IVR Functions

IVR allows UCCX to play recorded messages (prompts) or text to speech in response to
the caller’s input of either DTMF signaling or speech, respectively. Table 8-3 lists basic
and advanced IVR functions available with UCCX.
Table 8-3 UCCX IVR Functions

IVR Function Functionality Description
Prompt and Collect Basic Collects digits from the caller for account num-
DTMF bers and menu choices.
Basic Call-Control Basic Redirects the calls as needed.
Basic XML Data Basic Uses XML for holiday and status checks, and
Processing other types of lookups.

IVR Function Functionality Description

Database (ODBC) Advanced Connects to external databases for detailed call-
Integration to Selected er information and account transactions.
DBMS
HTTP-Triggered Scripted Advanced Can be used for callback requests.
Applications
Outbound Email Advanced Performed by the IVR and used for follow-up
Generation surveys or thank you emails.
Voice XML (VXML) Advanced Provides more detailed prompting. Recognition
for Speech Recognition applications allow callers to use voice rather than
Applications DTMF. Requires a third-party speech server such
as Nuance.
Java Object Support Advanced Allows developers to go beyond the included
script objects and create their own objects using
Java.
MRCP Integration to 3rd Advanced Java object support Media Resource Control
Party Speech Servers Protocol (MRCP) integration is supported, which
ties into the recognition functionality mentioned
earlier.
Outbound dialing with Advanced An IVR-based outbound dialer where the IVR
Call Progress Analysis places the calls rather than agents.
(CPA)
UCCX Deployment Models

Cisco UCCX offers two deployment models:
■ Single-server model: Suitable for smaller, noncritical deployments. Obviously, a

single UCCX server represents a single point of failure.
■ Two-server (cluster) model: The most common deployment model that provides
high availability within a data center and can also be split across a WAN (clustering
over WAN).
With local site (LAN) deployment, typically both UCCX servers would be local to the
primary and secondary CUCM servers; thus, they share the same primary and secondary
CUCM server configuration.
For cluster over WAN deployment, usually the local CUCM is different for each UCCX
server, so they need to be configured with a different primary and secondary CUCM
provider server. This reduces traffic over the WAN and ensures that failover works prop-
erly. Also, recording monitored calls is load balanced between the two nodes. The actual

UCCX Call Flow 215
recording is stored on the node that records the call. However, it is not replicated to the
other server.
UCCX Call Flow

Figure 8-2 illustrates a typical UCCX call flow for an incoming call from the PSTN for
IVR treatment and finally connection to an agent.
PSTN Analog
Phone
PSTN UCCX
Cluster
(5) CUCM
(1)
Cluster
(4) (3)
CC
CC
(2)
Voice
Gateway
(7)
Voice-Enabled
(6)
Switch
Contact Center Agent

IP Phones and CAD
Figure 8-2 UCCX Typical Call Flow
The call flow in Figure 8-2 is explained in the following steps:
Step 1. The PSTN (POTS/SIP) caller dials the number (possibly a toll-free number),
and the call is routed by the service provider to the voice gateway.

Step 2. The voice gateway routes the call to a call-control agent; for example, CUCM
using MGCP, H.323, or SIP.
Step 3. Using Dialed Number Identification Service (DNIS)/dialed number for the
call, CUCM matches a CTI route point (RP) associated with a UCCX JTAPI
user, and a JTAPI route request is sent to UCCX.
Step 4. Upon receiving the request from CUCM, UCCX selects a CTI port and
responds back to CUCM with the directory number/extension so that CUCM
can send a setup message to UCCX corresponding to a specific script/trigger.
The call is answered by the script, and an RTP stream is established between
the designated CTI port on UCCX and the voice gateway.
Step 5. If the script allows for auto-service menu, the user is prompted for data
(DTMF input) and given the required level of service. A script may also lead
to a caller connecting to an agent, in which case the call is queued in the
Contact Service Queue (CSQ) until an agent becomes available.
Step 6. When an agent logs in or concludes the previous call, UCCX reserves the
agent and initiates a call transfer to that agent’s IP Phone’s extension. CUCM
rings the agent’s IP Phone and consequently UCCX may signal a CTI screen
pop (CAD) on the agent’s desktop with call-related information (from the
external user information database).
Step 7. When the agent answers the call, the call transfer is completed and an RTP
stream is established between the agent’s IP Phone and the voice gateway.
UCCX Integration with CUCM

This section gives insight to UCCX integration with CUCM at a systemic level (for sub-
systems such as AXL, CTI, RMCM) and for creating CTI ports that UCCX leverages to
route calls to/from CUCM. The following steps outline the integration of UCCX with
CUCM:
Step 1. After UCCX server/cluster installation is complete, it can be integrated with

CUCM. Go to http://<server ip address>/appadmin on the UCCX server
and log in with Cisco Unified CCX Administration credentials. Select Fresh
Install and click Next.
Step 2. In the Cisco Unified CM Configuration - Service Provider Configuration win-

dow, enter the CUCM IP address/hostname and the AXL Admin User Name
and Password. Click Next.
Step 3. Enter the required license information by uploading the license file to UCCX.
Click Next.
Step 4. In the next window, the Component Activation window, ensure all required
components are activated and click Next.
Step 5. In the Publisher Activation window, select required data stores and click Next.

UCCX Integration with CUCM 217
Step 6. In the Cisco Unified CM Configuration window, select the AXL Service
Provider, Unified CM Telephony Provider, RmCm Provider, and enter
appropriate user credentials mapped to these subsystem users on CUCM, as
shown in Figure 8-3. Click Next.
Figure 8-3 UCCX CUCM Configuration
Step 7. Proceed through the next few windows—System Parameters Configuration

and Languages—and make the appropriate selections as per your deployment.
When you reach the Desktop Client Configuration Tool message, click OK.
Step 8. In the User Configuration window, select the CUCM users that require
administrative rights on the UCCX server.
Step 9. Log in to the UCCX server with the username and password defined in Step
8. Go to Subsystems > Cisco Unified CM Telephony > Call Control Group.
Click Add New and provide the required details as shown in Figure 8-4.
Click Add. This creates CTI ports on the CUCM server/cluster with provided
parameters.
At this time, the UCCX integration with CUCM is complete, including the AXL, CTI,
and RMCM subsystems and the creation of CTI ports on CUCM. However, the UCCX
administrator still needs to configure the following:
■ Skills
■ Assign skills to CSQs
■ Assign phones to users
■ Associate UCCX extensions (IPCC extension)
■ Assign skills to the users (resources)
Additionally, the UCCX administrator must create scripts and applications to handle
incoming calls from CUCM to UCCX and provide IVR/agent transfer functionality.

Figure 8-4 UCCX Call Control Group Definition
UCCX Scripting Components

The heart of UCCX is the scripting mechanism that enables calls to be entertained as
desired, such as
■ Queue the calls until the next agent becomes available
■ Play queue Music on Hold (MoH)
■ Transfer to the agent extension
■ Collect user digits
■ Trigger the next action
UCCX scripting is accomplished in UCCX Cisco Unified CCX Editor. There are different
panes within Unified CCX Editor that offer various functions, as shown in Figure 8-5.
The toolbar at the top of Figure 8-5 offers various options such as create a script, save
a script, and open a script. The window on the left offers numerous palettes that can be
used to construct or modify a UCCX script. The design window is employed to create
a script, modify a script, set properties of a script, and so on. The variables window is
used to assign variables such as agent extension, ID, and so on to various components of
a script.

Figure 8-5 Unified CCX Editor
UCCX scripting palettes are the core of a UCCX script. Some palettes are available only
with certain license options, whereas others are common among all UCCX licensing
options. The full set of palettes is as follows:
■ General: General objects/steps. Available with all license options.
■ Trigger: A call or HTTP request the system received that triggered the script.
Available with all license options.
■ Session: The system automatically associates a contact with a session when the con-
tact is received (inbound) or initiated (outbound). Available with all license options.
■ Contact: Represents a specific interaction with a customer such as a call, email mes-
sage, or HTTP request. Available with all license options.
■ Call Contact: Permits managing call session types. Available with all license options.
■ eMail Contact: Permits managing email session types. Available with IP-IVR or
Premium license only.
■ HTTP Contact: Enables managing web session types. Available with IP-IVR or

■ Media: Processes media interactions with callers. Available with all license options
with the exception of the Voice Browser and Name to User steps, which are available
only with IP-IVR or Premium license options.
■ User: Manages UCCX users’ information. Available with all license options.
■ Prompt: Creates dynamic prompts such as credit card number, date, text, time, cur-
rency, and so on. Available with all license options with the exception of the Create
TTS Prompt step, which is available only with IP-IVR or Premium license options.
■ Grammar: Allows specifying a set of all possible spoken phrases and/or DTMF dig-
its to be recognized by the Cisco Unified CCX solution. Available with all license
options.
■ Document: Enables managing file access. Available with all license options.
■ Database: Enables managing database access. Available with IP-IVR or Premium

license only.
■ ACD: ACD/ICD functional steps. Except for the Stop Monitor and Start Monitor
steps that are specific to the Premium license option and the Set Priority and Create
CSQ Prompt steps that are specific to the UCCX Enhanced or Premium license
options, all other steps are available.
■ Java: Allows Java object creation. Available with Enhanced or Premium license only.
Table 8-4 lists steps that are available for the preceding palettes.
Table 8-4 UCCX Scripting Components

Palette Step Description Availability
General Start, End The first and last steps of Available with all license
execution (implicit in any options.
new, existing script).
General If Branch based on a Boolean Available with all license
“if” condition. options.
General Increment, decre- Sets a certain increment Available with all license
ment Counters or decrement value for an options.
object.
General Goto, Label Jumps to any label in the Available with all license
script. options.
General Call Subflow A subflow is a script that is Available with all license
invoked from another options.
script.
General Exception Exception handling; allows Available with all license
Management Clear and Go To. options.


General Set Sets a variable/value. Available with all license
options.
Trigger Get Trigger Info Retrieves a reference to the Available with all license
triggering contact. options.
Trigger Trigger Application Triggers a specific Available with all license
application. options.
Session Session Mapping Contains all the data associ- Available with all license
ated with a contact. options.
Session Get Session Creates sessions manually. Available with all license
options.
Session Set Session Permits to change Session Available with all license
parameters. options.
Contact Accept/Reject/ Manages the contact in a Available with all license
Terminate script. options.
Contact GetContactInfo Permits to retrieve info. Available with all license
options.
Contact SetContact Permits to change contact Available with all license
information. options.
Call Contact Call Consult Transfer offers supervised Available with all license
Transfer transfer. options.
Call Contact Call Redirect Redirects the call to a Available with all license
specified destination. options.
Call Contact Place Call Places outbound calls. Available with all license
options.
Call Contact Call Hold/Unhold Holds and unholds calls Available with all license
respectively. options.
Call Contact Get Call Contact Accesses call-specific Available with all license
Info information. options.
Call Contact Get/Set Enterprise Gets or sets CTI data to Available with all license
Call Info store in local variables. options.
eMail Contact Create eMail Creates a new email. Available with IP-IVR or
eMail Contact Attach to eMail Adds an attachment to an Available with IP-IVR or
email. Premium license only.
eMail Contact Send eMail Sends an email to an email Available with IP-IVR or
address. Premium license only.


HTTP Contact Get/Set Contact Manages contact Available with IP-IVR or
Info information. Premium license only.
HTTP Contact HTTP Forward/ Launches an internal URI Available with IP-IVR or
Include deployed under the docu- Premium license only.
ment repository.
HTTP Contact HTTP Redirect Redirects to another Available with IP-IVR or
website. Premium license only.
HTTP Contact Send HTTP Sends response back to Available with IP-IVR or
Response originator. Premium license only.
Media Play Prompt Plays prompts (WAV files). Available with all license
options.
Media Extended Play Creates dynamic prompts Available with all license
Prompt (Date, Numbers, and so on) options.
Media Send Digit String Sends digits. Available with all license
options.
Media Menu Menu management. Available with all license
options.
Media Voice Browser Manages the voice browser Available with only IP-IVR
(available only with Nuance or Premium license options.
ASR) for external prompts.
User Authenticate User Authenticates a user/caller. Available with all license
options.
User Get User Retrieves user. Available with all license
options.
User Get/Set User Info Gets/changes user Available with all license
information. options.
Prompt Create Container Concatenates prompts. Available with all license
Prompt options.
Prompt Create TTS Prompt Plays back the text from Available with only IP-IVR
a string or document or Premium license options.
expression.
Prompt Upload Prompt Uploads prompts to the Available with all license
UCCX prompt repository. options.
Grammar Create Language Selects a set of grammars Available with all license
Grammar based on the language of options.
the call.


Grammar Create Menu Creates spoken word and/or Available with all license
Grammar DTMF menu. options.
Grammar Upload to the Uploads to the Grammar Available with all license
UCCX Grammar repository database. options.
repository
Document Create/Read/Cache/ Used for creation, reading Available with all license
Save File from, caching. and saving a options.
file.
Document Create/Search Creates or searches from an Available with all license
XML Files XML file. options.
Document Transform Processes an input docu- Available with all license
Document ment and stores results in options.
an output document.
Document Upload File to Uploads a document to Available with all license
UCCX Server UCCX server. options.
Database DB Get Connects to a database. Available with IP-IVR or
Database DB Read/Write Reads/writes data in a Available with IP-IVR or
database. Premium license only.
Database DB Release Releases database access. Available with IP-IVR or
ACD Select Resource Selects resource to queue Available with all license
for a CSQ or agent. options.
ACD Connect/Select If an agent is available, exits Available with all license
Resource on either “Connected” or options.
“Selected” output branch.
ACD Get Reporting Gets reporting information. Available with all license
Static options.
ACD Dequeue Dequeues a call. Available with all license
options.
ACD Set Priority Changes call priority. Specific to UCCX
Enhanced or Premium
license options
Java Create remote Java Permits to call a remote Available with Enhanced or
Object Java Custom procedure. Premium license only.

Call subflows (in the design window) are similar to a flowchart with procedures or func-
tion calls. Data can be passed to and from subflows. Subflows allow you to modularize
logic and package the same into reusable objects.
Several variable types are available, such as Integer, String, Character, Float, Long,
Double, and so on. A variable can be final and is considered as a constant. A variable may
also be an array. It can be a script parameter and changed in the Web Admin Tool as well.

Chapter 9
Cisco IOS Unified

Communications
Applications
Cisco IOS Unified Communication gateways offer a wide variety of functionality,

including terminating PSTN trunks to SIP trunks, call-control features, survivability
features, and redundancy options for remote site infrastructure. This chapter covers
several of the Cisco IOS UC applications: Cisco Unified Communications Manager
Express, Cisco Unity Express, Cisco Unified CME Basic Automatic Call Distribution
(B-ACD), Cisco Service Advertisement Framework (SAF) and Call Control Discovery
(CCD), and much more.
Cisco Unified Communications Manager Express

Cisco Unified Communications Manager Express (Cisco Unified CME) is the express
version of Cisco’s call-control solution and an important part of the Cisco Collaboration
portfolio. A Cisco Unified CME–based solution is ideal for small businesses or remote
sites in an enterprise solution. Figure 9-1 illustrates a Cisco Unified CME–based tele-
phony solution connecting two sites.

226 Chapter 9: Cisco IOS Unified Communications Applications
Cisco Unified Cisco Unified

IP Phone IP Phone
IP WAN
Cisco Unified PSTN

Cisco Unified
CME
CME

IP Phone IP Phone
Figure 9-1 Cisco Unified CME–based Telephony Solution
Basic Cisco Unified CME Setup

Cisco Unified CME supports both SCCP and SIP phones. For both SCCP and SIP phone
registration, certain common configuration is required to set up and initialize Cisco
Unified CME, such as Cisco IOS router setup so it can support phone registration and
other call-control functions. You must initially extract the Cisco Unified CME bundle
(full) into the router’s flash. (The Cisco Unified CME bundle is a set of phone firmware
files, media files, and other supporting files that helps set up the Cisco Unified CME fea-
ture on a router.) This is accomplished by using the following command:
CMERouter# archive tar /xtract tftp://10.65.35.254/cme-152-4Mv1.tar flash:
This command extracts all CUCME files, including ring tones, phone boot files, and so
on, to the router’s flash.
For every Cisco Unified CME deployment, DHCP-assigned IP addresses and NTP are
required. The Cisco Unified CME router can by itself act as the DHCP server, have DHCP
addresses assigned from an external DHCP, or relay DHCP addresses. The Cisco Unified
CME router can also act as NTP master or get time from an authoritative time source.
Example 9-1 illustrates DHCP and NTP configuration on Cisco Unified CME router (as
DHCP server and NTP client).
Example 9-1 Cisco Unified CME DHCP and NTP Configuration
CMERouter(config)# ip dhcp excluded-address 10.76.108.70 10.76.108.80

!
CMERouter(config)# ip dhcp pool IP-Phones
CMERouter(dhcp-config)# network 10.76.108.0 255.255.255.0

Cisco Unified CME–Based SCCP Phone Registration 227
CMERouter(dhcp-config)# default-router 10.76.108.76

CMERouter(dhcp-config)# option 150 ip 10.76.108.76
CMERouter(dhcp-config)# domain-name corp.local
CMERouter(dhcp-config)# lease 10
!
CMERouter(config)# clock timezone GMT +5 30
CMERouter(config)# ntp authentication-key 1 md5 C1sc0123
CMERouter(config)# ntp trusted-key 1
CMERouter(config)# ntp source GigabitEthernet 0/1
CMERouter(config)# ntp server 10.76.108.84 key 1 prefer source GigabitEthernet 0/1
version 3
CMERouter(config)# ntp authenticate
Example 9-2 illustrates the setup of Cisco Unified CME web GUI access and administra-
tive user access to the GUI.
Example 9-2 Cisco Unified CME GUI and Administration Access Configuration
CMERouter(config)# ip http server

CMERouter(config)# no ip http secure-server
CMERouter(config)# ip http path flash:
!
CMERouter(config-telephony)# web admin system name admin secret C1sc0123
CMERouter(config-telephony)# dn-webedit
At this time, the basic Cisco Unified CME setup is complete and the platform is ready to
be configured for SCCP and SIP endpoints.
Cisco Unified CME–Based SCCP Phone Registration

SCCP phone registration with Cisco Unified CME is conducted via the following steps:
Step 1. Configure Cisco Unified CME as a TFTP server (for the phones) pointing to
the firmware files, as shown in the following configuration snippet:
CMERouter(config)# tftp-server flash:/Phones/7945-7965/apps45.9-3-
1ES13.sbn alias apps42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/cnu45.9-3-
1ES13.sbn alias cnu42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/cvm45sccp.9-3-
1ES13.sbn alias cvm42sccp.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/dsp45.9-3-
1ES13.sbn alias dsp42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/jar45sccp.9-3-
1ES13.sbn alias jar42sccp.9-3-1ES13.sbn

CMERouter(config)# tftp-server flash:/Phones/7945-7965/SCCP45.9-3-

1SR2-1S.loads alias SCCP42.9-3-1SR2-1S.loads
CMERouter(config)# tftp-server flash:/Phones/7945-7965/
term45.default.loads alias term42.default.loads
CMERouter(config)# tftp-server flash:/Phones/7945-7965/
term65.default.loads alias term62.default.loads
Step 2. Set up Cisco Unified CME telephony-service parameters by defining the

maximum number of ephones, the maximum number of DNs, the source
address for SCCP signaling, and the load for the endpoint, and creating
configuration files:
CMERouter(config-telephony)# no auto-reg-ephone
CMERouter(config-telephony)# max-ephones 20
CMERouter(config-telephony)# max-dn 40
CMERouter(config-telephony)# load 7965 SCCP45.9-3-1SR2-1S
CMERouter(config-telephony)# ip source-address 10.76.108.76 port 2000
CMERouter(config-telephony)# create cnf-files
Step 3. Define ephone DNs and ephones. In the following example, two ephone DNs
are defined, one with dual-line capability to support two calls per line and the
other with octo-line capability to support up to eight calls per line. Also, the
ephone definition defines the type of device, button overlay, and the MAC
address of the phone.
CMERouter(config)# ephone-dn 1 dual-line

CMERouter(config-ephone-dn)# number 8001 secondary 42618001
CMERouter(config-ephone-dn)# description 42618001
CMERouter(config-ephone-dn)# label 42618001
!
CMERouter(config)# ephone-dn 2 octo-line
!
CMERouter(config-ephone)# description 7965 phone 1
CMERouter(config-ephone)# mac-address 0010.968C.C2B3
CMERouter(config-ephone)# username SCCP1 password cisco
!
009_9780133845969_ch09.indd 228 6/25/14 11:35 AM

Cisco Unified CME–Based SIP Phone Registration 229

Cisco Unified CME–Based SIP Phone Registration

The steps in the following configuration example show how to register Cisco Unified
CME–based SIP phones:
Step 1. Configure Cisco Unified CME as a TFTP server (for the phones) pointing to
the firmware files, as shown in the following configuration snippet:
CMERouter(config)# tftp-server flash:/Phones/9971/
dkern9971.100609R2-9-4-1-9.sebn alias dkern9971.100609R2-9-4-1-9.sebn
CMERouter(config)# tftp-server flash:/Phones/9971/kern9971.9-4-1-9.sebn
alias kern9971.9-4-1-9.sebn
CMERouter(config)# tftp-server flash:/Phones/9971/rootfs9971.9-4-1-9.
sebn alias rootfs9971.9-4-1-9.sebn
sboot9971.031610R1-9-4-1-9.sebn alias sboot9971.031610R1-9-4-1-9.sebn
CMERouter(config)# tftp-server flash:/Phones/9971/sip9971.9-4-1-9.loads
alias sip9971.9-4-1-9.loads
skern9971.022809R2-9-4-1-9.sebn alias skern9971.022809R2-9-4-1-9.sebn
Step 2. Allow SIP to SIP calls and specify the interface to bind media and signaling:
CMERouter(config)# voice service voip
CMERouter(conf-voi-serv)# allow-connections sip to sip
CMERouter(conf-voi-serv)# sip
CMERouter(conf-serv-sip)# registrar server
CMERouter(conf-serv-sip)# bind all source-interface GigabitEthernet 0/1
Step 3. Define the global voice register pool to initiate SIP phone registration. The
mode option cme sets the router to accept SIP registration as CUCME (the
default is SRST, as discussed later in this chapter). The source-address param-
eter defines the address and SIP port at which phones will try to register. Also
define the maximum number of DNs, pools, and so on. The create profile
command creates a SIP profile.
CMERouter(config)# voice register global
CMERouter(config-register-global)# mode cme
CMERouter(config-register-global)# source-address 10.76.108.76 port
5060
CMERouter(config-register-global)# max-dn 40
CMERouter(config-register-global)# max-pool 10
CMERouter(config-register-global)# load 9971 sip9971.9-4-1-9
009_9780133845969_ch09.indd 229 6/25/14 11:35 AM

CMERouter(config-register-global)# authenticate register

CMERouter(config-register-global)# tftp-path flash:
CMERouter(config-register-global)# create profile
Step 4. Create voice register DNs (equivalent to ephone DNs) and define voice register
pools (equivalent to ephones):
CMERouter(config)# voice register dn 1

CMERouter(config-register-dn)# number 8003
CMERouter(config-register-dn)# name Phone 1
CMERouter(config-register-dn)# label 42618003
!
CMERouter(config-register-dn)# name Phone 2
CMERouter(config-register-dn)# label 42618004
!
CMERouter(config)# voice register pool 1
CMERouter(config-register-pool)# id mac 64AE.0CF6.6C0D
CMERouter(config-register-pool)# type 9971
CMERouter(config-register-pool)# dtmf-relay sip-notify
CMERouter(config-register-pool)# username SIP1 password cisco
CMERouter(config-register-pool)# description 42618003
CMERouter(config-register-pool)# number 1 dn 1
CMERouter(config-register-pool)# session transport tcp
!
CMERouter(config-register-pool)# id mac 10BD.18DC.97F5
CMERouter(config-register-pool)# type 9971
CMERouter(config-register-pool)# dtmf-relay sip-notify
CMERouter(config-register-pool)# username SIP2 password cisco
CMERouter(config-register-pool)# description 42618004
CMERouter(config-register-pool)# session transport tcp
Cisco Unified CME Single Number Reach

Similar to CUCM, Cisco Unified CME also supports Single Number Reach (SNR) for
mobile workers. Users can set up remote destinations to receive calls on their handsets,
home phone, and so on. Example 9-3 illustrates SNR configuration for SCCP Cisco
Unified IP Phones.

Cisco Unified CME Single Number Reach 231
Example 9-3 SNR Configuration for SCCP Cisco Unified IP Phones
CMERouter(config)# ephone-template 1
CMERouter(config-ephone-template)# softkeys idle Dnd Gpickup Pickup Mobility
CMERouter(config-ephone-template)# softkeys connected Endcall Hold LiveRcd Mobility
!
CMERouter(config-ephone-dn)# mobility
CMERouter(config-ephone-dn)# snr 4082220000 delay 5 timeout 15 cfwd-noan 8100
!
CMERouter(config-ephone)# ephone-template 1
In Example 9-3, the Mobility softkey for idle and connected states is added to the ephone
template. The ephone DN is set to enable mobility and define SNR with remote num-
ber, delay, timeout, and no-answer parameters. Finally, the ephone DN is assigned to an
ephone.
Example 9-4 illustrates SNR configuration for SIP Cisco Unified IP Phones.
Example 9-4 SNR Configuration for SIP Cisco Unified IP Phones
CMERouter(config)# voice register template 1

CMERouter(config-register-temp)# softkeys idle Redial Cfwdall
CMERouter(config-register-temp)# softkeys connected Confrn Hold Endcall
!
CMERouter(config-register-dn)# mobility
CMERouter(config-register-dn)# snr calling-number local
CMERouter(config-register-dn)# snr 4082220000 delay 1 timeout 10
CMERouter(config-register-dn)# snr ring-stop
!
CMERouter(config-register-pool)# template 1
In Example 9-4, like the SCCP phone configuration in Example 9-3, the template is
changed to have idle/connected states with the Mobility softkey, followed by assigning
mobility and SNR options to the voice register DN, and assigning template and DN to the
voice register pool.

Survivable Remote Site Telephony

For uninterrupted call processing at remote sites when phones are unable to reach CUCM
(due to WAN disruption or CUCM server failure), Cisco Unified Survivable Remote Site
Telephony (SRST) can provide necessary call-control features. Cisco Unified SRST (here-
after also referred to simply as SRST) is a voice (Cisco IOS) gateway–based feature that
allows administrators to configure redundant call control for sites that do not have a local
CUCM server. Cisco IOS gateways support two types of SRST: (traditional) SRST (call-
manager fallback) and Cisco Unified CME–based SRST, also known as Enhanced SRST
(E-SRST). The major difference between the two types is that traditional SRST has basic
telephony features, whereas E-SRST provides an enhanced feature set to the endpoints
during SRST mode and Cisco Unified CME syncs with CUCM to get updates when they
happen on CUCM. Figure 9-2 depicts a Cisco Unified SRST and Cisco Unified CME
SRST solution.
Cisco Unified CME

CUCM SRST Router
Cluster
PSTN
Signaling with
SRST Gateway
Signaling with
CUCM
IP WAN
V
Cisco Unified SRST Router
(MGCP, H.323, SIP Gateway)
V PSTN
V
Signaling with
SRST Gateway
Figure 9-2 Cisco Unified SRST and Cisco Unified CME SRST Solution
Cisco Unified SRST is invoked when a phone loses connectivity to the CUCM server it
is registered with and attempts to register with its configured SRST reference (defined in
CUCM). In case of traditional SRST, the router builds upon the configured application
service. The SRST gateway detects newly registered IP Phones and queries them for their
configuration, and then auto-configures itself. The SRST gateway uses SNAP technology
to auto-configure the router to provide call processing. Cisco Unified SRST is mostly
leveraged with MGCP fallback, as explained in the next section. The following are some
features of Cisco Unified SRST:
■ Simple one-time configuration of basic SRST functions
■ Option for SRTP media encryption
■ Support for Forced Authorization Code (FAC)

■ Normalized +E.164 support
■ Customizable programmable line keys and button layout control
If the SRST reference defined in CUCM is a Cisco Unified CME router, the router first
looks for an existing configured ephone with the MAC address of the phone trying to
register. If an ephone is found, the stored configuration is used. No phone configuration
settings provided by SNAP are applied, and no ephone template is applied. If an ephone
is not located for the MAC address of the registration phone, the router adds the ephone
and applies an ephone template (similar to configuration using SNAP). Here are some
standout E-SRST features:
■ Automatic provisioning of remote branch sites since E-SRST router is in-sync with
CUCM that pushes the updates to the branch routers. Automatic sync for moves,
adds, and deletions from CUCM to router.
■ GUI interface for provisioning, monitoring, reporting, and troubleshooting.
■ On Demand information sync with CUCM.
Example 9-5 outlines SRST configuration.
Example 9-5 SRST Configuration
SRSTRouter(config)# call-manager-fallback
SRSTRouter(config-cm-fallback)# ip source-address 10.76.108.78 port 2000
SRSTRouter(config-cm-fallback)# max-ephones 10
SRSTRouter(config-cm-fallback)# max-dn 100
SRSTRouter(config-cm-fallback)# max-conferences 4 gain -6
SRSTRouter(config-cm-fallback)# transfer-system full-consult
SRSTRouter(config-cm-fallback)# secondary-dialtone 9
SRSTRouter(config-cm-fallback)# moh music-on-hold.au
SRSTRouter(config-cm-fallback)# time-format 24
SRSTRouter(config-cm-fallback)# date-format dd-mm-yy
SRSTRouter(config-cm-fallback)# system message SRST Mode
In Example 9-5, under call-manager-fallback, max-ephones and max-dn are defined for
the number of phones at the remote site. The secondary-dialtone option provides end
users with the usual dialing experience they would have when phones are registered with
CUCM. The specified MoH file allows playing MoH when a remote site is in SRST mode.
Even when the remote site is not in SRST mode, this feature can still be used to locally
provide multicast MoH at the remote site. The time-format and date-format parameters
set the correct time and date format for the phones.
Example 9-6 depicts Cisco Unified CME–based SRST.

Example 9-6 Cisco Unified CME–based SRST Configuration
CMERouter(config-telephony)# srst mode auto-provision none
CMERouter(config-telephony)# srst dn line-mode dual
CMERouter(config-telephony)# srst ephone template 1
CMERouter(config-telephony)# srst dn template 1
CMERouter(config-telephony)# srst ephone description E-SRST
CMERouter(config-telephony)# max-ephone 20
CMERouter(config-telephony)# moh music-on-hold.au
CMERouter(config-telephony)# max-conferences 4 gain -6
CMERouter(config-telephony)# secondary-dialtone 9
CMERouter(config-telephony)# system message SRST Mode
In Example 9-6, to enable Cisco Unified CME, under telephony-service the srst com-
mands define the mode for provisioning, the mode for ephone-dns (dual-line), the ephone
template, the DN template, and the description. Other options are similar to regular SRST
configuration, as explained in the previous Example 9-5.
Example 9-7 describes the configuration for Cisco Unified CME–based SIP SRST.
Example 9-7 Cisco Unified CME–based SIP SRST Configuration
CMERouter(config)# voice register global

CMERouter(config-register-global)# mode srst
CMERouter(config-register-global)# source-address 10.76.108.76 port 5060
CMERouter(config-register-global)# max-dn 40
CMERouter(config-register-global)# max-pool 10
CMERouter(config-register-global)# system message SRST Mode
<output omitted for brevity>
In Example 9-7, the Cisco Unified CME–based SIP configuration has been changed from
mode cme to srst.
In both SRST and E-SRST, a dial plan is required so that in the absence of CUCM, the
router can send and receive calls to and from the PSTN. Example 9-8 shows a basic dial
plan for an SRST gateway to accept incoming calls and to enable users to dial NANP
emergency, local, national, and international numbers.
009_9780133845969_ch09.indd 234 6/25/14 11:35 AM

Example 9-8 SRST Dial-Plan Configuration
SRSTRouter(config)# dial-peer voice 1 pots

SRSTRouter(config-dial-peer)# description incoming calls
SRSTRouter(config-dial-peer)# incoming called-number .
SRSTRouter(config-dial-peer)# direct-inward-dial
SRSTRouter(config-dial-peer)# port 0/2/0:23
SRSTRouter(config-dial-peer)# forward-digits all
!
SRSTRouter(config-dial-peer)# description Local
SRSTRouter(config-dial-peer)# destination-pattern 9[2-9]......
!
SRSTRouter(config-dial-peer)# description Long Distance
SRSTRouter(config-dial-peer)# destination-pattern 91[2-9]..[2-9]......
!
SRSTRouter(config-dial-peer)# description International
SRSTRouter(config-dial-peer)# destination-pattern 9011T
!
SRSTRouter(config-dial-peer)# description Emergency
SRSTRouter(config-dial-peer)# destination-pattern 911
Whether using Cisco Unified SRST or Cisco Unified CME–based SRST, the router has to
be defined as an SRST reference in CUCM. To configure an SRST reference, follow these
steps:
Step 1. Go to Cisco Unified CM Administration, choose System > SRST, click Add
New, and provide the required details about the remote site gateway, as shown
in Figure 9-3. Ensure that the SRST gateway’s hostname/IP address is defined
and the correct protocol (SCCP/SIP) port is chosen.

Figure 9-3 Cisco SRST Reference Configuration
Step 2. Browse to System > Device Pool and select a device pool for remote site
phones, assuming that you have created a device pool per remote site.
Configure the SRST reference in the device pool and save the configuration.
MGCP Fallback
MGCP fallback (briefly discussed in Chapter 3, “Telephony Standards and Protocols”) is
used to provide call-control functionality using an alternative application (H.323 opera-
tion) when a gateway is configured for MGCP in CUCM and CUCM is unreachable.
An MGCP gateway, like phones, also registers with CUCM. MGCP fallback enables a
gateway to act as a local call-control agent when the CUCM server to which remote site
phones and the gateway register is offline or WAN connectivity is lost. Therefore, Cisco
Unified SRST provides seamless call-control functionality. Figure 9-4 shows MGCP fall-
back (MGCP application to default application H.323).
To enable MGCP fallback and enable SRST, follow these steps:
Step 1. Configure an SRST reference in CUCM and assign it to the appropriate

CUCM device pool (covered in the previous section).
Step 2. Configure the Call Forward Unregistered (CFUR) internal and external des-
tinations on line appearance of remote-site phones to an E.164 number (for
example, a shared line on the main site or voicemail number). This is accom-
plished by going to Device > Phone, selecting a phone, selecting a line, and
setting CFUR.

Multicast Music on Hold in SRST 237
CUCM
Cluster MGCP Application
Gateway
Fallback
Default Application
H.323 MGCP Gateway
with SRST
IP WAN
V V
V
PSTN
Figure 9-4 MGCP Fallback
Step 3. Configure the MGCP fallback and Cisco Unified SRST on remote site
gateway(s) and implement an SRST dial plan on the remote site gateway(s).
MGCP fallback configuration is shown here:
MGCPRouter(config)# ccm-manager fallback-mgcp

MGCPRouter(config)# application
MGCPRouter(config-app)# global
MGCPRouter(config-app-global)# service alternate default
Multicast Music on Hold in SRST

Apart from CUCM-based MoH, which by default is unicast, an SRST router can play an
audio file from its flash as a multicast MoH to users in the remote sites. This helps save
valuable bandwidth otherwise required for streaming MoH over the WAN. This feature,
however, has some limitations:
■ A single MoH source must be used across all phones for this feature to work.
■ MoH from an SRST router cannot be unicast.
Multicast MoH can work in one of two modes:
■ Non-fallback mode: When the WAN link is up and the phones are controlled by
CUCM. This allows the phones to consult the local MoH file instead of reaching out
to CUCM across the WAN.
■ Fallback mode: When SRST is active; for example, when the remote site has lost con-
nectivity to the central site CUCM. In this case, the branch router can continue to
provide multicast MoH.
To configure multicast MoH, both the CUCM MoH server and the voice gateway at
the remote site need to be configured. Assuming that multicast routing in the router

is enabled and pim dense mode for required interface(s) is configured, CUCM and the
router must be designed to support multicast MoH. To configure CUCM to support mul-
ticast MoH, follow these steps in Cisco Unified CM Administration:
Step 1. Choose Media Resources > Music on Hold Audio Source and select the
audio source you are enabling for multicast. Ensure that the Allow Multicast
check box is checked.
Step 2. Navigate to Media Resources > Music on Hold Server Configuration. Enable
multicast support and select the option of using either the port number or the
IP address.
Step 3. Go to Media Resources > Media Resource Group (MRG) and click Add
New. Add a new MRG and ensure that it has the multicast-enabled MoH
server assigned to it and is multicast enabled.
Step 4. Assign the MRG to an MRGL by going to Media Resources > Media
Resource Group List and assigning the MRGL to a device pool.
Step 5. Configure the SRST router for multicast MoH. The following example shows
SRST multicast MoH configuration:
SRSTRouter(config)# ccm-manager music-on-hold

!
SRSTRouter(config)# interface loopback 10
SRSTRouter(config-if)# ip address 10.86.108.82 255.255.255.255
!
SRSTRouter(config)# call-manager-fallback
SRSTRouter(config-cm-fallback)# ip source-address 10.76.108.78 port
2000
SRSTRouter(config-cm-fallback)# moh music-on-hold.au
SRSTRouter(config-cm-fallback)# multicast moh 239.1.1.1 port 16384
route 10.86.108.82 10.76.108.78
Cisco IOS Dial Plan

Cisco IOS routers can implement a dial plan to route calls within a site, outside of a site
to the PSTN, or to a main site/another remote site. A Cisco IOS dial plan has multiple
components, such as:
■ Dial peer: For accepting VoIP or POTS calls coming into voice gateways and for
sending calls to destination devices/trunks. Dial peers can point to or accept calls
from an IP (H.323, SIP, MGCP) endpoint/call-control/ephone or a PBX/PSTN-facing
trunk (T1, E1, E1-R2, BRI).
■ Digit manipulation: For manipulating digits so that the calling/called number can
be changed and delivered as required to the destination; capabilities include the
following:

■ Number expansion (num-exp)
■ Automatic digit strip for POTS dial peers
■ Voice translation rules and profiles
■ Prefixing digits
■ Forwarding digits
■ Class of restriction (CoR): Enables limited incoming/outgoing calls as per classes of

restriction based on dial peers/ephones (as discussed in Chapter 5, “Cisco Unified
Communications Security”).
■ Call coverage: Allows implementing various call features, such as
■ Call hunting and hunt groups
■ Call pickup/waiting/forwarding
■ Shared DNs
■ Basic Cisco IOS queuing mechanisms
Voice Translation Rules and Profiles

Similar to CUCM, digit manipulation is required in Cisco IOS voice gateways to route
calls and translate a number (calling or called party) so that the call is successfully
routed to the destination. A voice translation rule can manipulate a calling-party num-
ber (Automatic Number Identification [ANI]) or a called-party number (Dialed Number
Identification Service [DNIS]) for incoming, outgoing, and redirected calls. Voice transla-
tion profile allows implementing the translation rule to a voice dial peer, voice port, trunk
group, SRST implementation, source IP group, and VoIP incoming as inbound or out-
bound translation rule for called or calling number. Table 9-1 shows the various regular
expressions used for voice translation rules.
Table 9-1 Voice Translation Rule Regular Expressions

Character Description
. Match any single digit.
0 to 9,*,# Any specific character.
[0–9] Any range or sequence of characters.
* Modifier-match none or more occurrences.
+ Modifier-match one or more occurrences.
? Modifier-match none or one occurrence.
\ In the match pattern, indicates where to slice the number, and in the replace-
ment pattern, indicates where to copy the number to keep.

Character Description
() Group regular expressions.
/ Delimiter that marks start and end of both matching and replacement strings.
^ Match an expression at start of a line.
Examples 9-9 and 9-10 illustrate voice translation rules followed by an expected output
using a test command.
Example 9-9 Voice Translation Rule - Number Expansion (Test Commands)
Router(config)# voice translation-rule 1

Router(cfg-translation-rule)# rule 1 /$^[2-9].........$/ /91\1/
Router(cfg-translation-rule)# rule 2 /^8.../ /9222&/
!
Router# test voice translation-rule 1 4082228000
Matched with rule 1
Original number: 4082228000 Translated number: 914082228000
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none
!
Matched with rule 2
Example 9-10 Voice Translation Rule - Digit Discard (Test Commands)

Router(cfg-translation-rule)# rule 1 /^9/ //
Router(cfg-translation-rule)# rule 2 /.*/ /2228000/
!
Matched with rule 1
!
Router# test voice translation-rule 2 .
Matched with rule 2
Original number: . Translated number: 2228000

With the rules defined, translation profiles are required to apply the rules at the dial peer
or trunk group level for incoming or outgoing calls as required. The following voice trans-
lation profiles can be defined:
■ called: Defines the translation profile rule for the called number
■ calling: Defines the translation profile rule for the calling number
■ redirect-called: Defines the translation profile rule for the redirect-called number
Using the previously defined rules as shown in Examples 9-9 and 9-10, the profiles can be
defined as shown in Example 9-11.
Example 9-11 Voice Translation Profile Configuration
Router(config)# voice translation-profile PSTN-OUT

Router(cfg-translation-profile)# translate calling 1
!
Router(config)# voice translation-profile PSTN-IN
Router(cfg-translation-profile)# translate called 2
!
Router(config)# dial-peer voice 250 POTS
Router(config-dial-peer)# translation-profile outgoing PSTN-OUT
Router(config-dial-peer)# destination-pattern 9T
Router(config-dial-peer)# forward digits all
Router(config-dial-peer)# port 0/0:23
!
Router(config)# dial-peer voice 251 POTS
Router(config-dial-peer)# translation-profile incoming PSTN-IN
Router(config-dial-peer)# incoming called-number .
Router(config-dial-peer)# direct-inward-dial
Router(config-dial-peer)# forward digits all
Router(config-dial-peer)# port 0/0:23
The Example 9-11 translation-rule 1 helps to set the outgoing calls (national) with a prefix
of 91 and the local calls with a prefix of 9. The translation-rule 2 helps strip 9 from calls
coming in with 9 as a prefix; otherwise, for any other match it sets the called number to
2228000. Finally, the translation profiles PSTN-IN and PSTN-OUT apply the rules to dial
peers 250 and 251 for outgoing and incoming calls, respectively.
At times, sending the numbering plan along with the dialed number (to PSTN) is required.
In such a case, the translation rule can be used to append the appropriate numbering plan
to different rules so that ANI (calling number) is understood correctly by the PSTN pro-
vider. Example 9-12 describes numbering plan manipulation using translation rules and
profiles.

Example 9-12 Voice Translation Rule Configuration with Plan Type

Router(cfg-translation-rule)# rule 1 /^.*/ /9&/ type any subscriber
Router(cfg-translation-rule)# rule 2 /^.*/ /91&/ type any national
Router(cfg-translation-rule)# rule 3 /^.*/ /9011&/ type any international
!
Router(config)# voice translation-profile PSTN-NumberPlan
Router(cfg-translation-profile)# translate calling 11
In Example 9-12, translation-rule 11 helps to output the right numbering plan against
local, national, and international calls to the PSTN provider. The test commands in
Example 9-13 verify the output.
Example 9-13 Voice Translation Test Commands
Router# test voice translation-rule 11 2228000 type subscriber

Matched with rule 1
Original number type: subscriber Translated number type: subscriber
!
Router# test voice translation-rule 11 4082228000 type national plan national
Matched with rule 2
Original number type: national Translated number type: national
Original number plan: national Translated number plan: national
Voice translation rules can also be used to block certain patterns as per policy or require-
ments. The following configuration illustrates voice translation rule setup to reject a par-
ticular pattern and provide a cause code of invalid number to the call initiator:
Router(cfg-translation-rule)# rule 1 reject /9011252*/
Cisco IOS Dial-Peer Matching Logic

Cisco IOS dial peers are used to route calls to VoIP and PSTN (POTS) destinations.
Multiple dial peers can be configured with various destination numbers (patterns) and
answer-address. Moreover, multiple dial peers with the same destination pattern may be
configured for redundancy. Dial-peer selection of the dial peer can be based on the called
number, such as DNIS, on the calling number, such as ANI, or on both. Keeping all this in
mind, there is dial-peer matching logic for outgoing and inbound calls that you must pay
attention to.

When matching an inbound dial peer, there is a specific order of matching that is based
on the configured parameters on the dial peer. In the case of inbound dial-peer matching,
the following rules apply:
1. Called number matching based on the DNIS is performed; based on the most explic-
it match. This is configured using the incoming called-number command.
2. If no dial peer is found, calling number matching based on the ANI is performed;
based on the most explicit match. This is configured using the answer-address
command.
3. Calling number matching based on the ANI is performed; based on the most explicit
match port. This is configured using the destination-pattern command.
4. If multiple dial peers have the same port (POTS dial peer), the dial peer added to the
configuration earlier (or in order of addition) is considered. Port-based matching is
configured with the port command.
5. If nothing matches, default dial-peer 0 is used.
When matching an outbound dial peer, the router always uses the destination-pattern
command. In case of outbound dial-peer matching, the following rule applies: called
number based on DNIS matching the outbound dial-peer destination pattern and most
explicit match. Dial-peer routing for POTS is based on the port command and for VoIP is
based on the session target command. In certain cases, two or more dial peers may have
the same destination pattern—for instance, VoIP dial peers to CUCM subscribers for call
processing redundancy. In such a case, the preference command can be added to each
dial peer to set a priority, with preference 0 being the default and highest preference.
Multiple dial peers can be defined with the same destination pattern with preference 1,
2, 3, and so on. Example 9-14 illustrates dial-peer preference configuration.
Example 9-14 Cisco IOS Router Dial-Peer Preference Configuration
IOSRouter(config)# dial-peer 100 voice voip

IOSRouter(config-dial-peer)# description Calls to Primary CUCM
IOSRouter(config-dial-peer)# preference 1
IOSRouter(config-dial-peer)# destination-pattern 8...
IOSRouter(config-dial-peer)# session-target ipv4:10.76.108.146
IOSRouter(config-dial-peer)# dtmf-relay h245-alphanumeric
IOSRouter(config-dial-peer)# no vad
!
IOSRouter(config)# dial-peer 101 voice voip
IOSRouter(config-dial-peer)# description Calls to Secondary CUCM
IOSRouter(config-dial-peer)# preference 2
IOSRouter(config-dial-peer)# destination-pattern 8...
IOSRouter(config-dial-peer)# session-target ipv4:10.76.108.147
IOSRouter(config-dial-peer)# dtmf-relay h245-alphanumeric
IOSRouter(config-dial-peer)# no vad

Cisco IOS Media Resources

Cisco IOS routers provide hardware digital signal processor (DSP) resources that can be
used for various media functions such as transcoding, conferencing, Media Termination
Point (MTP), and so on. This section covers DSP resource management and Cisco IOS–
based media resources.
Cisco IOS DSP Management

DSP resource management (DSPRM) is a Cisco IOS feature that maintains the state for
each DSP and DSP channel. DSPRM maintains a resource table for each DSP and has the
following features:
■ Resets DSPs, brings up DSPs, and downloads application images to DSPs during a
DSP upgrade
■ Discovers the on-board DSP SIMM modules and, based on the user configuration,
determines the type of application image that a DSP uses
■ Maintains the DSP initialization states and resource states, and manages the DSP
resources
■ Handles failures such as DSP crashes and session terminations while simultaneously
allowing log/crash dump generation
■ Provides keepalive mechanism between DSPs and primary and backup CUCM
servers
■ Performs periodic DSP resource checks and keeps a tab on maximum sessions
configured
■ Interfaces with the backplane Protocol Control Information (PCI) driver for sending
and receiving DSP control messages
When a request for a media session is received from the signaling layer, DSPRM assigns
the available DSPs from the respective media resource pool, such as transcoding or con-
ferencing, as instructed by CUCM’s MRGLs. Following are some useful commands to
monitor DSP resources:
■ show voice dsp active
■ show voice dsp group all
■ show voice dsp sorted-list
■ show voice dsp capabilities
■ show voice dsp group
■ show voice dsp statistics

Cisco IOS Media Resources 245
Cisco IOS Conferencing Resources

CUCM provides a conferencing facility for ad hoc and Meet-Me conferences (as dis-
cussed in Chapter 4, “Cisco Unified Communications Manager”). This section addresses
the configuration of a Cisco IOS hardware conference bridge to support CUCM confer-
encing. Example 9-15 shows the conference bridge configuration.
Example 9-15 Cisco IOS Hardware Conference Bridge Configuration
IOSRouter(config)# voice-card 0
IOSRouter(config-voicecard)# dsp services dspfarm
!
IOSRouter(config)# sccp local GigabitEthernet 0/0
IOSRouter(config)# sccp ccm 10.76.108.146 identifier 1 priority 1 version 7.0+
IOSRouter(config)# sccp
!
IOSRouter(config)# sccp ccm group 1
IOSRouter(config-sccp-ccm)# bind interface GigabitEthernet 0/1
IOSRouter(config-sccp-ccm)# associate ccm 1 priority 1
IOSRouter(config-sccp-ccm)# associate profile 1 register HWCFB
IOSRouter(config-sccp-ccm)# switchback method graceful
!
IOSRouter(config)# dspfarm profile 1 conference
IOSRouter(config-dspfarm-profile)# codec g711ulaw
IOSRouter(config-dspfarm-profile)# codec g711alaw
IOSRouter(config-dspfarm-profile)# codec g729ar8
IOSRouter(config-dspfarm-profile)# codec g729abr8
IOSRouter(config-dspfarm-profile)# codec g729r8
IOSRouter(config-dspfarm-profile)# codec g729br8
IOSRouter(config-dspfarm-profile)# maximum conference-participants 20
IOSRouter(config-dspfarm-profile)# maximum sessions 20
IOSRouter(config-dspfarm-profile)# associate application SCCP
IOSRouter(config-dspfarm-profile)# no shut
In Example 9-15, DSP resources on voice-card 0 (PVDM) are leveraged for the DSP farm.
SCCP is the application that drives the conference bridges on Cisco IOS. It is used to
bind the source interface to the application and set up the CUCM/Cisco Unified CME IP
address(es) that it should be registered with. The CCM group defines the various param-
eters related to the conference bridge and the name HWCFB with which the conference
resource registers with CUCM/Cisco Unified CME. Finally, the DSP profile defines the
purposes of the application—from conferencing to transcoding to MTP—and sets the
maximum participants per session and maximum sessions, sets the codecs acceptable
during conference calls, and associates the SCCP application to the profile. Note that the
same configuration framework is needed for Cisco Unified CME conferencing.

Cisco IOS Transcoding Resources

A Cisco IOS gateway’s DSPs can be leveraged for transcoding and as MTP resources, as
discussed in Chapter 4. Example 9-16 shows the configuration of an SCCP group and
a DSP profile for enabling transcoding resources on a Cisco IOS gateway (building on
Example 9-15).
Example 9-16 Cisco IOS Transcoding Configuration
IOSRouter(config)# sccp ccm group 1

IOSRouter(config-sccp-ccm)# bind interface GigabitEthernet 0/1
IOSRouter(config-sccp-ccm)# associate ccm 1 priority 1
IOSRouter(config-sccp-ccm)# associate profile 2 register HWXCD
IOSRouter(config-sccp-ccm)# switchback method graceful
!
IOSRouter(config)# dspfarm profile 2 transcode
IOSRouter(config-dspfarm-profile)# codec g711ulaw
IOSRouter(config-dspfarm-profile)# codec g711alaw
IOSRouter(config-dspfarm-profile)# codec g729ar8
IOSRouter(config-dspfarm-profile)# codec g729abr8
IOSRouter(config-dspfarm-profile)# maximum sessions 20
IOSRouter(config-dspfarm-profile)# associate application SCCP
IOSRouter(config-dspfarm-profile)# no shut
In Example 9-16, the SCCP CCM group is used to bind profile 2 (the transcoding profile)
and register it as HWXCD with CUCM/Cisco Unified CME. The DSP profile transcoding
allows SCCP to control the DSP resources and set up transcoding for various code
types. Note that the same configuration framework is needed for Cisco Unified CME
transcoding.
Cisco Unified CME–Based Media Resources

Cisco Unified CME, analogous to CUCM, also provides media resources for functions
such as conferencing, MTP, and transcoding. It also leverages Cisco IOS media resources
for the same purpose.
Cisco Unified CME Conferencing and Transcoding

Conferences in Cisco Unified CME can be supported using software or hardware confer-
ence bridges. Software conference bridges use a router CPU and have limitations such
as a maximum of three participants with G.711 codec only. As a leading practice it is
recommended to use hardware conference bridges where possible to avoid utilizing Cisco
Unified CME CPU resources for media functions. With a hardware conference bridge
enabled, more than three participants can join per conference, and in the case of

Cisco Unified CME–Based Media Resources 247
endpoints using multiple codecs, hardware conference bridges support transcoding as

well as conferencing.
For conference bridges to work, DNs need to be configured to act as bridges with the
ad hoc/Meet-Me feature enabled. These special DNs cannot be assigned to ephones or
have other features enabled. Moreover, conference DNs must be dual-line or octo-line to
support multiple participants. Cisco Unified CME supports two types of conferences:
ad hoc and Meet-Me conferences. Similar to CUCM ad hoc conference calls, the initia-
tor can call a party and use the Conf softkey to dial other parties and join them to the
conference. For Meet-Me conferences, the initiator presses the MeetMe softkey before
dialing the conference number, and other parties need to only dial the conference number
to join the conference.
Cisco Unified CME supports transcoding between G.711 and G.729 for three-way ad
hoc software conferencing, call forward/call transfer, MoH, and calls to CUE. Special DN
configuration for transcoding is not required because transcoding is activated when the
ephone participating in a differential codec call requires codec conversion.
Example 9-17 outlines the ad hoc/Meet-Me conference and transcoding configuration

(in addition to the Cisco IOS conference bridge and transcoding configuration detailed
earlier).
Example 9-17 Cisco Unified CME–based Conferencing and Transcoding Configuration
CMERouter(config- telephony)# conference hardware
CMERouter(config-telephony)# max-ephones 10
CMERouter(config-telephony)# sdspfarm conference mute-on 110 mute-off 111
CMERouter(config-telephony)# sdspfarm units 2
CMERouter(config-telephony)# sdspfarm tag 1 HWCFB
CMERouter(config-telephony)# sdspfarm transcode sessions 20
CMERouter(config-telephony)# sdspfarm tag 2 HWXCD
CMERouter(config-telephony)# transfer-system full-consult
CMERouter(config-telephony)# transfer-pattern 8...
!
CMERouter(config)# ephone-template 1
CMERouter(config-ephone-template)# softkeys hold Join Newcall Resume Select
CMERouter(config-ephone-template)# softkeys idle Cfwdall ConfList Dnd Join Newcall
Pickup Redial
CMERouter(config-ephone-template)# softkeys seized Endcall Redial Meetme Cfwdall
Pickup
CMERouter(config-ephone-template)# softkeys connected ConfList Confrn Endcall Hold
Select Trnsfer
!
CMERouter(config)# ephone-dn 1 dual-line


!
!
CMERouter(config-ephone-dn)# description ad-hoc conference A000
CMERouter(config-ephone-dn)# number A000
CMERouter(config-ephone-dn)# conference ad-hoc
!
CMERouter(config-ephone-dn)# description meet-me conference 8888
CMERouter(config-ephone-dn)# conference meetme
!
CMERouter(config-ephone-dn)# description meet-me conference 8888 extension
CMERouter(config-ephone-dn)# conference meetme
!
CMERouter(config-ephone)# mac-address 0010.968C.C2B3
CMERouter(config-ephone)# conference admin
CMERouter(config-ephone)# conference add-mode creator
CMERouter(config-ephone)# conference drop-mode creator
!

In Example 9-17, under telephony-service, the use of hardware conference prevents use
of Cisco Unified CME CPU resources for software conferences. The sdspfarm com-
mands are used to define conferencing and transcoding services by defining two units
so that two (dspfarms) services can be defined with different sdspfarm tags. The tags are
used to differentiate and define conferencing and transcoding services. Following this,
conferencing mute-on/mute-off (optional) codes and transcoding sessions are defined.
The ephone-template command sets the Idle, Sized, Connected, and Hold softkeys to
include support for ad hoc/Meet-Me conference calls and also to enable the user to dis-
play a list of conference participants. Ephone-dn 20 is a special ephone-dn used for ad
hoc conferencing, and ephone-dns 21 and 22 are also special ephone-dns used for Meet-
Me conference. The Meet-Me ephone-dns have call hunting, as ephone-dn 22 allows
hunting to the next ephone-dn 23 (lower preference) with the same extension. Finally,
the ephone templates and ephone-dns are assigned to the ephones, with the first ephone
assigned conference admin, add-mode creator (adding parties to conference), and drop-
mode creator (drops conference when creator leaves).
Cisco IOS–Based Call Queuing

Cisco IOS routers provide basic call queuing and self-service functionality thanks to TCL
scripts and hunt groups. This section covers Cisco IOS–based call queuing mechanisms.
Cisco Unified CME Basic Automatic Call Distribution

Cisco Unified CME provides a basic Interactive Voice Response (IVR)/Auto-Attendant
(AA) feature for sites that do not have a local Cisco Unity Express (CUE), Cisco Unity
Connection (CUC), or UCCX server. This feature is known as Basic Automatic Call
Distribution (B-ACD) and it can provide basic call handling and some self-service options
for incoming calls to a Cisco Unified CME. B-ACD can be used as a backup for UCCX/
IPCC when the link between the main and remote site is down, to provide basic IVR/self-
service options.
B-ACD is invoked when a call arrives either internally or from the PSTN and hits a dial
peer (VoIP/POTS) that is associated with the B-ACD application. The caller is sent to an
IVR that prompts the caller to choose from a list of options. For instance, “Press 1 for
Sales, press 2 for Marketing, or press 0 for the Operator.” If the caller presses 1 and no
one is available in the Sales department, the caller is placed in a queue. The caller then
waits for an agent to become available, during which time the music-on-hold is played.
The call can be sent back to the queue to find an active agent. If no agents are available,
the caller can then be sent to a final destination number (for example, voice mail).
B-ACD contains two TCL scripts, app-b-acd-aa-3.0.0.2.tcl and app-b-acd-3.0.0.2.tcl, the

only difference in the names being that the name of the first script includes –aa (which
stands for Auto-Attendant). The script with –aa is invoked when a call hits an Auto-
Attendant dial peer. The script has a twofold function: playing prompts and digit collec-
tion. The second script is in charge of routing the call to hunt groups and call queuing (if
the members of a hunt group are busy).

Assuming that B-ACD scripts have been downloaded and extracted to Cisco Unified
CME flash, the following steps are required to configure CME B-ACD:
■ Setting up call queuing and AA services
■ Setting up ephone hunt groups
■ Setting up incoming dial peers for AA pilot numbers
The B-ACD 3.0.0.2 script tar file can be downloaded from http://software.cisco.com/
download/release.html?mdfid=277641082&catid=278875240&softwareid=283451126&
release=8.8&relind=AVAILABLE&rellifecycle=&reltype=latest.
Example 9-18 shows B-ACD–based AA configuration.
Example 9-18 Cisco Unified CME–based B-ACD Script
CMERouter(config)# application
CMERouter(config-app)# service callqueue flash:/scripts/app-b-acd-3.0.0.2.tcl
CMERouter(config-app-param)# param queue-len 10
CMERouter(config-app-param)# param aa-hunt1 8888
CMERouter(config-app-param)# param number-of-hunt-grps 2
CMERouter(config-app-param)# param queue-manager-debugs 1
!
CMERouter(config-app)# service aa-bcd flash:/scripts/app-b-acd-aa-3.0.0.2.tcl
CMERouter(config-app-param)# paramspace english location flash:/prompts/
CMERouter(config-app-param)# paramspace english index 0
CMERouter(config-app-param)# paramspace english language en
CMERouter(config-app-param)# param aa-pilot 8000
CMERouter(config-app-param)# param voice-mail 8100
CMERouter(config-app-param)# param max-time-vm-retry 2
CMERouter(config-app-param)# param second-greeting-time 30
CMERouter(config-app-param)# param call-retry-timer 5
CMERouter(config-app-param)# param max-time-call-retry 30
CMERouter(config-app-param)# param service-name callqueue
CMERouter(config-app-param)# param queue-overflow-extension 8010
CMERouter(config-app-param)# param handoff-string aa-bcd
!
CMERouter(config)# ephone-hunt 1 longest-idle
CMERouter(config-ephone-hunt)# pilot 8888
CMERouter(config-ephone-hunt)# list 8001, 8002
CMERouter(config-ephone-hunt)# timeout 10, 10
!
CMERouter(config)# ephone-hunt 2 longest-idle
CMERouter(config-ephone-hunt)# pilot 8889

CMERouter(config-ephone-hunt)# list 8003, 8004

CMERouter(config-ephone-hunt)# timeout 10, 10
!
CMERouter(config-dial-peer)# service aa-bcd
CMERouter(config-dial-peer)# incoming called-number 8000
CMERouter(config-dial-peer)# no vad
!
CMERouter(config)# dial-peer voice 81 pots
CMERouter(config-dial-peer)# service aa-bcd
CMERouter(config-dial-peer)# incoming called-number 4082228000
CMERouter(config-dial-peer)# translation-profile incoming strip-E164
CMERouter(config-dial-peer)# direct-inward-dial
CMERouter(config-dial-peer)# port 1/0:23
CMERouter(config-dial-peer)# forward digits-all
In Example 9-18, service aa-bcd and callqueue are configured for AA and call queuing,
respectively. Going over application aa-bcd, you first notice the location of scripts, fol-
lowed by the location of prompts, and finally a description of the language for prompts
as English via paramspace english parameters. Next, aa-pilot is used to define the
B-ACD application’s pilot number, which must match the VoIP and/or POTS dial peer
incoming called number (this can be translated to the AA pilot number via translation
profiles). Next, Example 9-18 uses voice-mail to set the voicemail number and max-time-
vm-retry to set the maximum number of attempts to reach voicemail. Then the param-
eters for second greeting, call retry, and maximum call retries are defined. Following
these, the queue script is invoked (with hand-off from the AA script) that enables the call
to eventually land into one or more hunt groups, thereby enabling hunting of ephones
assigned to the hunt groups. The queue-overflow-extension sets the extension to send
calls to in case the queue length is exceeded.
Now, looking into the call queuing script, it begins by definition of the queue-len for
the calls that are not answered/answerable by ephones logged in to the hunt group. This
might occur if all logged-in (users) agents are busy or no agents are logged in. Then the
options to dial as per the B-ACD menu option (derived from en_bacd_options_menu.au)
for example, 1, 2, 0 (menu option 0 is hard coded for operator extension and the B-ACD
script assumes that the hunt group with the highest aa-hunt number is the operator
group) are configured with each hunt group associated with a number. Finally, queue-
manager-debugs enables debugging for the call queue.
A variation to B-ACD is to have the caller immediately routed to a configured hunt group
so that the caller does not hear any prompt and is not required to provide any DTMF
inputs. This type of B-ACD routing is known as a drop-through option. This is useful in
009_9780133845969_ch09.indd 251 6/25/14 11:35 AM

case the caller should be greeted and put into a queue to speak with an agent or wait for
an agent to become available. Example 9-19 shows the configuration of a drop-through
option.
Example 9-19 B-ACD Drop-Through Option
CMERouter(config)# application
CMERouter(config-app)# service callqueue flash:/scripts/app-b-acd-3.0.0.2.tcl
CMERouter(config-app-param)# param queue-len 10
!
CMERouter(config-app)# service aa-bcd flash:/scripts/app-b-acd-aa-3.0.0.2.tcl
CMERouter(config-app-param)# param drop-through-option 1
CMERouter(config-app-param)# param drop-through-prompt _bacd_welcome.au
It is important to note that both AA and call queuing applications need to be loaded
(activated). This is accomplished by using the following commands:
CMERouter# call application voice load callqueue
CMERouter# call application voice load aa-acd
Voice Hunt Groups

Cisco Unified CME offers voice hunt groups so that a call to a single number can be
answered by more than a single endpoint. In other words, voice hunt groups are a mecha-
nism of distributing calls among a group of phones so that the call is answered in time or
rings a dedicated final destination number, such as voice mail. Voice hunt groups support
the following features:
■ Calls can be forwarded to another voice hunt group.
■ Calls can be transferred to another voice hunt group.
■ The members of a voice hunt group can be SCCP endpoints, SIP endpoints, ds0-
group, pri-group, FXS port, or SIP trunk.
■ The maximum number of members in a voice hunt group is 32.
There are different types of hunting possible within a voice hunt group:
■ Sequential: Each extension number in the hunt group is tried sequentially, starting
from the first number. If the end of the group is reached without finding an

available number, the call is forwarded to a number configured as a final destination.

For example, in a hunt group with for members, 8001, 8002, 8003, and 8004, the call
hunting will always start at 8001.
■ Peer mode: A call is made to hunt extension numbers in a circular list. The starting
point in the list for a new call is set by the last number that answered the preceding
call—that is, n + 1, with n being the last number to answer the call. For example, in
a hunt group with members 8001, 8002, 8003, and 8004, if 8003 answered the last
call, then hunting will begin at 8004.
■ Longest Idle: As the name suggests, the starting point in the list for a new call is set
by the number that has been on-hook for the longest period of time. The number of
hops can be defined to allow a call to hop to longest-idle number before the call is
sent to final destination.
■ Parallel: All the numbers in the group rings simultaneously (also known as Call Blast,
covered in the next section).
To configure a voice hunt group, use the following command:
CMERouter(config)# voice hunt-group 1 [longest-idle | parallel | peer |

sequential ]
Call Blast
Call blast, also known as parallel hunt group, allows a user to dial a pilot number that
rings two to ten different extensions simultaneously. Call blast is analogous to the broad-
cast hunt-group mechanism in CUCM. The first extension to answer the call gets con-
nected to the caller, while other extensions stop ringing. A timeout value can be set so
that if none of the extensions answers before the timer expires, all the extensions stop
ringing and the final destination number rings indefinitely, which can be set to another
hunt group or a voicemail number. Example 9-20 shows the configuration of a call blast/
parallel hunt group that rings extensions 8001, 8002, 8003, 8004, and 8005 when the
pilot number 8700 or secondary E.164 4082228700 is called (from another ephone or a
dial peer).
Example 9-20 Call Blast/Parallel Hunt Group Configuration
CMERouter(config)# voice hunt-group 2 parallel

CMERouter(config-voice-hunt-group)# pilot 8700 secondary 4082228700
CMERouter(config-voice-hunt-group)# list 8001, 8002, 8003, 8004, 8005
CMERouter(config-voice-hunt-group)# final 8100
CMERouter(config-voice-hunt-group)# timeout 20
CMERouter(config-voice-hunt-group)# statistics collect

Cisco Unity Express

Cisco Unity Express (CUE) is the counterpart of CUC for voice mail for the Cisco
Express solution portfolio. CUE is often integrated with Cisco Unified CME to provide
a voicemail solution for an enterprise remote site or a small business. CUE runs on Cisco
IOS modules such as Advanced Integration Module (AIM2-CUE), Enhanced Network
Module (NME-CUE), and Services-Ready Engine (SM-SRE) modules. CUE typically
resides on the same chassis as Cisco Unified CME. However, for certain implementations,
CUE can reside on a dedicated Cisco IOS chassis. CUE also provides Auto-Attendant
functionality similar to that of CUC, although at a smaller scale.
Cisco Unified CME and CUE Integration

The integration between CUE and Cisco Unified CME is accomplished via SIP, while
the integration with a CUCM can be done via JTAPI/CTI-QBE. Example 9-21 illustrates
Cisco Unified CME and CUE integration.
Example 9-21 Cisco Unified CME Voicemail Configuration
CMERouter(config- telephony)# voicemail 8100
!
CMERouter(config-ephone-dn)# number 8110....
CMERouter(config-ephone-dn)# mwi on
!
CMERouter(config-ephone-dn)# number 8111....
CMERouter(config-ephone-dn)# mwi off
!
CMERouter(config-dial-peer)# dtmf-relay sip-notify
!
CMERouter(config-dial-peer)# incoming called-number 811[10]....
!
!
CMERouter(config)# interface ISM0/0
CMERouter(config-if)# ip unnumbered GigabitEthernet 0/0

Cisco Unified CME and CUE Integration 255
CMERouter(config-if)# service-module ip address 10.76.108.79 255.255.255.0

CMERouter(config-if)# service-module ip default-gateway 10.76.108.76
!
CMERouter(config)# ip route 10.76.108.79 255.255.255.255 ISM0/0
In Example 9-21, the voicemail number defined under telephony-service enables the
users to press the voice messaging (envelope) button and get to voicemail. The MWI On
and Off numbers are defined as a kind of prefix such that these On or Off numbers can
be prefixed to the extension for which MWI must be turned on or off. SIP dial-peer 8100
points to the CUE module’s IP address with the VM number as the destination pattern.
SIP dial-peer 8111 enables Cisco Unified CME to accept incoming MWI requests from
CUE and appropriately light up or switch off the MWI on a phone. The CUE interface
(Integrated Service Module [ISM] in this case) is bound with the Cisco Unified CME’s
interface, with the latter’s interface IP set as the default gateway for CUE, and a static
route points the way to the CUE module via the CLI or GUI.
In addition to the configuration in Example 9-21, CUE should be configured for voice-
mail application. This is accomplished by logging in to CUE using the command service-
engine ISM 0/0 session. CUE configuration for basic voicemail integration requires
setting up a system for SIP for routing to Cisco Unified CME and enabling it, setting up
the voicemail number and enabling it, and setting up MWI numbers. A list of existing
ccn applications, triggers, and subsystems can be seen by using the command show ccn
<parameter>, as shown in Example 9-22.
Example 9-22 CUE Outcalling MWI Configuration
CUE(config)# ccn subsystem sip

CUE(config-sip)# gateway address 10.76.108.76
CUE(config-sip)# enable
CUE(config-sip)# end
!
CUE(config)# ccn trigger sip phonenumber 8100
Adding new trigger
CUE(config-trigger)# enabled
CUE(config-trigger)# application "voicemail"
CUE(config-trigger)# end
!
CUE(config)# ccn application ciscomwiapplication aa
Modifying existing application
CUE(config-application)# description "ciscomwiapplication"
CUE(config-application)# enabled
CUE(config-application)# maxsessions 2
CUE(config-application)# script "setmwi.aef"
CUE(config-application)# parameter "CallControlGroupID" "0"
CUE(config-application)# parameter "strMWI_OFF_DN" "8111"

CUE(config-application)# parameter "strMWI_ON_DN" "8110"

CUE(config-application)# end application
The CUE web administration GUI can be accessed using the URL http://<IP address of
CUE>/admin/.
CUE Message Waiting Indicator

CUE supports multiple types of MWI mechanisms, which are based on SIP. The mecha-
nisms are
■ Outcalling (SIP INVITE)
■ Subscribe - Notify
■ Unsolicited Notify
Figure 9-5 gives an insight to the different MWI mechanisms that can be configured for a
CUE MWI application.
Figure 9-5 CUE MWI Options
Outcalling
The Outcalling option allows CUE to make an outbound call to the Cisco Unified CME
router using a SIP INVITE message. This option was covered in Example 9-22 (Cisco
Unified CME and CUE integration). The Outcalling option works for SCCP phones only.

CUE Message Waiting Indicator 257
(SIP) Subscribe Notify

CUE can be configured to send the NOTIFY message to Cisco Unified CME when
phones are subscribed to receive MWI updates using the SUBSCRIBE message. SIP
Notify is used to tell Cisco Unified CME to light the lamp for a particular extension.
This mechanism is employed for SIP phones. However, SCCP phones can also utilize this
mechanism. The Subscribe - Notify option can be used concurrently with the Outcalling
option. To configure the Subscribe - Notify mechanism in Cisco Unity Express
Administration, choose Voice Mail > Message Waiting Indicators > Settings and check
the Subscribe – Notify check box. Also, check the Include Envelope Information in
the Notifications check box. Example 9-23 outlines SIP and SCCP phones using the
Subscribe - Notify mechanism.
Example 9-23 CUE SIP Notify–based MWI
CMERouter(config-sip-ua)# mwi-server ipv4:10.76.108.79 port 5060
!
CMERouter(config-register-dn)# mwi
!
CMERouter(config-ephone-dn)# mwi sip
CMERouter(config-ephone-dn)# mwi-type both
The MWI server must be set up on the Cisco Unified CME so that the CUE IP address
and (optionally) port (as well as other parameters) are specified. SIP-based ephones (SIP-
UA) and SCCP-based ephone-dns send the SUBSCRIBE message to the MWI server that
is defined. The subscription definition forces the MWI service defined on the CUE and
CUE to notify the ephone-dns with an MWI update when there is a new voicemail mes-
sage for a voicemail subscriber.
Unsolicited Notify
CUE can be configured to notify MWI to endpoints without SUBSCRIBE. The
Unsolicited Notify option forces CUE to send the NOTIFY message to indicate that
a new message has been received on CUE and the ephone does not need to send the
SUBSCRIBE method to the MWI server. This implies that the voice register DN and
ephone DN no longer need the MWI option configured; the NOTIFY occurs without
subscription. The Unsolicited Notify option cannot be combined with the Outcalling

option. To configure the Unsolicited Notify mechanism in Cisco Unity Express

Administration, choose Voice Mail > Message Waiting Indicators > Settings and check
the Unsolicited Notify check box. Subsequently, the MWI server on Cisco Unified CME
needs to be set up to receive Unsolicited Notify, as shown in the following configuration
snippet:
CMERouter(config-sip-ua)# mwi-server ipv4:10.76.108.79 unsolicited port 5060
CUE Web Inbox

CUE Web Inbox offers subscribers (users) a means to easily and conveniently manage
their voice messages and greetings through the web browser. The user GUI is accessed by
going to http://<IP address of CUE>/user/. Users can listen to, save, delete, and compose
voicemail messages and greetings through the CUE Web Inbox GUI interface. Users can
manage all of the following mailbox settings via CUE Web Inbox:
■ Compose, reply, and forward voice mails
■ Use the inline recording tool
■ Upload a prerecorded message
■ Change message properties: Urgent, Private
■ Set messages for future message delivery
■ Manage all eight greetings (Standard, Internal, Closed, Busy, Alternate, Meeting,
Vacation, Extended Absence)
■ Manage notification devices and cascading settings
CUE VoiceView Express

The CUE VoiceView Express feature is analogous to the Visual Voicemail feature in CUC
that allows voicemail subscribers to browse, listen to, send, and manage their voicemail
messages from their Cisco Unified IP Phone’s display and softkeys. This can save time
compared to logging in to the GUI and is more intuitive compared to the usual Telephony
User Interface (TUI). The following steps define the configuration required to enable this
feature. Note that VoiceView Express is enabled by default on CUE.
Step 1. Go to Cisco Unity Express Administration and choose Voice Mail

>VoiceView Express >Service Configuration. Ensure that the Enable
VoiceView Express check box is checked, as shown in Figure 9-6.

CUE Auto-Attendant 259
Figure 9-6 Enabling CUE VoiceView Express
Step 2. Log in to the Cisco Unified CME router and add the respective command for
SCCP or SIP phones as follows:
CMERouter(config-telephony)# url services http://10.76.108.79/voiceview
VoiceView Express
CMERouter(config-register-global)# url service http://10.76.108.79/
voiceview
Step 3. Apply the configuration (create cnf-files for SCCP phones and create profile
for SIP phones) and reset the ephones.
CUE Auto-Attendant
CUE, as described earlier, can act as an auto-attendant (AA) for remote sites or small
business solutions. An AA solution is a logical mapping of greetings, options, and
responses that helps answer incoming calls by providing a menu-based system that offers
callers menu-based options or plays specific greetings. The CUE AA is based on scripts
that provide options or prompts that can be used for self-service options for a caller.
Cisco Unified Communications Express Editor can be employed to create customized
scripts for various AA flows. CUE scripting and Cisco Unified Communications Express
Editor are discussed in the next section.
CUE default installation includes a prebuilt (default) basic AA application. To config-

ure the CUE AA in Cisco Unity Express Administration, choose Voice Mail > Auto
Attendant and click on autoattendant (system default). You can set up the AA param-
eters as shown in Figure 9-7.

Figure 9-7 CUE AA Configuration
Alternatively, you can configure the AA parameters from the CUE CLI. The default AA
script is preconfigured in the CUE CLI and you can see the parameters/details by using
the command CUE# show ccn application aa. Example 9-24 shows configuration of AA
script.
Example 9-24 CUE AA Configuration via CLI
CUE(config)# ccn application autoattendant aa

Modifying existing application
CUE(config-application)# description "autoattendant"
CUE(config-application)# enabled
CUE(config-application)# maxsessions 10
CUE(config-application)# script "aa.aef"
CUE(config-application)# parameter "dialByExtnAnytime" "true"
CUE(config-application)# parameter "busOpenPrompt" "AABusinessOpen.wav"
CUE(config-application)# parameter "dialByExtnAnytimeInputLength" "4"
CUE(config-application)# parameter "operExtn" "8900"
CUE(config-application)# parameter "welcomePrompt" "AAWelcome.wav"
CUE(config-application)# parameter "disconnectAfterMenu" "false"
CUE(config-application)# parameter "dialByFirstName" "false"
CUE(config-application)# parameter "busClosedPrompt" "AABusinessClosed.wav"
009_9780133845969_ch09.indd 260 6/25/14 11:35 AM

CUE Scripting 261
CUE(config-application)# parameter "allowExternalTransfers" "false"

CUE(config-application)# parameter "holidayPrompt" "AAHolidayPrompt.wav"
CUE(config-application)# parameter "businessSchedule" "systemschedule"
CUE(config-application)# parameter "MaxRetry" "3"
CUE(config-application)# end application
Finally, Cisco Unified CME needs to redirect calls to a predetermined AA number to

CUE, as shown in Example 9-25.
Example 9-25 Cisco Unified CME to CUE SIP Dial Peer

CMERouter(config-dial-peer)# dtmf-relay sip-notify
CUE Scripting
In certain cases the standard AA can be too limited. For administrators and organiza-
tions that wish to leverage the CUE AA to its fullest potential, CUE offers a script editor
that allows the creation of custom scripts. Custom scripts can be loaded into CUE to
provide a much more complex AA application. CUE offers a built-in script editor and a
stand-alone Windows-based script editor, Cisco Unified Communications Express Editor.
Figure 9-8 shows the CUE built in script editor in action. To access the CUE built-in
script editor in Cisco Unity Express Administration, choose System > Scripts and click
New. The built-in script editor enables administrators to define multistep scripts and add
new elements such as a submenu, dial-by-name, dial-by-extension, and so on to create a
customized AA script.
Figure 9-8 depicts the aacustomized.aef script implementation.
Figure 9-8 shows how to create a customized script titled aacustomized.aef using the
CUE built-in script editor with the following settings and call flow:
■ Allows dialing by extension anytime during the main menu options. Extensions are
defined to have a four-digit length. Alternate Menu is chosen for Business Closed
hours. Business Schedule follows system schedule.
■ The script opens with a Welcome greeting during business hours.
009_9780133845969_ch09.indd 261 6/25/14 11:35 AM

■ The Auto-Attendant menu is played for normal business hours:
■ 1: Dial 8010 for Sales (transfer to extension 8010)
■ 2: Dial 8011 for Customer Service (transfer to extension 8011)
■ 3–8: Unassigned
■ 9: Dial by Extension
■ 0: Operator (transfer to extension 8999)
■ The Auto-Attendant menu is played for closed business hours.
■ The caller can press 1 to leave a message in operator (general) voicemail (transfer to
voicemail box 8999).
■ A goodbye prompt is played at the end of the conversation.
The Windows-based script editor allows you to create scripts on a PC (independent of

CUE). After you create scripts, you can upload them to and configure them on CUE.
Figure 9-9 depicts the Windows-based script editor.
Figure 9-8 CUE Script Editor: Customized Script

Figure 9-9 CUE PC-based Script Editor
The appearance and functionality of Cisco Unified Communications Express Editor

is similar to that of Cisco Unified CCX Editor (covered in Chapter 8). Cisco Unified
Communications Express Editor can be downloaded from http://software.cisco.com/
download/release.html?mdfid=283671889&flowid=45715&softwareid=282774364&
release=8.6.7&relind=AVAILABLE&rellifecycle=&reltype=latest.
CUE Voice Profile for Internet Email

CUE supports Voice Profile for Internet Email (VPIM) to allow voicemail message net-
working using Simple Mail Transfer Protocol (SMTP) and Multipurpose Internet Mail
Extensions (MIME). VPIM permits server to server message exchange (message inter-
working). VPIM networking functionalities are as follows:
■ Allows a message that was created on one system to be sent to another system (CUE
to CUE or CUE to CUC, and vice versa)
■ Uses SMTP to transport messages.
■ MIME is employed for voice mail, vCard (phone number, text name, and email
address), and spoken name transport.
■ Delayed delivery records are generated if a message is not delivered in 1 hour, and
non-delivery records are generated if the message is undeliverable after 6 hours.

The following terms are important in the context of VPIM:
■ Location: Represents a Cisco Unity Express or CUC system in a VPIM network. A

location must be defined for the local system and for a remote system participating
in VPIM networking. A location may send a vCard for a message targeted for a user
on a remote system.
■ Directory Entries: Provide spell-by-name and spoken-name confirmation. CUE

supports Static entries (Local users and manually defined Remote users), Dynamic
entries (LRU Cache), and No entries (uses Blind Addressing).
■ Least Recently Used (LRU) cache: When a system shares its location information
with a remote system, it allows the remote system to cache the information of the
sender. This cache is known as the LRU cache. The remote system references cached
information to address messages coming from VPIM networked system. It’s impor-
tant to understand that the LRU cache cannot be employed for defined remote users.
However, the local system must receive a message from a user on a remote system
before the LRU cache is populated.
■ Blind addressing: Used when no entry exists in the LRU cache of the remote system
and no remote user for the destination has been defined. In such case, the remote
user’s extension and location must be used to address the message.
To configure CUE to CUC VPIM networking, follow these steps:
Step 1. In Cisco Unity Express Administration, choose Configure > Network

Locations and click Add. Add a location and enter the required details such
as location name, abbreviation, domain name/IP address, VPIM broadcast ID,
and so on, as shown in Figure 9-10.
Step 2. Create a local location for the local CUE server followed by one or more
remote locations for CUC or CUE servers that will participate in VPIM.
Ensure that the local location is assigned as the local location by clicking the
location, typing the location ID in the Local Location ID field (as shown in
Figure 9-11), and then clicking Apply.
Step 3. Navigate to Configure > Remote Users and click Add. Provide the required
details such as user ID, first and last name, primary extension, display name,
and remote location.
Step 4. Go to Cisco Unity Connection Administration and choose Networking >

VPIM (assuming that an SMTP server is configured in CUC). Add a new loca-
tion and provide the required information such as display name (remote loca-
tion ID), dial ID (location ID), partition, SMTP domain name (for remote sys-
tem; i.e., CUE), and IP address (CUE), and optionally provide a remote phone
prefix, as shown in Figure 9-12.

Figure 9-10 CUE VPIM Location Definition
Figure 9-11 CUE Local and Remote VPIM Location Definition

Figure 9-12 CUC VPIM Location Definition
Step 5. Go to Contacts > Contacts and click Add New. Provide the required details
such as alias (user ID), first and last name, and display name. Ensure that the
List in Directory check box is checked. Define VPIM settings by defining
Delivery Location (configured in Step 4), VPIM Remote Mailbox Number,
and Local Extension.
To send VPIM messages on a Cisco Unified IP Phone, follow these steps:
Step 1. Press the Messages button and log in to your voice mailbox.
Step 2. Press option 2 and use the dial-by-extension option.
Step 3. If the user is defined as a remote user in CUE, dial the voice mailbox DN of
the VPIM user (for example, 8000) and record and send a message (location
is known to CUE). If the remote user is not defined, enter the location ID fol-
lowed by the voice mailbox extension.
Cisco IOS Call Admission Control

As previously discussed in Chapter 4, the purpose of Call Admission Control (CAC) is
to ensure that oversubscription of a (WAN) link doesn’t happen pertinent to voice/video
calls. In other words, CAC ensures that too many voice calls are not allowed across the
network on a WAN link, and that voice calls are admitted to the network only as long as

Cisco IOS Call Admission Control 267
the network can ensure sufficient quality of service. There are three types of CAC mech-
anisms, as described in this section:
■ Local CAC
■ Reservation-based CAC
■ Measurement-based CAC
Local CAC
Local CAC is based on a device’s local determination, such as the state of an outgoing
interface or link. The different mechanisms that are part of local CAC are
■ max-connections: Allows a dial peer to enforce a maximum connection limit on a

VoIP or POTS dial peer. The command max-conn puts limits on active connections
through a dial peer.
■ Local Voice Busyout (LVBO): Allows PBX trunks connected to a voice gateway to
be taken out of service when WAN conditions are not suitable for voice transport.
LVBO allows a gateway to monitor up to 32 interfaces and provides the ability to
monitor the state of network interfaces, including both LAN and WAN, and thereby
busy out trunks to the PBX if any of the monitored links fails. LVBO can be imple-
mented under voice ports (T1/E1) by using the command busyout monitor <inter-
face type>.
■ Voice Bandwidth: A Voice over Frame Relay (VoFR)-only mechanism as it allows

the map class to account for the bandwidth and deduct bandwidth on each active
call. Voice bandwidth is configured by the command frame-relay voice-bandwidth
<bandwidth in bps>.
Reservation-Based CAC
Reservation-based CAC is based on the reservation or calculation of required resources
before a call can be admitted. RSVP (discussed in Chapter 4), CUCM locations-based
CAC (LCAC), and gatekeeper zone–based CAC are types of reservation-based CAC.
Example 9-26 shows configuration of a gatekeeper zone–based CAC.
Example 9-26 Gatekeeper Zone–Based CAC
GKRouter(config)# gatekeeper
GKRouter(config-gk)# zone local CUCMGK corp.local 10.10.1.180
GKRouter(config-gk)# zone remote CMEGK corp.local 10.10.2.180
GKRouter(config-gk)# zone prefix CUCMGK 1*
GKRouter(config-gk)# gw-type-prefix 1#* default-technology
GKRouter(config-gk)# bandwidth session zone CUCMGK 256
GKRouter(config-gk)# bandwidth total zone CUCMGK 2048

GKRouter(config-gk)# bandwidth interzone default 512

GKRouter(config-gk)# bandwidth remote 512
GKRouter(config-gk)# no shutdown
In Example 9-26, bandwidth commands are used to define per-session (call) bandwidth
for calls from the CUCMGK zone, total bandwidth available for the CUCMGK zone,
default interzone bandwidth between CUCMGK and other zones, and the bandwidth
available between CUCMGK and a remote CMEGK zone. It is important to note that
gatekeepers subtract bandwidth from a configured pool of bandwidth twice that of a
codec bit rate (such as a G.711 call that uses 64 Kbps from one endpoint). A gatekeeper
subtracts 128 Kbps (for bidirectional call) and likewise 16 Kbps for a 8-Kbps G.729 call
between two endpoints.
Measurement-Based CAC
Measurement-based CAC techniques look ahead into the network to measure the state
of the network in order to determine whether to allow a new call. This involves the use
of probes such as Cisco Service Level Agreement (SLA) or Service Assurance Agent
(SAA) probes. Measurement-based CAC mechanisms include Advanced Voice Busyout
(AVBO) and PSTN Fallback. AVBO is an advancement of the LVBO feature that adds the
capability to probe destinations using Cisco SLA/SAA and has the ability to busy out a
trunk or voice ports based on network conditions. AVBO uses the Impairment Calculated
Planning Impairment Factor (ICPIF) or specific network delay, or loss values for its opera-
tion. PSTN fallback is based on SAA and acts on ICPIF or delay, or loss values as con-
figured. PSTN fallback does not busy out a trunk or voice ports, but instead works on a
per-call basis.
Cisco IOS CDR Accounting

Cisco IOS gateways support accounting that can be used for collecting information.
This data can be used for a number of purposes such as billing, auditing, and report-
ing. Specific to the Cisco IOS voice feature, gateways allow Call Detail Record (CDR)
accounting to gather CDRs from Cisco IOS gateways analogous to CUCM CDRs. Each
accounting record contains accounting attribute-value (AV) pairs. Accounting packets for
voice calls consist of standard and voice-specific attributes.
Cisco IOS voice gateways can generate CDRs using three different accounting methods:
■ File accounting: CDR information is written into CSV files, and these files can be
transferred to a billing server using FTP.
■ Syslog: Syslog protocol–based accounting for CDRs.
■ RADIUS: RADIUS-based CDR accounting

Cisco IOS CDR Accounting 269
File Accounting
The file accounting method is the simplest to set up and enables you to specify one of
three formats for CDR data:
■ Detailed: All attributes are sent.
■ Compact: Minimal attributes are sent based on options available with the
cdr-format compact command.
■ Customized: Accounting templates can be built as required.
A central FTP server or site-specific FTP server (preferred for SRST scenarios) is required
to receive CSV files from the router. Example 9-27 outlines the configuration for the file
accounting method.
Example 9-27 File Accounting–based CDR Accounting
Router(config)# gw-accounting file

Router(config-gw-accounting-file)# primary ftp 10.96.108.100 username cdradmin
password 0 C1sc0123
Router(config-gw-accounting-file)# cdr-format compact
Router(config-gw-accounting-file)# maximum buffer-size 10
Router(config-gw-accounting-file)# maximum retry-count 5
Router(config-gw-accounting-file)# maximum fileclose-timer 30
Router(config-gw-accounting-file)# maximum cdrflush-timer 300
In Example 9-27 the router is set up for file accounting, with the primary FTP server and
credentials defined. The CDR format is kept at compact (regular set of VSAs) with the
CDR buffer size set to 10, the file close timer set to 30 minutes, and the CDR flush timer
set to 300 minutes. The retry interval (keepalive) for the primary server is set to five tries.
Syslog-Based CDR Accounting

Syslog-based CDR accounting is useful in environments where syslog is deployed across
remote sites and at the central site. However, CDRs are considered non-critical. This is
primarily because syslog works on the User Datagram Protocol (UDP), and in case of
network problems, there can be instances where CDRs are lost in transit. To enable sys-
log-based CDR accounting, use the command gw-accounting syslog.
RADIUS-Based CDR Accounting

RADIUS-based accounting is useful when an organization has standardized AAA con-
trols using RADIUS and requires various VSAs relevant to voice CDRs. Example 9-28
shows the configuration of RADIUS-based CDR accounting.

Example 9-28 RADIUS-based CDR Accounting
Router(config)# aaa new-model

!
Router(config)# aaa authentication login h323 group radius
Router(config)# aaa authorization exec h323 group radius
Router(config)# aaa accounting connection h323 start-stop radius
Router(config)# aaa session-id common
Router(config)# radius-server host 10.76.108.202 auth-port 1812 acct-port 1813
Router(config)# radius-server key C1sc0123
Router(config)# radius-server vsa send accounting
Router(config)# radius-server vsa send authentication
!
Router(config)# gw-accounting aaa
Router(config-gw-accounting-aaa)# acct-template callhistory-detail
Router(config-gw-accounting-aaa)# attribute acct-session-id overloaded
Router(config-gw-accounting-aaa)# attribute h323-remote-id resolved
In Example 9-28 AAA is enabled on the Cisco IOS router, followed by setting up the
router to send H.323 attributes and to communicate with a RADIUS server. VSA attri-
butes are set up to be reported by the RADIUS server. Finally, gw-accounting aaa
enables RADIUS AAA accounting and sets up the router to send all call history VSAs
(equivalent to detailed format in file accounting) with attributes from sessions and
remote h323-id.
Cisco Service Advertisement Framework and Call

Control Discovery
Chapter 4 provides an in-depth introduction to SAF and CCD. The purpose of this sec-
tion is to explore the configuration of Cisco SAF Forwarder—that is, configuring a Cisco
IOS router to support Cisco SAF clients (CUCM and CUCME). Figure 9-13 depicts the
SAF client–forwarder relationship and various protocols and entities involved in a SAF
network.
Example 9-29 builds on Figure 9-13 by showing the configuration of SAF and CCD on a
Cisco IOS router.
Example 9-29 SAF and CCD Configuration on IOS Router
SAFRouter(config)# router eigrp SAF

SAFRouter(config-router)# service-family ipv4 autonomous-system 100
SAFRouter(config-router-sf)# neighbor 10.76.108.235 loopback 0 remote 10
SAFRouter(config-router-sf)#topology base
SAFRouter(config-router-sf-topology)#external-client CUCM-Cluster1
SAFRouter(config-router-sf)# sf-interface GigabitEthernet 0/0

Cisco Service Advertisement Framework and Call Control Discovery 271
SAFRouter(config-router-sf-interface)# no split-horizon
SAFRouter(config-router-sf-interface)# hello-interval 10
SAFRouter(config-router-sf-interface)# hold-time 20
!
SAFRouter(config)# service-family external-client listen ipv4 5050
SAFRouter(config-external-client)# external-client CUCM-Cluster1
SAFRouter(config-external-client-mode)# username CUCM-SAF
SAFRouter(config-external-client-mode)# password C1sc0123456
SAFRouter(config-external-client-mode)# keepalive 5000
!
SAFRouter(config)# voice service saf
SAFRouter(conf-voi-serv-saf)# profile trunk-route 1
SAFRouter(conf-voi-serv-saf-tr)# session protocol sip interface loopback 0 transport
udp port 5060
SAFRouter(conf-voi-serv-saf)#profile dn-block 1
SAFRouter(conf-voi-serv-saf-dnblk)#pattern 1 type global 1408222XXXX
SAFRouter(conf-voi-serv-saf-dnblk)#pattern 2 type extension 43611000
SAFRouter(conf-voi-serv-saf)# profile callcontrol 1
SAFRouter(conf-voi-serv-saf-cc)# dn-service
SAFRouter(conf-voi-serv-saf-cc-dn)# trunk-route 1
SAFRouter(conf-voi-serv-saf-cc-dn)# dn-block 1
SAFRouter(conf-voi-serv-saf)# channel 1 vrouter SAF asystem 100
SAFRouter(conf-voi-serv-saf-chan)# subscribe callcontrol wildcarded
SAFRouter(conf-voi-serv-saf-chan)# publish callcontrol 1
CUCM Cluster
(SAF External Client)
CCD
SAF Client SAF Publish/

Protocol Advertise
SAF Forwarding
Protocol
SAF Network
SAF Notify
SAF Forwarder SAF Forwarder
(Adjacent Neighbors)
Figure 9-13 SAF Client–Forwarder Relationship and SAF Network

SAF leverages EIGRP (virtual router), although the underlying network can use static
routing or any dynamic routing protocol. EIGRP routing instance SAF initiates a SAF-
associated configuration on the Cisco IOS router. The service-family and autonomous-
system attributes are required because SAF clients must know them to register with
this forwarder. Neighbors won’t form a neighbor relationship unless these values match
between forwarders. The sf-interface command (a default command that allows SAF on
all interfaces) permits a specific interface, thereby limiting SAF to a particular interface.
SAF authorizes multiple service topology databases per service-family, in this case defin-
ing SAF client(s). The service-family allows SAF client configuration so that a client–
forwarder authentication relationship can be built. A client label is unique across an AS,
and only one client can use a client label. The username and password are implemented
for security validation with a SAF client. Keepalives are used between the SAF client and
forwarder to ensure that the forwarder is available; otherwise, the clients can reroute the
calls out the alternate path (PSTN).
The command voice service saf initiates CCD service on the router. This is followed by
creating a trunk profile to let other devices know with which protocol to contact the SAF
client/forwarder. The dn-block command defines the routes to advertise. A callcontrol
profile ties all these entities together. Finally, the callcontrol profile(s) need to be associ-
ated with SAF as, for instance, a channel using the EIGRP process name and AS number.
The publish process advertises the callcontrol profile to the SAF network, whereas the
subscribe process makes the router listen to wildcard (all) advertisements (could be set to
listen to specific advertisements as well).
Cisco Unified Border Element

Cisco Unified Border Element (CUBE) is a Cisco IOS–based feature that is available in
Cisco Integrated Services Routers Generation 2 (ISR G2) and Cisco Aggregation Services
Routers (ASR) platforms and enables organizations to consume SIP trunking services
(primarily) from a SIP service provider/IT service provider (SIP SP/ITSP) network. CUBE
provides the following functionality and services:
■ A security demarcation (border) between the trusted enterprise network and untrust-
ed public network.
■ Hiding of internal enterprise IP addresses, presenting a single IP address for signaling

and media to the outside world (ITSP).
■ A single point for controlling signaling and media.
■ Advanced media interworking features such as background noise cancellation, QoS

marking, and sophisticated interface queuing mechanisms.
■ Tools such as Cisco IOS Firewall (providing Context-Based Access Control) and
Cisco Intrusion Prevention System (IPS) to manage common vulnerability exploits,
such as preventing denial-of-service (DoS) attacks and detecting malformed packets.
■ DTMF interworking, transcoding, and other media functions.

CUBE Redundancy
As an important part of the SIP trunking solution, CUBE should be deployed in high-
availability (redundant) mode where possible. The following options are available for
CUBE redundancy:
■ Inbox redundancy: Provides high-availability within the same box (local redun-
dancy) in the same chassis (supported in Cisco ASR 1000 Series only) with stateful
failover. Inbox redundancy can be hardware based or software based. Hardware-
based inbox redundancy leverages a dual-control plane and a dual-forwarding plane
in ASR 1006—for example, two route processors (Active/Standby) within the same
chassis. Software-based redundancy is supported with Cisco ASR 1001, 1002, and
1004 Series, wherein two instances of Cisco IOS run on the same route processor.
■ Box-to-box redundancy (Layer 2): Uses Hot Standby Router Protocol (HSRP) and
the underlying switching infrastructure to form an Active/Standby pair of routers.
Inheriting the HSRP feature, the Active/Standby pair shares the same virtual IP (VIP)
address and persistently exchanges keepalive messages. The two physical chassis can
be placed in the same data center or can be geographically separated (provided Layer
2 SLAs are met). Box-to-box redundancy is available for Cisco ISR G2 and Cisco
ASR 1001, 1002, 1004 and 1006, and supports stateful failover.
■ Clustering (with load balancing): Offers both high availability and scalability by
spreading calls across different chassis in the same data center or geographically
separated sites. Clustering allows multiple CUBE routers (ASRs and ISRs) to perform
load balancing as a SIP proxy manages call distribution across the cluster.
CUBE box-to-box high availability is covered in this section. Figure 9-14 shows the
CUBE chassis (ISR G2 router) deployed in a box-to-box redundancy configuration
using HSRP.
Inside Outside
Active CUBE
GE 0/0 GE 0/1
10.76.108.2 192.168.108.2
CUCM
Cluster HSRP Address Keepalives Keepalives HSRP Address
10.76.108.1 192.168.108.1
SIP SP
Network
HSRP HSRP
Keepalives Keepalives Group 9
Group 1 192.168.108.254
10.76.108.146
10.76.108.3 192.168.108.3
GE 0/0 GE 0/1
Standby CUBE
Figure 9-14 CUBE Box-to-Box Redundancy
Example 9-30 and Example 9-31 outline the Active and Standby CUBE configurations.
009_9780133845969_ch09.indd 273 6/25/14 11:35 AM

Example 9-30 Active CUBE Router Configuration
CUBEA(config)# voice service voip

CUBEA(conf-voi-serv)# mode border-element
CUBEA(conf-voi-serv)# allow-connections sip to sip
CUBEA(conf-voi-serv)# redundancy
!
CUBEA(config)# redundancy inter-device
CUBEA(config-red-interdevice)# scheme standby SB-Group
!
CUBEA(config)# track 1 interface GigabitEthernet 0/0 line-protocol
!
CUBEA(config)# track 2 interface GigabitEthernet 0/1 line-protocol
!
CUBEA(config)# ipc zone default
CUBEA(config-ipczone)# association 1
CUBEA(config-ipczone-assoc)# protocol sctp
CUBEA(config-ipc-protocol-sctp)# local-port 5500
CUBEA(config-ipc-local-sctp)# local-ip 10.76.108.2
CUBEA(config-ipc-protocol-sctp)# remote-port 5500
CUBEA(config-ipc-remote-sctp)# remote-ip 10.76.108.3
CUBEA(config-ipczone-assoc)# no shutdown
!
CUBEA(config)# interface GigabitEthernet 0/0
CUBEA(config-if)# ip address 10.76.108.2 255.255.255.0
CUBEA(config-if)# standby version 2
CUBEA(config-if)# standby 1 ip 10.76.108.1
CUBEA(config-if)# standby 1 priority 50
CUBEA(config-if)# standby 1 track 1 decrement 10
CUBEA(config-if)# standby 1 preempt
CUBEA(config-if)# standby 1 name SB-Group
!
CUBEA(config)# interface GigabitEthernet 0/1
CUBEA(config-if)# ip address 192.168.108.2 255.255.255.0
CUBEA(config-if)# standby version 2
CUBEA(config-if)# standby 9 ip 192.168.108.1
CUBEA(config-if)# standby 9 priority 50
CUBEA(config-if)# standby 9 preempt
CUBEA(config-if)# standby 9 track 2 decrement 10
!
CUBEA(config)# dial-peer voice 500 voip
CUBEA(config-dial-peer)# description Calls-To-SIP-SP
CUBEA(config-dial-peer)# destination-pattern 9T
CUBEA(config-dial-peer)# session protocol sipv2
CUBEA(config-dial-peer)# session target ipv4:192.168.108.254

CUBEA(config-dial-peer)# voice-class sip bind control source-interface

GigabitEthernet 0/1
CUBEA(config-dial-peer)# voice-class sip bind media source-interface
GigabitEthernet 0/1
CUBEA(config-dial-peer)# codec g711ulaw
!
CUBEA(config)# dial-peer voice 510 voip
CUBEA(config-dial-peer)# description Calls-To-CUCM
CUBEA(config-dial-peer)# destination-pattern 408222....
CUBEA(config-dial-peer)# session protocol sipv2
CUBEA(config-dial-peer)# session target ipv4:10.76.108.146
CUBEA(config-dial-peer)# voice-class sip bind control source-interface
GigabitEthernet 0/0
CUBEA(config-dial-peer)# voice-class sip bind media source-interface
GigabitEthernet 0/0
CUBEA(config-dial-peer)# codec g711ulaw
!
CUBEA(config)# ip rtcp report interval 3000
!
CUBEA(config)# gateway
CUBEA(config-gateway)# media-inactivity-criteria all
CUBEA(config-gateway)# timer receive-rtp 86400
CUBEA(config-gateway)# timer receive-rtcp 5
Example 9-31 Standby CUBE Configuration
CUBEB(config)# voice service voip

CUBEB(conf-voi-serv)# mode border-element
CUBEB(conf-voi-serv)# allow-connections sip to sip
CUBEB(conf-voi-serv)# redundancy
!
CUBEB(config)# redundancy inter-device
CUBEB(config-red-interdevice)# scheme standby SB-Group
!
CUBEB(config)# track 1 interface GigabitEthernet 0/0 line-protocol
!
CUBEB(config)# track 2 interface GigabitEthernet 0/1 line-protocol
!
CUBEB(config)# ipc zone default
CUBEB(config-ipczone)# association 1
CUBEB(config-ipczone-assoc)# protocol sctp
CUBEB(config-ipc-protocol-sctp)# local-port 5500
CUBEB(config-ipc-local-sctp)# local-ip 10.76.108.3
CUBEB(config-ipc-protocol-sctp)# remote-port 5500
CUBEB(config-ipc-remote-sctp)# remote-ip 10.76.108.2
CUBEB(config-ipczone-assoc)# no shutdown

!
CUBEB(config)# interface GigabitEthernet 0/0
CUBEB(config-if)# ip address 10.76.108.3 255.255.255.0
CUBEB(config-if)# standby version 2
CUBEB(config-if)# standby 1 ip 10.76.108.1
CUBEB(config-if)# standby 1 priority 50
CUBEB(config-if)# standby 1 preempt
CUBEB(config-if)# standby 1 track 1 decrement 10
CUBEB(config-if)# standby 1 name SB-Group
!
CUBEB(config)# interface GigabitEthernet 0/1
CUBEB(config-if)# ip address 192.168.108.3 255.255.255.0
CUBEB(config-if)# standby version 2
CUBEB(config-if)# standby 9 ip 192.168.108.1
CUBEB(config-if)# standby 9 priority 50
CUBEB(config-if)# standby 9 preempt
CUBEB(config-if)# standby 9 track 2 decrement 10
!
CUBEB(config)# dial-peer voice 500 voip
CUBEB(config-dial-peer)# description Calls-To-SIP-SP
CUBEB(config-dial-peer)# destination-pattern 9T
CUBEB(config-dial-peer)# session protocol sipv2
CUBEB(config-dial-peer)# session target ipv4:192.168.108.254
CUBEB(config-dial-peer)# voice-class sip bind control source-interface
GigabitEthernet 0/1
CUBEB(config-dial-peer)# voice-class sip bind media source-interface
GigabitEthernet 0/1
CUBEB(config-dial-peer)# codec g711ulaw
!
CUBEB(config)# dial-peer voice 510 voip
CUBEB(config-dial-peer)# description Calls-To-CUCM
CUBEB(config-dial-peer)# destination-pattern 408222....
CUBEB(config-dial-peer)# session protocol sipv2
CUBEB(config-dial-peer)# session target ipv4:10.76.108.146
CUBEB(config-dial-peer)# voice-class sip bind control source-interface
GigabitEthernet 0/0
CUBEB(config-dial-peer)# voice-class sip bind media source-interface
GigabitEthernet 0/0
CUBEB(config-dial-peer)# codec g711ulaw
!
CUBEB(config)# ip rtcp report interval 3000
!
CUBEB(config)# gateway
CUBEB(config-gateway)# media-inactivity-criteria all
CUBEB(config-gateway)# timer receive-rtp 86400
CUBEB(config-gateway)# timer receive-rtcp 5

In Example 9-30 and Example 9-31, under voice service voip (global mode), the mode
is defined as border-element and redundancy is enabled for SIP connections and enables
CUBE checkpointing (a stateful failover mechanism). Next, a redundancy scheme is
defined via the scheme standby command. The track interface command allows the
router to track the line protocol state of the monitored interfaces. The ipczone commands
help define HSRP configuration for keepalive exchange. The standby commands enable
HSRP on the internal CUCM facing and external SIP SP-facing interfaces, respectively.
The dial peers define calls to the SIP SP and CUCM and bind media as well as signaling
to respective interfaces. The ip rtcp and media-inactivity commands configure a media
inactivity feature to clean up any calls that may not disconnect after a failover.
CUBE SIP Profiles

CUBE SIP profiles is a mechanism used to normalize or customize SIP messages at the
network border (border implies the logical boundary shared between an enterprise and
a service provider) to provide interoperability between potentially incompatible devices.
SIP incompatibilities can arise due to
■ A device rejecting an unknown header (value or parameter) instead of ignoring it
■ A device expecting an optional header value or parameter
■ A device sending a value or parameter that must be changed or suppressed or “nor-

malized” before it leaves or enters the enterprise logical perimeter to comply with an
service provider’s or organization’s policies
Figure 9-15 illustrates the concept of SIP profiles.
SIP INVITE Sent By CUBE SIP INVITE Expected By SIP SP
Sent: Sent:
INVITE sip:[email protected]:5060 SIP/2.0 INVITE sip:[email protected]:5060 SIP/2.0
......... .........
User-Agent: Cisco-SIPGateway/IOS-15.2.3.T User-Agent: Cisco CUCM9.1/IOS-15.2.3T
......... .........
Diversion: <sip:[email protected]>; Diversion: <sip:[email protected]>;
privacy=off;reason=unconditional;screen=yes privacy=off;reason=unconditional;screen=yes
......... .........
m=audio 6001 RTP/AVP 0 8 18 101 m=audio 32278 RTP/AVP 18 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
......... .........
SIP SP
Network
CUBE
Figure 9-15 CUBE to SIP SP Communication and SIP Normalization

Pertinent to Figure 9-15, the following are requirements of the SIP SP:
■ Condition 1: For call forward and transfer scenarios back to the PSTN, the diversion
header should match the registered DID (E.164 number).
■ Condition 2: The User-Agent (UA) field in all SIP messages should state the version
of CUCM and CUBE.
The SIP INVITE sent by CUBE needs to be normalized so that the SP network can accept
the incoming SIP INVITE as per the configuration of the SP softswitch. In this case a SIP
profile needs to be defined to help normalize diversion headers to an E.164 number and
set the UA field to the correct CUCM and CUBE version. Example 9-32 illustrates the
CUBE SIP profile that supports both normalization tasks (SIP INVITE and REINVITE
diversion header and SIP UA description).
Example 9-32 CUBE SIP Normalization Profile
CUBE(config)# voice class sip-profiles 1000

CUBE(config-class)# request INVITE sip-header Diversion modify "sip:(.*>)"
"sip:[email protected]"
CUBE(config-class)# request REINVITE sip-header Diversion modify "sip:(*.>)"
"sip:[email protected]"
CUBE(config-class)# request ANY sip-header User-Agent modify "User-Agent:(.*)"
"User-Agent: CUCM 9.1/IOS-15.2.3T"
The SIP profile can be applied at a global level under voice service voip or can be applied
to an SP-facing dial peer (dial-peer specific), as shown in Example 9-33.
Example 9-33 CUBE SIP Profile Global and Dial-Peer Specific Application
CUBE(config)# voice service voip

CUBE(conf-voi-serv)# sip
CUBE(conf-serv-sip)# sip profiles 1000
!
CUBE(config)# dial-peer voice 1000 voip
CUBE(config-dial-peer)# description Calls To/From SP
CUBE(config-dial-peer)# voice-class sip profiles 1000
CUBE(config-dial-peer)# codec g711ulaw
CUBE Early Offer and Delayed Offer

The concept of Early Offer (EO) and Delayed Offer (DO) was discussed in Chapter 3. To
recap, in an EO, the calling device (session initiator) sends its capabilities (for example,
codecs supported in the SDP) contained in the initial INVITE, thereby allowing the called
device to make its choice (for example, its preferred codec) for the session. In a DO the
session initiator does not send its capabilities in the initial INVITE. However, it waits

for the called device to send its capabilities first and then negotiates what it wants (for
example, which codecs).
CUBE also supports EO and DO calls to/from CUCM/SIP SP. More often than not, SIP
SPs require an EO and CUCM to do both DO and EO to CUBE. However, even if CUCM
is sending a DO INVITE, CUBE can reinitiate the call leg out to the SIP SP as an EO
INVITE (with SDP). Delayed Offer to Early Offer (DO-EO) interworking can use CUBE
flow-through or flow-around. Table 9-2 describes the EO and DO relationship with SIP
INVITE (with and without SDP).
Table 9-2 CUBE DO and EO

Early Offer (EO) Delayed Offer (DO)
Offer SDP in INVITE No SDP in INVITE
Answer SDP in 180/183 SDP in 200
Figure 9-16 gives an overview of a CUCM to CUBE DO and CUBE to SIP SP EO call
setup. Note that not all call signaling events are shown; the emphasis is on CUBE per-
forming DO-EO for SIP INVITE and consequent events.
CUCM CUBE
SIP SP
Network
INVITE (Without SDP) INVITE (Offer SDP)
180/183/200 (Offer SDP) 180/183/200 (Offer SDP)
ACK/PRACK (Answer SDP) ACK/PRACK (Answer SDP)
RTP RTP
IP Phone PSTN Phone
Figure 9-16 CUBE to SIP SP DO-EO
The following configuration snippet illustrates CUBE setup for EO negotiation:

CUBE(config)# voice service voip
CUBE(config-voi-serv)# sip
CUBE(config-serv-sip)# early-offer forced
CUBE DTMF Interworking

At times, DTMF incompatibility may exist between different devices initiating or accept-
ing calls via CUBE. This might be due to the difference in protocols, standards, and the
way implementation was done. In such scenarios, DTMF interworking is required to
ensure that caller inputs reach through to the destination application/device.

For example, when an SCCP endpoint registered with CUCM tries to call a toll-free
number in the SIP (PSTN) cloud, the call signaling passes through CUCM to CUBE (via
H.323 trunk to CUBE), from CUBE to the SIP SP (via SIP trunk) softswitch, and finally
to the destination PBX/phone. On the way, there is a requirement for DTMF interworking
between the H.323 incoming dial peer on CUBE from CUCM and the SIP outgoing dial
peer to the SIP SP, and the appropriate DTMF type must be configured at the incoming
and outgoing dial peers as shown in Example 9-34.
Example 9-34 CUBE DTMF Interworking Configuration

CUBE(config-dial-peer)# description Calls to/From CUCM
CUBE(config-dial-peer)# destination-pattern 42618...$
CUBE(config-dial-peer)# session target ipv4:10.76.108.240
CUBE(config-dial-peer)# incoming called-number .
CUBE(config-dial-peer)# dtmf-relay h245-alphanumeric
CUBE(config-dial-peer)# no vad
!
CUBE(config-dial-peer)# description Calls to/From SIP-SP
CUBE(config-dial-peer)# destination-pattern 9T
CUBE(config-dial-peer)# session protocol sipv2
CUBE(config-dial-peer)# session target ipv4:X.X.X.X
CUBE(config-dial-peer)# incoming called-number 4082228...$
CUBE(config-dial-peer)# dtmf-relay rtp-nte
CUBE(config-dial-peer)# no vad
CUBE supports multiple DTMF methods/interworking schemes, as shown in Table 9-3.
Table 9-3 CUBE DTMF Interworking

SIP SIP H323 H.323 H323 SIP
NOTIFY NOTIFY H.245- H.245- H.245- NOTIFY
Alphanumeric Alphanumeric Alphanumeric
RFC 2833 NOTIFY H.245-Signal H.245-Signal H.245-Signal NOTIFY
RFC 2833 RFC 2833 RFC 2833 RFC 2833 RFC 2833 NOTIFY
NOTIFY KPML H.245- RFC 2833 H.245- RFC 2833
Alphanumeric Alphanumeric
RFC 2833 KPML H.245-Signal RFC 2833 H.245-Signal RFC 2833
KPML KPML Voice In-Band RFC 2833 RFC 2833 RFC 2833

SIP SIP H323 H.323 H323 SIP

Voice In-Band RFC 2833 H.245- KPML
Alphanumeric
H.245-Signal KPML
Voice In-Band RFC 2833
It’s important to note that DSPs are required only for the voice in-band to RFC 2833
DTMF conversion.
Also, CUBE supports DTMF interworking to enable a delay between the dtmf-digit
begin and dtmf-digit end events in the RFC 2833 packets or to generate RFC 4733–
compliant rtp-nte packets. The command dtmf-interworking has the following options:
■ rtp-nte: Used to introduce a delay between the dtmf-digit begin and dtmf-digit end
events in the RFC 2833 packet if the remote system cannot handle RFC 2833 pack-
ets sent in a single burst. This option is available under (global) voice service voip
and dial-peer.
■ standard: Generates RFC 4733–compliant packets. This option is available under

(global) voice service voip and dial-peer.
■ system: Enables global-level dtmf-interworking configuration (derived from voice

service voip). This is the default configuration under dial-peer. This option is avail-
able only under dial-peer.
CUBE Mid-Call Signaling

CUBE supports SIP mid-call RE-INVITE leveraging the midcall-signaling command. In
most scenarios SIP to SIP video and SIP to SIP RE-INVITE–based supplementary ser-
vices require mid-call signaling to be configured before configuring other supplementary
services. CUBE also offers the capability to consume mid-call signaling RE-INVITEs/
UPDATEs. Figure 9-17 depicts the mid-call signaling flows and CUBE intercepting the
RE-INVITEs. Mid-call RE-INVITE/UPDATE consumption works only with media
flow-through.
Mid-call signaling supports the following modes:
■ Block: Blocks all the incoming RE-INVITEs/UPDATEs; handled locally by CUBE.
■ Passthrough (Media Change): Optimizes the number of RE-INVITEs/UPDATEs

(with SDP) within the call. Mid-call signaling changes are passed through only when
there are new media changes, for example, video escalation, fax.
■ Preserve-codec: Helps preserve the established codec and denies any codec (mid-
call) changes.

CUCM
CUBE
SIP SP
Network
Call Is Established Call Is Established
Mid-Call Signaling
IP Phone Passthru PSTN Phone
Mid-Call RE-INVITE
(with Media Type Change)
RE-INVITE (with SDP)
200 OK
200 OK
ACK
ACK
Call Is Established Call Is Established
IP Phone Mid-Call Signaling PSTN Phone

Block
Mid-Call RE-INVITE
200 OK
ACK
Figure 9-17 CUBE Mid-Call Signaling (Passthru and Block)
Example 9-35 shows the configuration of mid-call signaling options at (global) voice ser-
vice voip and dial-peer level.
Example 9-35 CUBE Mid-Call Signaling Configuration
CUBE(conf)# voice service voip

CUBE(config-voi-serv)# sip
CUBE(config-serv-sip)# midcall-signaling [block | passthru | preserve-codec]
!
CUBE(conf)# dial-peer voice 180 voip
CUBE(config-dial-peer)# voice-class sip midcall-signaling [block | passthru |
preserve-codec]

Chapter 10
Cisco Collaboration Network

Management
Every Cisco Collaboration network requires diligent planning and deployment for an
organization to leverage the many services that it has to offer. However, the ongoing
maintenance and management of a Cisco Collaboration solution is equally important
to ensure that the services provided remain uninterrupted. This chapter covers the
management aspect of a Cisco Collaboration solution.
CUCM Serviceability and OS Administration

Managing CUCM has various elements to it, and the most widely used components and
tools are explained in this section.
CUCM Database Replication

When a CUCM cluster is installed, the cluster members sync system and user data among
themselves. CUCM uses Informix as its database for appliance (Linux) version. Informix
uses Informix Dynamic Server (IDS) to replicate the system and user-facing features
between servers. The CUCM database topology is full mesh, meaning that every server
connects to every other server. The publisher server is the master database (full read-
write) and subscriber databases can read and write only user-facing feature information.
This concept is depicted in Figure 10-1.
With CUCM release 9.x, if the publisher server is offline or not available, user-facing fea-
tures such as Call Forward All and MWI are accessible. However, system-facing features
are not accessible, such as the ability to add or delete a phone or a trunk.
The following are possible CUCM DB replication states:
■ 0 – Replication Initialized: Indicates that replication is in the process of setup.
■ 1 – Number of Replicates not correct: Indicates replication still in the setup

process.
010_9780133845969_ch10.indd 283 6/25/14 11:39 AM

284 Chapter 10: Cisco Collaboration Network Management
■ 2 – Replication is good: Logical connections are established and tables match the
other servers on the cluster.
■ 3 – Tables are suspect: Logical connections are established, but tables don’t match.
■ 4 – Database Setup Failed/dropped: The server no longer has an active logical con-
nection to receive a database table, and no replication takes place in this state.
CUCM Publisher
Full DB Access
(System and User Facing
Features)
CUCM Subscribers CUCM Subscribers

Partial DB Access Partial DB Access
(User Facing Features) (User Facing Features)
Figure 10-1 CUCM Database Architecture
CUCM Service Activation

CUCM functionality is dependent on a number of services that can be broadly classified
into Feature Services and Network Services.
CUCM Feature Services can be activated or deactivated by going to Cisco Unified

Serviceability > Tools > Service Activation. Table 10-1 lists the CUCM Feature Services.
Table 10-2 lists the CUCM Network Services.
Table 10-1 CUCM Feature Services

Feature Service Description
Cisco CallManager Provides call processing and call control.
Cisco Messaging Interface Used with voicemail systems that employ the Simplified
Message Desk Interface (SMDI).
Cisco Unified Mobile Voice Required for Cisco Unified Mobility (SNR, MVA).
Access Service
Cisco IP Voice Media Streaming Provides media services such as Annunciator, MoH, confer-
Application ence bridges, transcoders, MTP, and so on.


Cisco CTIManager Provides interface service for CTI/JTAPI/TAPI applications.
Cisco Extension Mobility Used with the CUCM Extension Mobility feature.
Cisco Extended Functions Provides support for features such as Call Back and Quality
Report Tool (QRT).
Cisco Dialed Number Analyzer Supports the CUCM Dialed Number Analyzer tool.
Cisco DHCP Monitor Service Monitors IP address changes for IP Phones.
Cisco Intercluster Lookup Used by the ILS process for exchanging updates with the
Service ILS network.
Cisco Location Bandwidth Used by LBM for Enhanced Location Call Admission
Manager Control (E-LCAC).
Cisco Dialed Number Analyzer Supplements DNA service (can be activated on one or more
Server nodes in a cluster).
Cisco TFTP Responsible for building and serving files for devices such as
Cisco Unified IP Phones.
Cisco IP Manager Assistant Used for IPMA/UCMA function that allows manager-
assistant function to be deployed.
Cisco WebDialer Web Service Enables users to make calls from web/desktop-based
applications.
Cisco SOAP - CDRonDemand Simple Object Access Protocol (SOAP)/HTTPS-based ser-
Service vice for third-party Call Detail Record (CDR) solutions.
Cisco CAR Web Service Responsible for web-based interface for CDR Analysis and
Reporting (CAR).
Cisco Bulk Provisioning Service Responsible for Bulk Administration Tool (BAT) for bulk
administration of users and phones.
Cisco AXL Web Service Enables interaction/modification of CUCM database entries
via AXL client applications.
Cisco UXL Web Service Used for Cisco IP Phone Address Book Synchronization.
Cisco TAPS Service Used for auto-registration of phones followed by a user
responding to IVR prompts, to enable users to configure
their own devices.
Cisco Serviceability Reporter Responsible for generating daily reports.
Cisco CallManager SNMP Used to implement CISCO-CCM-MIB, which allows SNMP
Service access to CUCM.
Cisco CTL Provider Works with CAPF and CTL Client to change the security
mode of a cluster from non-secure mode to secure (mixed-
mode) mode.


Cisco Certificate Authority Issues locally significant certificates (LSC) to Cisco Unified
Proxy Function (CAPF) IP Phones.
Cisco DirSync Responsible for CUCM to LDAP interaction for user
information.
Table 10-2 CUCM Network Services

Network Service Description
Cisco CallManager Serviceability Supports Real-Time Monitoring Tool (RTMT).
RTMT
Cisco RTMT Reporter Servlet Allows you to publish RTMT reports.
Cisco Log Partition The Log Partition Monitoring feature monitors disk usage
Monitoring Tool of the log partition, and the Log Partition Monitoring Tool
supports this feature.
Cisco Tomcat Stats Servlet Allows monitoring of Tomcat perfmon counters by using
RTMT or the CLI.
Cisco RIS Data Collector RIS maintains real-time information including device sta-
tus, performance counters, alarms, and so on.
Cisco AMC Service Aids RTMT to extract real-time information on a server or
servers in a cluster.
Cisco Audit Event Service Helps log administrative/user events.
Platform Administrative Web Also known as PAWS, allows applications to initiate and
Service monitor upgrades on multiple CUCM clusters from a
single management client.
Cisco DB Backend service responsible for CUCM database engine.
Cisco DB Replicator Supports database configuration and data synchronization
within CUCM cluster.
SNMP Master Agent Supports SNMP request for authentication, authorization,
and other privacy functions.
MIB2 Agent Provides CUCM SNMP access via CUCM MIB.
Host Resources Agent Provides SNMP access to information such as storage
resources and device information.
System Application Agent Provides access for SNMP to applications installed on
CUCM.
Cisco CDP Agent Enables access for SNMP to network information obtained
via CDP.


Cisco Syslog Agent Required for syslog messages using CISCO-SYSLOG-MIB.
Cisco Certificate Expiry Monitor Enables monitoring for CUCM certificate expiry.
Cisco Certificate Change Responsible for checking the expiration status of certifi-
Notification cates.
Cisco ELM Client Service Helps track licensing.
Cisco Tomcat Service for CUCM Administration, OS, DRS, and user
GUI.
Cisco License Manager Helps track and manage licenses on CUCM.
Cisco CallManager Serviceability Supports Cisco Unified Serviceability.
Cisco CDP Provides CDP advertisements.
Cisco Trace Collection Servlet Supports trace collection for Cisco Trace Collection
Service.
Cisco Trace Collection Service Supports trace collection.
Cisco Database Layer Monitor Monitors the CUCM database layer.
Cisco CallManager Admin Used for the web interface used to configure CUCM.
Cisco SOAP-Real-Time Service Enables collecting real-time device and CTI application
APIs information, and provides APIs to start, activate, and stop
services.
Cisco SOAP-Performance Enables performance monitoring counters for applications.
Monitoring APIs
Cisco SOAP-Log Collection APIs Allows collection of log files for APIs.
SOAP - Diagnostic Portal Supports diagnostics for SOAP to DB connection.
Database Service
Cisco DRF Master Services scheduled backup and restore.
Cisco DRF Local Supports the Cisco DRF Local Agent.
Cisco CallManager Personal Supports the Cisco Personal Directory.
Directory
Cisco Extension Mobility Enables Cisco Extension Mobility service.
Application
Cisco CallManager Cisco IP Supports service URLs pertinent to Cisco Unified IP
Phone Services Phone.
Cisco User Data Services Interface for endpoints to get data from CUCM.
Cisco Change Credential Used for EM Pin change by end user.


Cisco E911 Supports enhanced 911.
Cisco CDR Repository Maintains/moves CDRs obtained from the Cisco CDR
Manager Agent service.
Cisco CDR Agent Responsible for transferring CDR/CMR files from the
CUCM server to the CDR repository server.
Cisco CAR Scheduler Can be used to schedule CAR tasks.
Cisco SOAP - CallRecord Helps with the CUCM call recording feature.
Service
Cisco CAR DB CAR DB service.
Cisco Trust Verification Service Used for SBD feature.
CUCM Call Detail Records and Call Management

Records
CUCM produces two types of call records that store call history and diagnostic infor-
mation, respectively. The records are Call Detail Records (CDR) and Call Management
Records (CMR). CDRs contain information about calls processed by CUCM, such as a
record of all calls that have been made or received by users, which is useful for billing
purposes. CDR data can be used for call tracking and capacity planning. CMR, on the
other hand, contains QoS or diagnostic information about the calls (also known as diag-
nostic records) such as total data sent/received, jitter, latency, and lost packets. CDR and
CMR are collectively known as CDR data.
In the context of CDR, a call is considered as started when the caller goes off-hook, and
a call is considered ended when either the caller or the called party goes on-hook. CUCM
has a service parameter, CDR Log Calls with Zero Duration Flag, that determines whether
CDRs for calls that were never connected or were connected for less than a second are
generated. CDRs are generated on each call processing server in a cluster as flat text
files. To enable CDR, go to Cisco Unified CM Administration, choose System > Service
Parameters, select CUCM Service (for a CCM service–enabled server), and set the CDR
Enabled Flag to True. Additionally, the Enterprise Parameter CDR File Time Interval can
be set for an external CDR (third-party) server. This parameter sets the time interval for
collecting CDR data via an external CDR server.
CMR can also be enabled via CUCM service parameters by browsing to System >
Service Parameters, selecting CUCM Service, and setting the Call Diagnostics Enabled
parameter to either Enabled Only When CDR Enabled Flag Is True or Enabled
Regardless of CDR Enabled Flag.
CUCM creates a CDR flat file for each end-to-end call and two CDR files for a confer-
ence call. Because flat files are fixed-length files, one CDR flat file can contain the data

CUCM Disaster Recovery 289
of more than one call. The CDR agent service pushes flat files from call processing
subscriber(s) to the CDR Repository Manager on the publisher node. CUCM also pro-
vides a web application known as CDR Analysis and Reporting (CAR) that can be used
to analyze the CDRs. The CAR Scheduler service runs only on the publisher node and
enables reading the contents of the flat files and writes the same into the CAR database.
The CDR Repository Manager keeps the files in the preserve folder at file list activelog /
cm/cdr_repository/preserve/<YYYYMMDD>/.
CDR flat files can be in various states, namely:
■ car/yyyymmdd: CAR Scheduler service uses soft links to determine what files need
to be processed by the CDR Loader.
■ destinationx/yyyymmdd: CDR Repository Manager service uses soft links to deter-

mine what files need to be transferred to billing server.
■ preserve/yyyymmdd: Files that are waiting to be sent out and/or to be loaded

by CAR.
■ processed/yyyymmdd: Files that were successfully sent to all specified destinations

(billing servers) and loaded by CAR.
■ tmp: Files waiting to be processed.
■ trans: Files being received from a CUCM node.
To add a CDR billing (an external third-party) server, go to Tools > CDR Management
Configuration and add a new billing server.
CUCM Disaster Recovery

CUCM offers a Disaster Recovery System (DRS) that enables the administrator to back up
and restore the following:
■ CUCM configuration database
■ CDRs
■ CMRs
■ CDR Analysis and Reporting (CAR)
■ Enterprise License Manager (ELM)
Similarly, Cisco Unity Connection, Cisco UCCX, and Cisco IM and Presence servers also
offer a DRS solution that enables a Cisco Collaboration network administrator to sched-
ule backups and leverage them in case a server needs to be rebuilt.
DRS utilizes Cisco Disaster Recovery Framework (DRF) service and enables administra-
tors to initiate a manual or automatic (scheduled) backup. DRS permits CUCM admin-
istrators to schedule backup on all seven days of the week (recommended practice) or
select specific days when backup should take place. It also allows setting the maximum

number of backups (minimum 1 and maximum 14) to be stored on a network share. DRS
uses SFTP to store a backup file with a .tar extension on an SFTP repository. DRS can
also store a backup on a tape drive. However, this option is supported only with a physi-
cal server, not on a virtual machine. To access CUCM DRS, go to https://<ip address or
hostname of server>/drf.
To set up CUCM DRS for backup, follow these steps.
Step 1. Go to Disaster Recovery System > Backup > Backup Device and add a new
backup device. Enter the required details for the network share, such as SFTP
server credentials, directory, and so on. Click Save.
Step 2. Navigate to Backup > Scheduler, provide a name for the schedule, and
choose the backup device created previously. Additionally, select the frequen-
cy of the backup. Click Save.
Step 3. If you want to perform a manual backup, go to Backup > Manual Backup.
To run a restore login, go to CUCM DRS, choose Restore > Restore Wizard, and follow
the prompts.
While restoring, the important thing to remember is that the CUCM server being restored
has the exact same CUCM version and patch level as the previous server. Moreover,
although not mandatory, it is recommended to back up each server in a CUCM cluster
so that the manually uploaded TFTP files such as ring lists, backgrounds, and so on are
backed up.
User Management
The Cisco Collaboration solution offers users a range of services and facilities that they
can leverage. CUCM has a full-fledged, built-in user management system to assist admin-
istrators with user management.
CUCM has two types of users:
■ Application users: System-level users employed for certain system functionality or

feature set. These users are associated with Cisco Unified Communications features
or applications, such as CUCM Administrator, UCCX JTAPI, and so on. Application
users are always created in CUCM and cannot be created on a Lightweight Directory
Access Protocol (LDAP) server, and hence are always internal users. Moreover, appli-
cation users do not have an interactive login and serve only for internal communica-
tions within CUCM and communications between CUCM and other applications.
■ End users: Created for actual physical users and support an interactive login. These
users can be associated with endpoints, devices, and applications so that the user
can control IP Phones, personalize some commonly used features, and leverage
Cisco UC features. End users can be created in CUCM or can be synced with an
LDAP server such as Microsoft Active Directory, OpenLDAP, iPlanet, and so on.

User Management 291
LDAP directories are based on the X.500 standard and are a specialized database that
contains information about end users such as username, user department, user phone
number, user password, user email address, and so on. Syncing CUCM with LDAP pro-
vides applications the capability to get all user information from a single repository avail-
able to several applications, with a remarkable reduction in maintenance costs through the
ease of adds, moves, and changes. By default, all users are provisioned manually in the
publisher database through CUCM Administration User Management > End Users.
CUCM users can be synced with Cisco Unity Connection and Cisco IM and Presence
via an AXL/SOAP interface. Hence, the existing users can be imported into the aforesaid
applications even without having them directly integrated with the LDAP server, making
CUCM a single point of contact with LDAP. Alternatively, Cisco Unity Connection and
Cisco IM and Presence servers can be directly integrated with LDAP.
End users can be further classified into two types:
■ Core users: End users that have usually one or two devices assigned to them. They
are expected to have a single line and commonality across all devices assigned to
them. In other words, instead of managing devices one by one, core users can add on
one device a feature/service such as speed dial, and it applies to all the devices that
the user has.
■ Advanced users: Users that have multiple phones with one or more lines on each
device. They are expected to have multiple devices with multiple lines so they can
pick and choose between devices, lines, and Cisco Collaboration services they wish
to leverage.
CUCM 9.x offers the ability to manage both LDAP synced and local users; for example,
administrators can have local users coexist with LDAP synced users. Moreover, CUCM
offers the ability to modify local users and roles assigned to LDAP users and convert an
LDAP user to a local user (by checking the Convert LDAP Synchronized User to Local
User check box on the user page). Figure 10-2 illustrates LDAP and local users coexisting
on a CUCM server.
Figure 10-2 CUCM End Users Created Locally and Synced from LDAP

Note in the User Status column that the User Status field can be employed to differenti-
ate between local users and LDAP synchronized users.
The CUCM end user web page and associated options can be accessed via https://<IP
address or hostname of CUCM server>/ucmuser. CUCM users can be added or details
can be modified in bulk using Bulk Administration Tool (BAT). BAT provides multiple
options such as Users, Phones and Users, Manager/Assistants, and User Device Profile
for various user-related operations. The Cisco Collaboration network’s user management
automation and associated tasks can also be achieved by utilizing Prime Collaboration
Provisioning (part of Cisco Prime Collaboration Suite). User management can be accom-
plished by browsing to Administration > User Management.
Cisco EnergyWise
Cisco EnergyWise is an energy (power) management solution that enables the IT and
facility managers to administer and monitor energy consumption to manage network and
connected devices, including switches, routers, Power over Ethernet (PoE)-capable end-
points, and so on, using their existing network infrastructure.
The following are characteristics of EnergyWise:
■ Uses the network to measure, monitor, and manage energy, allowing the network to
be the command and control plane for power management.
■ Uses the network to aggregate power usage reporting while simultaneously allowing
the network to provide secure, reliable energy management.
■ Uses the network effect to provide services such as location and presence for energy
management.
Cisco EnergyWise architecture has the following components:
■ Domain: A logical grouping of Cisco devices such as Cisco switches and routers. A
domain is a single unit of energy management. Domain members share neighbor rela-
tionships with each other.
■ Domain members: Switches, routers, and network controllers. They resemble end-
points in that they draw power. However, domain members can work together to
propagate EnergyWise messages across the network, to form an EnergyWise cloud.
For endpoints, Cisco IOS switches and routers act as parents.
■ Endpoints: Classified as the power consumers—for example, Cisco Unified IP

Phones, PCs, HVAC, and so on. The endpoints are typically PoE and non-PoE devic-
es. Endpoints can respond to EnergyWise command and control queries. However,
they cannot forward them. Endpoints are also known as child domain members
because they have a parent-child relationship with domain members (switches and
routers).

■ EnergyWise Managers: EnergyWise management can be done via control appli-

cations and devices that use Cisco EnergyWise features to measure, monitor, and
manage power consumption. Cisco EnergyWise has two management options:
SNMP-MIB, whereby the MIB provides power information of a domain member and
its attached endpoints, and the Toolkit Management API, which makes use of Cisco
EnergyWise queries to manage and control the entire domain.
Figure 10-3 represents Cisco EnergyWise architecture.
EnergyWise Manager
EnergyWise
Cloud
Cisco Switch
(Domain Member)
Parents
Cisco Switch Cisco Router Cisco Switch

(Domain Member) (Domain Member) (Domain Member)
Children

Cisco Jabber PC
IP Phone IP Phone
(Endpoint) (Endpoint)
(Endpoint) (Endpoint)
Figure 10-3 Cisco EnergyWise Architecture
Cisco EnergyWise is supported on the following Cisco platforms (not a comprehensive

list, because Cisco EnergyWise is also supported with third-party devices/applications):
■ Cisco Catalyst Switches (6500, 4500, 3500, 3700, 2900 Series)
■ Cisco ISR G2 Routers (1900, 2900, 3900 series)
■ Cisco Unified IP Phones (69XX, 79XX, 89XX, 99XX Series)
■ Cisco VDI Phone backpack and tower
■ Cisco Prime LAN Management Solution (LMS)

EnergyWise supports neighbor discovery (members/parents) using EnergyWise-enabled

discovery events via CDP (on supported devices) and then UDP broadcast. This leads to
the population of a neighbor table on a member. In case a device is multiple hops away or
connected through a darknet (non-EnergyWise-supporting network), static neighborship
can be set up.
EnergyWise has a mechanism to differentiate between relatively important devices and

nonessential devices in the domain in terms of their energy consumption; for example, an
emergency phone in the lobby that should never be put to sleep vs. an employee phone
that can be put to idle (sleep) mode to conserve energy. Importance values range from 1
to 100, with 100 being most important. By default, all devices have an importance value
of 1. EnergyWise also supports easing power management by defining roles (to define
device function) and keywords (additional tags) that can be assigned as per business rules
or processes to infrastructure devices and endpoints.
The following configuration illustrates Cisco EnergyWise configuration on a Cisco IOS

router:
UCSwitch(config)# energywise domain CORP.LOCAL security shared-secret 7 c1sc0123

protocol udp port 54000 interface Loopback0
Upon configuring an EnergyWise domain on a Cisco IOS device, EnergyWise is acti-

vated automatically. Cisco EnergyWise (domain) configuration and parent-child relation-
ships can be discovered by following the commands in Example 10-1.
Example 10-1 EnergyWise CLI Commands
UCSwitch# show energywise

Module/
Interface Role Name Usage Category Lvl Imp Type
--------- ---- ---- ----- -------- --- --- ----
WS-C3750E-24PD UCSwitch-1 101.0 (W) consumer 10 1 parent
Subtotals: (Consumer: 101.0 (W), Meter: 0.0 (W), Producer: 0.0 (W))
Total: 101.0 (W), Count: 1
UCSwitch# show energywise domain

Name : UCSwitch-1
Domain : CORP.LOCAL
Protocol : udp
IP : 10.86.108.254
Port : 54000
UCSwitch# show energywise children

Module/

Interface Role Name Usage Category Lvl Imp Type

--------- ---- ---- ----- -------- --- --- ----
WS-C3750E-24PD UCSwitch-1 101.0 (W) consumer 10 1 parent
Gi1/0/3 IP Phone 9971 SEP64AE0CF66C0D 7.5 (W) consumer 10 1 PoE
Gi1/0/5 IP Phone 9971 SEP10BD18DC97F5 7.1 (W) consumer 10 1 PoE
Gi1/0/6 IP Phone 9951 SEPE84040A24BBD 6.0 (W) consumer 10 1 PoE
Subtotals: (Consumer: 121.6 (W), Meter: 0.0 (W), Producer: 0.0 (W))
Total: 121.6 (W), Count: 4


CCIE Collaboration Quick Reference

Uploaded by

Copyright:

Available Formats

CCIE Collaboration Quick Reference

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CCIE Collaboration Quick Reference

Uploaded by

Copyright:

Available Formats

What is the purpose of the book?

What is the purpose of the book?

What are some of the Cisco platforms that support Cisco EnergyWise?

What are some of the Cisco platforms that support Cisco EnergyWise?

From the Library of YAOBIN NDNF