CCIE COLLABORATION QUICK REFERENCE cisco press.pdf

From the Library of Juan Arcaya

CCIE Collaboration Quick Reference Akhil Behl, CCIE No. 19564

Cisco Press 800 East 96th Street Indianapolis, IN 46240


ii

CCIE Collaboration Quick Reference

CCIE Collaboration Quick Reference Akhil Behl, CCIE No. 19564 (Voice and Security) Copyright© 2014 Pearson Education, Inc. Published by: Cisco Press 800 East 96th Street Indianapolis, IN 46240 USA All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information 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.


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 [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected].

Feedback Information At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community. Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through email at [email protected]. Please make sure to include the book title and ISBN in your message. We greatly appreciate your assistance. Publisher: Paul Boger

Senior Project Editor: Tonya Simpson

Editor-in-Chief: David Dusthimer

Copy Editor: Bill McManus

Business Operation Manager, Cisco Press: Jan Cornelssen

Technical Editor: Paulo Lopes

Executive Editor: Brett Bartow

Editorial Assistant: Vanessa Evans

Managing Editor: Sandra Schroeder

Designer: Mark Shirar

Development Editor: Marianne Bartow

Composition: Jake McFarland


iv


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


v

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


vi


Dedication This book is dedicated first to my family, my dear wife Kanika and my lovely sons Shivansh and Shaurya, for without their support, encouragement, and patience, it would not exist. Secondly, to my parents, Vijay Behl and Ravi Behl, and my brothers, Nikhil Behl and Ankit Behl, who have always been there to support me and guide me in all my endeavors.

Acknowledgments I would like to thank the following amazing people and teams for helping me create this book: My wife, Kanika, and my kids, Shivansh and Shaurya, for sacrificing many days and weekends over the past year so that I could work on this book. Without their patience and support, this book would not have been possible. The technical reviewer, Paulo Lopes, for his invaluable feedback and for providing exceptional technical coverage. The Cisco Press editorial team: Brett Bartow, the executive editor, for seeing the value and vision in the proposed title and providing me the opportunity to build this title; and Marianne Bartow, development editor, and Christopher Cleveland, senior development editor, for their support and guidance all throughout. It is my sincere hope to work again with them in the near future. Everyone else in the Cisco Press production team, for their support and commitment.


vii

Contents at a Glance Chapter 1

Cisco Collaboration Infrastructure 1

Chapter 2

Quality of Service (QoS) 31

Chapter 3

Telephony Standards and Protocols 55

Chapter 4

Cisco Unified Communications Manager 95

Chapter 5

Cisco Unified Communications Security 145

Chapter 6

Cisco Unity Connection 167

Chapter 7

Cisco Unified IM and Presence 191

Chapter 8

Cisco Unified Contact Center Express 209

Chapter 9

Cisco IOS Unified Communications Applications 225

Chapter 10

Cisco Collaboration Network Management 283


viii


Contents Chapter 1

Cisco Collaboration Infrastructure

1

Cisco Unified Communications Deployment Models 1 Single-Site Deployment Model

2

Multisite WAN with Centralized Call Processing Deployment Model 3 Multisite WAN with Distributed Call Processing Deployment Model 4 Clustering over WAN Call Processing Deployment Model 5 Network Services

6

Dynamic Host Configuration Protocol 6 Domain Name System 7 Trivial File Transfer Protocol 8 Network Time Protocol 11 Cisco Discovery Protocol 12 Link Layer Discovery Protocol 14 Power over Ethernet 15 Voice and Data VLANs 16 IP Routing in Cisco Collaboration Campus Environments 17 Campus Infrastructure Design 17 Campus Access Layer

18

Campus Distribution Layer 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


ix

Layer 2 Marking

34

Layer 3 Marking

35

Network-Based Application Recognition 36 Classification Service Classes 37 Classification and Marking for Softclients 37 Classification and Marking for Video Traffic 38 Queuing

38

Cisco Queuing Toolset 39 Weighted Random Early Detection 40 WAN QoS Considerations 41 Traffic Policing and Shaping 41 Link Efficiency Mechanisms 43 Compressed RTP

43

Link Fragmentation and Interleaving 43 Multilink PPP

44

Frame Relay Forum 12 44 Voice Activity Detection 45 LAN QoS Considerations 46 QoS Trust Boundary 46 QoS Considerations for WLAN Endpoints 47 QoS Considerations for Virtual Unified Communications with Cisco UCS

48

Medianet 49 Medianet QoS Classes of Service 52 Chapter 3

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


x


H.239-Based Dual Video Channels and Cisco Video Equipment Support 82 Analog Telephony 83 Foreign Exchange Office 83 FXO Disconnect 83 Foreign Exchange Station 84 E&M

84

Digital Telephony 85 Integrated Services Digital Network 85 Q Signaling Protocol 87 Channel Associated Signaling 87 T1 CAS 87 E1 R2 88 Non-Facility Associated Signaling

88

Analog and Digital Telephony Call Signaling Elements 89 Direct Inward Dial 89 Caller ID 89 Echo

90

Trans Hybrid Loss 90 Fax and Modem Protocols 91 Fax Services over IP Network 91 Modem Services over IP Network 93 Chapter 4

Cisco Unified Communications Manager 95 CUCM Redundancy and Device Registration 95 CUCM Device Pool 96 Common Device Configuration 98 Codec Selection 99 CUCM Features 100 Call Park and Directed Call Park 100 Call Pickup and Group Pickup 101 Meet-Me Conference

102

Busy Lamp Field Speed Dials 102 CUCM Native Call Queuing 102 Call Hunting 103 CUCM Media Resources 104 Annunciator 104 Conference Bridge

104


xi

Media Termination Point 105 Transcoder 105 Music on Hold 105 Media Resource Group and Media Resource Group List 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


xii


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


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


xiv


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 CME–Based SCCP Phone Registration 227 Cisco Unified CME–Based SIP Phone Registration 229 Cisco Unified CME Single Number Reach 230 Survivable Remote Site Telephony 232 MGCP Fallback 236 Multicast Music on Hold in SRST 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 CME–Based Media Resources 246 Cisco Unified CME Conferencing and Transcoding 246 Cisco IOS–Based Call Queuing

249

Cisco Unified CME Basic Automatic Call Distribution 249 Voice Hunt Groups

252

Call Blast 253 Cisco Unity Express

254


xv

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

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


xvi


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


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.


This page intentionally left blank


Chapter 1

Cisco Collaboration Infrastructure

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

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

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

■

Centralized deployment model: The Cisco UC and Collaboration services are located in a central campus site or data center. However, the endpoints, 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.


2

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

V

Internet

CUCM Cluster CC

PSTN V

V

Endpoints

Figure 1-1

Single-Site Deployment Model


Cisco Unified Communications Deployment Models

3

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

V

V

CC

PSTN V

Endpoints V

Endpoints

Figure 1-2

Multisite WAN with Centralized Call Processing Deployment Model


4


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 doesn’t allow for new calls via the IP WAN.

■

Deploy SRST for remote sites to ensure that the branch router has the capacity for handling IP Phone registration in case of a WAN failure. The voice gateway also provides local PSTN connectivity for remote site endpoints so that emergency calls, toll-free calls, and calls local to a region use the local gateway instead of the IP WAN to the campus PSTN SBC or router.

■

Deploy a low-bandwidth audio codec (for example, G.729) between remote sites and the central site and deploy G.711 within a site for optimum voice quality.

■

Deploy DSP resources at remote sites for conferencing, transcoding, or MTP resources.

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

Media Resources


Infrastructure

Internet CUCM Cluster

CUCM Cluster

IP WAN

V

V CC

PSTN V

V

Endpoints

V

Endpoints

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


001_9780133845969_ch01.indd 4

6/24/14 4:23 PM

Cisco Unified Communications Deployment Models

5

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


Infrastructure

Internet

Internet

IP WAN

V

V CUCM Cluster Over WAN

PSTN V

PSTN V

V

Endpoints

V

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.


6


Network Services This section covers the various network services essential for a functional Cisco Collaboration solution: ■

Dynamic Host Configuration Protocol (DHCP)

■

Domain Name System (DNS)

■

Trivial File Transfer Protocol (TFTP)

■

Network Time Protocol (NTP)

■

Cisco Discovery Protocol (CDP)

■

Link Layer Discovery Protocol (LLDP)

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


Network Services

7

Example 1-1 shows configuration of a DHCP server on a Cisco IOS router. Example 1-1 Cisco IOS Router–based DHCP Server Configuration UCRouter (config)# service dhcp ! UCRouter (config)# ip dhcp excluded-address 10.10.0.1 10.10.0.10 ! UCRouter (config)# ip dhcp pool VOICE UCRouter (config-dhcp)# network 10.10.0.0 255.255.255.0 UCRouter (config-dhcp)# default-router 10.10.0.1 UCRouter (config-dhcp)# domain-name mydomain.local UCRouter (config-dhcp)# option 150 ip 10.76.108.146 UCRouter (config-dhcp)# lease 7 UCRouter (config-dhcp)# dns-server 10.10.0.2

In Example 1-1, the ip dhcp excluded-address command helps segregate addresses from the assignment pool so they are not assigned to any endpoint. The DHCP pool defines a network from which the endpoints can get their IP address, option 150, and other 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 won’t 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.


001_9780133845969_ch01.indd 7

6/24/14 4:24 PM

8


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

■

Certificate Trust List (CTL) files (only if the cluster is in mixed mode)

■

Identity Trust List (ITL) files (for all endpoints that register with CUCM)

■

Tone localization files

■

User interface (UI) localization and dictionary files

■

Ring List files


Network Services

■

Softkey and Phone Button Template files

■

Background images

9

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


10


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.


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 publisher’s NTP source implicitly. You can add a phone NTP reference for SIP endpoints. To add a phone NTP reference in CUCM, go to the Cisco Unified CM Administration page and choose System > Phone NTP Reference. You must assign this NTP reference to a date/time group, which in turn is assigned to a device pool.


12


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.


Network Services

Table 1-1

13

CDP TLV Fields

CDP TLV Field

Description

Device ID

Identifies the sending device’s hostname

Address

Provides the address of the interface (physical, loopback, VLAN) that is sending the CDP update

Port ID

Specifies the port from which the CDP update is sent (outgoing port)

Capabilities

Identifies the device’s functional capabilities (e.g., router, switch, host)

Version

Specifies the Cisco IOS or firmware version running on the device advertising the updates

Platform

Identifies the hardware or virtual platform

Full/Half Duplex

Indicates the duplex mode of the advertising device’s connected interface

VTP Domain

Identifies the VTP domain of the advertising device (if any)

Management Address

Identifies the management address of the advertising device (if any)

Example 1-3 illustrates how to access CDP timer, holdtime, and version information as well as CDP discovery information. Example 1-3 CDP Information UCSwitch# show cdp Global CDP information: Sending CDP packets every 60 seconds Sending a holdtime value of 180 seconds Sending CDPv2 advertisements is enabled ! UCSwitch# show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater

Device ID

Local Intrfce

Platform

Port ID

CM91PUB

Fas 0/30

Holdtme 135

Capability H

VMware

eth0

CUPS91

Fas 0/26

169

H

VMware

eth0

UCRouter

Fas 0/24

163

R S I

CISCO3945-Gig 0/0


14


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 device’s hostname

System Description

Provides details about the advertising device’s OS/firmware

System Capabilities

Identifies the device’s functional capabilities (e.g., router, switch, host)

Management Address

Provides the management IP address (if any)

Port VLAN ID

Identifies the native VLAN ID of the advertising port

MAC/PHY Configuration/Status

Provides the MAC address and other physical characteristics


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.


16


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 topology–independent 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 Phone’s 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


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 Cisco’s recommended core, distribution, and access (CDA) layer approach. Layer 3 routing protocols such as Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF) are commonly employed in unified IP environments. Routing protocol parameters such as timers, path/link costs, and route summaries can be used to optimize and control convergence times and distribute traffic across multiple paths. Cisco recommends using the 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, it’s important to understand the design basics. One of the most important principles of campus network


18


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. It’s the focal point at which network policies are created and enforced. This layer is responsible for aggregating incoming user traffic from wiring closet access switches and then aggregating it to the core. At the distribution layer, it is important to provide redundancy to ensure high availability, including 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


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.


20


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.


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.


22


■

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 Phone’s UI. 2. If an address has not been manually configured, use DHCPv6 to assign an address. 3. If neither a DHCPv6 address nor a manually configured address is available, and Stateless Address Autoconfiguration (SLAAC, RFC 2462) is enabled for the IP Phone (CUCM default is on), the IP Phone uses SLAAC to create an IPv6 address. The router RA “O” bit should be set. Cisco IOS devices support one link-local address, multiple unique-local addresses, 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 routers—for example, Telnet, Secure Shell (SSH), and so on. For responses to devices, routers attempt to use the same network prefix as the device that is initiating communication. To allow IPv6-based call processing, IPv6 must first be enabled throughout a CUCM cluster. This involves the following steps: Step 1.

Configure IPv6 via the Cisco Unified CM Administration page by choosing System > Server Configuration. IPv6 must be configured via the OS CLI or Cisco Unified Operating System page on each server in the cluster.

Step 2.

Enable IPv6 cluster-wide via the Cisco Unified CM Administration page by choosing System > Enterprise Parameters; and setting Enable IPv6 to True, set IP Addressing Mode Preference for Media to IPv6, IP Addressing Mode Preference for Signaling to IPv6, and Allow Auto-Configuration for Phones (SLAAC) to On.


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.


24


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 UCS–based virtualized UC application and network architecture. Cisco UCS leverages the concept of service profiles for statelessness. This allows for any damaged hardware (blade) to be changed without affecting the virtual machines (VM) running on it. The VMs can be moved to another blade by disassociating the service 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.


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)

V

Fibre Channel

Ethernet

LAN Switch

Figure 1-9

Nexus 5000 Series Switch

Storage Array SAN Switch (MDS 9000 Series)

Cisco UCS–based UC Application and Network Virtualization Architecture

Moreover, Cisco supports UC on UCS deployments in three support models: ■

UC on UCS Tested Reference Configuration (TRC): Tested and approved by Cisco UC and UCS BUs/teams

■

UC on UCS Specs-based: Generic server hardware validation by UCS BU/team

■

Third-party Server Specs-based: No hardware validation by UCS BU/team

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


26


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)


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


28


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 Today’s dynamic environments and organizations demand more than just regular wired IP Phones—they demand mobility. Wi-Fi is an important aspect because being mobile yet connected within an enterprise is paramount in today’s connected world. Cisco offers on-campus mobility using Voice over Wireless LAN (VoWLAN) with Cisco Unified Wireless IP Phone 7925G. From an infrastructure perspective, Cisco offers two wireless network infrastructure solutions: Cisco Unified Wireless LAN Controller (WLC) and Cisco Autonomous Access Points (AP). A VoWLAN architecture encompasses multiple components, as shown in Figure 1-10. Cisco VoWLAN solution has many components, including the following: ■

Cisco WLC

■

Lightweight access points

■

Directory server (LDAP) for endpoint authentication

■

Wi-Fi endpoints, including PCs or laptops with Jabber

■

Wi-Fi–capable Cisco Unified IP Phones

The interaction between endpoints and wireless APs is where Wi-Fi primarily comes into play; the rest is an augmentation to existing wired infrastructure.


Wireless in Cisco Collaboration Solutions

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.




Chapter 2

Quality of Service (QoS)

Voice and video over IP traffic consists of two parts: media/bearer traffic and signaling traffic. Media traffic is based on the Real-time Transport Protocol (RTP), which runs on top of the User Datagram Protocol (UDP). Signaling traffic is based on a number of protocols, such as Session Initiation Protocol (SIP), Skinny Call Control Protocol (SCCP), H.323 protocol, and Media Gateway Control Protocol (MGCP), all of which are TCP/UDP based. When an RTP packet is lost, re-creating or retransmitting it is neither possible nor worthwhile. As its name indicates, RTP works in real time, so any attempt to restore missing packets would not make sense because the packets would arrive out of order/sequence during a live conversation. In today’s converged networks where voice, video, and data coexist, it is important to treat voice and video traffic differently from data traffic, which is mostly TCP based and is easily retransmitted without loss of quality. Quality of service (QoS) enables network administrators to leverage tools for providing special treatment for delay and timesensitive traffic such as voice. The network infrastructure must provide classification, policing, and scheduling services for multiple traffic classes. Voice quality is directly affected by the following three QoS factors: ■

Latency (delay): The unwarranted time required for a packet to traverse the network from source to destination

■

Jitter (delay variation): Irregular time interval in the arrival of packets

■

Packet loss: Packets lost in transit from source to destination due to network 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 fixed delay or a variable delay depending on where it is introduced. Fixed delay adds to overall delay introduced from source to destination. Variable delay is a function of queues and buffers.


32

Chapter 2: Quality of Service (QoS)

Table 2-1 Sources of Delay During Voice Packet Formation and Traversal from Source to Destination Delay

Description

Coder delay

The time taken by a digital signal processor (DSP) to compress a block of pulse-code modulated (PCM) samples. This is a fixed delay function for a certain endpoint with a certain codec.

Packetization delay

The time it takes to put a payload (encoded voice) into a voice packet and encapsulate it within IP, UDP, and RTP headers. It’s a fixed delay function.

Queuing delay

The delay experienced as a frame is queued waiting to be transmitted on a link. It’s a variable delay function because it depends on link speed.

Serialization delay

The time taken to put a frame on the wire from a network interface. It’s a fixed delay function.

Propagation delay

The time taken for a bit to traverse a network link (from one end to the other).

De-jitter delay

The delay experienced as a result of a de-jitter buffer on a receiving device (such as a Cisco IOS router) that eliminates any jitter between packets before they are sent out to their destination. It’s a fixed delay function.

QoS Requirements for Voice and Video The key QoS requirements and recommendations for RTP traffic are ■

Voice bearer traffic should be marked to DSCP EF per the QoS baseline and RFC 3246.

■

Packet loss should be no more than 1 percent.

■

One-way latency (mouth to ear) should be no more than 150 ms.

■

Average one-way jitter should be targeted under 30 ms.

Additionally, for voice calls, the following are recommended leading practices: ■

17 to 106 kbps of guaranteed priority bandwidth should be provided per call for media (depending on the sampling rate, codec, and Layer 2 overhead).

■

150 bps + Layer 2 overhead guaranteed bandwidth should be provided for voicecontrol traffic per call.

Additional requirements for video traffic are as follows:


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


34


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 Tag–based QoS (CoS) Marking

The TPID field is a 2-byte field and contains a fixed value of 0x8100 that indicates a tagged (802.1Q) frame. The TCI field is a 2-byte field that contains three subfields:


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.


36


IPv4 Packet

ToS

1

2

3

4

Precedence

5

6

7

8

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 doesn’t exceed the subscribed rate.

■

Best Effort (BE): Specified when all 6 bits of the DS field are 0; that is, the packet doesn’t need any specific QoS treatment or doesn’t meet the requirements of any of the other defined classes. BE is also known as default PHB.

■

Class Selector (CS): Used for backward compatibility with network devices and applications that use IP Precedence. When using this PHB, the last 3 bits of the DSCP field are 0.

■

Expedited Forwarding (EF): States a low-delay, low-loss, and low-jitter QoS 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)


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


002_9780133845969_ch02.indd 37

6/24/14 4:28 PM

38


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 application’s buffering capabilities).

■

Packet loss should be no more than 5 percent.

Queuing Beginning with classification and marking, a packet needs to be treated as per the QoS policy. QoS tools such as policing or queuing can make forwarding or dropping 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.


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 packet’s 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


40


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 link’s bandwidth, whereas video traffic is given 10 percent of priority guaranteed bandwidth. Signaling traffic is given up to 128 kbps of bandwidth, and the remaining 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 interface’s 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


WAN QoS Considerations

41

MQC-based WRED configuration is as follows: UCRouter(config)# policy-map HTTPS UCRouter(config-pmap)# class HTTP-Secure UCRouter(config-pmap-c)# random-detect dscp-based

The command random-detect [dscp-based | prec-based] can be used to define either DSCP-based marking or IP precedence–based marking for calculating drop probability. The default is prec-based.

WAN QoS Considerations WAN links typically require additional mechanisms such as traffic policing, traffic 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.


42


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 !


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 it’s specified, the PPP, HDLC, or Frame Relay interfaces send compressed headers only if they receive compressed headers. cRTP can be configured via the MQC and by using the command compression header ip rtp.

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


44


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 !


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


46


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

QoS Trust Boundary When deploying QoS, a trust boundary must be defined so that the QoS marking can be trusted from the devices connected at that boundary. The definition of a trust boundary depends on what types of devices are connected at the access layer in a LAN and their trust level. The connected endpoints/devices can be considered as one of the following: ■

Untrusted endpoints: Devices from which QoS marking cannot be trusted when 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.


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)

6

EF (DSCP 46)

IP interactive video traffic (videoconferencing)

5

AF41 (DSCP 34)

IP streaming video traffic (live, prerecorded)

5

CS4 (DSCP 32)


48


Network Service/ Application

IEEE 802.11e UP Marking

PHB/DSCP

Voice and video signaling traffic (SIP, H.323, MGCP, SCCP)

4

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 LAP’s WLAN GUI > Edit. For autonomous WAPs, CAC can be enabled from the CLI by entering the dot11 ssid voice command followed by the admit-traffic command. Beyond the wireless realm, the QoS for wired infrastructure helps ensure that voice and video signaling and media traffic go from source to destination within the expected time and with minimal packet loss and jitter.

QoS Considerations for Virtual Unified Communications with Cisco UCS In a virtualized environment, Unified Communications applications connect to a 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


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


50


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

V

Figure 2-4

Medianet Architecture

Medianet has the following components: ■

■

Media monitoring tools/components, which give insight into a network’s capacity, performance, and readiness to support rich-media content. These tools include ■

Mediatrace

■

IP SLA Video Operation

■

Performance Monitor

Medianet is supported by the following endpoints (not an all-inclusive list): ■

Cisco TelePresence


Medianet

■

■

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 network’s 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.


52


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.


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 software–based multimedia Cisco Collaboration applications such as Cisco Unified Personal Communicator and Cisco Unified Video Advantage. It focuses primarily on voice and video components of these applications.


54


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.


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.


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.


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


58


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 2000–2003 and SCCPS uses TCP port 2443. CUCM uses SCCP to control analog ports on VGXXX gateways and ATA18X, FXS ports on Cisco IOS router modules, Cisco Unified IP Phones, Cisco roundtable 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: 1—Off Hook 2—On Hook 3—Ring Out 4—Ring In 5—Connected 6—Busy 7—Line In Use 8—Hold 9—Call Waiting


VoIP Signaling Protocols

59

10—Call Transfer 11—Call Park 12—Call Proceed 13—In Use Remotely 14—Invalid Number Figure 3-2 illustrates the SCCP call flow between a CUCM server and SCCP endpoints registered to it. The following events occur during the SCCP call flow illustrated in Figure 3-2: 1. IP Phone A goes off-hook and signals this event to CUCM. 2. CUCM sends messages to IP Phone A to play the dial tone, display text, and set its lamp state to on. 3. IP Phone A starts sending digits dialed by the user, with the first digit dialed and sent to CUCM leading CUCM to specify to IP Phone A to stop playing the dial tone. 4. The user continues dialing the number, and these digits are sent to CUCM. CUCM performs digit analysis and finds a match for the dialed number that corresponds to the directory number (DN) of IP Phone B. 5. CUCM indicates to IP Phone B that it should blink its lamp and ring to inform the user of an incoming call. CUCM also sends information about the calling party (IP Phone A) to IP Phone B. This information contains calling party name, calling party number, and so on. 6. CUCM sends an alerting (ringback) message to IP Phone A at the same time as it rings IP Phone B. CUCM also sends information about the called party (IP Phone B) to IP Phone A. 7. The user of IP Phone B answers the call and goes off-hook. An off-hook message is sent to CUCM. 8. CUCM instructs IP Phone B to stop blinking the lamp (set to a steady state) and to stop the ring tone. At the same time, CUCM also informs IP Phone A to stop the alerting tone. 9. CUCM requests information such as the to/from IP addresses and the UDP ports for RTP exchange between IP Phone A and IP Phone B. Both phones respond, and CUCM informs IP Phone A of IP Phone B’s RTP information and vice versa. CUCM notifies the IP Phones to open the media channel and start media transmission. 10. RTP traffic flow is set up between the two IP Phones as the users begin their conversation. 11. The user of IP Phone B decides to end the call, thereby sending an on-hook message to CUCM.


60


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



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 MG’s analog (FXS/FXO) or digital (T1-PRI/T1-CAS) port/ endpoint/trunk. MGCP architecture defines nine call states, as shown in Table 3-2. Table 3-2

MGCP Call States

MGCP Call State

Description

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


62


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.



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 music−on-hold MGCPRouter(config)# ccm-manager mgcp ! MGCPRouter(config)# mgcp MGCPRouter(config)# mgcp call-agent 10.76.108.146 2427 service-type mgcp version 0.1 MGCPRouter(config)# mgcp bind control source-interface loopback 0 MGCPRouter(config)# mgcp bind media source-interface loopback 0/0 MGCPRouter(config)# mgcp dtmf-relay codec all mode out-of-band ! MGCPRouter(config)# dial-peer voice 999 pots MGCPRouter(config-dial-peer)# service mgcpapp MGCPRouter(config-dial-peer)# port 1/0/1:23

In Example 3-1, the ccm-manager fallback-mgcp command enables CUCM fallback when a CUCM server is unavailable. The command ccm-manager switchback graceful enables graceful switchback from one CUCM server to another in case of a CUCM server failure. Other options are immediate, never, schedule-time, and uptime-delay. The 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.


003_9780133845969_ch03.indd 63

6/25/14 8:28 AM

64


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

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



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 endpoint’s off-hook transition. 8. Gateway B responds to the request with its session description to CUCM. 9. CUCM relays the session description received from Gateway B to Gateway A in a modify connection request (MDCX). This request might contain an encapsulated notify request that describes the relevant signals and events at this stage of the call setup. Gateway A responds to the request. 10. Now that Gateway A and Gateway B have the required session descriptions to 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


66


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.



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.


68


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 server’s failure to fulfill a valid request by client.

Global Failure (6XX)

Indicates a global failure and that the request cannot be fulfilled at any server.

Figure 3-4 depicts a SIP call flow between UAs (Cisco Unified IP Phones) and a UAS/ B2BUA (CUCM).



IP Phone A

CUCM

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.


003_9780133845969_ch03.indd 69

6/25/14 8:28 AM

70


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.


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 = , where defines a unique session parameter and 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)


72


■

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


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 WebEx–enabled TelePresence conference call can share content from his or her desktop. SIP BFCP works with Cisco TelePresence, EX Series endpoints, and Cisco Jabber with video desktop sharing. Example 3-5 shows SDP output from a video conference where one of the participants is sharing PowerPoint slides during the call. Example 3-5 SDP Output from BFCP-Enabled Call v=0 o=Sam

2890844526 2890842807 IN IP4 10.10.200.100

s=meeting c=IN 10.10.200.100 t=0 0 m=video 49680 RTP/AVP 31 a=rtpmap:31 H261/9000 a=content:slides m=video 49680 RTP/AVP 31 a=rtpmap:31 H261/9000 a=content:main

In Example 3-5, “slides” is the presentation stream and “main” is the main video stream. The streams are controlled by both SIP and BFCP, where BFCP is used for “asking 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


74


■

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. It’s important to note that H.323 call signaling is based on the ITU-T Recommendation Q.931 protocol. An H.323 ecosystem has many elements to it: ■

H.323 terminals/endpoints: Devices such as call-control agents (CUCM, CUCME), multipoint control units (MCU), third-party IP Phones, and so on. Cisco Unified IP Phones cannot process H.323 directly and can only work with SCCP or SIP.

■

H.323 gateways: Fundamental units of an H.323 ecosystem that enable the IP and POTS worlds to come together. H.323 gateways can connect to call-control agents, gatekeepers, session border controllers, and so on.



■

H.323 gatekeeper: Vital element of an H.323 ecosystem as it can provide multiple voice services to endpoints and gateways. A gatekeeper can have a centralized (or decentralized) dial plan, can control bandwidth across WAN links for H.323 voice calls, and can perform user authentication, endpoint registration, admission and request (RAS), and so on.

■

Session border controller (SBC): Known as Cisco Unified Border Element (CUBE) in Cisco terminology, an SBC can process H.323 messages and can help interconnect multiple organizations leveraging the H.323 suite for voice and video calls, either directly or via an IT service provider (ITSP).

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:


76


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)



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 gatekeeper’s name and add a prefix to the local zone list. In this case, all prefixes beginning with digit 1 are associated with the gatekeeper CUCMGK. The gw-type-prefix 1#*default-technology command specifies a default technology prefix 1#*, which is used to route calls if the called number does not 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.


003_9780133845969_ch03.indd 77

6/25/14 8:28 AM

78


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 call’s release.

Progress

Sent by an H.323 gateway to indicate a call’s progress. You typically see Progress messages when internetworking with a non-ISDN network, because audio cut-through must be treated differently in this case.

Status

Used to respond to an unknown call signaling message or to a Status Inquiry message.

Status Inquiry

Used to request call status. Normally the device receiving this message responds with a Status message indicating the current call state for the specific call reference.

Notify

Used to notify a device of a change that has occurred in the call.

Table 3-7 lists the RAS signaling messages. Table 3-7

H.323 RAS Messages

RAS Signaling Message

Description

Gatekeeper Request (GRQ)

Sent from an endpoint/gateway for gatekeeper 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.




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 zone’s endpoint.

Location Confirmation (LCF)

Sent by the gatekeeper in response to an LRQ to pass on the information about an endpoint in its zone to a querying gatekeeper.

Location Reject (LRJ)

Sent by the gatekeeper in response to an LRQ by the originating gatekeeper if the resource doesn’t exist in its zone.

Admission Request (ARQ)

Sent by an endpoint/gateway when it receives a call from an endpoint (FXS analog phone or from an IP Phone registered with CUCM).

Admission Confirmation (ACF)

Sent by the gatekeeper if the remote endpoint is 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


80



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 gatekeeper’s zone. 4. The H.323 gatekeeper returns an RCF indicating that the gatekeeper will add Gateways A and B to its zone. 5. Gateway A sends a local ARQ message to the H.323 gatekeeper seeking 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.



H.323 Gateway A

Gatekeeper

81

H.323 Gateway B

V

V GRQ

GRQ

GCF

GCF

RRQ

RRQ

RCF

RCF

H.225 ARQ H.225 ACF Call Setup Call Processing H.225 ARQ H.225 ACF Alerting Connect H.245 Terminal Capabilities H.245 Terminal Capabilities H.245 Master-Slave Determination H.245 Open Audio Logical Channel H.245 Open Audio Logical Channel ACK H.245 Open Audio Logical Channel H.245 Open Audio Logical Channel ACK RTP

RTP

End Session End Session Release Complete

Figure 3-5

DRQ

DRQ

DCF

DCF

H.323 RAS Call Flow


82


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 gatekeeper’s bandwidth pool.

H.239-Based Dual Video Channels and Cisco Video Equipment Support As mentioned earlier in this chapter, H.239 is the ITU standard for a second video 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.


Analog Telephony

83

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

Foreign Exchange Office (FXO)

■

Foreign Exchange Station (FXS)

■

Ear & Mouth (E&M)

Foreign Exchange Office An FXO interface allows a Cisco Collaboration network to connect with a central office (CO)/PSTN network using analog signaling. An FXO interface on a Cisco router leverages an RJ-11 connector to link with CO. From a CO’s perspective, an FXO device is a regular telephone and should be able to accept on-hook and off-hook, ringing, and send-receive voice frequency signals. An FXO interface can use loop-start or ground-start signaling. Loop-start signaling is a type of supervisory signaling provided by a telephone exchange that allows the indication of on-hook and off-hook states. When in idle state, a loop potential is maintained by direct current (DC) voltage of –48 V provided by the 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


84


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 doesn’t 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.


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 doesn’t 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 doesn’t wait for the on-hook at the receiver side. The initiator goes off-hook and waits for 150 ms and then sends the dialed digits.

Digital Telephony Similar to analog telephony, digital telephony also transmits human voice from one point to another. However, the major distinction is that digital telephony leverages digitization of signaling and audio transmissions. This is accomplished by transforming analog signals into digital signals by use of digital electronics. Digitization of voice has many benefits, including quality improvement, more channels to transmit voice, and overall lower cost of operation (compared to individual FXO trunks). Digital interfaces/circuits come in many flavors, such as T1, E1, Basic Rate Interface (BRI), Primary Rate Interface (PRI), and so on.

Integrated Services Digital Network ISDN is a circuit-switched telephone network system designed to allow digital 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.


86


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


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,


88


ground-start, and E&M variants. E&M supports feature groups such as feature groups D and FGD. Example 3-11 describes the configuration of a T1 CAS circuit. Example 3-11 T1 CAS Configuration CASRouter(config)# controller T1 0/0/0 CASRouter(config-controller)# framing esf CASRouter(config-controller)# linecode b8zs CASRouter(config-controller)# ds0-group 0 timeslots 1-12 type e&m-fgd CASRouter(config-controller)# ds0-group 1 timeslots 13-24 type fgd-eana ! CASRouter(config)# dial-peer voice 90 pots CASRouter(config-dialpeer)# destination-pattern 9T CASRouter(config-dialpeer)# direct-inward-dial CASRouter(config-dialpeer)# port 0/0/0:1

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

Non-Facility Associated Signaling The NFAS protocol allows a single D channel to control multiple PRI interfaces. In other words, instead of giving away a D channel on, say, four PRI T1 trunks, NFAS can be used to tie together all trunks’ D channels, thereby using a single D channel on one of the four


003_9780133845969_ch03.indd 88

6/25/14 8:28 AM

Analog and Digital Telephony Call Signaling Elements

89

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

Analog and Digital Telephony Call Signaling Elements The following sections describe some of the elements that are part of almost every 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 party’s information, such as number and calling name (where supported). With Cisco voice gateways, Caller ID has certain restrictions with certain protocols. Caller ID works for FXS ports with all supported protocols such as MGCP, H.323, SIP, and SCCP. Caller ID, however, does not work on FXO ports with the MGCP protocol because it is not 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).


003_9780133845969_ch03.indd 89

6/25/14 8:28 AM

90


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.


Fax and Modem Protocols

Step 2.

91

Execute the Tone Sweep test for this voice port by issuing the command test voice port 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


003_9780133845969_ch03.indd 91

6/25/14 8:28 AM

92


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

V

V

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


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 passthrough—the analog voice stream is encoded into G.711 and passed through the network tunneled in an RTP stream and decoded back to analog signals at the far end. Modem pass-through can be configured globally in voice service voip or per dial-peer basis using the modem passthrough command. Modem relay supports modem connections across traditional TDM networks. Similar to fax relay, modem relay demodulates a modem signal at one voice gateway and passes it as packet data to the receiving voice gateway, where the signal is re-modulated and sent to the receiving modem. Cisco voice gateways, upon detection of the modem answer tone, switch into modem pass-through mode. If the Call Menu (CM) signal is detected, the gateways switch into modem relay mode. Modem relay supports V.34 modulation and V.42 error correction. Signaling support includes SIP, MGCP, SCCP, and H.323. Modem relay can be configured globally in voice service voip or per dial-peer basis using the modem relay command.


003_9780133845969_ch03.indd 93

6/25/14 8:28 AM



Chapter 4

Cisco Unified Communications Manager

Cisco Unified Communications Manager (CUCM) is an IP PBX that delivers enterpriseclass telephony features and functions. CUCM offers interfaces that include Cisco Unified IP Phones, voice messaging (Cisco Unity Connection), presence (Cisco Unified IM Presence), interactive voice response (IVR), voice gateways, and other multimedia applications. CUCM is the core of almost every Cisco Collaboration solution.

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


96

Chapter 4: Cisco Unified Communications Manager

Cisco Unified CM Group

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


CUCM Device Pool


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


98



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.


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.


100


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.


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 phone’s Call Pickup group number. The following steps show how to configure a Call Pickup group in Cisco Unified CM Administration: Step 1.

Choose Call Routing > Call Pickup Group.

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


102


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 phone’s Phone Button Template, click Copy, and instead of regular Speed Dials, select Speed Dial BLF (for the number of BLF speed dials required).

Step 3.

Go to Device > Phone and select the phone for which BLF needs to be enabled. Select the new Phone Button Template and click Save.

Step 4.

Add a remote phone’s DN that needs to be monitored and provide other required details. Click Save.

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


CUCM Features

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.


104


CUCM Media Resources This section covers the various media resources offered by CUCM for functions such as voice prompts/announcements, transcoding, conferencing, and so on. It also covers their management mechanisms.

Annunciator Annunciator is a Cisco IP Voice Media Streaming (IPVMS) application service process that runs on a CUCM node that has the IPVMS service activated. Annunciator plays recorded announcements to devices on specific events, such as a user dialing an invalid number. An annunciator is automatically created when IPVMS service is activated on one or more nodes in a cluster. No configuration is needed except to change the device pool to a specific device pool—for example, changing to Datacenter-DP a device pool that contains all media resources. To change the device pool, go to Media Resources > Annunciator and select the annunciator for which the device pool is to be changed. Choose the appropriate device pool and click Save.

Conference Bridge As discussed in a previous section, CUCM supports two types of conferences, ad-hoc and Meet-Me. For either conference type, a conference bridge resource is required, either a hardware conference bridge or a software conference bridge. Similar to Annunciator, a software conference bridge runs on CUCM and is automatically created when IPVMS service is activated on a node. Where possible, use of hardware conference bridge(s) is recommended because software conference bridges have an impact on CUCM CPU and memory, and only support G.711 calls. Hardware conference bridges can be 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.”


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 MTP’s device pool, go to Media Resources > MTP and select the MTP for which the device pool is to be changed. Choose the appropriate device pool and click Save. For hardware MTP configuration, refer to the “Resource Reservation Protocol” section later in this chapter.

Transcoder Sometimes it is required to have one codec converted to another; for example, G.729 calls traversing over a WAN from a remote site might need to be converted to G.711 at the data center. Transcoders are the hardware resources that enable a Cisco Collaboration network to convert calls from one codec to another. Transcoders can be enabled on Cisco IOS gateways and, like hardware conference bridges, they also leverage DSPs off PVDMs. To configure a transcoder, follow these steps in Cisco Unified CM Administration: Step 1.

Choose Media Resources > Transcoder.

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


004_9780133845969_ch04.indd 105

6/25/14 10:15 AM

106


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.


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


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


108


■

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


004_9780133845969_ch04.indd 108

6/25/14 10:15 AM

CUCM Dial Plan 109

CSSs can be applied to anything that is required to call entities, such as ■

Devices

■

Directory numbers

■

Gateways

■

Trunks

■

Translation patterns

From a user perspective, when the user dials digits, they’re processed by CUCM (digit analysis/manipulation) and the device’s (phone’s) CSS determines if the digits dialed have access to the destination resource, which may be another phone, a route pattern, a 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


110


route list–based digit manipulation (digit manipulation is covered later in this chapter). Hence, route lists serve a twofold purpose: providing alternate call path(s), and amending a dialed number so that the call goes successfully through the first available call path.

Route Group Route groups are logical entities that allow multiple gateways/trunks to be placed in one or more route groups. This offers a level of redundancy when a certain endpoint or trunk is not available. Also, route groups offer load balancing of calls. Route groups offer two distribution algorithms: circular and top down. In the circular algorithm, all gateway endpoints/trunks assigned to a route group are used, starting from the first entity, and then the cycle begins again from the top. In the top-down algorithm, the first member of a route group is used until it is unavailable, at which point CUCM call routing logic uses the next-in-order gateway endpoint or trunk.

Globalized Call Routing Globalization of a CUCM dial plan allows a simplified approach to dial numbers for 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


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 site’s gateway. Essentially, the decision making happens at the device pool level, which defines the LRG, which in turn has access to the local gateway for the site from which the call originated. This concept is illustrated in Figure 4-6. Device-Pool Site A

Site-A 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 Group–Based Call Routing


004_9780133845969_ch04.indd 111

6/25/14 10:15 AM

112


An LRG allows site specificity of call routing to be established by the calling device’s location as derived from the device pool. In this case, and as shown in Figure 4-6, Device-Pool Sites A and B assign the LRG and inform CUCM that for Site A calls, Site-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 phone’s device pool. However, they can all call the same route pattern(s), and the calls are routed differently based on the caller’s currently associated LRG.

Time-of-Day Routing CUCM offers Time-of-Day routing to help administrators and organizations apply certain rules pertinent to dialing of long distance or international numbers (or stop dialing of any numbers except emergency calls, depending on an organization’s policy) post business hours. The following example illustrates the Time-of-Day routing concept. A phone in an organization’s U.S. office is used to call an international number +91XXXXXXXXXX during business hours. The CSS of the phone has access to a partition that allows calls to access the (international) route pattern as the partition is active during those hours. Post 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 organization’s office is open 8:00 a.m. to 5:00 p.m. Monday through Friday and 10:00 a.m. to 5:00 p.m. on Saturday, then two time periods can be defined and assigned to the same time schedule.

■

Partitions: Once a time schedule is defined, it must be assigned to a partition for the partition to be active/inactive during a specific time period.

After Time-of-Day routing is enabled, before routing a call, CUCM filters partitions in the calling device’s CSS. This is based on the time and time zone of the calling device and the time schedules assigned to partitions. Then the active partition is used to route the call. If there are no active partitions (for the dialed number destination) the caller gets a fast-busy tone.

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


CUCM Dial Plan 113

have an application dial rule to resolve the number to the route plan. An application dial rule helps automatically strip numbers from, or add numbers to, a telephone number that a user dials. For example, an application dial rule can automatically prefix a digit to a telephone number to provide access to an outside line. The following is an example of an outline for an application dial plan: ■

For seven-digit dialing where the number begins with 222 and the number of digits is seven, prefix 9.

■

For ten-digit local dialing where the number begins with 408 and the number of 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.


114


■

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.


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 0–9, *, #, 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.


004_9780133845969_ch04.indd 115

6/25/14 10:15 AM

116


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


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:@;?

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.


118


■

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

[email protected]

[email protected]

DN 99901

DN 99902

Figure 4-9

Directory URI-based SIP Call

Currently, URI dialing is supported only by a subset of IP Phones (including 99XX and 8961 IP Phones, except transfer, conferencing, and forwarding in the latter case), Jabber clients, and video endpoints. In the context of URI-based call routing, the following specifics come into play: ■

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


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 endpoint’s 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 [email protected] and xyz@ siteB.corp.local, instead of a flat schema, such as [email protected] and [email protected]. Moreover, the remote clusters may not be aware of the local cluster’s route strings (SIP route patterns). In this instance, Intercluster Lookup Service (ILS) comes to the rescue. It enables clusters to exchange URIs and create a URI to route string mapping table, as shown in Figure 4-10. [email protected]

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

[email protected] > SiteB.corp.local [email protected] > SiteC.corp.local

si

l

ca

te

.lo

.c eA

t

si

si

l

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

t

si

C

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

[email protected] > SiteA.corp.local [email protected] > SiteC.corp.local

[email protected] > SiteA.corp.local [email protected] > SiteB.corp.local

siteB.corp.local siteC.corp.local

[email protected]

Figure 4-10

[email protected]

ILS URI to Route String Mapping Between CUCM Clusters

ILS allows propagation of individual alpha URIs between call-control agents (clusters) and helps bind an alpha URI with attributes that allow routing to the URI’s home cluster. Each call-control agent replicates its alpha URIs to its neighbors and also announces a SIP route


120


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


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. Don’t set the Registration Server.

Figure 4-12

ILS Configuration

Step 4.

On other clusters, to join an ILS network, set the Role to Spoke Cluster and configure Registration Server as the SME IP address/hostname (in the 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.


122


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:

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:


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 server—basically, any device that sources media. Locations can be dynamically associated to endpoints via device mobility groups (IP subnets). Figure 4-14 depicts location configuration between a hub site and a remote site.

Figure 4-14

Location-based CAC Configuration

LCAC has a new option for immersive video: TelePresence. Now, you can establish 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 isn’t supported in real-world network models where customer networks are multitier and multihop instead of simple hub-and-spoke topology.

■

It has no intercluster bandwidth management support.

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


124


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.



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 path’s weight determines the effective path.

■

A tiebreak of equally weighted paths is determined by LBM based on location name.

■

After the effective path is determined, all subsequent calls that have the same source and destination locations will use the same effective path.

LBM is a CUCM service that is activated by default for upgrades to CUCM 9.x from 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 cluster’s 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


126


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

Shared location: A Shared/Common location is configured with the same name on clusters participating in an LBM replication network. It serves two purposes: it enables clusters to propagate their respective configured topologies to one another, and it provides the ability for multiple clusters to apply CAC to the same locations.

Resource Reservation Protocol RSVP is a topology-aware CAC signaling protocol that has been designed to work with any WAN topology. It runs as a software feature on Cisco IOS routers and as an RSVP agent on CUCM. It has the following characteristics: ■

Uses existing routing protocols and dynamically adjusts to link failures/topology changes.

■

Reservations are receiver-initiated and are on a per-stream basis.

■

Operates transparently across non-RSVP routers, allowing for partial or gradual deployment.

■

Dynamically inserted (in pairs) by CUCM based on location policy.

■

Calls are accepted, re-marked, or rejected based on the outcome of RSVP reservation and configured policy (optional, mandatory).

Figure 4-17 represents RSVP call flow including endpoints, CUCM RSVP agents, and RSVP-enabled Cisco IOS routers. CUCM uses two RSVP application IDs: ■

AudioStream: Used for audio streams of voice calls

■

VideoStream: Used for audio and video streams of video calls

These IDs allow you to limit the maximum number of audio or video calls across a link. Voice calls are marked as EF (default) and video calls (both audio and video streams) are marked AF41 (default).



IP Phone A

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 Phone’s MRGL). Example 4-1 outlines the configuration of Cisco IOS router MTP as the RSVP agent.


128


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:


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. CUCM’s Silent Monitoring feature allows an authorized party to eavesdrop on a conversation between two or more parties without either call participant knowing they are being monitored. This allows Contact Centers to monitor the quality of service their agents provide to the


130


customers. CUCM’s 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

Caller’s 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 agent’s IP Phone’s internal DSP resources mix the media streams of the agent and caller and send them to the supervisor. The following are features of Silent Monitoring: ■

Allows supervisors to monitor calls using their IP Phone. The media (RTP) plays through the IP Phone and not the PC.

■

Monitoring sessions are managed as normal calls; calls can be transferred, held, or conferenced.


CUCM-Based 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 agent’s IP Phone relays two independent media streams (agent and caller) to the recording server via the SIP trunk. Two broad recording modes are available with CUCM-based Call Recording: ■

Automatic silent recording: Records all calls automatically on a line appearance. Automatic silent recording is invoked by CUCM. There’s no visual indication of the recording session.

■

Selective recording: Allows calls to be recorded as needed. Selective recording can be further classified into two types of recording: ■

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

■

Selective user recording: Invoked by an agent via a CTI-enabled desktop and/or softkey/programmable line key. Cisco Unified IP Phone displays recording session messages.

The following are Call Recording features: ■

Call data is provided in the SIP header via CallID (RefCI), Directory Number (DN), Device Name (MAC Address), Line Display Name, and Near-end/Far-end. Other callspecific data is retrieved via CTI using CallID.


004_9780133845969_ch04.indd 131

6/25/14 10:15 AM

132


■

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 Recording—that is, to connect a Recorder (Recording Server) to CUCM and configure a phone for recording—follow 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.


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.


004_9780133845969_ch04.indd 133

6/25/14 10:15 AM

134


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 user’s home cluster’s dialing behavior. EMCC supports secure phone registration. The EMCC process works as follows: ■

The user from the home cluster logs in to a phone at a visiting cluster.

■

The login procedure brings the device information into the home cluster database.

■

The home cluster database builds a temporary device with the user’s device profile.

■

The home cluster TFTP server builds the phone configuration file.

■

After login, the visiting cluster directs the phone to the home cluster TFTP server.

■

The IP phone downloads its TFTP configuration from the home cluster TFTP server and cross-registers with the home cluster CUCM.

To configure EMCC, first complete the EM configuration steps, and then follow these steps: Step 1.

Go to the Cisco Unified CM Operating System Administration page and choose Security > Bulk Certificate Management > Export and export the home cluster’s Tomcat, TFTP, and CAPF certificates (assuming that you have the SFTP server set up and functional).

Step 2.

Consolidate and import certificates into all remote (visiting) clusters.

Step 3.

Repeat Steps 1 and 2 to export, consolidate, and import certificates from visiting clusters to the home cluster.


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 device’s device pool and the device pool configured on the IP subnet. If the Physical Location is different, CUCM applies the IP subnet’s device pool configuration to the endpoint, builds a new configuration file, and resets the endpoint. The settings applied to roaming handsets include Date/Time Group, Region, Location, SRST Reference, Physical Location, and MRGL.


136


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 there’s an incoming call, it rings the local IP Phone as well as any of the enabled remote devices. If the call goes unanswered, it is routed to the local IP Phone. Figure 4-20 shows the Mobile Connect call flows. As shown in Figure 4-20, there are two call flows: one from the PSTN caller to a user’s desk phone that is enabled for mobility, and the other from a user’s remote device to an internal phone. For the first call flow, when the PSTN caller rings the desk phone +15555559000, CUCM intercepts the call and, using the user’s configured remote destination profile(s), rings all the remote devices (in this case the user’s mobile phone at +14088888000) including the desk phone (DN 9000) with caller ID of PSTN caller (+15558888000). At this time, the user has an option to pick up the call on any local and reachable device, be it the desk phone or the mobile phone. For the second call flow, the user dials an internal number (9001) using the E.164 number +15555559001, CUCM intercepts the call and matches the dialed number to the remote destination(s) configured, which in turn is mapped to an internal DN. After finding a match, CUCM directs the call to the internal number (after digit striping/manipulation) with caller ID of internal DN 9000.


CUCM Mobility

137

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.


004_9780133845969_ch04.indd 137

6/25/14 10:15 AM

138


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 user’s desk phone.

Step 7.

Add Remote Destination(s) number(s). This can be accomplished by CUCM administrator by browsing to Remote Destination Profile page or by CUCM users browsing to CCMUser > User Options > Mobility Settings > Remote Destinations. Ensure that the Mobile Phone and Enable Mobile Connect check boxes are checked. Select a Ring Schedule and Ringing option.

Mobile Voice Access Mobile Voice Access (MVA) extends Mobile Connect capabilities that enable a system to make enterprise calls from any location. MVA allows enterprises to leverage an integrated voice response (IVR) system on an H.323 VXML gateway so that the IVR system can be used to initiate Mobile Connect calls and activate or deactivate Mobile Connect. Figure 4-21 illustrates the MVA call flow. As shown in Figure 4-21, a corporate user calls in to the MVA number +15555559999 that triggers the MVA application. The user then keys in the remote destination number (+15558888000) followed by the PIN, both of which are relayed to CUCM by the voice gateway. Once authenticated, the user is connected to the dialed remote destination number. The following steps show how to configure CUCM for MVA (assuming Mobile Connect is enabled on the cluster): Step 1.

Go to Cisco Unified Serviceability > Tools > Service Activation and enable Cisco Unified Mobile Voice Access Service.

Step 2.

Navigate to the Cisco Unified CM Administration page and choose System > Services Parameter > CUCM > Clusterwide Parameters (Mobility). Set Enterprise Feature Access to True, Enable Mobile Voice Access to True, Mobile Voice Access Number (for example, 9999), and Matching Caller ID with Remote Destination as Partial Match.


004_9780133845969_ch04.indd 138

6/25/14 10:15 AM

CUCM Mobility

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 !


004_9780133845969_ch04.indd 139

6/25/14 10:15 AM

140


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.



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


142


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 can’t go through via the IP network, CCD Requesting Service routes the call via the PSTN network.

Figure 4-23 illustrates CCD advertised and learned routes (dial plan) across a 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.



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 router’s external-client configuration. Click Save.

Step 2.

Navigate to Advanced Features > SAF > SAF Forwarder and create a new SAF forwarder. Use the external client configuration parameters to complete the Client Label, SAF Forwarder Address, and SAF Forwarder Port fields, and from the SAF Security Profile drop-down list, select the security profile 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.


144


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.


Chapter 5

Cisco Unified Communications Security

As discussed in the previous chapters, a Cisco Collaboration solution has many elements, including infrastructure, endpoints, applications, gateways, and so on. While all of these work together to deliver a seamless user experience, they need to be secured to ensure that business continuity is maintained and the communication channels are operational. The objective of securing a Cisco Collaboration solution is to secure a converged communications network to protect its availability, the confidentiality of data that it carries, and the integrity of this data.

Security Policy The fundamental step to achieve a robust and secure converged network is to develop a security policy that specifies an appropriate security plan, design, implementation, and operations policy. A security policy gives direction to the efforts to deploy security controls at the various layers of the OSI model, starting at the physical layer, Layer 1, up through the application layer, Layer 7. At a high level, a security policy should at least address the following from a Cisco Collaboration network perspective: ■

Acceptable usage and conduct pertinent to Cisco Collaboration network resources

■

Physical layer security

■

Network infrastructure security

■

Perimeter security

■

Server hardening

■

User endpoint security

■

Wireless infrastructure security

■

Backup and restore (including disaster recovery) security

■

Provision for lawful interception of calls 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.

There’s no single security control or tool/mechanism to thwart all the attack types listed in Table 5-1. Defense-in-Depth, also known as a layered security approach, is required to mitigate these threats. The following sections give insight into security measures at the various layers of the OSI model.

Layer 1 Security Physical security entails securing Cisco Collaboration assets from physical access by an intruder and from potential damage by surrounding environmental factors. The major physical security controls include ■

Guards at data center or facility periphery

■

Badged access to data center/facilities

■

CCTV, alarms, and sensors at data center/facility entry and exits

■

Cisco Collaboration equipment secured in racks in data center and in closets at user access level

■

Uninterruptible power supply (UPS) for servers and network devices


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 switch’s CAM table and not in the running configuration.

Upon violation of the number of MAC addresses per port, you can configure violation rules in one of following three ways: ■

Protect: When the switch port reaches its configured maximum number of secure MAC addresses, it starts dropping frames with an unknown source MAC address.

■

Restrict: Similar to the protect option, the major difference being that the restrict option can send an SNMP trap and a syslog message. It increments the violation counter when a port security violation occurs.

■

Shutdown: After a port security violation occurs, the port is shut down and put in err-disable state. This option also allows generation of the SNMP and syslog notifications, identical to the restrict option, and it will also increment a violation counter.


148


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.



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 don’t accept any BPDUs. Root Guard ensures that when the root (or root bridge) is elected, a new BPDU on a designated port isn’t entertained. The following is a configuration of BPDU Guard and Root Guard for thwarting STP manipulation: UCSWITCH(config)# spanning-tree portfast bpduguard UCSWITCH(config)# spanning-tree guard root

Dynamic ARP Inspection An attacker can poison the Address Resolution Protocol (ARP) table. The intent is to conceal the identity so that the attacker’s switch/PC becomes the default gateway for the telephony subnet. ARP poisoning can be implemented by replying to and poisoning the network so that the attacker’s MAC address seems to be mapped to the default gateway IP address of the endpoints. An ARP attack can be mitigated by implementing Dynamic ARP Inspection (DAI), wherein the switch checks the IP/MAC mappings in the DHCP snooping binding table, thereby establishing the authenticity of packets before forwarding the packets to the destination. DAI drops all ARP packets that do not pass the inspection process. Example 5-3 outlines the process to enable DAI on a global and 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. It’s a framework designed to address and provide port-based access control using authentication, primarily using Extensible Authentication Protocol (EAP) as the key protocol. 802.1x is a Layer 2 protocol for transporting authentication messages (EAP) between a supplicant (user/endpoint/ PC) and an authenticator (switch or access point) with an (optional) authentication server


150


(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 Phone’s vendor-specific attribute (VSA).

Step 4.

IP Phone traffic is initially allowed on either VLAN until it sends an 802.1Q tagged packet. Then only voice VLAN is allowed for the IP Phone.

Step 5.

The daisy-chained PC (connected to the PC port on the IP Phone) 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



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:


152


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.


Firewall Traversal Mechanisms

153

Cisco ASA works in routed mode, transparent mode, or multiple-context mode. In routed mode Cisco ASA appears as a hop in the network—that is, it works at Layer 3. Routed mode supports multiple interfaces and practically all Cisco Collaboration services/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


154


signaling), but with encrypted signaling leveraging Transport Layer Security (TLS), a NAT/ALG-aware firewall is unable to look into the content of packets.

IPsec Tunnels Site-to-site or remote-access VPN IPsec tunnels can be used to enable NAT exemption. Moreover, if the VPN gateway is placed behind a firewall, the firewall is unable to inspect or modify the contents of the packet within the tunnel. This is an ideal solution when a corporate firewall is required to filter all traffic except voice/video traffic.

IP-Based ACLs Traffic from the Internet, remote sites, telecommuters, and remote workers can be filtered based on IP ACLs. This allows a modest degree of control on the traffic that traverses through the firewall. In such cases, inspections may still be required to handle voice and video signaling and media traffic.

Port-Based ACLs Synonymous to IP-based ACLs, port-based ACLs can be used for filtering traffic from/ to an external network to the data center. Port-based ACLs give an administrator or a security engineer a greater degree of control and allow for the least permissive policy. However, port-based ACLs are also the most tedious to configure because every port for a Cisco Collaboration protocol or service needs to be looked at and allowed or denied as per the organization’s policy. In case of voice and video signaling and media traffic, quite a few protocols and ports must be permitted to ensure that the Collaboration services operate appropriately. As discussed in Chapter 3, “Telephony Standards and Protocols,” the most commonly used voice and video protocols include SCCP, MGCP, H.323, SIP, RTP, and RTCP. Moreover, there are other protocols that are used for administration and integration of voice services, such as SSH, TAPI/JTAPI, HTTP, HTTPS, TFTP, DNS, and LDAP. For a complete list of TCP/UDP ports that are required for firewall traversal for CUCM, refer to “Cisco Unified Communications Manager TCP and UDP Port Usage” at www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/port/9_1_1/CUCM_BK_ T2CA6EDE_00_tcp-port-usage-guide-91/CUCM_BK_T2CA6EDE_00_tcp-port-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.


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

It’s 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 organization’s 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 doesn’t require internal endpoints to be encrypted; hence, the CUCM cluster within an organization’s data center can be in unsecure mode or mixed mode.

Cisco ASA Phone Proxy and TLS Proxy services are not supported with CUCM version 9.x. Instead, Cisco VPN Phone is recommended for secure remote endpoint connection and traversal at the enterprise-edge firewall. Also, as an alternative to the ASA Phone Proxy feature, Cisco Unified Border Element (CUBE) supports Phone Proxy with B2BUA line-side support for CUCM. Phone Proxy is supported with Cisco IOS version 15.3(3) M1 and later on the Cisco Integrated Services Routers Generation 2 (ISR G2) platform. It allows organizations to have phones on the Internet connected to a CUBE at the edge of the enterprise and securely set up signaling/media with phones in the enterprise premises.


156


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


RTP

Figure 5-3

Cisco VPN Phone

Cisco VPN Phone is supported on 7942G, 7945G, 7962G, 7965G, 7975G, and 99xx series as well as 89xx series Cisco Unified IP Phones. For a complete list of supported IP Phones in a certain CUCM version, go to Cisco Unified CM Administration and choose Cisco Unified Reporting > System Reports > Unified CM Phone Feature List > Generate a New Report > Feature: Virtual Private Network Client. The minimum requirements for implementing Cisco VPN Phone are as follows: ■

IP Phone SCCP firmware version 9.0(2)SR1S or later

■

CUCM 8.0.1 or later

■

Cisco ASA IOS 8.0.4 or later

■

AnyConnect VPN Pkg 2.4.1012

■

AnyConnect premium license and AnyConnect for Cisco VPN Phone license required for Cisco ASA

Example 5-5 outlines the configuration on Cisco ASA to support Cisco VPN Phone. Example 5-5 Cisco ASA VPN Phone Configuration UCASA(config)# group-policy GroupPolicy1 attributes UCASA(config-group-policy)# vpn-tunnel-protocol WebVPN ! UCASA(config)# ip local pool VPN-Phone 10.10.1.200-10.10.1.254 mask 255.255.255.0 !


Application Layer Security

157

UCASA(config)# tunnel-group VPNPhone type remote-access ! UCASA(config)# tunnel-group VPNPhone webvpn-attributes UCASA(config-tunnel-webvpn)# group-url https://UCASA.org.corp/PhoneVPN enable ! UCASA(config)# tunnel-group VPNPhone general-attributes UCASA(config-tunnel-general)# address-pool VPN-Phone UCASA(config-tunnel-general)# default-group-policy GroupPolicy1 ! UCASA(config)# webvpn UCASA(config-webvpn)# enable outside UCASA(config-webvpn)# anyconnect image disk0:/anyconnect-win-3.1.00495-k9.pkg 1 UCASA(config-webvpn)# anyconnect enable UCASA(config-webvpn)# tunnel-group-list enable

The following steps summarize the configuration required on CUCM to support the Cisco VPN Phone feature: Step 1.

Upload VPN certificates from Cisco ASA to CUCM by going to Cisco Unified CM Operating System Administration and choosing Security > Certificate Management. Upload the Cisco ASA self-signed certificate as Phone-VPN-Trust certificate.

Step 2.

Configure the VPN gateway by browsing to Cisco Unified CM Administrator and choosing Advanced Features > VPN > VPN Gateway.

Step 3.

Create a VPN group under Advanced Features > VPN > VPN Group.

Step 4.

Configure the VPN Profile under Advanced Features > VPN > VPN Profile.

Step 5.

Assign the VPN group and profile to the Common Phone Profile by going to Device > Device Settings > Common Phone Profile.

Step 6.

Configure the Cisco Unified IP Phone with a TFTP server manually and 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 model’s application layer’s services. The following sections address the security mechanisms offered by Cisco Unified CM.


158


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

Default authentication of the TFTP downloaded files (configuration, locale, and so on)

■

Optional encryption of the TFTP configuration files

■

Certificate verification for the phone-initiated HTTPS connections using a remote certificate trust store on CUCM and TVS

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

CUCM Security Modes CUCM provides two security modes: ■

Non-secure mode (default mode)

■

Mixed mode (secure mode)

Non-secure mode is the default mode when a CUCM cluster (or server) is installed fresh. In this mode, CUCM cannot provide secure signaling or media services. To enable secure mode on a CUCM server/cluster, the Certificate Authority Proxy Function (CAPF) 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:


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 cluster’s conversion to mixed mode by going to System > Enterprise Parameters. The parameter Cluster Security Mode should be 1, which indicates that the cluster is running in mixed mode.

CTL Client and CTL File The CTL client, as discussed earlier, is a plug-in that can be downloaded from the CUCM Administration GUI and that runs on a Windows PC to convert a CUCM cluster from non-secure mode to mixed mode. A CTL client signs various certificates. A CTL file contains the following: ■

Server Certificate

■

Public Key

■

Serial Number

■

Signature

■

Issuer Name

■

Subject Name

■

Server Function


005_9780133845969_ch05.indd 159

6/25/14 11:07 AM

160


■

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


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

Cisco Manufacturing

MIC (Cisco CA Public Key)


Figure 5-5

Cisco CUCM CAPF Server

CAPF TLS

LSC (CAPF Public Key)


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.


162


■

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)

V

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.


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.


005_9780133845969_ch05.indd 163

6/25/14 11:07 AM

164


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 ! UCRouter(config)# dial-peer voice 7 pots UCRouter(config-dial-peer)# corlist outgoing local !


Preventing Toll Fraud

165

UCRouter(config)# dial-peer voice 11 pots UCRouter(config-dial-peer)# corlist outgoing national

Cisco Unity Connection Restriction Rules Cisco Unity Connection can transfer calls from voice mail to the PSTN. This feature can be exploited for conducting toll fraud. To ensure that your Cisco Unity Connection 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.




Chapter 6


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

Cisco Unity Connection High Availability CUC servers can be deployed in an active-active cluster model, with a publisher/ subscriber configuration so that both servers can concurrently accept voicemail calls, place outbound calls, and accept incoming administrative/user HTTP requests. If one server goes down, the other active server preserves the majority of end-user functionality, including voice calls and HTTP requests, but with lower port capacity. Similar to CUCM, the publisher database has full read/write access, whereas the subscriber database is read access only. An active-active cluster pair supports up to 500 ports per CUC cluster or 250 ports per server, and a single CUC cluster supports up to 20,000 voicemail users (subscribers). In a CUC cluster, under ideal circumstances, the CUC publisher should handle the majority of administration traffic, such as CUC administration tasks (GUI access, bulk 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:


168

Chapter 6: Cisco Unity Connection

■

The maximum round-trip latency must be no more than 150 ms.

■

Firewalls must not block the required ports. For a list of all ports required by CUC 9.1, refer to www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/security/ guide/9xcucsec010.html.

■

Depending on the number of voice messaging ports on each CUC server, guaranteed bandwidth must be available at all times with no steady-state congestion: ■

For 50 voice messaging ports on each server: 7 Mbps

■


■


■


■


Cisco Unity Connection Integration with CUCM and CUCME CUC supports SCCP voicemail and SIP voicemail integration with CUCM and CUCME, as shown in Figure 6-1.

CUCM 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


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.


170


Figure 6-2 CUCM Voicemail Port Wizard Confirmation Page Step 9.

Navigate to Advanced Features > Voice Mail > Message Waiting and click Add New. Enter a number in the Message Waiting Number field, and then click the On radio button for the Message Waiting Indicator option. Click Save, and then click Add New. Enter a second number and select the Off radio button. Click Save.

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


006_9780133845969_ch06.indd 170

6/25/14 11:11 AM


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.) It’s 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).


172


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



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 !


174


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 !


Cisco Unity Connection Dial Plan

175

CMERouter(config)# sip-ua CMERouter(config-sip-ua)# mwi-server 10.76.108.244 unsolicited

In Example 6-2, the dial peers point to the CUC subscriber and publisher, respectively, with the voicemail number as destination-pattern. The max-conn <> command specifies the number of voicemail ports on each server.

Cisco Unity Connection Dial Plan Similar to CUCM, CUC also has dial plan components that allow the implementation of restrictions related to callers being able to send messages to other users (or system entities) as defined by the organization’s messaging policy. For example, an organization could have a requirement that users cannot leave voice messages for directors and above. In such cases, partitions can be used to segregate the following objects: ■

Contacts

■

Call handlers (system, directory, and interview handlers)

■

Distribution lists

■

Users

Partitions define who or what can be reached, search spaces (equivalent to CUCM CSS), and define by whom or what partitions are reachable. Search spaces can be assigned to any object that can initiate a call or a user that can address a message to another user or entity. Partitions can be assigned to various search spaces to ensure that the call restrictions are in place for system entities and subscribers (users). The following objects can be assigned to a search space: ■

Call handlers (system and directory handlers)

■

Routing rules

■

Users

To create a new partition or search space, go to the Cisco Unity Connection Administration page and click Dial Plan in the navigation pane on the left. From there, you can define new partitions and search spaces. The system default partition and search space are created during CUC installation and must be replaced with appropriate 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.


176


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 user’s (subscriber’s) extension, the system directory, or the operator. In case a caller does not make a selection, the caller is directed to the operator.

■

Operator: Allows the caller to dial 0 to connect to the subscriber/extension defined as an operator. If an operator extension is not defined or an operator is unavailable, the Operator call handler default configuration takes a message.

■

Goodbye: Plays a goodbye announcement, after which it disconnects the call. This call handler is invoked by default when a user has finished recording a message via the Operator call handler.

Figure 6-3 shows the default system call handlers available with CUC.

Figure 6-3

CUC System Call Handlers


Call Handlers

177

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

CUC System Call Handler Options

System Call Handler Option

Description

Transfer Rules

Allow administrator(s) to configure a standard, closed, or alternate transfer rule. While standard transfer is enabled by default, it cannot be deleted and is without an end date. The closed transfer rule, if enabled, overrides the standard 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.


178


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 user’s extension, a call handler, another directory handler, or a conversation. If a caller doesn’t provide any input, the previously stated actions can be repeated or the caller can be sent to the Goodbye call handler. Finally, if a caller presses 0, the caller is transferred to an operator.


Call Handlers

■

179

Greeting: Can be recorded as an opening prompt for a directory handler. If no greeting is recorded, the system directory handler uses a default greeting that prompts the user’s input.

Figure 6-4 represents a directory handler configuration.

Cisco Unity Connection Interview Handlers CUC interview handlers are yet another special type of call handler. An interview handler primarily allows a caller to answer a series of questions and subsequently records the caller’s responses. These responses are delivered to a message recipient so that the recipient can understand the caller’s 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 organization’s requirements. Figure 6-5 shows an interview handler.

Figure 6-5

CUC Interview Handler

The configuration of an interview handler has two major sections: ■

Basic Configuration: Defines basic properties of an interview handler such as name, extension, language, recipient, after-interview action, and so on. After a response is recorded, it is sent to the recipient user or distribution list. Consequently, the


180


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 doesn’t synchronize the following messages: ■

Sent messages

■

Draft messages


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 server’s IP address

■

Exchange server type (2003/2007/2010)

■

Active Directory account to access Exchange


182


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


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 Messaging–enabled users, confirm that the Generate SMTP Proxy Address from Corporate Email Address is checked (user-by-user basis or via BAT or via user template). Users can be provisioned/edited by browsing to Users > Users. Also ensure that after a user is configured, under the edit option, choose Unified Messaging Accounts and define the user’s Unified Messaging services as shown in Figure 6-8.

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 Phone’s screen. Visual Voicemail is a combination of a MIDlet (a Java application that runs on IP Phones) and a phone service that points to the MIDlet. Follow these steps to configure Visual Voicemail: Step 1.

Ensure that all phones have Web Access set to Enabled. You can accomplish this either via BAT, by browsing to Cisco Unified CM Administration > System > Enterprise Phone Configuration, or by setting the Common Phone Profile Configuration by browsing to Device > Device Settings > Common Phone Profile.

Step 2.

Create a new Voice Mail Pilot in addition to the standard Voice Mail Pilot. Provide a unique pilot number (different from that of the regular Voice Mail Pilot) and other required parameters.


184


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:///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 . Save the configuration.

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

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


Voice Mail for Cisco Jabber

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


186


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:


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 location’s configuration file and downloading the local configuration file and uploading it to the remote location).


188


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.


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




Chapter 7

Cisco Unified IM and Presence

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

Cisco Unified Communications Manager IM and Presence Components A Cisco Unified CM IM and Presence solution has several components that work 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)


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


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 cluster’s publisher uses a database connection to the CUCM publisher to synch user and device information. Multiple subclusters provide higher capacity, and when a subcluster has two servers, it offers redundancy and high availability. A Cisco Unified CM IM and Presence cluster can be integrated with only one CUCM cluster. Figure 7-2 shows CUCM cluster integration with a Cisco Unified IM Presence cluster.



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


194


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



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 organization’s LDAP server; for example, Microsoft Active Directory).

Step 9.

Navigate to User Management > User Settings > Service Profile. Click Add New. Enter the service profile name as Jabber and enter a meaningful 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


196


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

Figure 7-5

Presence Gateway Configuration

Figure 7-6

CCMCIP Profile Configuration


Cisco Jabber

197

The integration of CUCM and the Cisco CM Unified IM and Presence server is 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.


198


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


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 sender’s desktop in addition to a camera video stream. Video desktop sharing can link Jabber client and Cisco video endpoints.

Presence Federation Federation facilitates IM and Presence collaboration between a Cisco Unified CM IM and Presence server and a third-party vendor. This allows IM and Presence information


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


200


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.


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.


202


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 Cisco’s cloud-based solution. The Collaboration Cloud (as shown in Figure 7-11) is a shared platform that builds on the following: ■

XMPP IM service

■

Meeting (rich media conferencing) services

■

Single identity (database)


Presence Cloud Solutions

■

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)


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.


204


■

Contacts are stored in a cloud database (including corporate and federated contacts) and contact searches are performed in the cloud database.

■

Ad hoc desktop sharing is available in cloud mode by default. The sharing session is hosted in the cloud.

■

An IM logging and archiving option is available for consumers to log/archive IM chats, including group chats within and outside of their organization.

■

Federated single-sign on (SSO) using corporate credentials is available.

Note that cloud-based presence solutions support only interdomain federation.

Group Chat and Compliance The Jabber client has the capability to provide group chat service. Moreover, the Jabber client provides IM logging for organizational compliance (for example, for audits or legal matters).

Group Chat When multiple people need to have a chat conversation simultaneously, a group chat can be established. Group chat can be either an ad hoc chat (temporary group chat) initiated by a user when required or a permanent group chat. A temporary group chat doesn’t require any special configuration. A permanent chat room, however, requires an external database such as PostgreSQL. PostgreSQL can be used for compliance features as well, as covered in the next section. The major 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.


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.


206


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.


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. Customer’s archiving endpoints such as compliance servers need to be entered into the Cisco WebEx Administration tool. The following parameters are required: ■

Endpoint name

■

Endpoint type

■

Endpoint parameters (vary depending on endpoint type)

After endpoints have been configured, users must be assigned for logging by creating users, employing CSV files, directory integration, or Security Assertion Markup Language (SAML).




Chapter 8

Cisco Unified Contact Center Express

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

Cisco UCCX Architecture Figure 8-1 illustrates the Cisco UCCX architecture and its interaction with the Cisco Collaboration solution. Cisco 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

V

Cisco Voice Gateway

Cisco UCCX Architecture and Interaction with Cisco Collaboration Network


210

Chapter 8: Cisco Unified Contact Center Express

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

Cisco UCCX Components and Subsystems Cisco UCCX consists of four major components and several subcomponents: ■

■

■

UCCX Engine: The UCCX Engine processes and executes applications using the functionality of the following subsystems: ■

Script execution

■

Cisco Agent Desktop (CAD) communication

■

CUCM/CTI manager JTAPI communication

■

UCCX Administration interface

■

Resource Manager and Contact Manager (RMCM) subsystem (responsible for tracking the state of the agents and contacts active in the system)

Database: The UCCX database component consists of four data stores: ■

Agent Data Store (ADS): Composed of statistics, logs, and pointers to recordings

■

Configuration Data Store (CDS): Contains information pertinent to resources (agents), skills, teams, and queues

■

Historical Data Store (HDS): Contains Contact Call Detail Records (CCDR)

■

Repository Data Store (RDS): Contains prompts, grammar, and documents

Monitoring: Monitoring is used for remote monitoring, where a supervisor calls into a script that allows monitoring of an agent’s call. It can be based on desktopbased monitoring such as CAD to Cisco Supervisor Desktop (CSD) or Switched Port Analyzer (SPAN) port monitoring.


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.


212


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.


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 caller’s input of either DTMF signaling or speech, respectively. Table 8-3 lists basic and advanced IVR functions available with UCCX. Table 8-3

UCCX IVR Functions

IVR Function

Functionality

Description

Prompt and Collect 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.


214


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


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.


216


Step 2.

The voice gateway routes the call to a call-control agent; for example, CUCM using MGCP, H.323, or SIP.

Step 3.

Using Dialed Number Identification Service (DNIS)/dialed number for the call, CUCM matches a CTI route point (RP) associated with a UCCX JTAPI user, and a JTAPI route request is sent to UCCX.

Step 4.

Upon receiving the request from CUCM, UCCX selects a CTI port and responds back to CUCM with the directory number/extension so that CUCM can send a setup message to UCCX corresponding to a specific script/trigger. The call is answered by the script, and an RTP stream is established between the designated CTI port on UCCX and the voice gateway.

Step 5.

If the script allows for auto-service menu, the user is prompted for data (DTMF input) and given the required level of service. A script may also lead to a caller connecting to an agent, in which case the call is queued in the Contact Service Queue (CSQ) until an agent becomes available.

Step 6.

When an agent logs in or concludes the previous call, UCCX reserves the agent and initiates a call transfer to that agent’s IP Phone’s extension. CUCM rings the agent’s IP Phone and consequently UCCX may signal a CTI screen pop (CAD) on the agent’s desktop with call-related information (from the external user information database).

Step 7.

When the agent answers the call, the call transfer is completed and an RTP stream is established between the agent’s IP Phone and the voice gateway.

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


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 windows—System Parameters Configuration and Languages—and make the appropriate selections as per your deployment. When you reach the Desktop Client Configuration Tool message, click OK.

Step 8.

In the User Configuration window, select the CUCM users that require administrative rights on the UCCX server.

Step 9.

Log in to the UCCX server with the username and password defined in Step 8. Go to Subsystems > Cisco Unified CM Telephony > Call Control Group. Click Add New and provide the required details as shown in Figure 8-4. Click Add. This creates CTI ports on the CUCM server/cluster with provided parameters.

At this time, the UCCX integration with CUCM is complete, including the AXL, CTI, and RMCM subsystems and the creation of CTI ports on CUCM. However, the UCCX administrator still needs to configure the following: ■

Skills

■

Assign skills to CSQs

■

Assign phones to users

■

Associate UCCX extensions (IPCC extension)

■

Assign skills to the users (resources)

Additionally, the UCCX administrator must create scripts and applications to handle incoming calls from CUCM to UCCX and provide IVR/agent transfer functionality.


218


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.


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.


220


■

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


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.


General

Goto, Label

Jumps to any label in the script.


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.



Palette

Step

Description

Availability

General

Set

Sets a variable/value.


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.


Session

Set Session

Permits to change Session parameters.


Contact

Accept/Reject/ Terminate

Manages the contact in a script.


Contact

GetContactInfo

Permits to retrieve info.


Contact

SetContact

Permits to change contact information.


Call Contact

Call Consult Transfer

Transfer offers supervised transfer.


Call Contact

Call Redirect

Redirects the call to a specified destination.


Call Contact

Place Call

Places outbound calls.


Call Contact

Call Hold/Unhold

Holds and unholds calls respectively.


Call Contact

Get Call Contact Info

Accesses call-specific information.


Call Contact

Get/Set Enterprise Call Info

Gets or sets CTI data to store in local variables.


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.


eMail Contact Send eMail

Sends an email to an email address.


221



222


Palette

Step

Description

Availability

HTTP Contact Get/Set Contact Info

Manages contact information.


HTTP Contact HTTP Forward/ Include

Launches an internal URI deployed under the document repository.


HTTP Contact HTTP Redirect

Redirects to another website.


HTTP Contact Send HTTP Response

Sends response back to originator.


Media

Play Prompt

Plays prompts (WAV files).


Media

Extended Play Prompt

Creates dynamic prompts Available with all license (Date, Numbers, and so on) options.

Media

Send Digit String

Sends digits.


Media

Menu

Menu management.


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.


User

Get User

Retrieves user.


User

Get/Set User Info

Gets/changes user information.


Prompt

Create Container Prompt

Concatenates prompts.


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.


Grammar

Create Language Grammar

Selects a set of grammars based on the language of the call.




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.


Document

Upload File to UCCX Server

Uploads a document to UCCX server.


Database

DB Get

Connects to a database.


Database

DB Read/Write

Reads/writes data in a database.


Database

DB Release

Releases database access.


ACD

Select Resource

Selects resource to queue for a CSQ or agent.


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.


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



224


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.


Chapter 9

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

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


226

Chapter 9: Cisco IOS Unified Communications Applications



IP WAN

Cisco Unified CME

PSTN Cisco Unified CME


Figure 9-1


Cisco Unified CME–based Telephony Solution

Basic Cisco Unified CME Setup Cisco Unified CME supports both SCCP and SIP phones. For both SCCP and SIP phone registration, certain common configuration is required to set up and initialize Cisco Unified CME, such as Cisco IOS router setup so it can support phone registration and other call-control functions. You must initially extract the Cisco Unified CME bundle (full) into the router’s flash. (The Cisco Unified CME bundle is a set of phone firmware files, media files, and other supporting files that helps set up the Cisco Unified CME 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 router’s flash. For every Cisco Unified CME deployment, DHCP-assigned IP addresses and NTP are required. The Cisco Unified CME router can by itself act as the DHCP server, have DHCP addresses assigned from an external DHCP, or relay DHCP addresses. The Cisco Unified CME router can also act as NTP master or get time from an authoritative time source. Example 9-1 illustrates DHCP and NTP configuration on Cisco Unified CME router (as DHCP server and NTP client). Example 9-1 Cisco Unified CME DHCP and NTP Configuration CMERouter(config)# ip dhcp excluded-address 10.76.108.70 10.76.108.80 ! CMERouter(config)# ip dhcp pool IP-Phones CMERouter(dhcp-config)# network 10.76.108.0 255.255.255.0


Cisco Unified CME–Based SCCP Phone Registration

227

CMERouter(dhcp-config)# default-router 10.76.108.76 CMERouter(dhcp-config)# option 150 ip 10.76.108.76 CMERouter(dhcp-config)# domain-name corp.local CMERouter(dhcp-config)# lease 10 ! CMERouter(config)# clock timezone GMT +5 30 CMERouter(config)# ntp authentication-key 1 md5 C1sc0123 CMERouter(config)# ntp trusted-key 1 CMERouter(config)# ntp source GigabitEthernet 0/1 CMERouter(config)# ntp server 10.76.108.84 key 1 prefer source GigabitEthernet 0/1 version 3 CMERouter(config)# ntp authenticate

Example 9-2 illustrates the setup of Cisco Unified CME web GUI access and 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 CME–Based SCCP Phone Registration SCCP phone registration with Cisco Unified CME is conducted via the following steps: Step 1.

Configure Cisco Unified CME as a TFTP server (for the phones) pointing to the firmware files, as shown in the following configuration snippet: CMERouter(config)# tftp-server flash:/Phones/7945-7965/apps45.9-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


228


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

1

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


009_9780133845969_ch09.indd 228

6/25/14 11:35 AM

Cisco Unified CME–Based SIP Phone Registration

229

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

Cisco Unified CME–Based SIP Phone Registration The steps in the following configuration example show how to register Cisco Unified CME–based SIP phones: Step 1.

Configure Cisco Unified CME as a TFTP server (for the phones) pointing to the firmware files, as shown in the following configuration snippet: CMERouter(config)# tftp-server flash:/Phones/9971/ dkern9971.100609R2-9-4-1-9.sebn alias dkern9971.100609R2-9-4-1-9.sebn CMERouter(config)# tftp-server flash:/Phones/9971/kern9971.9-4-1-9.sebn alias kern9971.9-4-1-9.sebn CMERouter(config)# tftp-server flash:/Phones/9971/rootfs9971.9-4-1-9. sebn alias rootfs9971.9-4-1-9.sebn 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


009_9780133845969_ch09.indd 229

6/25/14 11:35 AM

230


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.


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.


232


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) gateway–based feature that allows administrators to configure redundant call control for sites that do not have a local CUCM server. Cisco IOS gateways support two types of SRST: (traditional) SRST (callmanager fallback) and Cisco Unified CME–based SRST, also known as Enhanced SRST (E-SRST). The major difference between the two types is that traditional SRST has basic telephony features, whereas E-SRST provides an enhanced feature set to the endpoints during SRST mode and Cisco Unified CME syncs with CUCM to get updates when they happen on CUCM. Figure 9-2 depicts a Cisco Unified SRST and Cisco Unified CME SRST solution.

Cisco Unified CME 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

V

Figure 9-2

V

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)


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 CME–based SRST.


234


Example 9-6 Cisco Unified CME–based 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 CME–based SIP SRST. Example 9-7 Cisco Unified CME–based SIP SRST Configuration CMERouter(config)# voice register global CMERouter(config-register-global)# mode srst CMERouter(config-register-global)# source-address 10.76.108.76 port 5060 CMERouter(config-register-global)# max-dn 40 CMERouter(config-register-global)# max-pool 10 CMERouter(config-register-global)# system message SRST Mode

In Example 9-7, the Cisco Unified CME–based SIP configuration has been changed from mode cme to srst. In both SRST and E-SRST, a dial plan is required so that in the absence of CUCM, the router can send and receive calls to and from the PSTN. Example 9-8 shows a basic dial plan for an SRST gateway to accept incoming calls and to enable users to dial NANP emergency, local, national, and international numbers.


009_9780133845969_ch09.indd 234

6/25/14 11:35 AM

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 CME–based SRST, the router has to be defined as an SRST reference in CUCM. To configure an SRST reference, follow these steps: Step 1.

Go to Cisco Unified CM Administration, choose System > SRST, click Add New, and provide the required details about the remote site gateway, as shown in Figure 9-3. Ensure that the SRST gateway’s hostname/IP address is defined and the correct protocol (SCCP/SIP) port is chosen.


236


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.


Multicast Music on Hold in SRST

CUCM Cluster

237

MGCP Application Gateway Fallback Default Application H.323

V

IP WAN

MGCP Gateway with SRST

V

PSTN

V

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


238


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:


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.

[0–9]

Any range or sequence of characters.

*

Modifier-match none or more occurrences.

+

Modifier-match one or more occurrences.

?

Modifier-match none or one occurrence.

\

In the match pattern, indicates where to slice the number, and in the replacement pattern, indicates where to copy the number to keep.


240


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




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






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







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.


242


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


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


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.


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 pattern—for instance, VoIP dial peers to CUCM subscribers for call processing redundancy. In such a case, the preference command can be added to each dial peer to set a priority, with preference 0 being the default and highest preference. Multiple dial peers can be defined with the same destination pattern with preference 1, 2, 3, and so on. Example 9-14 illustrates dial-peer preference configuration. Example 9-14 Cisco IOS Router Dial-Peer Preference Configuration IOSRouter(config)# dial-peer 100 voice voip IOSRouter(config-dial-peer)# description Calls to Primary CUCM IOSRouter(config-dial-peer)# preference 1 IOSRouter(config-dial-peer)# destination-pattern 8... IOSRouter(config-dial-peer)# session-target ipv4:10.76.108.146 IOSRouter(config-dial-peer)# dtmf-relay h245-alphanumeric IOSRouter(config-dial-peer)# no vad ! IOSRouter(config)# dial-peer 101 voice voip IOSRouter(config-dial-peer)# description Calls to Secondary CUCM IOSRouter(config-dial-peer)# preference 2 IOSRouter(config-dial-peer)# destination-pattern 8... IOSRouter(config-dial-peer)# session-target ipv4:10.76.108.147 IOSRouter(config-dial-peer)# dtmf-relay h245-alphanumeric IOSRouter(config-dial-peer)# no vad


244


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 CUCM’s MRGLs. Following are some useful commands to monitor DSP resources: ■

show voice dsp active

■

show voice dsp group all

■

show voice dsp sorted-list

■

show voice dsp capabilities

■

show voice dsp group

■

show voice dsp statistics


Cisco IOS Media Resources

245

Cisco IOS Conferencing Resources CUCM provides a conferencing facility for ad hoc and Meet-Me conferences (as 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 application—from conferencing to transcoding to MTP—and sets the maximum participants per session and maximum sessions, sets the codecs acceptable during conference calls, and associates the SCCP application to the profile. Note that the same configuration framework is needed for Cisco Unified CME conferencing.


246


Cisco IOS Transcoding Resources A Cisco IOS gateway’s DSPs can be leveraged for transcoding and as MTP resources, as discussed in Chapter 4. Example 9-16 shows the configuration of an SCCP group and a DSP profile for enabling transcoding resources on a Cisco IOS gateway (building on Example 9-15). Example 9-16 Cisco IOS Transcoding Configuration IOSRouter(config)# sccp ccm group 1 IOSRouter(config-sccp-ccm)# bind interface GigabitEthernet 0/1 IOSRouter(config-sccp-ccm)# associate ccm 1 priority 1 IOSRouter(config-sccp-ccm)# associate profile 2 register HWXCD IOSRouter(config-sccp-ccm)# switchback method graceful ! IOSRouter(config)# dspfarm profile 2 transcode IOSRouter(config-dspfarm-profile)# codec g711ulaw IOSRouter(config-dspfarm-profile)# codec g711alaw IOSRouter(config-dspfarm-profile)# codec g729ar8 IOSRouter(config-dspfarm-profile)# codec g729abr8 IOSRouter(config-dspfarm-profile)# maximum sessions 20 IOSRouter(config-dspfarm-profile)# associate application SCCP IOSRouter(config-dspfarm-profile)# no shut

In Example 9-16, the SCCP CCM group is used to bind profile 2 (the transcoding profile) and register it as HWXCD with CUCM/Cisco Unified CME. The DSP profile transcoding allows SCCP to control the DSP resources and set up transcoding for various code types. Note that the same configuration framework is needed for Cisco Unified CME transcoding.

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

Cisco Unified CME Conferencing and Transcoding Conferences in Cisco Unified CME can be supported using software or hardware 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


Cisco Unified CME–Based Media Resources

247

endpoints using multiple codecs, hardware conference bridges support transcoding as well as conferencing. For conference bridges to work, DNs need to be configured to act as bridges with the ad hoc/Meet-Me feature enabled. These special DNs cannot be assigned to ephones or have other features enabled. Moreover, conference DNs must be dual-line or octo-line to support multiple participants. Cisco Unified CME supports two types of conferences: ad hoc and Meet-Me conferences. Similar to CUCM ad hoc conference calls, the 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 CME–based 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


248


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

1

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


Cisco IOS–Based 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 IOS–Based Call Queuing Cisco IOS routers provide basic call queuing and self-service functionality thanks to TCL scripts and hunt groups. This section covers Cisco IOS–based call queuing mechanisms.

Cisco Unified CME Basic Automatic Call Distribution Cisco Unified CME provides a basic Interactive Voice Response (IVR)/Auto-Attendant (AA) feature for sites that do not have a local Cisco Unity Express (CUE), Cisco Unity Connection (CUC), or UCCX server. This feature is known as Basic Automatic Call Distribution (B-ACD) and it can provide basic call handling and some self-service options for incoming calls to a Cisco Unified CME. B-ACD can be used as a backup for UCCX/ IPCC when the link between the main and remote site is down, to provide basic IVR/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).


250


Assuming that B-ACD scripts have been downloaded and extracted to Cisco Unified CME flash, the following steps are required to configure CME B-ACD: ■

Setting up call queuing and AA services

■

Setting up ephone hunt groups

■

Setting up incoming dial peers for AA pilot numbers

The B-ACD 3.0.0.2 script tar file can be downloaded from http://software.cisco.com/ download/release.html?mdfid=277641082&catid=278875240&softwareid=283451126& release=8.8&relind=AVAILABLE&rellifecycle=&reltype=latest. Example 9-18 shows B-ACD–based AA configuration. Example 9-18 Cisco Unified CME–based B-ACD Script CMERouter(config)# application CMERouter(config-app)# service callqueue flash:/scripts/app-b-acd-3.0.0.2.tcl CMERouter(config-app-param)# param queue-len 10 CMERouter(config-app-param)# param aa-hunt1 8888 CMERouter(config-app-param)# param 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



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 application’s pilot number, which must match the VoIP and/or POTS dial peer incoming called number (this can be translated to the AA pilot number via translation profiles). Next, Example 9-18 uses voice-mail to set the voicemail number and max-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


009_9780133845969_ch09.indd 251

6/25/14 11:35 AM

252


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



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 call—that is, n + 1, with n being the last number to answer the call. For example, in a hunt group with members 8001, 8002, 8003, and 8004, if 8003 answered the last call, then hunting will begin at 8004.

■

Longest Idle: As the name suggests, the starting point in the list for a new call is set by the number that has been on-hook for the longest period of time. The number of hops can be defined to allow a call to hop to longest-idle number before the call is sent to final destination.

■

Parallel: All the numbers in the group rings simultaneously (also known as Call Blast, covered in the next section).

To configure a voice hunt group, use the following command: CMERouter(config)# voice hunt-group 1 [longest-idle | parallel | peer | sequential ]

Call Blast Call blast, also known as parallel hunt group, allows a user to dial a pilot number that rings two to ten different extensions simultaneously. Call blast is analogous to the 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


254


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


Cisco Unified CME and CUE Integration

255

CMERouter(config-if)# service-module ip address 10.76.108.79 255.255.255.0 CMERouter(config-if)# service-module ip default-gateway 10.76.108.76 ! CMERouter(config)# ip route 10.76.108.79 255.255.255.255 ISM0/0

In Example 9-21, the voicemail number defined under telephony-service enables the users to press the voice messaging (envelope) button and get to voicemail. The MWI On and Off numbers are defined as a kind of prefix such that these On or Off numbers can be prefixed to the extension for which MWI must be turned on or off. SIP dial-peer 8100 points to the CUE module’s IP address with the VM number as the destination pattern. SIP dial-peer 8111 enables Cisco Unified CME to accept incoming MWI requests from CUE and appropriately light up or switch off the MWI on a phone. The CUE interface (Integrated Service Module [ISM] in this case) is bound with the Cisco Unified CME’s interface, with the latter’s interface IP set as the default gateway for CUE, and a static route points the way to the CUE module via the CLI or GUI. In addition to the configuration in Example 9-21, CUE should be configured for 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 , 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"


256


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


CUE Message Waiting Indicator

257

(SIP) Subscribe Notify CUE can be configured to send the NOTIFY message to Cisco Unified CME when phones are subscribed to receive MWI updates using the SUBSCRIBE message. SIP Notify is used to tell Cisco Unified CME to light the lamp for a particular extension. This mechanism is employed for SIP phones. However, SCCP phones can also utilize this mechanism. The Subscribe - Notify option can be used concurrently with the Outcalling option. To configure the Subscribe - Notify mechanism in Cisco Unity Express Administration, choose Voice Mail > Message Waiting Indicators > Settings and check the Subscribe – Notify check box. Also, check the Include Envelope Information in the Notifications check box. Example 9-23 outlines SIP and SCCP phones using the Subscribe - Notify mechanism. Example 9-23 CUE SIP Notify–based MWI CMERouter(config)# sip-ua 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


258


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:///user/. Users can listen to, save, delete, and compose voicemail messages and greetings through the CUE Web Inbox GUI interface. Users can manage all of the following mailbox settings via CUE Web Inbox: ■

Compose, reply, and forward voice mails

■

Use the inline recording tool

■

Upload a prerecorded message

■

Change message properties: Urgent, Private

■

Set messages for future message delivery

■

Manage all eight greetings (Standard, Internal, Closed, Busy, Alternate, Meeting, Vacation, Extended Absence)

■

Manage notification devices and cascading settings

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

Go to Cisco Unity Express Administration and choose Voice Mail >VoiceView Express >Service Configuration. Ensure that the Enable VoiceView Express check box is checked, as shown in Figure 9-6.


CUE Auto-Attendant

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.


260


Figure 9-7 CUE AA Configuration Alternatively, you can configure the AA parameters from the CUE CLI. The default AA script is preconfigured in the CUE CLI and you can see the parameters/details by using the command CUE# show ccn application aa. Example 9-24 shows configuration of AA script. Example 9-24 CUE AA Configuration via CLI CUE(config)# ccn application autoattendant aa Modifying existing application CUE(config-application)# description "autoattendant" CUE(config-application)# enabled CUE(config-application)# maxsessions 10 CUE(config-application)# script "aa.aef" CUE(config-application)# parameter "dialByExtnAnytime" "true" CUE(config-application)# parameter "busOpenPrompt" "AABusinessOpen.wav" CUE(config-application)# parameter "dialByExtnAnytimeInputLength" "4" CUE(config-application)# parameter "operExtn" "8900" CUE(config-application)# parameter "welcomePrompt" "AAWelcome.wav" CUE(config-application)# parameter "disconnectAfterMenu" "false" CUE(config-application)# parameter "dialByFirstName" "false" CUE(config-application)# parameter "busClosedPrompt" "AABusinessClosed.wav"


009_9780133845969_ch09.indd 260

6/25/14 11:35 AM

CUE Scripting

261

CUE(config-application)# parameter "allowExternalTransfers" "false" CUE(config-application)# parameter "holidayPrompt" "AAHolidayPrompt.wav" CUE(config-application)# parameter "businessSchedule" "systemschedule" CUE(config-application)# parameter "MaxRetry" "3" CUE(config-application)# end application

Finally, Cisco Unified CME needs to redirect calls to a predetermined AA number to CUE, as shown in Example 9-25. Example 9-25 Cisco Unified CME to CUE SIP Dial Peer CMERouter(config)# dial-peer 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.


009_9780133845969_ch09.indd 261

6/25/14 11:35 AM

262


■

The Auto-Attendant menu is played for normal business hours: ■

1: Dial 8010 for Sales (transfer to extension 8010)

■

2: Dial 8011 for Customer Service (transfer to extension 8011)

■

3–8: Unassigned

■

9: Dial by Extension

■

0: Operator (transfer to extension 8999)

■

The Auto-Attendant menu is played for closed business hours.

■

The caller can press 1 to leave a message in operator (general) voicemail (transfer to voicemail box 8999).

■

A goodbye prompt is played at the end of the conversation.

The Windows-based script editor allows you to create scripts on a PC (independent of CUE). After you create scripts, you can upload them to and configure them on CUE. Figure 9-9 depicts the Windows-based script editor.

Figure 9-8

CUE Script Editor: Customized Script


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.


264


The following terms are important in the context of VPIM: ■

Location: Represents a Cisco Unity Express or CUC system in a VPIM network. A location must be defined for the local system and for a remote system participating in VPIM networking. A location may send a vCard for a message targeted for a user on a remote system.

■

Directory Entries: Provide spell-by-name and spoken-name confirmation. CUE supports Static entries (Local users and manually defined Remote users), Dynamic entries (LRU Cache), and No entries (uses Blind Addressing).

■

Least Recently Used (LRU) cache: When a system shares its location information with a remote system, it allows the remote system to cache the information of the sender. This cache is known as the LRU cache. The remote system references cached information to address messages coming from VPIM networked system. It’s 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 user’s extension and location must be used to address the message.

To configure CUE to CUC VPIM networking, follow these steps: Step 1.

In Cisco Unity Express Administration, choose Configure > Network Locations and click Add. Add a location and enter the required details such as location name, abbreviation, domain name/IP address, VPIM broadcast ID, and so on, as shown in Figure 9-10.

Step 2.

Create a local location for the local CUE server followed by one or more remote locations for CUC or CUE servers that will participate in VPIM. Ensure that the local location is assigned as the local location by clicking the location, typing the location ID in the Local Location ID field (as shown in Figure 9-11), and then clicking Apply.

Step 3.

Navigate to Configure > Remote Users and click Add. Provide the required details such as user ID, first and last name, primary extension, display name, and remote location.

Step 4.

Go to Cisco Unity Connection Administration and choose Networking > VPIM (assuming that an SMTP server is configured in CUC). Add a new 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.


CUE Voice Profile for Internet Email

Figure 9-10

CUE VPIM Location Definition

Figure 9-11

CUE Local and Remote VPIM Location Definition

265


266


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 doesn’t happen pertinent to voice/video calls. In other words, CAC ensures that too many voice calls are not allowed across the network on a WAN link, and that voice calls are admitted to the network only as long as


Cisco IOS Call Admission Control

267

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

Local CAC

■

Reservation-based CAC

■

Measurement-based CAC

Local CAC Local CAC is based on a device’s local determination, such as the state of an outgoing interface or link. The different mechanisms that are part of local CAC are ■

max-connections: Allows a dial peer to enforce a maximum connection limit on a VoIP or POTS dial peer. The command max-conn puts limits on active connections through a dial peer.

■

Local Voice Busyout (LVBO): Allows PBX trunks connected to a voice gateway to be taken out of service when WAN conditions are not suitable for voice transport. LVBO allows a gateway to monitor up to 32 interfaces and provides the ability to monitor the state of network interfaces, including both LAN and WAN, and thereby busy out trunks to the PBX if any of the monitored links fails. LVBO can be implemented under voice ports (T1/E1) by using the command busyout monitor .

■

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 .

Reservation-Based CAC Reservation-based CAC is based on the reservation or calculation of required resources before a call can be admitted. RSVP (discussed in Chapter 4), CUCM locations-based CAC (LCAC), and gatekeeper zone–based CAC are types of reservation-based CAC. Example 9-26 shows configuration of a gatekeeper zone–based CAC. Example 9-26 Gatekeeper Zone–Based CAC GKRouter(config)# gatekeeper GKRouter(config-gk)# zone local CUCMGK corp.local 10.10.1.180 GKRouter(config-gk)# zone remote CMEGK corp.local 10.10.2.180 GKRouter(config-gk)# zone prefix CUCMGK 1* GKRouter(config-gk)# gw-type-prefix 1#* default-technology GKRouter(config-gk)# bandwidth session zone CUCMGK 256 GKRouter(config-gk)# bandwidth total zone CUCMGK 2048


268


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 protocol–based accounting for CDRs.

■

RADIUS: RADIUS-based CDR accounting


Cisco IOS CDR Accounting

269

File Accounting The file accounting method is the simplest to set up and enables you to specify one of three formats for CDR data: ■

Detailed: All attributes are sent.

■

Compact: Minimal attributes are sent based on options available with the cdr-format compact command.

■

Customized: Accounting templates can be built as required.

A central FTP server or site-specific FTP server (preferred for SRST scenarios) is required to receive CSV files from the router. Example 9-27 outlines the configuration for the file accounting method. Example 9-27 File Accounting–based CDR Accounting Router(config)# gw-accounting file Router(config-gw-accounting-file)# primary ftp 10.96.108.100 username cdradmin password 0 C1sc0123 Router(config-gw-accounting-file)# cdr-format compact Router(config-gw-accounting-file)# maximum buffer-size 10 Router(config-gw-accounting-file)# maximum retry-count 5 Router(config-gw-accounting-file)# maximum fileclose-timer 30 Router(config-gw-accounting-file)# maximum cdrflush-timer 300

In Example 9-27 the router is set up for file accounting, with the primary FTP server and credentials defined. The CDR format is kept at compact (regular set of VSAs) with the CDR buffer size set to 10, the file close timer set to 30 minutes, and the CDR flush timer set to 300 minutes. The retry interval (keepalive) for the primary server is set to five tries.

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


270


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 Forwarder—that is, configuring a Cisco IOS router to support Cisco SAF clients (CUCM and CUCME). Figure 9-13 depicts the SAF client–forwarder relationship and various protocols and entities involved in a SAF network. Example 9-29 builds on Figure 9-13 by showing the configuration of SAF and CCD on a Cisco IOS router. Example 9-29 SAF and CCD Configuration on IOS Router SAFRouter(config)# router eigrp SAF SAFRouter(config-router)# service-family ipv4 autonomous-system 100 SAFRouter(config-router-sf)# neighbor 10.76.108.235 loopback 0 remote 10 SAFRouter(config-router-sf)#topology base SAFRouter(config-router-sf-topology)#external-client CUCM-Cluster1 SAFRouter(config-router-sf)# sf-interface GigabitEthernet 0/0


Cisco Service Advertisement Framework and Call Control Discovery

271

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

CUCM Cluster (SAF External Client)

CCD

SAF Client Protocol

SAF Publish/ Advertise SAF Forwarding Protocol SAF Network SAF Notify

SAF Forwarder

SAF Forwarder

(Adjacent Neighbors)

Figure 9-13

SAF Client–Forwarder Relationship and SAF Network


272


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 won’t form a neighbor relationship unless these values match between forwarders. The sf-interface command (a default command that allows SAF on all interfaces) permits a specific interface, thereby limiting SAF to a particular interface. SAF authorizes multiple service topology databases per service-family, in this case 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 IOS–based feature that is available in Cisco Integrated Services Routers Generation 2 (ISR G2) and Cisco Aggregation Services Routers (ASR) platforms and enables organizations to consume SIP trunking services (primarily) from a SIP service provider/IT service provider (SIP SP/ITSP) network. CUBE provides the following functionality and services: ■

A security demarcation (border) between the trusted enterprise network and 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.


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 1006—for example, two route processors (Active/Standby) within the same chassis. Software-based redundancy is supported with Cisco ASR 1001, 1002, and 1004 Series, wherein two instances of Cisco IOS run on the same route processor.

■

Box-to-box redundancy (Layer 2): Uses Hot Standby Router Protocol (HSRP) and the underlying switching infrastructure to form an Active/Standby pair of routers. Inheriting the HSRP feature, the Active/Standby pair shares the same virtual IP (VIP) address and persistently exchanges keepalive messages. The two physical chassis can be placed in the same data center or can be geographically separated (provided Layer 2 SLAs are met). Box-to-box redundancy is available for Cisco ISR G2 and Cisco ASR 1001, 1002, 1004 and 1006, and supports stateful failover.

■

Clustering (with load balancing): Offers both high availability and scalability by spreading calls across different chassis in the same data center or geographically separated sites. Clustering allows multiple CUBE routers (ASRs and ISRs) to perform load balancing as a SIP proxy manages call distribution across the cluster.

CUBE box-to-box high availability is covered in this section. Figure 9-14 shows the CUBE chassis (ISR G2 router) deployed in a box-to-box redundancy configuration using HSRP. Inside

Outside Active CUBE

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.


009_9780133845969_ch09.indd 273

6/25/14 11:35 AM

274


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



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


276


! 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



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 provider’s or organization’s policies

Figure 9-15 illustrates the concept of SIP profiles. SIP INVITE Sent By CUBE Sent: INVITE sip:[email protected]:5060 SIP/2.0 ......... User-Agent: Cisco-SIPGateway/IOS-15.2.3.T ......... Diversion: ; 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:[email protected]:5060 SIP/2.0 ......... User-Agent: Cisco CUCM9.1/IOS-15.2.3T ......... Diversion: ; 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


278


Pertinent to Figure 9-15, the following are requirements of the SIP SP: ■

Condition 1: For call forward and transfer scenarios back to the PSTN, the diversion header should match the registered DID (E.164 number).

■

Condition 2: The User-Agent (UA) field in all SIP messages should state the version of CUCM and CUBE.

The SIP INVITE sent by CUBE needs to be normalized so that the SP network can accept the incoming SIP INVITE as per the configuration of the SP softswitch. In this case a SIP profile needs to be defined to help normalize diversion headers to an E.164 number and set the UA field to the correct CUCM and CUBE version. Example 9-32 illustrates the CUBE SIP profile that supports both normalization tasks (SIP INVITE and REINVITE diversion header and SIP UA description). Example 9-32 CUBE SIP Normalization Profile CUBE(config)# voice class sip-profiles 1000 CUBE(config-class)# request INVITE sip-header Diversion modify "sip:(.*>)" "sip:[email protected]" CUBE(config-class)# request REINVITE sip-header Diversion modify "sip:(*.>)" "sip:[email protected]" CUBE(config-class)# request ANY sip-header User-Agent modify "User-Agent:(.*)" "User-Agent: CUCM 9.1/IOS-15.2.3T"

The SIP profile can be applied at a global level under voice service voip or can be applied to an SP-facing dial peer (dial-peer specific), as shown in Example 9-33. Example 9-33 CUBE SIP Profile Global and Dial-Peer Specific Application CUBE(config)# voice service voip CUBE(conf-voi-serv)# sip CUBE(conf-serv-sip)# sip profiles 1000 ! CUBE(config)# dial-peer voice 1000 voip CUBE(config-dial-peer)# description Calls To/From SP CUBE(config-dial-peer)# voice-class sip profiles 1000 CUBE(config-dial-peer)# codec g711ulaw

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



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.


280


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



SIP

SIP

H323

H.323


H323

281

SIP

H.245KPML Alphanumeric H.245-Signal

KPML


It’s important to note that DSPs are required only for the voice in-band to RFC 2833 DTMF conversion. Also, CUBE supports DTMF interworking to enable a delay between the dtmf-digit begin and dtmf-digit end events in the RFC 2833 packets or to generate RFC 4733– compliant rtp-nte packets. The command dtmf-interworking has the following options: ■

rtp-nte: Used to introduce a delay between the dtmf-digit begin and dtmf-digit end events in the RFC 2833 packet if the remote system cannot handle RFC 2833 packets sent in a single burst. This option is available under (global) voice service voip and dial-peer.

■

standard: Generates RFC 4733–compliant packets. This option is available under (global) voice service voip and dial-peer.

■

system: Enables global-level dtmf-interworking configuration (derived from voice service voip). This is the default configuration under dial-peer. This option is 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-INVITE–based 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.


282


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]


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.


010_9780133845969_ch10.indd 283

6/25/14 11:39 AM

284

Chapter 10: Cisco Collaboration Network Management

■

2 – Replication is good: Logical connections are established and tables match the other servers on the cluster.

■

3 – Tables are suspect: Logical connections are established, but tables don’t match.

■

4 – Database Setup Failed/dropped: The server no longer has an active logical 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.


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.


286


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.


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.


288


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 service–enabled server), and set the CDR Enabled Flag to True. Additionally, the Enterprise Parameter CDR File Time Interval can be set for an external CDR (third-party) server. This parameter sets the time interval for collecting CDR data via an external CDR server. CMR can also be enabled via CUCM service parameters by browsing to System > Service Parameters, selecting CUCM Service, and setting the Call Diagnostics Enabled parameter to either Enabled Only When CDR Enabled Flag Is True or Enabled Regardless of CDR Enabled Flag. CUCM creates a CDR flat file for each end-to-end call and two CDR files for a conference call. Because flat files are fixed-length files, one CDR flat file can contain the data


CUCM Disaster Recovery

289

of more than one call. The CDR agent service pushes flat files from call processing subscriber(s) to the CDR Repository Manager on the publisher node. CUCM also 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//. 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


290


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


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


292


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:///ucmuser. CUCM users can be added or details can be modified in bulk using Bulk Administration Tool (BAT). BAT provides multiple options such as Users, Phones and Users, Manager/Assistants, and User Device Profile for various user-related operations. The Cisco Collaboration network’s user management automation and associated tasks can also be achieved by utilizing Prime Collaboration Provisioning (part of Cisco Prime Collaboration Suite). User management can be 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 consumers—for 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).


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)


294


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

1

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/


Cisco EnergyWise

Interface ---------

Role

Name

Usage

Category --------

Lvl

Imp

295

Type

----

----

-----

---

---

----

WS-C3750E-24PD

UCSwitch-1

101.0 (W) consumer

10

1

parent

Gi1/0/3

IP Phone 9971

SEP64AE0CF66C0D

7.5 (W)

consumer

10

1

PoE

Gi1/0/5

IP Phone 9971

SEP10BD18DC97F5

7.1 (W)

consumer

10

1

PoE

Gi1/0/6

IP Phone 9951

SEPE84040A24BBD

6.0 (W)

consumer

10

1

PoE

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



CCIE COLLABORATION QUICK REFERENCE cisco press.pdf

Recommend Documents