You are on page 1of 315

From the Library of Juan Arcaya

CCIE Collaboration Quick


Reference
Akhil Behl, CCIE No. 19564

Cisco Press
800 East 96th Street
Indianapolis, IN 46240

From the Library of Juan Arcaya

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 storage 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 damages 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.

From the Library of Juan Arcaya

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 department at corpsales@pearsoned.com or (800) 382-3419.
For government sales inquiries, please contact governmentsales@pearsoned.com.
For questions about sales outside the U.S., please contact international@pearsoned.com.

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 feedback@ciscopress.com. 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

From the Library of Juan Arcaya

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 current 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 masters 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.

From the Library of Juan Arcaya

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.

From the Library of Juan Arcaya

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.

From the Library of Juan Arcaya

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

From the Library of Juan Arcaya

viii

CCIE Collaboration Quick Reference

Contents
Chapter 1

Cisco Collaboration Infrastructure

Cisco Unified Communications Deployment Models 1


Single-Site Deployment Model

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

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


Campus Core Layer

18

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

From the Library of Juan Arcaya

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

From the Library of Juan Arcaya

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

From the Library of Juan Arcaya

xi

Media Termination Point 105


Transcoder 105
Music on Hold 105
Media Resource Group and Media Resource Group List
Trusted Relay Point
CUCM Dial Plan

106

107

107

Partitions and Calling Search Spaces

108

Translation Patterns 109


Route Patterns 109
Route List 109
Route Group 110
Globalized Call Routing
Local Route Group

110

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

135

Mobile Connect

136

Mobile Voice Access

133

138

Service Advertisement Framework and Call Control Discovery

140

SAF Architecture 140


Call Control Discovery Service

142

From the Library of Juan Arcaya

xii

CCIE Collaboration Quick Reference

Chapter 5

Cisco Unified Communications Security


Security Policy

145

145

Threats to Cisco Collaboration Networks 146


Layer 1 Security

146

Layer 2 Security

147

Port Security 147


DHCP Snooping 148
Root Guard and BPDU Guard
Dynamic ARP Inspection

149

149

802.1x 149
Layer 3 Security

151

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

From the Library of Juan Arcaya

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


Cisco Unity Connection SIP Voicemail Integration with CUCM

169

171

Cisco Unity Connection SCCP Voicemail Integration with CUCME


Cisco Unity Connection SIP Voicemail Integration with CUCME
Cisco Unity Connection Dial Plan

172

174

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

From the Library of Juan Arcaya

xiv

CCIE Collaboration Quick Reference

Chapter 8

Cisco Unified Contact Center Express


Cisco UCCX Architecture

209

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
UCCX Call Flow

214

215

UCCX Integration with CUCM

216

UCCX Scripting Components 218


Chapter 9

Cisco IOS Unified Communications Applications


Cisco Unified Communications Manager Express

225

225

Basic Cisco Unified CME Setup 226


Cisco Unified CMEBased SCCP Phone Registration 227
Cisco Unified CMEBased 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
Cisco IOS Dial Plan

237

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 CMEBased Media Resources 246
Cisco Unified CME Conferencing and Transcoding 246
Cisco IOSBased Call Queuing

249

Cisco Unified CME Basic Automatic Call Distribution 249


Voice Hunt Groups

252

Call Blast 253


Cisco Unity Express

254

From the Library of Juan Arcaya

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

From the Library of Juan Arcaya

xvi

CCIE Collaboration Quick Reference

Icons Used in This Book

Communication
Server

PC

PC with
Software

Terminal

File
Server

Sun
Workstation

Macintosh

Access
Server

ISDN/Frame Relay
Switch

Ciscoworks
Workstation

ATM
Switch

Modem

Token
Ring
Token Ring

Printer

Laptop

Web
Server

IBM
Mainframe

Front End
Processor

Cluster
Controller

Multilayer
Switch

FDDI
Gateway

Router

Network Cloud

Bridge

Line: Ethernet

Hub

Line: Serial

DSU/CSU
DSU/CSU

FDDI

Catalyst
Switch

Line: Switched Serial


Cisco ASA

From the Library of Juan Arcaya

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

From the Library of Juan Arcaya

This page intentionally left blank

From the Library of Juan Arcaya

Chapter 1

Cisco Collaboration
Infrastructure

Cisco Unied 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 efciently by leveraging various unied 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, applications, 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.

From the Library of Juan Arcaya

Chapter 1: Cisco Collaboration Infrastructure

These three broad deployment models can be further classified into the following categories 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

Internet

CUCM
Cluster
CC

PSTN
V

Endpoints

Figure 1-1

Single-Site Deployment Model

From the Library of Juan Arcaya

Cisco Unified Communications Deployment Models

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 conferencing 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 processing and other telephony functions. The centralized CUCM cluster connects with endpoints 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.
Applications

Media Resources

Media and Conference Resources

Infrastructure

Internet

CUCM
Cluster

IP WAN

CC

PSTN
V

Endpoints
V

Endpoints

Figure 1-2

Multisite WAN with Centralized Call Processing Deployment Model

From the Library of Juan Arcaya

Chapter 1: Cisco Collaboration Infrastructure

The following are some best practices associated with the multisite WAN with centralized 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
doesnt 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.
Applications

Media Resources

Media and Conference Resources

Infrastructure

Internet
CUCM
Cluster

CUCM
Cluster

IP WAN

V
CC

PSTN
V

Endpoints

Endpoints

Figure 1-3 Multisite WAN with Distributed Call Processing Deployment Model

From the Library of Juan Arcaya

001_9780133845969_ch01.indd 4

6/24/14 4:23 PM

Cisco Unified Communications Deployment Models

The following are some best practices associated with the multisite WAN with distributed call processing deployment model:

Deploy SIP proxies such as the Cisco Unified SIP Proxy (CUSP) to provide call routing 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 maintained. 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 Resources

Media and Conference Resources

Infrastructure

Internet

Internet

IP WAN

V
CUCM
Cluster Over WAN

PSTN
V

PSTN
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 processing 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.

From the Library of Juan Arcaya

Chapter 1: Cisco Collaboration Infrastructure

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

From the Library of Juan Arcaya

Network Services

Example 1-1 shows configuration of a DHCP server on a Cisco IOS router.


Example 1-1 Cisco IOS Routerbased 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 parameters, 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
wont be able to resolve the name of the CUCM server(s) when DNS service is unavailable. 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.

From the Library of Juan Arcaya

001_9780133845969_ch01.indd 7

6/24/14 4:24 PM

Chapter 1: Cisco Collaboration Infrastructure

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

From the Library of Juan Arcaya

Network Services

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 proprietary 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 available phone image stored in flash memory. Using this image, the IP Phone initializes 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 information 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 configuration 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 running. 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 nonvolatile RAM and reboots.

Step 7.

After rebooting, the IP Phone downloads other information such as the softkey 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 number (DN).

From the Library of Juan Arcaya

10

Chapter 1: Cisco Collaboration Infrastructure

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, configuration, 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 hierarchy. 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 firmware 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.

From the Library of Juan Arcaya

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 infrastructure helps administrators to troubleshoot and correlate events in a Cisco Collaboration
network. Devices in a Cisco Collaboration network can receive the time from an authoritative 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 authoritative 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 publishers 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.

From the Library of Juan Arcaya

12

Chapter 1: Cisco Collaboration Infrastructure

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 switches. 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), including 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, followed by a number of Type, Length, and Value (TLV) fields. Table 1-1 illustrates various
CDP TLV fields.

From the Library of Juan Arcaya

Network Services

Table 1-1

13

CDP TLV Fields

CDP TLV Field

Description

Device ID

Identifies the sending devices 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 devices 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 devices 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

Platform

Port ID

CM91PUB

Fas 0/30

Holdtme
135

Capability
H

VMware

eth0

CUPS91

Fas 0/26

169

VMware

eth0

UCRouter

Fas 0/24

163

R S I

CISCO3945-Gig 0/0

From the Library of Juan Arcaya

14

Chapter 1: Cisco Collaboration Infrastructure

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 infrastructure components.

Link Layer Discovery Protocol


LLDP is a vendor-neutral Layer 2 protocol and is analogous to CDP. LLDP is the standards-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 devices hostname

System Description

Provides details about the advertising devices OS/firmware

System Capabilities

Identifies the devices 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
Configuration/Status

Provides the MAC address and other physical characteristics

From the Library of Juan Arcaya

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 implementation (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 standardsbased 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.

From the Library of Juan Arcaya

16

Chapter 1: Cisco Collaboration Infrastructure

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 standards-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 connected device.
It is recommended to deploy PoE-capable switches at the campus access layer within wiring 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 topologyindependent network.
When a switch is configured for data and voice VLANs, Cisco Unified IP Phones connect to the user-facing access layer ports on the switch, followed by a PC or a data device
connecting to the IP Phones PC port. IP Phones come with a built-in switch that interfaces 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 following 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

From the Library of Juan Arcaya

IP Routing in Cisco Collaboration Campus Environments

17

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 Ciscos 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 passiveinterface command to prevent routing neighbor adjacencies via the access layer.

Campus Infrastructure Design


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

From the Library of Juan Arcaya

18

Chapter 1: Cisco Collaboration Infrastructure

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 performance boost from packet forwarding handled by specialized hardware. Layer 3 switching 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 wiring closet switches to the next-hop switch. Its 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 redundant 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 redundant subsystems (such as Catalyst Supervisor Engine modules). Cisco Catalyst switches

From the Library of Juan Arcaya

IP Routing in Cisco Collaboration Campus Environments

19

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

Campus Routed Access Layer Design

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

Layer 3

Layer 3

Distribution

Routed Access Campus Design

Traditional Cisco Campus Design

As previously mentioned, Cisco-recommended CDA architecture should be followed


while designing a campus network. There are two options for access layer design pertinent to campus network design, as shown in Figure 1-7:

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

From the Library of Juan Arcaya

20

Chapter 1: Cisco Collaboration Infrastructure

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, compared 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) characters 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.

From the Library of Juan Arcaya

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

Figure 1-8

Unique-local

Global

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 communication 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 communications, inter-site VPNs, and so forth. Subnet IDs are typically defined using a hierarchical addressing plan to allow for route summarization.

From the Library of Juan Arcaya

22

Chapter 1: Cisco Collaboration Infrastructure

Global address: Address that is routable across the Internet. Global addresses constitute 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 providers 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 uniquelocal 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
Phones 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, multiple 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 routersfor 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.

From the Library of Juan Arcaya

Virtualization in Cisco Collaboration Solutions

Step 3.

23

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 interoperate. 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 platforms 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
Experience Infrastructure
(VXI)

Delivers integrated Unified Communications platform, is device


agnostic, and delivers enterprise voice, video, mobility, presence,
and session management with security.

Cisco Virtualization
Experience Media Engine
(VXME)

Enables Jabber to run in virtualized environments. This is a subcomponent of Cisco VXI.

Cisco Virtualization
Experience Client (VXC)

A thin client designed to easily integrate into a virtualized infrastructure. This is a subcomponent of the Cisco VXI solution.

From the Library of Juan Arcaya

24

Chapter 1: Cisco Collaboration Infrastructure

Virtual Solution

Description

Cisco VXC Manager

Used for managing and deploying VXC thin client. This is a subcomponent of the Cisco VXI solution.

Cisco Virtual Desktop


Infrastructure (VDI)

Solution to deliver virtualized desktops and applications by


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 encompassing 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 communicate 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 UCSbased 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 profile 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 applications. 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.

From the Library of Juan Arcaya

Virtualization in Cisco Collaboration Solutions

25

UC Applications
(Guest Virtual Machines)
VMware
Hypervisor

B-Series Blade

Cisco UCS 5100 Series


Chassis

6200 Series Fabric


Interconnect
Fibre Channel over
Ethernet (FCoE)

Fibre Channel

Ethernet

LAN Switch

Figure 1-9

Nexus 5000
Series Switch

Storage Array
SAN Switch
(MDS 9000 Series)

Cisco UCSbased 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.

From the Library of Juan Arcaya

26

Chapter 1: Cisco Collaboration Infrastructure

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

From the Library of Juan Arcaya

IP Multicast

27

After the platformConfig.xml file is generated, you can use it to install primary and secondary 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 information 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 infrastructure must support the forwarding of multicast IP traffic from the CUCM servers or

From the Library of Juan Arcaya

28

Chapter 1: Cisco Collaboration Infrastructure

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


Todays dynamic environments and organizations demand more than just regular wired
IP Phonesthey demand mobility. Wi-Fi is an important aspect because being mobile
yet connected within an enterprise is paramount in todays 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-Ficapable 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.

From the Library of Juan Arcaya

Wireless in Cisco Collaboration Solutions

Cisco WLC

29

CUCM

Lightweight AP

Switch

Cisco Unified IP
Laptop with
Phone (Wireless) Softphone (Jabber)

Figure 1-10

Switch

LDAP

Cisco Unified IP
Phone (Wired)

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

From the Library of Juan Arcaya

This page intentionally left blank

From the Library of Juan Arcaya

Chapter 2

Quality of Service (QoS)

Voice and video over IP trafc consists of two parts: media/bearer trafc and signaling
trafc. Media trafc is based on the Real-time Transport Protocol (RTP), which runs
on top of the User Datagram Protocol (UDP). Signaling trafc 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 todays converged networks where voice, video, and data coexist, it is important to
treat voice and video trafc differently from data trafc, 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 timesensitive trafc such as voice. The network infrastructure must provide classication,
policing, and scheduling services for multiple trafc 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 congestion, 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 xed 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.

From the Library of Juan Arcaya

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. Its a fixed delay
function.

Queuing delay

The delay experienced as a frame is queued waiting to be transmitted on a link. Its 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.
Its 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. Its 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 voicecontrol traffic per call.

Additional requirements for video traffic are as follows:

From the Library of Juan Arcaya

QoS Deployment Architectures

The minimum priority bandwidth guarantee required is size of Video-stream + 10 to


20 percent.

Call Admission Control (CAC) must be enabled.

33

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 various 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/
Marking
IP Precedence
DSCP
RSVP
ACLs

Figure 2-1

Policing

Queuing

Traffic Policing
Rate Limiting

LLQ
CBWFQ
WRED

Shaping/
Fragmentation
FRTS
LFI
FRF.12
MLP

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 fragmentation. It is essential to plan and deploy end-to-end QoS in LAN, WAN, and virtualized environments to ensure that voice and video quality is acceptable. The sections that

From the Library of Juan Arcaya

34

Chapter 2: Quality of Service (QoS)

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 covered 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 recognize 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
Preamble
(8)

Destination
Address
(6)

Source
Address
(6)

User Priority
(3)

TPID
(2)

TCI
(2)

Type/
Length
(2)

CFI
(1)

Data
(Payload)

FCS
(2)

VLAN ID
(12)

Used for CoS


Markings

Figure 2-2

IEEE 802.1Q Tagbased 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:

From the Library of Juan Arcaya

Classification and Marking 35

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

From the Library of Juan Arcaya

36

Chapter 2: Quality of Service (QoS)

IPv4 Packet

ToS

Precedence

ToS

MBZ

IP Precedence
DSCP

Figure 2-3

CU

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 provides assurance that a packet is forwarded as long as it doesnt exceed the subscribed
rate.

Best Effort (BE): Specified when all 6 bits of the DS field are 0; that is, the packet
doesnt need any specific QoS treatment or doesnt 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 treatment 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)

From the Library of Juan Arcaya

Classification and Marking 37

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

From the Library of Juan Arcaya

002_9780133845969_ch02.indd 37

6/24/14 4:28 PM

38

Chapter 2: Quality of Service (QoS)

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


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

From the Library of Juan Arcaya

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


(WFQ)

A flow-based algorithm, derived from Fair Queuing (FQ), and a


default queuing method for low-speed interfaces. WFQ makes
forwarding decisions based on a packets size and Layer 3 priority 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 different classes, with different amounts of bandwidth or priority
treatment for these classes.
Class-Based Weighted Fair
Queuing (CBWFQ)

Similar to LLQ, but without the PQ mechanism.

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

From the Library of Juan Arcaya

40

Chapter 2: Quality of Service (QoS)

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 markings (default markings by Cisco UC applications and the majority of endpoints) for signaling that is matched. Voice audio is given priority treatment of guaranteed 20 percent
of the links 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 traffic 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 interfaces output queue from filling to its capacity, 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 various 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

From the Library of Juan Arcaya

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 precedencebased marking for calculating drop probability.
The default is prec-based.

WAN QoS Considerations


WAN links typically require additional mechanisms such as traffic policing, traffic shaping, 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 (buffering) 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 conforms to or exceeds the configured rate. Actions can be stated for traffic that conforms 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.

From the Library of Juan Arcaya

42

Chapter 2: Quality of Service (QoS)

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)# policy-map HTTPS
UCRouter(config-pmap)# class HTTP-Secure
UCRouter(config-pmap-c)# police cir 512000 bc 64000 be 64000 conformaction set-dscp-transmit af21 exceed-action set-dscp-transmit af11
violate-action drop
!
UCRouter(config)# interface FastEthernet 0/0
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 MQCbased shaping, traffic can be shaped to either average or peak. If shape average is specified, 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)# policy-map HTTPS
UCRouter(config-pmap)# class HTTP-Secure
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
!

From the Library of Juan Arcaya

Link Efficiency Mechanisms

43

UCRouter(config)# interface serial 0/0


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 mechanisms are helpful for ensuring QoS for voice media and signaling packets/frames traversing 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 its 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

From the Library of Juan Arcaya

44

Chapter 2: Quality of Service (QoS)

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)# interface serial 0/0
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)# interface serial 0/0
UCRouter(config-if)# frame-relay traffic-shaping
!

From the Library of Juan Arcaya

Link Efficiency Mechanisms

45

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 fragment 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 command 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 disconnected for the parties participating in the call. Comfort noise generation (CNG) eliminates 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

From the Library of Juan Arcaya

46

Chapter 2: Quality of Service (QoS)

LAN QoS Considerations


Although its 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 layerCisco 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 traversing 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, wireless 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 conditionally 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.

From the Library of Juan Arcaya

QoS Considerations for WLAN Endpoints

Table 2-4

47

Switch CoS Trust Policies

QoS Trust Policy

Description

mls qos trust cos

The switch trusts the CoS value of all frames entering 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 entering 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 counterparts, require QoS for voice and video traffic. However, unlike wired networks, wireless networks are a shared medium and wireless endpoints do not have committed bandwidth 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/
Application

IEEE 802.11e UP Marking

PHB/DSCP

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)

From the Library of Juan Arcaya

48

Chapter 2: Quality of Service (QoS)

Network Service/
Application

IEEE 802.11e UP Marking

PHB/DSCP

Voice and video signaling


traffic (SIP, H.323, MGCP,
SCCP)

CS3 (DSCP 24)

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 LAPs 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 virtual 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 traffic. This approach is not recommended by Cisco because some converged network adapters (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 (ignoring 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

From the Library of Juan Arcaya

Medianet

49

corresponding L2 CoS values that can be interpreted by FIs. This traffic can then be prioritized 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

From the Library of Juan Arcaya

50

Chapter 2: Quality of Service (QoS)

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

From the Library of Juan Arcaya

Medianet

WebEx Meeting Client for Windows

Jabber for Windows

EX Series endpoints

Cisco Catalyst switches

Cisco IOS routers

51

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 ranging from device-specific, such as CPU or memory, to interfacespecific, such as input interface speed, to flow-specific, such as
DSCP values or jitter. Mediatrace collects information from network nodes along the traffic flow path and presents this information 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
Agreement Video
Operation (IP SLA VO)

A readiness assessment tool for gauging a networks capacity to


carry rich-media traffic. It is used for network-based IP SLAs for
synthetic traffic generation, pre-deployment assessment, preevent 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 hopby-hop basis. It is used to determine jitter, packet loss, and multiplexed 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, whereas 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.

From the Library of Juan Arcaya

52

Chapter 2: Quality of Service (QoS)

Medianet Component

Description

Media Services Proxy


(MSP)

Provides a subset of Medianet services on behalf of non-Cisco


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
Databases

Enables the application to convey information about itself to the


underlying network via MSI-enabled endpoints as well as MSPor 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


(MSI)

A software package that resides on the endpoints. MSI comes


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 network 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 service 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 requirements 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.

From the Library of Juan Arcaya

Medianet

Table 2-7

53

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

From the Library of Juan Arcaya

54

Chapter 2: Quality of Service (QoS)

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/
Management (OAM)

For network operations, administration, and management traffic, 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.

From the Library of Juan Arcaya

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 processor (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 commonly used codecs in a Cisco Collaboration network.

From the Library of Juan Arcaya

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 functionality. iLBC is supported by SIP, SCCP, MGCP, and H.323 endpoints. 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
Codec (iSAC)

A robust, bandwidth-adaptive, wideband and super-wideband


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


Transport Multiplex
(LATM)

An Advanced Audio Coding-Low Delay (AAC-LD) MPEG-4 Part


3 media type. It is a super-wideband audio codec that provides
superior sound quality for voice and music. LATM codec provides 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 frequency 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 resolution) and is processed at 12.8 kHz.

From the Library of Juan Arcaya

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 concurrently 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 signaling 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 information, 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

IP Phone

Figure 3-1

RTCP/SRTCP

IP Phone

RTP/SRTP and RTCP/SRTCP Flow

From the Library of Juan Arcaya

58

Chapter 3: Telephony Standards and Protocols

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 communicate 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 20002003 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 conference 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 dualtone 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:
1Off Hook
2On Hook
3Ring Out
4Ring In
5Connected
6Busy
7Line In Use
8Hold
9Call Waiting

From the Library of Juan Arcaya

VoIP Signaling Protocols

59

10Call Transfer
11Call Park
12Call Proceed
13In Use Remotely
14Invalid 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 Bs 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.

From the Library of Juan Arcaya

60

Chapter 3: Telephony Standards and Protocols

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 Keypad Button
Station Keypad Button

Station Call Information


Station Set Lamp (Blink)

Station Call Information


Station Start Tone (Alerting)

Station Set Ringer (Ring)

Station Off Hook


Station Set Ringer (Off)

Station Stop Tone


Station Set Lamp (Steady)
Station Open Receive Channel
Station Cell Information

Station Open Receive Channel

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 Stop Media Transmission
Station Set Lamp (Off)
Station On Hook

Figure 3-2

Station On Hook
Station Set Lamp (Off)
Station Close Receive Channel
Station Stop Media Transmission

SCCP Call Flow Between Two IP Phones Registered to Same CUCM

From the Library of Juan Arcaya

VoIP Signaling Protocols

61

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 intelligence, thus it controls the MGs 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
(CRCX)

Command from a call-control agent to an MGCP-controlled gateway 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
(MDCX)

Command from a call-control agent to an MGCP-controlled


gateway that modifies the parameters associated with an existing
connection.

DeleteConnection
(DLCX)

Bidirectional command that is used by a call-control agent to inform


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
(EPCF)

Configuration command from a call-control agent to an MGCPcontrolled gateway. It configures the gateway with the bearer information, which specifies whether audio calls will be encoded using
mu-law or A-law.

From the Library of Juan Arcaya

62

Chapter 3: Telephony Standards and Protocols

MGCP Call State

Description

NotificationRequest
(RQNT)

Command from a call-control agent to an MGCP-controlled gateway 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 gateway to audit the status of an endpoint (port), such as bearer information, signal status, and event status.

AuditConnection
(AUCX)

Command from a call-control agent to an MGCP-controlled gateway 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/offhook and digit reception.

RestartInProgress (RSIP) Command from a gateway to a call-control agent to inform the callcontrol agent that the gateway is taking an endpoint or group of
endpoints out of service or returning an endpoint or group of endpoints 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 gateway 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 keepalive 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.

From the Library of Juan Arcaya

VoIP Signaling Protocols

63

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 musicon-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 command 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 loopback). 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 autoconfigure 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.

From the Library of Juan Arcaya

003_9780133845969_ch03.indd 63

6/25/14 8:28 AM

64

Chapter 3: Telephony Standards and Protocols

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 description, 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
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)

Figure 3-3

DLCX

DLCX

DLCX Response

DLCX Response

MGCP Call Flow Between Two Gateways Registered to Same CUCM Server

From the Library of Juan Arcaya

VoIP Signaling Protocols

65

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 consider relevant, such as ringing and the endpoints 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 establish 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

From the Library of Juan Arcaya

66

Chapter 3: Telephony Standards and Protocols

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 signaling, 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 destination 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.

From the Library of Juan Arcaya

VoIP Signaling Protocols

67

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


(UAC)

Initiates and sends requests and gets a response from a SIP UAS or
SIP proxy server. UAC, however, is a logical role and lasts only for the
duration of a SIP transaction.

SIP user agent server


(UAS)

Responds to SIP requests by accepting, rejecting, or redirecting the


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 authenticates 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 service for the domain it handles. This allows users to register their current locations.

SIP back-to-back user


agent (B2BUA)

Receives requests from UAs. However, it generates a new request on


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.

From the Library of Juan Arcaya

68

Chapter 3: Telephony Standards and Protocols

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 register 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 setting up a call.

Provisional Response
Acknowledgement
(PRACK)

Adds an acknowledgement system to the Provisional response (1XX).


PRACK is sent in response to a Provisional response.

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

From the Library of Juan Arcaya

VoIP Signaling Protocols

IP Phone A

CUCM

69

IP Phone B

REGISTER

REGISTER

200 OK

200 OK

INVITE (SDP)
INVITE (SDP)

100 Trying
180 Ringing
200 OK
ACK
RTP
BYE

200 OK

100 Trying
180 Ringing
200 OK

ACK
RTP

BYE
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 capabilities 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 during 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.

From the Library of Juan Arcaya

003_9780133845969_ch03.indd 69

6/25/14 8:28 AM

70

Chapter 3: Telephony Standards and Protocols

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

From the Library of Juan Arcaya

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

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

From the Library of Juan Arcaya

72

Chapter 3: Telephony Standards and Protocols

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

From the Library of Juan Arcaya

H.323 Gateway, Gatekeeper, and RAS

73

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 anonymity is desired.
SIP BFCP is an application-sharing mechanism that leverages the BFCP protocol. For
instance, a user participating in a Cisco WebExenabled 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 permission 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 wishes 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

From the Library of Juan Arcaya

74

Chapter 3: Telephony Standards and Protocols

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 communication 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 implemented 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. Its 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.

From the Library of Juan Arcaya

H.323 Gateway, Gatekeeper, and RAS

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

75

H.323 Gateway
An H.323 gateway is a device that can interface with the public switched telephone network (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 signaling. 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 configure 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:

From the Library of Juan Arcaya

76

Chapter 3: Telephony Standards and Protocols

Step 1.

Go to the Cisco Unified CM Administration page and choose Device >


Gateway.

Step 2.

Click Add New.

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), description, 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)

From the Library of Juan Arcaya

H.323 Gateway, Gatekeeper, and RAS

77

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 controlled 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* command is employed to specify the gatekeepers 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 correspond 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 gatekeeper function on the Cisco IOS router.

H.225 and RAS Signaling


Table 3-6 lists the H.225 call signaling messages.

From the Library of Juan Arcaya

003_9780133845969_ch03.indd 77

6/25/14 8:28 AM

78

Chapter 3: Telephony Standards and Protocols

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 indicate 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 calls release.

Progress

Sent by an H.323 gateway to indicate a calls 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 discovery. A GRQ message can be a unicast or multicast
message.

Gatekeeper Confirmation (GCF)

Acceptance message from the gatekeeper to an endpoint/gateway so that the endpoint/gateway can work
with a gatekeeper.

From the Library of Juan Arcaya

H.323 Gateway, Gatekeeper, and RAS

RAS Signaling Message

Description

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 confirm 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 gatekeepers to obtain the IP of a different zones 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 doesnt 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 available 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 endpoint terminates the call).

Disengage Confirmation (DCF)

Sent by the gatekeeper in response to a DRQ confirming it has disengaged the call and released the associated bandwidth.

79

From the Library of Juan Arcaya

80

Chapter 3: Telephony Standards and Protocols

RAS Signaling Message

Description

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 processed; 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 gatekeeper 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 additional calls.
Resource Availability Confirmation
(RAC)

A notification from the gatekeeper to the endpoint/


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 gatekeeper is able to register new endpoints/gateways.
3. Both gateways send an RRQ message to the H.323 gatekeeper in an attempt to register as part of that gatekeepers 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 authorization 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.

From the Library of Juan Arcaya

H.323 Gateway, Gatekeeper, and RAS

H.323 Gateway A

Gatekeeper

81

H.323 Gateway B

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

Figure 3-5

DRQ

DRQ

DCF

DCF

H.323 RAS Call Flow

From the Library of Juan Arcaya

82

Chapter 3: Telephony Standards and Protocols

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 twoway 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 logical 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 disengagement 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 gatekeepers
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 channel that can be used for sharing content (analogous to SIP BFCP). H.239 is the only content 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.

From the Library of Juan Arcaya

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 COs 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 telephone exchange. Upon close of the loop, the current flows (indicating off-hook). Loopstart 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 common 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 disconnect 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

From the Library of Juan Arcaya

84

Chapter 3: Telephony Standards and Protocols

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 transmissions 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 enduser 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, loopstart 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 connector): Trunk Circuit and Signaling Unit. The Signaling Unit and Trunk Circuit communicate 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 frequently 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 doesnt offer ground isolation
and cannot be used in a back-to-back configuration. This variant is common 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.

From the Library of Juan Arcaya

Digital Telephony

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 configuration, but doesnt offer ground isolation. This E&M variant is common outside North America.

85

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 doesnt 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 transmission of voice and data over conventional telephone copper wires. ISDN is an ITU-T standard 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 (signaling) 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.

From the Library of Juan Arcaya

86

Chapter 3: Telephony Standards and Protocols

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

From the Library of Juan Arcaya

Digital Telephony

87

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 circuitswitched 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 robbing 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 permanently associated with that circuit. Signaling is based on analog signaling: loop-start,

From the Library of Juan Arcaya

88

Chapter 3: Telephony Standards and Protocols

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

From the Library of Juan Arcaya

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 analog 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 destination 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 calling partys 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 supported 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).

From the Library of Juan Arcaya

003_9780133845969_ch03.indd 89

6/25/14 8:28 AM

90

Chapter 3: Telephony Standards and Protocols

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 impedance 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 network, 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 cancellation 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, followed 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 hissing 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 problems 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 automatically 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.

From the Library of Juan Arcaya

Fax and Modem Protocols

Step 2.

91

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 transparent 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 protocols. 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
1100101101

G.711 64 kbps
Encoding

V
Fax Machine A

Analog Fax Data Tunneled G.711 64 kbps


Through 64 kbps IP Channel
Decoding

IP Network

Voice Gateway A

Fax (Analog) Data


1100101101

V
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

From the Library of Juan Arcaya

003_9780133845969_ch03.indd 91

6/25/14 8:28 AM

92

Chapter 3: Telephony Standards and Protocols

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 mechanism 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 communicating 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
1100101101
Fax Data

Fax Data Sent as


Data Packets

DSP Modulates
Fax Data

Fax (Analog) Data


1100101101

IP Network

Fax Machine A

Voice Gateway A

Voice Gateway B

Fax Machine A to Voice


Gateway A Connection

Figure 3-7

Voice Gateway to Voice Gateway


Connection

Fax Machine B

Voice Gateway B to Fax


Machine B Connection

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

On-Ramp
Gateway

Fax Data Sent as


Email

Email with TIFF


Attachment

IP Network

V
Fax Machine A

Voice Gateway A

Fax Machine A to Voice


Gateway A Connection

Figure 3-8

PC
Voice Gateway to PC (Email)

Store-and-Forward Fax Call Flow

From the Library of Juan Arcaya

Fax and Modem Protocols

93

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

From the Library of Juan Arcaya

003_9780133845969_ch03.indd 93

6/25/14 8:28 AM

This page intentionally left blank

From the Library of Juan Arcaya

Chapter 4

Cisco Unified
Communications Manager

Cisco Unied Communications Manager (CUCM) is an IP PBX that delivers enterpriseclass telephony features and functions. CUCM offers interfaces that include Cisco
Unied IP Phones, voice messaging (Cisco Unity Connection), presence (Cisco Unied
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 Phones device pools 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.

From the Library of Juan Arcaya

96

Chapter 4: Cisco Unified Communications Manager

Cisco Unified CM Group

CUCM
Subscriber 1

Signaling with
Primary CUCM

Figure 4-1

CUCM
Subscriber 2

Backup Connection
with Secondary CUCM

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

From the Library of Juan Arcaya

CUCM Device Pool

Device Pool Parameter

Description

Calling Search Space for


Auto-Registration

Calling restrictions for phones that auto-register with CUCM.

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
Services Enrolled Group

Used with Intercompany Media Engine (IME).

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


Telephony (SRST) Reference

Specifies a gateway that provides call-control functionality


if phones are unable to communicate with CUCM in case of
WAN failure.

Connection Monitor
Duration

Time period before a phone using Cisco Unified Survivable


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


Search Space

Used when a device is roaming.

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.

97

Calling Party Transformation Modifies the number used as the caller ID.
CSS

From the Library of Juan Arcaya

98

Chapter 4: Cisco Unified Communications Manager

Device Pool Parameter

Description

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


Settings

Allows addition or stripping of digits for national, international,


and subscriber numbers for calling party.

Incoming Called Party


Settings

Allows addition or stripping of digits for national, international,


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

Allows modification of the connected party number to E.164


or Direct Inward Dial (DID) format.

Redirecting Party
Transformation CSS

Allows modification of the redirecting party number.

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 combination can be used for system addressing.

IP Addressing Mode Preference for


Signaling

Specifies whether IPv4 only, IPv6 only, or a combination can be used for signaling.

Allow Auto-Configuration for Phones

Allows DHCPv6 auto-configuration for IP Phones.

From the Library of Juan Arcaya

Codec Selection

Common Device Parameter

Description

Use Trusted Relay Point

Defines whether the endpoint (to which Common


Device Configuration is applied) will use a TRP.

99

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 gateway/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 preference 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 selection 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.

From the Library of Juan Arcaya

100

Chapter 4: Cisco Unified Communications Manager

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 configure Call Park configuration in Cisco Unified CM Administration:
Step 1.

Choose Call Routing > Call Park.

Step 2.

Click Add New.

Step 3.

In the Call Park Number/Range field, enter a number or pattern (wildcard).

Step 4.

Enter other required details and click Save.

From the Library of Juan Arcaya

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

Click Add New.

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 followed 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 different 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 ringing phones 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 2.

Click Add New.

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.

From the Library of Juan Arcaya

102

Chapter 4: Cisco Unified Communications Manager

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

Click Add New.

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 feature 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 phones 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 phones 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.

From the Library of Juan Arcaya

CUCM Features

Figure 4-3

103

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 available, the call is answered. Otherwise, it hunts to the next line or moves to the next available 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 forwarded, 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.

From the Library of Juan Arcaya

104

Chapter 4: Cisco Unified Communications Manager

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 poolfor 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 configured 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 2.

Click Add New.

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.

From the Library of Juan Arcaya

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 hardware 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 MTPs 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 2.

Click Add New.

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 support is enabled, the multicast stream can increase, based on port number or IP address.

From the Library of Juan Arcaya

004_9780133845969_ch04.indd 105

6/25/14 10:15 AM

106

Chapter 4: Cisco Unified Communications Manager

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

Click Add New.

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.

From the Library of Juan Arcaya

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 illustrates the concept of an MTP used as a TRP.

Signaling to
CUCM

TRP (MTP)

Media Anchored
to TRP

Cisco Unified
IP Phone

Figure 4-4

Jabber
Softphone

Media Anchored
to TRP

Jabber
Softphone

Cisco Unified
IP Phone

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

From the Library of Juan Arcaya

108

Chapter 4: Cisco Unified Communications Manager

Trunks

Endpoints

Other ecosystem applications

Figure 4-5 depicts a high-level CUCM dial plan.

Class of Service
INTERNAL,
EMERGENCY
INTERNAL,
EMERGENCY, LOCAL
INTERNAL,
EMERGENCY, LOCAL,
NATIONAL

Calling Search
Spaces

Partitions

Route Patterns

INTERNAL

8XXXXXXX

EMERGENCY

911, 9.911

LOCAL

9.[2-9]XXXXXX

NATIONAL-CSS

NATIONAL

91.[2-9]XX[2-9]XXXXXX

Gateway/Trunks

Route Group

Route Lists

SIP-Trunk-Internal

RG-SIP-Trunk

RL-SIP-Trunk

Gateway 1

RG-Gateway-Trunk

RL-Gateway Trunk

INTERNAL-CSS
LOCAL-CSS

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

From the Library of Juan Arcaya

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, theyre processed by CUCM (digit
analysis/manipulation) and the devices (phones) CSS determines if the digits dialed have
access to the destination resource, which may be another phone, a route pattern, a gateway, 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 pattern 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

From the Library of Juan Arcaya

110

Chapter 4: Cisco Unified Communications Manager

route listbased 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 offnet calls from within an organization. Globalized call routing requires use of +E.164 dialing via use of the + sign prepended to international access codes. You should avoid overlapping 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 normalization, 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 example, \+.!) 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 concept. 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 predot 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

From the Library of Juan Arcaya

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 gateway). 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 sites 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 IP Phone
Device-Pool Site A

Site-A-RG
Site-A-Gateway
Route Pattern
911

Route List (PSTN)


Route Group
(Standard Local RG)

Site-A-Gateway
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 GroupBased Call Routing

From the Library of Juan Arcaya

004_9780133845969_ch04.indd 111

6/25/14 10:15 AM

112

Chapter 4: Cisco Unified Communications Manager

An LRG allows site specificity of call routing to be established by the calling devices
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-ARG 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 phones device pool.
However, they can all call the same route pattern(s), and the calls are routed differently
based on the callers 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 organizations policy) post business
hours.
The following example illustrates the Time-of-Day routing concept. A phone in an organizations 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 business 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 periods 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 organizations 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 devices 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

From the Library of Juan Arcaya

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 digits 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 useful 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 choosing 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.

From the Library of Juan Arcaya

114

Chapter 4: Cisco Unified Communications Manager

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


Prefix Digits 1408333

Calling Party: 14083331000


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 calling number. Various digit manipulation mechanisms and their specifics are listed and
described in Table 4-3.

From the Library of Juan Arcaya

CUCM Digit Manipulation 115

Table 4-3

CUCM Digit Manipulation Options

Digit Manipulation
Mechanism

Description

Configuration Approach

External Phone
Number Mask

Allows setting an E.164 address for the


user extension part of Calling/Called
Party Transformation settings and helps
format caller ID for PSTN outbound calls
made from phones. The route pattern
must honor the External Phone Number
Mask option (check box) so that the same
can be carried from the endpoint over to
the PSTN.

Navigate to Device >


Phone and select the
phone, select the appropriate line, and set the
External Phone Number
Mask.

Translation Pattern

When user-dialed digits match a


translation pattern, CUCM performs the
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.

Navigate to Call Routing >


Translation Pattern.

Transformation
Masks

Help manipulate the dialed digits (DNIS)


or calling party number (ANI), as part of
Calling/Called Party Transformation settings. A transformation mask can contain
digits 09, *, #, and X and can be applied
to a number to extend or
truncate it.

Can be configured under


translation patterns, route
patterns, or route list settings (applying to route
groups). Transformation
masks configured at the
route group level have
priority over those configured at the route pattern
level.

Digit Prefix and Digit Prefix digits to or strip dialed digits from
Stripping
a route or translation pattern for outbound 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 pattern 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 pattern. Valid digit discard instructions include
PreDot, PreAt, Trailing#, and so on.

From the Library of Juan Arcaya

004_9780133845969_ch04.indd 115

6/25/14 10:15 AM

116

Chapter 4: Cisco Unified Communications Manager

Digit Manipulation
Mechanism

Description

Configuration Approach

Significant Digits

Enables CUCM to manage only the leastsignificant N digits of the called number
for incoming calls (from PSTN gateway/
trunk or from another CUCM cluster) and
is available as part of the Gateway/Trunk
Configuration settings.

Navigate to Device
> Gateway/Trunk
Configuration > Call
Routing Information
Inbound Calls.

Calling Party Transformation Patterns


Calling and Called
Party Transformation control the adaptation of calling party
numbers from enterprise to PSTN E.164
Patterns
format. Called Party Transformation
Patterns manipulate the dialed digits,
Number Type, and Numbering Plan.

Navigate to Call Routing


> Transformation >
Transformation Pattern.

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

From the Library of Juan Arcaya

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 following 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 optional. 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 support 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.

From the Library of Juan Arcaya

118

Chapter 4: Cisco Unified Communications Manager

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

abc@corp.local

xyz@corp.local

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 specifics come into play:

Directory lookup based on the end-user directory on CUCM always returns a


number.

From the Library of Juan Arcaya

Intercluster Lookup Service

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 translation 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 transformation is the calling party transformation CSS on calling endpoint or calling endpoints
device pool.

The default Directory URI partition will have all auto-generated user-based URIs.

119

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 abc@siteA.corp.local and xyz@
siteB.corp.local, instead of a flat schema, such as abc@corp.local and xyz@corp.local.
Moreover, the remote clusters may not be aware of the local clusters 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.
abc@corp.local

ILS Learned URIs


to Route String Mapping
CUCM Cluster Site A
Route String: siteA.corp.local

xyz@corp.local > SiteB.corp.local


pqr@corp.local > SiteC.corp.local

si

ca

te

.lo

.c
eA

si

si

p
or

a
oc

te

l
p.

CUCM Cluster Site B


Route String: siteB.corp.local

A.
co

rp

.lo

.c

or

or

ca
l

p.
lo

.c
eB

ca

si

l
CUCM Cluster Site C
Route String: siteC.corp.local

ILS Exchange

ILS Learned URIs


to Route String Mapping

ILS Learned URIs


to Route String Mapping

abc@corp.local > SiteA.corp.local


pqr@corp.local > SiteC.corp.local

abc@corp.local > SiteA.corp.local


xyz@corp.local > SiteB.corp.local

siteB.corp.local
siteC.corp.local

xyz@corp.local

Figure 4-10

pqr@corp.local

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 URIs home cluster. Each
call-control agent replicates its alpha URIs to its neighbors and also announces a SIP route

From the Library of Juan Arcaya

120

Chapter 4: Cisco Unified Communications Manager

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 Spoke

ILS Spoke

Figure 4-11

ILS Hub

ILS Networking

From the Library of Juan Arcaya

Intercluster Lookup Service

121

To configure ILS, follow these steps:


Step 1.

Ensure that a unique Cluster ID is defined for each cluster that is going to participate 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 certificates 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. Dont 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 window 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.

From the Library of Juan Arcaya

122

Chapter 4: Cisco Unified Communications Manager

At this time, ILS configuration is complete. Remote cluster information and services provided 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 looking 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:abc@corp.local;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:

From the Library of Juan Arcaya

CUCM Call Admission Control

Locations-based CAC (LCAC)

Enhanced LCAC (E-LCAC)

Resource Reservation Protocol (RSVP)

123

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 serverbasically, 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 separate 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 bandwidth 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 isnt 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).

From the Library of Juan Arcaya

124

Chapter 4: Cisco Unified Communications Manager

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 bandwidth available between locations. Links logically represent the WAN link.

Weights: Used on links to provide a cost to the effective path. Weights are pertinent 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 indicates 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.

From the Library of Juan Arcaya

CUCM Call Admission Control

125

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 paths 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 previous 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 propagates its topology to other clusters configured in the LBM intercluster replication network. Each cluster then creates a Global Topology (also called Assembled Topology),
piecing together each clusters replicated topology. A single cluster, such as an SME cluster, 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 necessary 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

From the Library of Juan Arcaya

126

Chapter 4: Cisco Unified Communications Manager

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

From the Library of Juan Arcaya

CUCM Call Admission Control

IP Phone A

CUCM

RSVP Agent A

RSVP Agent B

127

IP Phone B

Call Setup to IP Phone B


Allocate RSVP Agent to
Phone A

Allocate RSVP Agent to


Phone B
Reserve Bandwidth from
RSVP Agent B to A

Reserve Bandwidth from


RSVP Agent A to B
Bandwidth Reservation
Successful

Alerting Tone

Bandwidth Reservation
Successful
Call Setup to IP Phone B
Answer

Connect

Connect

Connect

Connect

Non-RSVP Protected
RTP Stream

RSVP Protected
RTP Stream

RSVP Protected
RTP Stream

Non-RSVP Protected
RTP Stream

Figure 4-17

RSVP Call Flow Overview

RSVP configuration is a twofold process wherein CUCM and the IOS router must be configured 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 Phones MRGL). Example 4-1 outlines the configuration of Cisco IOS router MTP as
the RSVP agent.

From the Library of Juan Arcaya

128

Chapter 4: Cisco Unified Communications Manager

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:

From the Library of Juan Arcaya

CUCM-Based Call Recording and Silent Monitoring

129

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:
m=audio 20000 RTP/AVP 0
c=IN IP4 10.10.100.201
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv

In reply, the other RSVP agent sends the following SDP (result of 200 OK UPDATE):
m=audio 30000 RTP/AVP 0
c=IN IP4 10.20.10.200
a=curr:qos e2e sendrecv
a=des:qos mandatory 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:

Step 3.

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.

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

From the Library of Juan Arcaya

130

Chapter 4: Cisco Unified Communications Manager

customers. CUCMs Call Recording feature enables organizations to archive the conversation 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 support 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
Gateway

Observed
Voice Stream

MGCP/H.323/SIP

TAPI/JTAPI

Monitoring/Recording
Enabled Desktop Application

Callers Voice
Stream
SCCP/SIP

TAPI/JTAPI
SIP Trunk

VoiceEnabled Switch
Recording
Server

Monitored and
Recorded User (Agent)

Figure 4-19

Observer
(Supervisor)

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

From the Library of Juan Arcaya

CUCM-Based Call Recording and Silent Monitoring

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

131

To enable Silent Monitoring on a Cisco Unified IP Phone, follow these steps in Cisco
Unified CM Administration:
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 partition 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 agents 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. Theres 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 callspecific data is retrieved via CTI using CallID.

From the Library of Juan Arcaya

004_9780133845969_ch04.indd 131

6/25/14 10:15 AM

132

Chapter 4: Cisco Unified Communications Manager

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 settings. If the codec required is different than the original call, a transcoder is automatically inserted.

To configure CUCM-based Call Recordingthat is, to connect a Recorder (Recording


Server) to CUCM and configure a phone for recordingfollow these steps in Cisco
Unified CM Administration:
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 hostname 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.

From the Library of Juan Arcaya

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

From the Library of Juan Arcaya

004_9780133845969_ch04.indd 133

6/25/14 10:15 AM

134

Chapter 4: Cisco Unified Communications Manager

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 single 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 users home clusters 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 users 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 clusters 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 visiting clusters to the home cluster.

From the Library of Juan Arcaya

CUCM Mobility

Step 4.

Go to the Cisco Unified CM Administration page and choose Device >


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.

135

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 devices device pool and the device pool
configured on the IP subnet. If the Physical Location is different, CUCM applies the IP
subnets 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.

From the Library of Juan Arcaya

136

Chapter 4: Cisco Unified Communications Manager

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 information 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
theres 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 users
desk phone that is enabled for mobility, and the other from a users 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 users configured remote
destination profile(s), rings all the remote devices (in this case the users 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.

From the Library of Juan Arcaya

CUCM Mobility

137

Call from
+15558888000

PSTN Caller
+15558888000

Remote Phone
(of DN 9000)
+14088888000
Call to
+15555559000

Call to
+15555559001

PSTN

Cisco Unified IP Phone


DN = 9001
Voice
Gateway
5555559XXX

Call From 9000

Voice Enabled
Switch

CUCM
(Mobile Connect)

Figure 4-20

Cisco Unified IP Phone


DN = 9000

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.

From the Library of Juan Arcaya

004_9780133845969_ch04.indd 137

6/25/14 10:15 AM

138

Chapter 4: Cisco Unified Communications Manager

Step 3.

Go to the Cisco Unified CM Administration page and choose Device >


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

From the Library of Juan Arcaya

004_9780133845969_ch04.indd 138

6/25/14 10:15 AM

CUCM Mobility

PSTN Phone
+15558888000

139

Remote Phone
(of DN 9000)
+14088888000

Call from
+15555559000

Call to
+15555559999

PSTN

H.323 VXML
Voice Gateway
(IVR Application)

Remote Destination
Number and PIN

CUCM
(MVA)

9999

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

From the Library of Juan Arcaya

004_9780133845969_ch04.indd 139

6/25/14 10:15 AM

140

Chapter 4: Cisco Unified Communications Manager

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 administratively 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 discover 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.

From the Library of Juan Arcaya

Service Advertisement Framework and Call Control Discovery

CUCM Cluster
(SAF Client)

CUBE
(SAF Client)

CUCME
(SAF Client)

IOS Gateway
(SAF Client)

SME Cluster
(SAF Client)

CCD

CCD

CCD

CCD

CCD

SAF Client
Protocol

SAF Forwarder

SAF Forwarder

SAF Forwarder

SAF Forwarder

141

SAF Client
Protocol

SAF Forwarding
Protocol
SAF Forwarder

Figure 4-22

SAF Unaware Routers

SAF Forwarder

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 network 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 information, 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 consume, 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 forwarders as well as SAF clients so that the SAF-enabled network is aware of all learned call

From the Library of Juan Arcaya

142

Chapter 4: Cisco Unified Communications Manager

routes. This helps overcome the full-mesh, point-to-multipoint manual dial plan proliferation 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 signaling 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 information 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 configuration, 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 cant 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 SAFenabled 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.

From the Library of Juan Arcaya

Service Advertisement Framework and Call Control Discovery

DN Pattern

to DID Rule

IP Address

Protocol

8961XXXX +91114261 /4 10.86.108.230


8962XXXX

+656585 /4 10.96.108.240

143

SIP
H.323

DN Pattern

to DID Rule

8963XXXX

+1408567 /4 10.76.108.146

IP Address

Protocol
SIP

8962XXXX

+656585 /4 10.96.108.240

H.323

PSTN
8963XXXX

10.76.108.146

San Jose
SAF Forwarder

SAF-Enabled
Network

8961XXXX

10.86.108.230
Delhi

SAF Forwarder
Singapore
8962XXXX

10.96.108.240 SAF Forwarder

DN Pattern

to DID Rule

8963XXXX

+1408567 /4 10.76.108.146

H.323

8961XXXX +91114261 /4 10.86.108.230

H.323

Figure 4-23

IP Address

Protocol

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 routers 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 created in Step 1. Click Save.

Step 3.

Go to Call Routing > Call Control Discovery > Hosted DN Group and create a group. Enter required information and click Save.

From the Library of Juan Arcaya

144

Chapter 4: Cisco Unified Communications Manager

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 manipulation); 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


Learned Patterns

Specifies the number of patterns that a CUCM cluster


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


Patterns

Specifies whether CUCM issues an alarm when it learns


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.

From the Library of Juan Arcaya

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


From the Library of Juan Arcaya

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 possible threats to infrastructure, endpoints, devices, and applications. Security threats pertinent 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/
interception attacks

Aimed at voice and signaling sessions, leading to loss of confidentiality or integrity, or both.

Identity theft/
impersonation attacks

Used to exploit information in voice and video streams, leading to


loss of confidentiality.

Toll fraud

Occurs by means of unauthorized or fraudulent use of telephony


equipment or services.

Denial-of-service (DoS)
attacks

Leads to degradation of voice and video services.

Intrusion attacks

Targeted at services associated with or enabled by the telephony


implementation, such as servers in the same zone as UC servers.

Theres 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

From the Library of Juan Arcaya

Threats to Cisco Collaboration Networks

147

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 spoofing 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 addresses 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 switchs 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 notifications, identical to the restrict option, and it will also increment a violation counter.

From the Library of Juan Arcaya

148

Chapter 5: Cisco Unified Communications Security

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 errdisable 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 configuration 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)# interface FastEthernet 0/10
UCSWITCH(config-if)# ip dhcp snooping trust
!
UCSWITCH(config)# interface FastEthernet 0/20
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.

From the Library of Juan Arcaya

Threats to Cisco Collaboration Networks

149

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 topology 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
dont accept any BPDUs. Root Guard ensures that when the root (or root bridge) is elected, a new BPDU on a designated port isnt 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 attackers switch/PC becomes the default gateway for
the telephony subnet. ARP poisoning can be implemented by replying to and poisoning the network so that the attackers 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 perinterface basis.
Example 5-3 DAI Interface-Specific and Global Setup
UCSWITCH(config)# ip arp inspection vlan 300
!
UCSWITCH(config)# interface FastEthernet 0/1
UCSWITCH(config-if)# ip arp inspection trust

802.1x
802.1x is a standard set by the IEEE 802.1 working group. Its 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 protocol for transporting authentication messages (EAP) between a supplicant (user/endpoint/
PC) and an authenticator (switch or access point) with an (optional) authentication server

From the Library of Juan Arcaya

150

Chapter 5: Cisco Unified Communications Security

(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
(Authenticator)

LAN Switch
(Authenticator)

RADIUS/TACACS+
(Authentication Server)

EAPoL

EAPoW

PVID

Wireless Client
(Supplicant)

Figure 5-1

Wired Client
(Supplicant)

802.1Q
VVID

IP Phone
(Supplicant)

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 Phones


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) authenticates 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)# interface FastEthernet 1/1
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

From the Library of Juan Arcaya

Threats to Cisco Collaboration Networks

151

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 following configuration enables IP source guard on the FastEthernet 0/10 interface of a Cisco
Catalyst switch:

From the Library of Juan Arcaya

152

Chapter 5: Cisco Unified Communications Security

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)# interface FastEthernet 1/1
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, routing 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 following 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.

From the Library of Juan Arcaya

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 networkthat is, it works at Layer 3. Routed
mode supports multiple interfaces and practically all Cisco Collaboration services/applications. 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 firewall that acts like a bump in the wire. In transparent mode, Cisco ASA has some limitations 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 multiplecontext 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 firewall/ALG to reach the destination. Firewall traversal is provided in multiple ways, including NAT traversal, IPsec tunnels, IP ACLs, or port-based ACLs.

NAT Traversal
Almost every firewall (including Cisco ASA) provides NAT services to enable manipulating the IP address or port number, or both, for traffic going out or coming into a network. 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, thereby 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

From the Library of Juan Arcaya

154

Chapter 5: Cisco Unified Communications Security

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 organizations 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-usageguide-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 businessto-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.

From the Library of Juan Arcaya

Cisco ASA Proxy Features

Telepresence System

Data Center
Firewall

SIP

Firewall

SIP

Video IP Phone
SIP

Internet

SIP

Video IP Phone

Figure 5-2

155

SIP
CUCM Cluster

VCS Control

VCS Expressway

SIP
Telepresence System

VCS Expressway Firewall Traversal

Its important to note that SIP and H.323 protocol inspection on the firewall must be disabled. 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-PortUsage-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 contents. 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 traffic passing through the firewall is compliant with the organizations security policy.
TLS Proxy requires encrypted endpoints on the outside and inside of an ASAbrokered 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 endpoints 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 centralized CUCM cluster via the Internet. Moreover, unlike TLS Proxy, Phone Proxy
doesnt require internal endpoints to be encrypted; hence, the CUCM cluster within
an organizations 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.

From the Library of Juan Arcaya

156

Chapter 5: Cisco Unified Communications Security

Cisco VPN Phone


Cisco VPN Phone is a Cisco Unified IP Phonebased VPN solution that extends the
reach of your Cisco Collaboration solution to outside the logical perimeter of your organization. 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.
SCCP

Data Center

SCCP

SSL Session
(AnyConnect)
SOHO, Telecommuter,
Hotel Room

Enterprise Premises

Internet
Cisco Unified IP
Phone

CUCM Cluster

Cisco ASA

Cisco Unified IP
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
!

From the Library of Juan Arcaya

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 register 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 models
application layers services. The following sections address the security mechanisms
offered by Cisco Unified CM.

From the Library of Juan Arcaya

158

Chapter 5: Cisco Unified Communications Security

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 servers 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) service 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 nonsecure 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:

From the Library of Juan Arcaya

CUCM Security Modes

Step 1.

In Cisco Unified CM Administration, choose Serviceability > Tools >


Service Activation and enable CAPF and CTL services on the CUCM publisher 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 download 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 whichever servers they are configured. Click Done. Restart the CCM and TFTP
services on all servers where they are enabled and activated.

159

You can verify the clusters 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 contains the following:

Server Certificate

Public Key

Serial Number

Signature

Issuer Name

Subject Name

Server Function

From the Library of Juan Arcaya

005_9780133845969_ch05.indd 159

6/25/14 11:07 AM

160

Chapter 5: Cisco Unified Communications Security

DNS name

IP address for each server

A CTL file (downloaded to Cisco Unified IP Phones and softclients) consists of the following 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
Certificate

TFTP Trusted
Certificate

CTL Client Trusted


Certificate

CAPF Trusted
Certificate

CA Trusted
Certificate

Cisco ASA Trusted


Certificate

Figure 5-4

CTL File Contents

From the Library of Juan Arcaya

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 models, 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 organizations
internal CA or an external trusted CA. Figure 5-5 depicts the difference between the MIC
and the LSC.
Cisco Manufacturing CA

Cisco
Manufacturing

MIC
(Cisco CA
Public Key)

Cisco Unified IP Phone

Figure 5-5

Cisco CUCM CAPF Server

CAPF
TLS

LSC
(CAPF
Public Key)

Cisco Unified IP Phone

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

From the Library of Juan Arcaya

162

Chapter 5: Cisco Unified Communications Security

H.323 gateway with certificates exchanged with CUCM for SRTP and IPsec for protecting 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.
Voice Gateway

CUCM

Secure SIP
Trunk, IPsec for
MGCP/H.323
SCCPS or SIPS
(TLS Signaling)

IP Phone A

Figure 5-6

SRTP (Media)

SRTP (Media)

IP Phone B

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

From the Library of Juan Arcaya

Preventing Toll Fraud

Table 5-2

163

CUCM CoS Components

CUCM CoS Component

Description

Partitions and calling search


spaces (CSS)

Provide segmentation and control to the number that


can be called, or vice versa. As a leading practice recommendation, 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 restricted 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 partitions become inactive automatically. Helps restrain calls
made to national and international numbers after business hours. See Chapter 4 for more details.

Forced Authorization Code (FAC)


and Client Matter Code (CMC)

Used to control the access to international and long distance calls. FAC/CMC forces a user to enter a predetermined 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 originator 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.

From the Library of Juan Arcaya

005_9780133845969_ch05.indd 163

6/25/14 11:07 AM

164

Chapter 5: Cisco Unified Communications Security

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 configurable 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 implemented at either dialpeers or ephone-dns on a voice gateway. The dial-peer cor custom command 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 emergency
UCRouter(config-dp-corlist)# member local
!
UCRouter(config)# dial-peer cor list national
UCRouter(config-dp-corlist)# member emergency
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 voice 7 pots
UCRouter(config-dial-peer)# corlist outgoing local
<output-omitted for brevity>
!

From the Library of Juan Arcaya

Preventing Toll Fraud

165

UCRouter(config)# dial-peer voice 11 pots


UCRouter(config-dial-peer)# corlist outgoing national
<output-omitted for brevity>

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 system 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 everything 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.

From the Library of Juan Arcaya

This page intentionally left blank

From the Library of Juan Arcaya

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 Unied 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 administration, 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:

From the Library of Juan Arcaya

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

For 100 voice messaging ports on each server: 14 Mbps

For 150 voice messaging ports on each server: 21 Mbps

For 200 voice messaging ports on each server: 28 Mbps

For 250 voice messaging ports on each server: 35 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
Cluster

Cisco
Unified
CME

CUC
Cluster

WAN
CUCM
Cluster

SCCP Voicemail Integration

Cisco
Unified
CME

SIP Voicemail Integration

Figure 6-1
CUCME

CUC SCCP Voicemail and SIP Voicemail Integration with CUCM and

From the Library of Juan Arcaya

Cisco Unity Connection Integration with CUCM and CUCME

169

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.

From the Library of Juan Arcaya

170

Chapter 6: Cisco Unity Connection

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

From the Library of Juan Arcaya

006_9780133845969_ch06.indd 170

6/25/14 11:11 AM

Cisco Unity Connection Integration with CUCM and CUCME

171

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.) Its important to note that the primary and backup CUCM addresses 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 number 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 outcalling 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 second SIP trunk pointing to the CUC publisher (the leading practice recommendation is to send traffic to the CUC subscriber followed by the publisher).

From the Library of Juan Arcaya

172

Chapter 6: Cisco Unity Connection

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 section, 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 11
CMERouter(config-ephone-dn)# number 7711
CMERouter(config-ephone-dn)# mwi off
!
CMERouter(config)# ephone-dn 20
CMERouter(config-ephone-dn)# number 7000
CMERouter(config-ephone-dn)# name "VM-Port 1"
CMERouter(config-ephone-dn)# preference 0
CMERouter(config-ephone-dn)# no huntstop
!
CMERouter(config)# ephone-dn 21
CMERouter(config-ephone-dn)# number 7000
CMERouter(config-ephone-dn)# name "VM-Port 2"
CMERouter(config-ephone-dn)# preference 1
CMERouter(config-ephone-dn)# no huntstop

From the Library of Juan Arcaya

Cisco Unity Connection Integration with CUCM and CUCME

173

!
CMERouter(config)# ephone-dn 22
CMERouter(config-ephone-dn)# number 7000
CMERouter(config-ephone-dn)# name "VM-Port 3"
CMERouter(config-ephone-dn)# preference 2
CMERouter(config-ephone-dn)# no huntstop
!
CMERouter(config)# ephone-dn 23
CMERouter(config)# number 7000
CMERouter(config-ephone-dn)# name "VM-Port 4"
CMERouter(config-ephone-dn)# preference 3
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 21
CMERouter(config-ephone)# vm-device-id CMEVM-VI2
CMERouter(config-ephone)# button 1:21
!
CMERouter(config)# ephone 22
CMERouter(config-ephone)# vm-device-id CMEVM-VI3
CMERouter(config-ephone)# button 1:22
!
CMERouter(config)# ephone 23
CMERouter(config-ephone)# vm-device-id CMEVM-VI4
CMERouter(config-ephone)# button 1:23
!
CMERouter(config)# ephone-dn 101
CMERouter(config-ephone-dn)# number 7799
CMERouter(config-ephone-dn)# call-forward busy 7700
CMERouter(config-ephone-dn)# call-forward noan 7700 timeout 10
!
CMERouter(config)# ephone 101
CMERouter(config-ephone)# button 1:101
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
!

From the Library of Juan Arcaya

174

Chapter 6: Cisco Unity Connection

CMERouter(config)# dial-peer voice 200 voip


CMERouter(config-dial-peer)# preference 1
CMERouter(config-dial-peer)# destination-pattern 7000
CMERouter(config-dial-peer)# session target ipv4:10.76.108.243
CMERouter(config-dial-peer)# dtmf-relay h245-alphanumeric
CMERouter(config-dial-peer)# codec g711ulaw

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 voice 110 voip

CMERouter(config-dial-peer)# description to CUC Subscriber


CMERouter(config-dial-peer)# destination-pattern 7100
CMERouter(config-dial-peer)# session protocol sipv2
CMERouter(config-dial-peer)# session target ipv4:10.76.108.244
CMERouter(config-dial-peer)# dtmf-relay rtp-nte
CMERouter(config-dial-peer)# codec g711ulaw
CMERouter(config-dial-peer)# max-conn 15
CMERouter(config-dial-peer)# no huntstop
!
CMERouter(config)#

dial-peer voice 111 voip

CMERouter(config-dial-peer)# description to CUC Publisher


CMERouter(config-dial-peer)# destination-pattern 7100
CMERouter(config-dial-peer)# session protocol sipv2
CMERouter(config-dial-peer)# session target ipv4:10.76.108.243
CMERouter(config-dial-peer)# dtmf-relay rtp-nte
CMERouter(config-dial-peer)# max-conn 15
CMERouter(config-dial-peer)# codec g711ulaw
CMERouter(config-dial-peer)# preference 2
CMERouter(config-dial-peer)# huntstop
!

From the Library of Juan Arcaya

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 organizations 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 partitions 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.

From the Library of Juan Arcaya

176

Chapter 6: Cisco Unity Connection

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 (directory 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 users (subscribers) 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

From the Library of Juan Arcaya

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 transfer 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 greetings 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 administrator 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 greetings using Greeting Administrator.

From the Library of Juan Arcaya

178

Chapter 6: Cisco Unity Connection

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 existing 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
users extension, a call handler, another directory handler, or a conversation. If a
caller doesnt 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.

From the Library of Juan Arcaya

Call Handlers

179

Greeting: Can be recorded as an opening prompt for a directory handler. If no greeting is recorded, the system directory handler uses a default greeting that prompts the
users 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
callers responses. These responses are delivered to a message recipient so that the recipient can understand the callers requirements/concerns or data in a better way. An interview 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 organizations 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

From the Library of Juan Arcaya

180

Chapter 6: Cisco Unity Connection

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 solution, 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 consequence, 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
Messages

Voice
Messages

Message
Synchronization

Email
Messages

Cisco Unity Connection


(Cluster)

Figure 6-6

Microsoft Exchange
Server

Microsoft Outlook
Client

CUC Single Inbox Architecture

When configured for single inbox, CUC doesnt synchronize the following messages:

Sent messages

Draft messages

From the Library of Juan Arcaya

Cisco Unity Connection Single Inbox

Messages set for future delivery but not yet delivered

Broadcast messages

Unaccepted dispatch messages

181

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 messages 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 message 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 messages, 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 servers IP address

Exchange server type (2003/2007/2010)

Active Directory account to access Exchange

From the Library of Juan Arcaya

182

Chapter 6: Cisco Unity Connection

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 certificate 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, WebBased 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 service 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

From the Library of Juan Arcaya

Cisco Unity Connection Visual Voicemail

Step 4.

Figure 6-8

183

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 Messagingenabled 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 users Unified
Messaging services as shown in 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 voicemail 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 Phones 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.

From the Library of Juan Arcaya

184

Chapter 6: Cisco Unity Connection

Step 3.

Create a new Hunt Pilot specifically for Visual Voicemail. Point it to an existing 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.

From the Library of Juan Arcaya

Voice Mail for Cisco Jabber

Figure 6-9

Figure 6-10

185

Cisco Jabber (Visual) Voice Mail

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

From the Library of Juan Arcaya

186

Chapter 6: Cisco Unity Connection

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

CUCM Jabber Service Profile


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 classified into the following categories:

From the Library of Juan Arcaya

Cisco Unity Connection Voicemail Networking

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 messaging platforms such as Cisco Unity Express and third-party voicemail systems

187

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 provisioned within the enterprise. CUC supports intrasite networking with other CUC clusters/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 uploading the remote locations configuration file and downloading the local configuration file
and uploading it to the remote location).

From the Library of Juan Arcaya

188

Chapter 6: Cisco Unity Connection

CUC Cluster
(Location)

Intrasite Links
CUC Cluster

CUC Cluster
(Location)

(Location)

Figure 6-12

CUC Server

CUC Server

(Location)

(Location)

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 networking. A single location from each site acts as a gateway to the other site, and these gateways 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 replication 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, synchronization settings and tasks, and intersite SMTP routing.

From the Library of Juan Arcaya

Cisco Unity Connection Voicemail Networking

189

Directory Exchange
HTTP/HTTPS
Message
Exchange

SMTP Server

Connection Site

Figure 6-13

SMTP Server

Connection Site

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 supports standards-based VPIM networking. The VPIM concept and networking with CUE
are discussed in Chapter 9, Cisco IOS UC Applications.

From the Library of Juan Arcaya

This page intentionally left blank

From the Library of Juan Arcaya

Chapter 7

Cisco Unified IM and


Presence

Cisco Unied Instant Messaging (IM) and Presence is now better known as Cisco Unied
Communications Manager IM and Presence (Cisco Unied CM IM and Presence).
This is due to the integration of Cisco Unied Presence technology with Cisco Unied
Communications Manager for Release 9.0 and later. Cisco Unied 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 together 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)

From the Library of Juan Arcaya

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
MeetingPlace

Video
Phone

SIP
SIMPLE

IBM
Sametime

XMPP

Video Client
On PC

XMPP

CUCM

CTI/SIP/DB
SIP
SIMPLE

Jabber
Client

SIP
SIMPLE

XMPP

SIP
SIMPLE
Cisco Unified
IP Phone

CSTA over SIP/


SIP SIMPLE

Microsoft
Lync

Figure 7-1

Cisco CM IM
and Presence

XMPP

Google
Talk

Cisco Unity
Connection

LDAP
LDAP

XMPP/SIP
SIMPLE

Third-Party
API

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

From the Library of Juan Arcaya

Cisco Unified CM IM and Presence Server Integration with CUCM

193

Cisco Unified IM Presence Cluster


1A

DB Sync

2A
IDS

IDS

1B

CUCM Cluster

Subcluster 1

Figure 7-2

3A

2B
Subcluster 2

3B
Subcluster 3

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

From the Library of Juan Arcaya

194

Chapter 7: Cisco Unified IM and Presence

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

Step 7.

Go to User Management > User Settings > UC Service, click Add New, and
select the UC Service Type Voicemail. Click Next. Enter the required details
for the Cisco Unity Connection server (voice messaging server).

From the Library of Juan Arcaya

Cisco Unified CM IM and Presence Server Integration with CUCM

Step 8.

Go to User Management > User Settings > UC Service, click Add New, and
select the UC Service Type Directory. Click Next. Enter the required details
for the LDAP server (the organizations 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 description 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 profile. For LDAP, enter the required details such as username, password, search
base, and so on as shown in Figure 7-4.

Figure 7-4

195

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

From the Library of Juan Arcaya

196

Chapter 7: Cisco Unified IM and Presence

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

From the Library of Juan Arcaya

Cisco Jabber

197

The integration of CUCM and the Cisco CM Unified IM and Presence server is complete. 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 communication tool, giving end users features and functionality such as voice, video, desktop sharing, 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.

From the Library of Juan Arcaya

198

Chapter 7: Cisco Unified IM and Presence

Cisco Jabber

IM and Presence
Contact Management
File Transfer

XMPP

IP Phone
Control

User Data Sync

Cisco

Figure 7-7

Cisco IM
and Presence

Visual
Voicemail

Directory Search
Authentication

Telephony
Presence
Cisco WebEx

Directory
Search

CUCM

LDAP

Cisco Unity
Connection

Jabber Architecture

As previously mentioned, Jabber can be deployed in two major deployment models, onpremises 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 sharing. BFCP encodes a video stream of the senders 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

From the Library of Juan Arcaya

Presence Federation

199

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 federation 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/
OCS/LCS Client

Cisco Jabber
Client

LDAP

SIP
Cisco Unified IM and
Presence Cluster

Figure 7-8

Microsoft Lync/OCS/
LCS Server

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

From the Library of Juan Arcaya

200

Chapter 7: Cisco Unified IM and Presence

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 (created 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 certificate 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 latter 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 format, it is recommended to use the Jabber XML file.

From the Library of Juan Arcaya

Presence Federation

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.

201

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 federation 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 B
DomainB.com

Enterprise A
DomainA.com
Inside (Private)

DMZ

DMZ

Cisco Unified IM and


Presence Cluster

Inside (Private)
Microsoft Lync/
OCS/LCS Server

SIP
Cisco
ASA

Cisco Jabber
Client

Figure 7-9

Microsoft
Edge

Microsoft Lync/
OCS/LCS Client

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.

From the Library of Juan Arcaya

202

Chapter 7: Cisco Unified IM and Presence

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
DomainA.com

Enterprise B
DomainB.com

Inside (Private)

Inside (Private)

Cisco Unified IM and


Presence Cluster

XMPP Server

XMPP

Cisco
ASA

XMPP Client
(Google Talk,
IBM Sametime)

Cisco Jabber
Client

Figure 7-10

XMPP
Gateway

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

From the Library of Juan Arcaya

Presence Cloud Solutions

Central administration web-based interface

Directory

IM archiving

XMPP federation

WebEx
Administrator

203

Inter-Domain
Federation
HTTPS

Cisco
WebEx

XMPP

XMPP

XMPP

Contacts
TLS/SSL
(XMPP)
CUCM

SIP (Softphone)/HTTPS
LDAP
(Directory)

TLS
CTI (Desk Phone)/HTTPS
Cisco Jabber
Clients
IMAP (Visual Voicemail)

Cisco Unity
Connection

IM Archiving

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 continues with the chat transmission.

From the Library of Juan Arcaya

204

Chapter 7: Cisco Unified IM and Presence

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 doesnt 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 difference 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.

From the Library of Juan Arcaya

Group Chat and Compliance

205

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 disabled in policy settings as Local Archive. By default, this value is set to TRUE.

From the Library of Juan Arcaya

206

Chapter 7: Cisco Unified IM and Presence

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 logging 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 database (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.

From the Library of Juan Arcaya

Group Chat and Compliance

207

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 initiation 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.
Customers 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 creating users, employing CSV files, directory integration, or Security Assertion Markup
Language (SAML).

From the Library of Juan Arcaya

This page intentionally left blank

From the Library of Juan Arcaya

Chapter 8

Cisco Unified Contact Center


Express

Cisco Unied 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
UCCX Cluster

CUCM
Cluster

Cluster View
Daemon
Datastores

CC
CC

Administration

Secondary

UC Manager

Engine

Primary
Cisco Agent
Desktop (CAD)

CTI Manager

CAD Client
Cisco Unified IP
Phone

Figure 8-1

Cisco Voice
Gateway

Cisco UCCX Architecture and Interaction with Cisco Collaboration Network

From the Library of Juan Arcaya

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 agents call. It can be based on desktopbased monitoring such as CAD to Cisco Supervisor Desktop (CSD) or Switched Port
Analyzer (SPAN) port monitoring.

From the Library of Juan Arcaya

UCCX ACD/ICD, IVR, and CTI Functions

211

Recording: Allows agent calls to be recorded by the supervisor. If desktop monitoring 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 demanding 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 productivity. 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.

From the Library of Juan Arcaya

212

Chapter 8: Cisco Unified Contact Center Express

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


Reporting

Basic

Historical and Real Time Reporting are


run in separate applications: Historical
Reporting through a Windows application 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


associated codes

Advanced

Allows agents appropriate time to log


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 personalized 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 campaigns 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.

From the Library of Juan Arcaya

UCCX ACD/ICD, IVR, and CTI Functions

213

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 applications/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
Window in CAD or
IP Phone

Basic

Consists of enterprise data, or data that is connected to the call, being visible on the computer
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 automatically populates the information (agent display
data) in other applications.

Keystroke MacroEnabled Screen Pops

Advanced

Keystrokes can be recorded to automatically


launch a certain page within an application (for
example, CAD) or even launch a new application.

Embedded Web
Browser Integration

Advanced

CAD has a web browser integrated directly


into the application. Data can be passed to this
browser from the call, and the browser also contains 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 callers 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


DTMF

Basic

Collects digits from the caller for account numbers and menu choices.

Basic Call-Control

Basic

Redirects the calls as needed.

Basic XML Data


Processing

Basic

Uses XML for holiday and status checks, and


other types of lookups.

From the Library of Juan Arcaya

214

Chapter 8: Cisco Unified Contact Center Express

IVR Function

Functionality

Description

Database (ODBC)
Integration to Selected
DBMS

Advanced

Connects to external databases for detailed caller information and account transactions.

HTTP-Triggered Scripted Advanced


Applications

Can be used for callback requests.

Outbound Email
Generation

Advanced

Performed by the IVR and used for follow-up


surveys or thank you emails.

Voice XML (VXML)


for Speech Recognition
Applications

Advanced

Provides more detailed prompting. Recognition


applications allow callers to use voice rather than
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


Party Speech Servers

Outbound dialing with


Call Progress Analysis
(CPA)

Advanced

Java object support Media Resource Control


Protocol (MRCP) integration is supported, which
ties into the recognition functionality mentioned
earlier.
An IVR-based outbound dialer where the IVR
places the calls rather than agents.

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 properly. Also, recording monitored calls is load balanced between the two nodes. The actual

From the Library of Juan Arcaya

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)

(1)
(4)

CC

CUCM
Cluster
(3)

CC

(2)
Voice
Gateway

(7)

Voice-Enabled
Switch

(6)

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.

From the Library of Juan Arcaya

216

Chapter 8: Cisco Unified Contact Center Express

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 agents IP Phones extension. CUCM
rings the agents IP Phone and consequently UCCX may signal a CTI screen
pop (CAD) on the agents 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 agents IP Phone and the voice gateway.

UCCX Integration with CUCM


This section gives insight to UCCX integration with CUCM at a systemic level (for subsystems 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 window, 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.

From the Library of Juan Arcaya

UCCX Integration with CUCM

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.

Step 6.

Figure 8-3

217

UCCX CUCM Configuration

Step 7.

Proceed through the next few windowsSystem Parameters Configuration


and Languagesand 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.

From the Library of Juan Arcaya

218

Chapter 8: Cisco Unified Contact Center Express

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.

From the Library of Juan Arcaya

UCCX Scripting Components

Figure 8-5

219

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 contact is received (inbound) or initiated (outbound). Available with all license options.

Contact: Represents a specific interaction with a customer such as a call, email message, 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
Premium license only.

From the Library of Juan Arcaya

220

Chapter 8: Cisco Unified Contact Center Express

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, currency, 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 digits 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


execution (implicit in any
new, existing script).

Available with all license


options.

General

If

Branch based on a Boolean Available with all license


if condition.
options.

General

Increment, decrement Counters

Sets a certain increment


or decrement value for an
object.

Available with all license


options.

General

Goto, Label

Jumps to any label in the


script.

Available with all license


options.

General

Call Subflow

A subflow is a script that is Available with all license


options.
invoked from another
script.

General

Exception
Management

Exception handling; allows Available with all license


Clear and Go To.
options.

From the Library of Juan Arcaya

UCCX Scripting Components

Palette

Step

Description

Availability

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


application.

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


parameters.

Available with all license


options.

Contact

Accept/Reject/
Terminate

Manages the contact in a


script.

Available with all license


options.

Contact

GetContactInfo

Permits to retrieve info.

Available with all license


options.

Contact

SetContact

Permits to change contact


information.

Available with all license


options.

Call Contact

Call Consult
Transfer

Transfer offers supervised


transfer.

Available with all license


options.

Call Contact

Call Redirect

Redirects the call to a


specified destination.

Available with all license


options.

Call Contact

Place Call

Places outbound calls.

Available with all license


options.

Call Contact

Call Hold/Unhold

Holds and unholds calls


respectively.

Available with all license


options.

Call Contact

Get Call Contact


Info

Accesses call-specific
information.

Available with all license


options.

Call Contact

Get/Set Enterprise
Call Info

Gets or sets CTI data to


store in local variables.

Available with all license


options.

eMail Contact Create eMail

Creates a new email.

Available with IP-IVR or


Premium license only.

eMail Contact Attach to eMail

Adds an attachment to an
email.

Available with IP-IVR or


Premium license only.

eMail Contact Send eMail

Sends an email to an email


address.

Available with IP-IVR or


Premium license only.

221

Available with all license


options.

From the Library of Juan Arcaya

222

Chapter 8: Cisco Unified Contact Center Express

Palette

Step

Description

Availability

HTTP Contact Get/Set Contact


Info

Manages contact
information.

Available with IP-IVR or


Premium license only.

HTTP Contact HTTP Forward/


Include

Launches an internal URI


deployed under the document repository.

Available with IP-IVR or


Premium license only.

HTTP Contact HTTP Redirect

Redirects to another
website.

Available with IP-IVR or


Premium license only.

HTTP Contact Send HTTP


Response

Sends response back to


originator.

Available with IP-IVR or


Premium license only.

Media

Play Prompt

Plays prompts (WAV files).

Available with all license


options.

Media

Extended Play
Prompt

Creates dynamic prompts


Available with all license
(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
information.

Available with all license


options.

Prompt

Create Container
Prompt

Concatenates prompts.

Available with all license


options.

Prompt

Create TTS Prompt Plays back the text from


a string or document
expression.

Available with only IP-IVR


or Premium license options.

Prompt

Upload Prompt

Uploads prompts to the


UCCX prompt repository.

Available with all license


options.

Grammar

Create Language
Grammar

Selects a set of grammars


based on the language of
the call.

Available with all license


options.

From the Library of Juan Arcaya

UCCX Scripting Components

Palette

Step

Description

Grammar

Create Menu
Grammar

Creates spoken word and/or Available with all license


DTMF menu.
options.

Grammar

Upload to the
UCCX Grammar
repository

Uploads to the Grammar


repository database.

Document

Create/Read/Cache/ Used for creation, reading Available with all license


Save File
from, caching. and saving a options.
file.

Document

Create/Search
XML Files

Creates or searches from an Available with all license


XML file.
options.

Document

Transform
Document

Processes an input document and stores results in


an output document.

Available with all license


options.

Document

Upload File to
UCCX Server

Uploads a document to
UCCX server.

Available with all license


options.

Database

DB Get

Connects to a database.

Available with IP-IVR or


Premium license only.

Database

DB Read/Write

Reads/writes data in a
database.

Available with IP-IVR or


Premium license only.

Database

DB Release

Releases database access.

Available with IP-IVR or


Premium license only.

ACD

Select Resource

Selects resource to queue


for a CSQ or agent.

Available with all license


options.

ACD

Connect/Select
Resource

If an agent is available, exits Available with all license


options.
on either Connected or
Selected output branch.

ACD

Get Reporting
Static

Gets reporting information. Available with all license


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


Object

Permits to call a remote


Java Custom procedure.

Available with Enhanced or


Premium license only.

223

Availability

Available with all license


options.

From the Library of Juan Arcaya

224

Chapter 8: Cisco Unified Contact Center Express

Call subflows (in the design window) are similar to a flowchart with procedures or function 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.

From the Library of Juan Arcaya

Chapter 9

Cisco IOS Unified


Communications
Applications
Cisco IOS Unied 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 Unied Communications Manager
Express, Cisco Unity Express, Cisco Unied 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 Ciscos call-control solution and an important part of the Cisco Collaboration
portfolio. A Cisco Unified CMEbased solution is ideal for small businesses or remote
sites in an enterprise solution. Figure 9-1 illustrates a Cisco Unified CMEbased telephony solution connecting two sites.

From the Library of Juan Arcaya

226

Chapter 9: Cisco IOS Unified Communications Applications

Cisco Unified
IP Phone

Cisco Unified
IP Phone

IP WAN

Cisco Unified
CME

PSTN
Cisco Unified
CME

Cisco Unified
IP Phone

Figure 9-1

Cisco Unified
IP Phone

Cisco Unified CMEbased 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 routers 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 feature 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 routers 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

From the Library of Juan Arcaya

Cisco Unified CMEBased 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 administrative 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-service
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 CMEBased 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-31ES13.sbn alias apps42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/cnu45.9-31ES13.sbn alias cnu42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/cvm45sccp.9-31ES13.sbn alias cvm42sccp.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/dsp45.9-31ES13.sbn alias dsp42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/jar45sccp.9-31ES13.sbn alias jar42sccp.9-3-1ES13.sbn

From the Library of Juan Arcaya

228

Chapter 9: Cisco IOS Unified Communications Applications

CMERouter(config)# tftp-server flash:/Phones/7945-7965/SCCP45.9-31SR2-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-service
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-dn)# number 8002 secondary 42618002
CMERouter(config-ephone-dn)# description 42618002
CMERouter(config-ephone-dn)# label 42618002
!
CMERouter(config)# ephone 1
CMERouter(config-ephone)# description 7965 phone

CMERouter(config-ephone)# mac-address 0010.968C.C2B3


CMERouter(config-ephone)# type 7965
CMERouter(config-ephone)# button 1:1
CMERouter(config-ephone)# username SCCP1 password cisco
!
CMERouter(config)# ephone 2
CMERouter(config-ephone)# description 7965 phone 2
CMERouter(config-ephone)# mac-address 00C3.CF99.B188

From the Library of Juan Arcaya

009_9780133845969_ch09.indd 228

6/25/14 11:35 AM

Cisco Unified CMEBased SIP Phone Registration

229

CMERouter(config-ephone)# type 7965


CMERouter(config-ephone)# button 1:2
CMERouter(config-ephone)# username SCCP2 password cisco

Cisco Unified CMEBased SIP Phone Registration


The steps in the following configuration example show how to register Cisco Unified
CMEbased 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
CMERouter(config)# tftp-server flash:/Phones/9971/
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
CMERouter(config)# tftp-server flash:/Phones/9971/
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 parameter 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

From the Library of Juan Arcaya

009_9780133845969_ch09.indd 229

6/25/14 11:35 AM

230

Chapter 9: Cisco IOS Unified Communications Applications

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)# voice register dn 2
CMERouter(config-register-dn)# number 8004
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)# voice register pool 2
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)# number 1 dn 2
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.

From the Library of Juan Arcaya

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 10
CMERouter(config-ephone-dn)# number 8005
CMERouter(config-ephone-dn)# mobility
CMERouter(config-ephone-dn)# snr 4082220000 delay 5 timeout 15 cfwd-noan 8100
!
CMERouter(config)# ephone 5
CMERouter(config-ephone)# ephone-template 1
CMERouter(config-ephone)# button 1:10

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 number, 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)# voice register dn 3
CMERouter(config-register-dn)# number 8006
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)# voice register pool 3
CMERouter(config-register-pool)# template 1
CMERouter(config-register-pool)# number 1 dn 3

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.

From the Library of Juan Arcaya

232

Chapter 9: Cisco IOS Unified Communications Applications

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 (hereafter also referred to simply as SRST) is a voice (Cisco IOS) gatewaybased 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 (callmanager fallback) and Cisco Unified CMEbased 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


SRST Router

CUCM
Cluster
PSTN

Signaling with
SRST Gateway

Signaling with
CUCM

IP WAN

V
Cisco Unified SRST Router
(MGCP, H.323, SIP Gateway)
PSTN

Figure 9-2

Signaling with
SRST Gateway

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)

From the Library of Juan Arcaya

Survivable Remote Site Telephony

Normalized +E.164 support

Customizable programmable line keys and button layout control

233

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 CMEbased SRST.

From the Library of Juan Arcaya

234

Chapter 9: Cisco IOS Unified Communications Applications

Example 9-6 Cisco Unified CMEbased SRST Configuration


CMERouter(config)# telephony-service
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)# max-dn 40
CMERouter(config-telephony)# ip source-address 10.76.108.76 port 2000
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 commands 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 CMEbased SIP SRST.
Example 9-7 Cisco Unified CMEbased 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 CMEbased 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.

From the Library of Juan Arcaya

009_9780133845969_ch09.indd 234

6/25/14 11:35 AM

Survivable Remote Site Telephony

235

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 voice 10 pots
SRSTRouter(config-dial-peer)# description Local
SRSTRouter(config-dial-peer)# destination-pattern 9[2-9]......
SRSTRouter(config-dial-peer)# port 0/2/0:23
SRSTRouter(config-dial-peer)# forward-digits all
!
SRSTRouter(config)# dial-peer voice 20 pots
SRSTRouter(config-dial-peer)# description Long Distance
SRSTRouter(config-dial-peer)# destination-pattern 91[2-9]..[2-9]......
SRSTRouter(config-dial-peer)# port 0/2/0:23
SRSTRouter(config-dial-peer)# forward-digits all
!
SRSTRouter(config)# dial-peer voice 30 pots
SRSTRouter(config-dial-peer)# description International
SRSTRouter(config-dial-peer)# destination-pattern 9011T
SRSTRouter(config-dial-peer)# port 0/2/0:23
SRSTRouter(config-dial-peer)# forward-digits all
!
SRSTRouter(config)# dial-peer voice 911 pots
SRSTRouter(config-dial-peer)# description Emergency
SRSTRouter(config-dial-peer)# destination-pattern 911
SRSTRouter(config-dial-peer)# port 0/2/0:23
SRSTRouter(config-dial-peer)# forward-digits all

Whether using Cisco Unified SRST or Cisco Unified CMEbased 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 gateways hostname/IP address is defined
and the correct protocol (SCCP/SIP) port is chosen.

From the Library of Juan Arcaya

236

Chapter 9: Cisco IOS Unified Communications Applications

Figure 9-3
Step 2.

Cisco SRST Reference Configuration


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 operation) 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 fallback (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 destinations 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 accomplished by going to Device > Phone, selecting a phone, selecting a line, and
setting CFUR.

From the Library of Juan Arcaya

Multicast Music on Hold in SRST

CUCM
Cluster

237

MGCP Application
Gateway
Fallback
Default Application
H.323

IP WAN

MGCP Gateway
with SRST

PSTN

Figure 9-4
Step 3.

MGCP Fallback
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 connectivity 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

From the Library of Juan Arcaya

238

Chapter 9: Cisco IOS Unified Communications Applications

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

From the Library of Juan Arcaya

Cisco IOS Dial Plan

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

239

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 number (Automatic Number Identification [ANI]) or a called-party number (Dialed Number
Identification Service [DNIS]) for incoming, outgoing, and redirected calls. Voice translation 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 outbound 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.

[09]

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 replacement pattern, indicates where to copy the number to keep.

From the Library of Juan Arcaya

240

Chapter 9: Cisco IOS Unified Communications Applications

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

!
Router# test voice translation-rule 2 8000
Matched with rule 2
Original number: 8000

Translated number: 92228000

Original number type: none

Translated number type: none

Example 9-10 Voice Translation Rule - Digit Discard (Test Commands)


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

Translated number: 4082228000

Original number type: none

Translated number type: none

Original number plan: none

Translated number plan: none

!
Router# test voice translation-rule 2 .
Matched with rule 2
Original number: .

Translated number: 2228000

Original number type: none

Translated number type: none

Original number plan: none

Translated number plan: none

From the Library of Juan Arcaya

Cisco IOS Dial Plan

241

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 translation 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 provider. Example 9-12 describes numbering plan manipulation using translation rules and
profiles.

From the Library of Juan Arcaya

242

Chapter 9: Cisco IOS Unified Communications Applications

Example 9-12 Voice Translation Rule Configuration with Plan Type


Router(config)# voice translation-rule 11
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: 2228000

Translated number: 92228000

Original number type: subscriber


Original number plan: none

Translated number type: subscriber


Translated number plan: none

!
Router# test voice translation-rule 11 4082228000 type national plan national
Matched with rule 2
Original number: 4082228000

Translated number: 914082228000

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 requirements. The following configuration illustrates voice translation rule setup to reject a particular pattern and provide a cause code of invalid number to the call initiator:
Router(config)# voice translation-rule 1
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.

From the Library of Juan Arcaya

Cisco IOS Dial Plan

243

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

From the Library of Juan Arcaya

244

Chapter 9: Cisco IOS Unified Communications Applications

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 conferencing, as instructed by CUCMs 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

From the Library of Juan Arcaya

Cisco IOS Media Resources

245

Cisco IOS Conferencing Resources


CUCM provides a conferencing facility for ad hoc and Meet-Me conferences (as discussed in Chapter 4, Cisco Unified Communications Manager). This section addresses
the configuration of a Cisco IOS hardware conference bridge to support CUCM conferencing. 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 parameters 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 applicationfrom conferencing to transcoding to MTPand 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.

From the Library of Juan Arcaya

246

Chapter 9: Cisco IOS Unified Communications Applications

Cisco IOS Transcoding Resources


A Cisco IOS gateways 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 CMEBased 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 conference 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

From the Library of Juan Arcaya

Cisco Unified CMEBased 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 initiator 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 CMEbased Conferencing and Transcoding Configuration
CMERouter(config)# telephony-service
CMERouter(config- telephony)# conference hardware
CMERouter(config-telephony)# max-ephones 10
CMERouter(config-telephony)# max-dn 80
CMERouter(config-telephony)# ip source-address 10.76.108.76 port 2000
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)# number 8001 secondary 42618001

From the Library of Juan Arcaya

248

Chapter 9: Cisco IOS Unified Communications Applications

CMERouter(config-ephone-dn)# description 42618001


CMERouter(config-ephone-dn)# label 42618001
!
CMERouter(config)# ephone-dn 2 octo-line
CMERouter(config-ephone-dn)# number 8002 secondary 42618001
CMERouter(config-ephone-dn)# description 42618002
CMERouter(config-ephone-dn)# label 42618002
!
CMERouter(config)# ephone-dn 20 octo-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)# huntstop
!
CMERouter(config)# ephone-dn 21 octo-line
CMERouter(config-ephone-dn)# description meet-me conference 8888
CMERouter(config-ephone-dn)# number 8888
CMERouter(config-ephone-dn)# conference meetme
CMERouter(config-ephone-dn)# no huntstop
!
CMERouter(config)# ephone-dn 22 octo-line
CMERouter(config-ephone-dn)# description meet-me conference 8888 extension
CMERouter(config-ephone-dn)# number 8888
CMERouter(config-ephone-dn)# conference meetme
CMERouter(config-ephone-dn)# preference 1
CMERouter(config-ephone-dn)# huntstop
!
CMERouter(config)# ephone 1
CMERouter(config-ephone)# description 7965 phone

CMERouter(config-ephone)# mac-address 0010.968C.C2B3


CMERouter(config-ephone)# type 7965
CMERouter(config-ephone)# button 1:1
CMERouter(config-ephone)# conference admin
CMERouter(config-ephone)# conference add-mode creator
CMERouter(config-ephone)# conference drop-mode creator
CMERouter(config-ephone)# ephone-template 1
CMERouter(config-ephone)# username SCCP1 password cisco
!
CMERouter(config)# ephone 2
CMERouter(config-ephone)# description 7965 phone 2
CMERouter(config-ephone)# mac-address 00C3.CF99.B188
CMERouter(config-ephone)# type 7965
CMERouter(config-ephone)# button 1:2
CMERouter(config-ephone)# username SCCP2 password cisco
CMERouter(config-ephone)# ephone-template 1

From the Library of Juan Arcaya

Cisco IOSBased Call Queuing

249

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 commands 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 display 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 MeetMe 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 dropmode creator (drops conference when creator leaves).

Cisco IOSBased Call Queuing


Cisco IOS routers provide basic call queuing and self-service functionality thanks to TCL
scripts and hunt groups. This section covers Cisco IOSbased 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/selfservice 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 AutoAttendant dial peer. The script has a twofold function: playing prompts and digit collection. 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).

From the Library of Juan Arcaya

250

Chapter 9: Cisco IOS Unified Communications Applications

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-ACDbased AA configuration.
Example 9-18 Cisco Unified CMEbased 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 aa-hunt2 8889
CMERouter(config-app-param)# param aa-hunt10 8005
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 number-of-hunt-grps 2
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

From the Library of Juan Arcaya

Cisco IOSBased Call Queuing

251

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


CMERouter(config-ephone-hunt)# timeout 10, 10
!
CMERouter(config)# dial-peer voice 80 voip
CMERouter(config-dial-peer)# service aa-bcd
CMERouter(config-dial-peer)# destination-pattern 8000
CMERouter(config-dial-peer)# session target ipv4:10.76.108.78
CMERouter(config-dial-peer)# incoming called-number 8000
CMERouter(config-dial-peer)# dtmf-relay h245-alphanumeric
CMERouter(config-dial-peer)# codec g711ulaw
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, followed 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 applications 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-timevm-retry to set the maximum number of attempts to reach voicemail. Then the parameters 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, queuemanager-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

From the Library of Juan Arcaya

009_9780133845969_ch09.indd 251

6/25/14 11:35 AM

252

Chapter 9: Cisco IOS Unified Communications Applications

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-param)# param aa-hunt1 8888
<output omitted for brevity>
CMERouter(config-app-param)# param number-of-hunt-grps 1
!
CMERouter(config-app)# service aa-bcd flash:/scripts/app-b-acd-aa-3.0.0.2.tcl
<output omitted for brevity>
CMERouter(config-app-param)# param drop-through-option 1
CMERouter(config-app-param)# param drop-through-prompt _bacd_welcome.au
CMERouter(config-app-param)# param number-of-hunt-grps 1

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 mechanism 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, ds0group, 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

From the Library of Juan Arcaya

Cisco IOSBased Call Queuing

253

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
callthat 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 broadcast hunt-group mechanism in CUCM. The first extension to answer the call gets connected 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

From the Library of Juan Arcaya

254

Chapter 9: Cisco IOS Unified Communications Applications

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-service
CMERouter(config- telephony)# voicemail 8100
!
CMERouter(config)# ephone-dn 50
CMERouter(config-ephone-dn)# number 8110....
CMERouter(config-ephone-dn)# mwi on
!
CMERouter(config)# ephone-dn 51
CMERouter(config-ephone-dn)# number 8111....
CMERouter(config-ephone-dn)# mwi off
!
CMERouter(config)# dial-peer voice 8100 voip
CMERouter(config-dial-peer)# destination-pattern 8100
CMERouter(config-dial-peer)# session protocol sipv2
CMERouter(config-dial-peer)# session target ipv4:10.76.108.79
CMERouter(config-dial-peer)# dtmf-relay sip-notify
CMERouter(config-dial-peer)# codec g711ulaw
CMERouter(config-dial-peer)# no vad
!
CMERouter(config)# dial-peer voice 8111 voip
CMERouter(config-dial-peer)# incoming called-number 811[10]....
CMERouter(config-dial-peer)# codec g711ulaw
!
!
CMERouter(config)# interface ISM0/0
CMERouter(config-if)# ip unnumbered GigabitEthernet 0/0

From the Library of Juan Arcaya

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 modules 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 CMEs
interface, with the latters 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 voicemail application. This is accomplished by logging in to CUE using the command serviceengine 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"

From the Library of Juan Arcaya

256

Chapter 9: Cisco IOS Unified Communications Applications

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

From the Library of Juan Arcaya

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 Notifybased MWI
CMERouter(config)# sip-ua
CMERouter(config-sip-ua)# mwi-server ipv4:10.76.108.79 port 5060
!
CMERouter(config)# voice register dn 10
CMERouter(config-register-dn)# number 8113
CMERouter(config-register-dn)# mwi
!
CMERouter(config)# ephone-dn 30
CMERouter(config-ephone-dn)# number 8114 secondary 42618114
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 (SIPUA) 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 message 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

From the Library of Juan Arcaya

258

Chapter 9: Cisco IOS Unified Communications Applications

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

From the Library of Juan Arcaya

CUE Auto-Attendant

Figure 9-6
Step 2.

259

Enabling CUE VoiceView Express


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 configure 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 parameters as shown in Figure 9-7.

From the Library of Juan Arcaya

260

Chapter 9: Cisco IOS Unified Communications Applications

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"

From the Library of Juan Arcaya

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 voice 130 voip
CMERouter(config-dial-peer)# destination-pattern 8500
CMERouter(config-dial-peer)# session protocol sipv2
CMERouter(config-dial-peer)# session target ipv4:10.76.108.79
CMERouter(config-dial-peer)# dtmf-relay sip-notify
CMERouter(config-dial-peer)# codec g711ulaw
CMERouter(config-dial-peer)# no vad

CUE Scripting
In certain cases the standard AA can be too limited. For administrators and organizations 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.

From the Library of Juan Arcaya

009_9780133845969_ch09.indd 261

6/25/14 11:35 AM

262

Chapter 9: Cisco IOS Unified Communications Applications

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)

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

From the Library of Juan Arcaya

CUE Voice Profile for Internet Email

Figure 9-9

263

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 networking using Simple Mail Transfer Protocol (SMTP) and Multipurpose Internet Mail
Extensions (MIME). VPIM permits server to server message exchange (message interworking). 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.

From the Library of Juan Arcaya

264

Chapter 9: Cisco IOS Unified Communications Applications

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. Its important 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
users 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 location and provide the required information such as display name (remote location ID), dial ID (location ID), partition, SMTP domain name (for remote system; i.e., CUE), and IP address (CUE), and optionally provide a remote phone
prefix, as shown in Figure 9-12.

From the Library of Juan Arcaya

CUE Voice Profile for Internet Email

Figure 9-10

CUE VPIM Location Definition

Figure 9-11

CUE Local and Remote VPIM Location Definition

265

From the Library of Juan Arcaya

266

Chapter 9: Cisco IOS Unified Communications Applications

Figure 9-12
Step 5.

CUC VPIM Location Definition


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

From the Library of Juan Arcaya

Cisco IOS Call Admission Control

267

the network can ensure sufficient quality of service. There are three types of CAC mechanisms, as described in this section:

Local CAC

Reservation-based CAC

Measurement-based CAC

Local CAC
Local CAC is based on a devices 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 implemented under voice ports (T1/E1) by using the command busyout monitor <interface 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 zonebased CAC are types of reservation-based CAC.
Example 9-26 shows configuration of a gatekeeper zonebased CAC.
Example 9-26 Gatekeeper ZoneBased 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

From the Library of Juan Arcaya

268

Chapter 9: Cisco IOS Unified Communications Applications

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 operation. PSTN fallback is based on SAA and acts on ICPIF or delay, or loss values as configured. 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 reporting. 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 protocolbased accounting for CDRs.

RADIUS: RADIUS-based CDR accounting

From the Library of Juan Arcaya

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 Accountingbased 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 syslog-based CDR accounting, use the command gw-accounting syslog.

RADIUS-Based CDR Accounting


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

From the Library of Juan Arcaya

270

Chapter 9: Cisco IOS Unified Communications Applications

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 attributes 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 section is to explore the configuration of Cisco SAF Forwarderthat is, configuring a Cisco
IOS router to support Cisco SAF clients (CUCM and CUCME). Figure 9-13 depicts the
SAF clientforwarder 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

From the Library of Juan Arcaya

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
Protocol

SAF Publish/
Advertise
SAF Forwarding
Protocol
SAF Network
SAF Notify

SAF Forwarder

SAF Forwarder

(Adjacent Neighbors)

Figure 9-13

SAF ClientForwarder Relationship and SAF Network

From the Library of Juan Arcaya

272

Chapter 9: Cisco IOS Unified Communications Applications

SAF leverages EIGRP (virtual router), although the underlying network can use static
routing or any dynamic routing protocol. EIGRP routing instance SAF initiates a SAFassociated configuration on the Cisco IOS router. The service-family and autonomoussystem attributes are required because SAF clients must know them to register with
this forwarder. Neighbors wont 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 defining 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 associated 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 IOSbased 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 untrusted 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.

From the Library of Juan Arcaya

Cisco Unified Border Element

273

CUBE Redundancy
As an important part of the SIP trunking solution, CUBE should be deployed in highavailability (redundant) mode where possible. The following options are available for
CUBE redundancy:

Inbox redundancy: Provides high-availability within the same box (local redundancy) in the same chassis (supported in Cisco ASR 1000 Series only) with stateful
failover. Inbox redundancy can be hardware based or software based. Hardwarebased inbox redundancy leverages a dual-control plane and a dual-forwarding plane
in ASR 1006for 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

CUCM
Cluster

HSRP Address
10.76.108.1

GE 0/0

GE 0/1

10.76.108.2

192.168.108.2

Keepalives

Keepalives

HSRP Address
192.168.108.1
SIP SP
Network

HSRP
Group 1
10.76.108.146

Keepalives
10.76.108.3
GE 0/0

Keepalives

HSRP
Group 9

192.168.108.254

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

From the Library of Juan Arcaya

009_9780133845969_ch09.indd 273

6/25/14 11:35 AM

274

Chapter 9: Cisco IOS Unified Communications Applications

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

From the Library of Juan Arcaya

Cisco Unified Border Element

275

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

From the Library of Juan Arcaya

276

Chapter 9: Cisco IOS Unified Communications Applications

!
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

From the Library of Juan Arcaya

Cisco Unified Border Element

277

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 normalized before it leaves or enters the enterprise logical perimeter to comply with an
service providers or organizations policies

Figure 9-15 illustrates the concept of SIP profiles.


SIP INVITE Sent By CUBE
Sent:
INVITE sip:2000@192.168.108.254:5060 SIP/2.0
.........
User-Agent: Cisco-SIPGateway/IOS-15.2.3.T
.........
Diversion: <sip:8000@192.168.108.254>;
privacy=off;reason=unconditional;screen=yes
.........
m=audio 6001 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
.........

SIP INVITE Expected By SIP SP


Sent:
INVITE sip:2000@192.168.108.254:5060 SIP/2.0
.........
User-Agent: Cisco CUCM9.1/IOS-15.2.3T
.........
Diversion: <sip:4082228000@sip.corp.local>;
privacy=off;reason=unconditional;screen=yes
.........
m=audio 32278 RTP/AVP 18 8 101
a=rtpmap:0 PCMU/8000
.........

SIP SP
Network
CUBE

Figure 9-15

CUBE to SIP SP Communication and SIP Normalization

From the Library of Juan Arcaya

278

Chapter 9: Cisco IOS Unified Communications Applications

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:4082228000@sip.crop.local"
CUBE(config-class)# request REINVITE sip-header Diversion modify "sip:(*.>)"
"sip:4082228000@sip.crop.local"
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

From the Library of Juan Arcaya

Cisco Unified Border Element

279

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

Figure 9-16

PSTN Phone

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

From the Library of Juan Arcaya

280

Chapter 9: Cisco IOS Unified Communications Applications

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 voice 190 voip
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)# codec g711ulaw
CUBE(config-dial-peer)# no vad
!
CUBE(config)# dial-peer voice 191 voip
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)# codec g711ulaw
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

NOTIFY

NOTIFY

H.245H.245Alphanumeric Alphanumeric

H.245NOTIFY
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.245RFC 2833
Alphanumeric

H.245RFC 2833
Alphanumeric

RFC 2833

KPML

H.245-Signal

H.245-Signal

RFC 2833

KPML

KPML

Voice In-Band RFC 2833

RFC 2833

RFC 2833

RFC 2833

H323

SIP

From the Library of Juan Arcaya

Cisco Unified Border Element

SIP

SIP

H323

H.323

Voice In-Band RFC 2833

H323

281

SIP

H.245KPML
Alphanumeric
H.245-Signal

KPML

Voice In-Band RFC 2833

Its 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 packets sent in a single burst. This option is available under (global) voice service voip
and dial-peer.

standard: Generates RFC 4733compliant 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 available 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-INVITEbased supplementary services 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 (midcall) changes.

From the Library of Juan Arcaya

282

Chapter 9: Cisco IOS Unified Communications Applications

CUCM

CUBE
SIP SP
Network
Call Is Established

Call Is Established
Mid-Call Signaling
Passthru

IP Phone

Mid-Call RE-INVITE
(with Media Type Change)

PSTN Phone
RE-INVITE (with SDP)
200 OK

200 OK
ACK

ACK

Call Is Established

Call Is Established
Mid-Call Signaling
Block

IP Phone

PSTN Phone

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

From the Library of Juan Arcaya

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

From the Library of Juan Arcaya

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 dont match.

4 Database Setup Failed/dropped: The server no longer has an active logical connection 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
Partial DB Access
(User Facing Features)

Figure 10-1

CUCM Subscribers
Partial DB Access
(User Facing Features)

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


Access Service

Required for Cisco Unified Mobility (SNR, MVA).

Cisco IP Voice Media Streaming Provides media services such as Annunciator, MoH, conferApplication
ence bridges, transcoders, MTP, and so on.

From the Library of Juan Arcaya

CUCM Serviceability and OS Administration

Feature Service

Description

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

285

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


Service

Used by the ILS process for exchanging updates with the


ILS network.

Cisco Location Bandwidth


Manager

Used by LBM for Enhanced Location Call Admission


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 managerassistant function to be deployed.

Cisco WebDialer Web Service

Enables users to make calls from web/desktop-based


applications.

Cisco SOAP - CDRonDemand


Service

Simple Object Access Protocol (SOAP)/HTTPS-based service 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


Service

Used to implement CISCO-CCM-MIB, which allows SNMP


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 (mixedmode) mode.

From the Library of Juan Arcaya

286

Chapter 10: Cisco Collaboration Network Management

Feature Service

Description

Cisco Certificate Authority


Proxy Function (CAPF)

Issues locally significant certificates (LSC) to Cisco Unified


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


Monitoring Tool

The Log Partition Monitoring feature monitors disk usage


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


Service

Also known as PAWS, allows applications to initiate and


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.

From the Library of Juan Arcaya

CUCM Serviceability and OS Administration

Network Service

Description

Cisco Syslog Agent

Required for syslog messages using CISCO-SYSLOG-MIB.

287

Cisco Certificate Expiry Monitor Enables monitoring for CUCM certificate expiry.
Cisco Certificate Change
Notification

Responsible for checking the expiration status of certificates.

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


APIs

Enables collecting real-time device and CTI application


information, and provides APIs to start, activate, and stop
services.

Cisco SOAP-Performance
Monitoring APIs

Enables performance monitoring counters for applications.

Cisco SOAP-Log Collection APIs Allows collection of log files for APIs.
SOAP - Diagnostic Portal
Database Service

Supports diagnostics for SOAP to DB connection.

Cisco DRF Master

Services scheduled backup and restore.

Cisco DRF Local

Supports the Cisco DRF Local Agent.

Cisco CallManager Personal


Directory

Supports the Cisco Personal Directory.

Cisco Extension Mobility


Application

Enables Cisco Extension Mobility service.

Cisco CallManager Cisco IP


Phone Services

Supports service URLs pertinent to Cisco Unified IP


Phone.

Cisco User Data Services

Interface for endpoints to get data from CUCM.

Cisco Change Credential

Used for EM Pin change by end user.

From the Library of Juan Arcaya

288

Chapter 10: Cisco Collaboration Network Management

Network Service

Description

Cisco E911

Supports enhanced 911.

Cisco CDR Repository


Manager

Maintains/moves CDRs obtained from the Cisco CDR


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


Service

Helps with the CUCM call recording feature.

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 information, 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 diagnostic 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 serviceenabled 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 conference call. Because flat files are fixed-length files, one CDR flat file can contain the data

From the Library of Juan Arcaya

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 provides 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 determine 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 schedule backups and leverage them in case a server needs to be rebuilt.
DRS utilizes Cisco Disaster Recovery Framework (DRF) service and enables administrators to initiate a manual or automatic (scheduled) backup. DRS permits CUCM administrators 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

From the Library of Juan Arcaya

290

Chapter 10: Cisco Collaboration Network Management

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 physical 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 frequency 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 administrators 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, application users do not have an interactive login and serve only for internal communications 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.

From the Library of Juan Arcaya

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 provides applications the capability to get all user information from a single repository available 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

From the Library of Juan Arcaya

292

Chapter 10: Cisco Collaboration Network Management

Note in the User Status column that the User Status field can be employed to differentiate 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 networks 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 accomplished 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 endpoints, 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 relationships with each other.

Domain members: Switches, routers, and network controllers. They resemble endpoints 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 consumersfor example, Cisco Unified IP


Phones, PCs, HVAC, and so on. The endpoints are typically PoE and non-PoE devices. 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).

From the Library of Juan Arcaya

Cisco EnergyWise

293

EnergyWise Managers: EnergyWise management can be done via control applications 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
(Domain Member)

Cisco Router
(Domain Member)

Cisco Switch
(Domain Member)

Children

Cisco Jabber
(Endpoint)

Figure 10-3

Cisco Unified
IP Phone
(Endpoint)

PC
(Endpoint)

Cisco Unified
IP Phone
(Endpoint)

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)

From the Library of Juan Arcaya

294

Chapter 10: Cisco Collaboration Network Management

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 activated automatically. Cisco EnergyWise (domain) configuration and parent-child relationships 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

---------

----

----

-----

--------

---

---

----

UCSwitch-1

101.0 (W)

10

WS-C3750E-24PD

consumer

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/

From the Library of Juan Arcaya

Cisco EnergyWise

Interface
---------

Role

Name

Usage

Category
--------

Lvl

Imp

295

Type

----

----

-----

---

---

----

WS-C3750E-24PD

UCSwitch-1

101.0 (W) consumer

10

parent

Gi1/0/3

IP Phone 9971

SEP64AE0CF66C0D

7.5 (W)

consumer

10

PoE

Gi1/0/5

IP Phone 9971

SEP10BD18DC97F5

7.1 (W)

consumer

10

PoE

Gi1/0/6

IP Phone 9951

SEPE84040A24BBD

6.0 (W)

consumer

10

PoE

Subtotals: (Consumer: 121.6 (W), Meter: 0.0 (W), Producer: 0.0 (W))
Total: 121.6 (W), Count: 4

From the Library of Juan Arcaya

From the Library of Juan Arcaya

You might also like