You are on page 1of 634

Table of Contents POP-1

Volume 1

Course Introduction
1
Overview
1
Learner Skills and Knowledge
3
Course Goal and Objectives
4
Course Flow
5
Additional References
5
Cisco Glossary of Terms
6
Your Training Curriculum
1-1
Multisite Deployment Implementation
L Overview
1-1
1-1
Module Objectives
1-3
Identifying Issues in a Multisite Deployment
1-3
Objectives
1-4
Multisite DeploymentIssues Overview
1-6
Quality Issues
1-7
Quality Issues Example: Jitterand Packet Drops
1-8
Bandwidth Issues
1-8
Example: Bandwidth Issues
Bandwidth Issues Example: Voice and DataTraffic Competing for Bandwidth 1-9
Bandwidth Issues Example: Load Caused by Centralized Media Services 1-10
1-11
Availability Issues
1-12
Availability Issues Example: IP WAN Failure
1-13
Dial Plan Issues
Example: Variable-Length Numbering, E.164 Addressing, and DID 1-16
1-17
Fixed vs. Variable-Length Numbering Plans
Detection of End of Dialing in Variable-Length Numbering Plans 1-18
Optimized Call Routing and PSTN Backup 1-20
1-21
Example: TEHO
Example: Overlapping and Nonconsecutive Numbers 1-22
jm 1-23
Various PSTN Requirements
Issues Caused by Different PSTN Dialing 1-25

Dial Plan Scalability Issues 1-26


NAT and Security Issues 1-28
Example: NAT Security Issues 1-29
1-30
Summary
References 1-30

L identifying Multisite Deployment Solutions „ 1-31


1-31
Objectives
Multisite Deployment Solution Overview 1-32
QoS 1-33
mm QoS Advantages 1-34
Solutions to Bandwidth Limitations 1-35
Low-Bandwidth Codecs and RTP-Header Compression 1-37
Codec Configuration in Cisco Unified Communications Manager 1-38
Disabled Annunciator 1-39
Local vs. Remote Conference Bridges 1-40
Transcoders 1-41
Guidelines for Transcoder Configuration 1-42

Mixed Conference Bridge 1-44


Multicast MOH from Branch Router Flash 1-45
Multicast MOH from Branch Router Flash Example 1-47
Multicast MOHfrom Branch Router Flash: Cisco IOS Configuration Example 1-49
Alternatives to Multicast MOH from Branch Router Flash 1-50
Preventing Too Many Calls by CAC 1-51
Availability 1-52
PSTN Backup 1-53
MGCP Fallback; Normal Operation 1-54
MGCP Fallback: Fallback Mode
1-55
Fallback for IP Phones; Normal Operation 1-56
Fallback for IP Phones: Fallback Mode 1-57
Using CFUR toReach Remote-Site IP Phones Over the PSTN During WAN Failure 1-58
Using CFUR to Reach Usersof Unregistered Software IP Phones on Their Cell Phones 1-59
Automated Alternate Routing 1-60
Mobility Solutions 1-61
Dial Plan Solutions 1-62
Dial Plan Components in Multisite Deployments 1-64
Globalized Call-Routing Overview 1-65
Globalized Call Routing—Three Phases 1-68
Globalized Call Routing Advantages 1-70
NAT and Secunty Solutions 1-72
Cisco Unified Border Element in Flow-Through Mode 1-73
Summary 1-74
References
1-75
Implementing Multisite Connections 1-77
Objectives 1-77
Multisite Connection Options 1-78
Cisco Unified Communications ManagerConnection Options Overview 1-79
Cisco IOS Gateway Protocol Functions Review 1-80
Cisco IOS Gateway Protocol Comparison Review 1-81
SIP Trunk Characteristics 1-82
H.323 Trunk Overview 1-83
H 323 Trunk Comparison 1-84
MGCP Gateway Implementation Review 1-86
Cisco IOS Gateway MGCP Configuration Methods Review 1-87
Configuring Cisco IOS Gatewayfor MGCP—Example 1-89
H.323 Gateway Implementation Review 1-91
Cisco Unified Communications Manager H.323 Gateway Configuration 1-93
Cisco IOS H.323 Gateway Configuration 1-94
Trunk Implementation Overview 1-95
Gatekeeper-Controlled ICT and H.225 Trunk Configuration Overview 1-96
Trunk Types Used by Special Applications 1-97
SIP Trunk Implementation 1-98
Intercluster and H.225 Trunk Implementation 1-100
Cisco Unified Communications Manager Gatekeeper-Controlled ICT and H.225 Trunk
Configuration 1-102
Summary 1-105
References 1-105
Implementing a Dial Plan for International Multisite Deployments 1-107
Objectives 1-107
Multisite Dial Plan Overview 1-108
Dial Plan Requirements for Multisite Deployments with Distributed Call Processing 1-109
Dial Plan Scalability Solutions 1-110
Implementing Site Codes for On-Net Calls 1-112
Digit Manipulation Requirements for UsingAccess and Site Codes 1-113
Centralized Call-Processing Deployments: Access and Site Codes 1-114
Implementing PSTN Access in Cisco IOS Gateways 1-115
PSTN Access Example 1-116
ISDN TON 1-117
Example: ISDN TON—Calling NumberTransformation of Incoming Call 1-118
Implementing Selective PSTN Breakout 1-119
Configuring IP Phones to Use Local PSTN Gateway 1-120
Implementing PSTN Backup for On-Net Intersite Calls 1-121
DigitManipulation Requirements for PSTN Backup of On-Net Intersite Calls 1-122

ImplementingCisco Unified Communications Manager. Part 2 (CIPT2)v8.0 )2010 Cisco Systems, Inc.
Implementing TEHO ]_J24
Considerations for Using Remote PSTN Gateways - l-i«
TEHO Example Without Local Route Groups 1"127
mm TEHO Example with Local Route Groups 1"129
Implementing Globalized Call Routing ]-] 31
Globalized Call Routing: Number Formats 1-133
Normalization ofLocalized Call Ingress onGateways 1-136
mm Normalization of Localized Call Ingress from Phones 1-137
Localized Call Egress atGateways 1-138
Localized Call Egress at Phones 1-140
&. Globalized Call-Routing Example: Emergency Dialing 1-142
mm Considering Globalized Call-Routing Interdependences 1-146
Globalized Call Routing—TEHO Advantages 1-147
Globalized Call Routing—TEHO Example 1-148
* Summary I'ltn
mm References I Icl*
Module Summary ,
References 1-151
fk. Module Self-Check 1'153
'§m Module Self-Check Answer Key 1'158
Centralized Call-Processina Redundancy Implementation 2^
m- Overview 2-1
Me Module Objectives 2-1
Examining Remote Site Redundancy Options 2^
^. Objectives 2"3
^^ Remote Site Redundancy Overview 2-4
^m Remote Site Redundancy Technologies 2-5
When to Use MGCP Fallback 2-6
When to Use Cisco Unified SRST 2-7
f When to Use Cisco Unified Communications Manager Express inSRST Mode 2-9
•* Cisco Unified SRST Operation 2-10
Cisco Unified SRST Function: Switchover Signaling 2-11
Cisco Unified SRST Function: Call Flow After Switchover 2-12
f Cisco Unified SRST Function: Switchback 2-13
** Cisco Unified SRST Timing 2-14
MGCP Fallback Operation 2-15
MGCP Gateway Fallback: Switchover 2-16
* MGCP Gateway Fallback: Switchback 2-17
mm MGCP Gateway Fallback Process 2-18
Cisco Unified SRST Versions and Feature Support 2-19
Cisco Unified SRST 8.0 Platform Density 2-20
f' Plus (+) Prefix and E.164 Supportin Cisco Unified SRST 2-21
*•' Support for Multiple MOH Sources 2-22
Dial Plan Requirements for MGCP Fallbackand Cisco Unified SRST Scenarios 2-23
Ensure Connectivity for Remote Sites 2-24
** Ensure Connectivity from Main Site UsingCFUR 2-25
*•* CFUR Considerations 2-26
CFUR Interaction with Globalized Call Routing 2-28
CFUR Example WithoutGlobalized Call Routing 2-30
"* CFUR Example with Globalized Call Routing 2-31
<•*» Keeping Calling Privileges Active in SRST Mode 2-32
Cisco Unified SRST Dial Plan Requirements Example 2-33
Summary 2-34
* References 2-34

© 2010 Cisco Systems, Inc. Implementing Cisco Unified Communications Manager, Part2(CIPT2) v8.0
Implementing SRST and MGCP Fallback 2-35
Objectives 2-35
MGCP Fallbackand Cisco Unified SRST Configuration Overview 2-36
MGCP Fallback and Cisco Unified SRST Configuration Requirements 2-37
Cisco Unified Communications ManagerSRST Configuration 2-38
Step 1: SRST Reference 2-39
Step 2: Device Pool 2-40
Cisco IOS Gateway SRST Configuration 2-41
Steps 1 and 2: Enabling Cisco Unified SRST and Setting Cisco Unified SRST IP Address 2^2
Steps 3 and 4: Setting Maximum Directory Numbers and Telephones 2-43
Steps 5 and 6: Setting Maximum Directory Numbers Per Phone and Keepalive Timer 2^J4
Cisco Unified SRST Configuration Example 2-45
Cisco IOS GatewayMGCP GatewayFallback Configuration 2-46
Steps 1 and 2: Enabling MGCP Fallback and Setting Fallback Service 2-47
MGCP Fallback Configuration Example 2-48
Cisco Unified Communications Manager Dial Plan Configuration for SRSTSupport 2-49
Step 1: Define a CSS for CFUR 2-49
Step 2: Setting Max Forward Unregistered Hops to DN 2-50
Step 3: Configuring CFUR 2-51
Cisco IOS GatewayMGCP Fallback and Cisco Unified SRST Dial Plan Configuration 2-53
Additional SRST Dial Plan Requirements 2-54
Cisco Unified SRST Dial Plan Commands: Dial Peer 2-56
Cisco Unified SRST Dial Plan Commands: Open Numbering Plans 2-60
Cisco Unified SRST Dial Plan Commands: Number Modification (Voice Translation Profiles) 2-62
Cisco Unified SRST Dial Plan Commands: Number Modification (Voice Translation Rules) 2-63
Cisco Unified SRST Dial Plan Commands: Number Modification (Profile Activation) 2-64
Cisco Unified SRST Dial Plan Commands: COR 2-65
Cisco Unified SRST Dial Plan Example 2-67
Summary 2-70
References 2-70
Implementing Cisco Unified Communications Manager Express in SRST Mode 2-71
Objectives 2-71
Cisco Unified Communications Manager Express Overview 2-72
Cisco Unified Communications Manager Express in SRST Mode 2-73
When to Use Cisco Unified Communications Manager Express in SRST Mode 2-74
Cisco Unified Communications Manager Express Features 2-78
Important Cisco Unified Communications Manager Express Features 2-79
General Configuration of Cisco Unified CommunicationsManager Express 2-80
Cisco Unified Communications Manager Express: Basic Configuration Example 2-82
Providing Phone Loads 2-83
Cisco Unified Communications Manager Express: MOH 2-84
Additional MOH Sources 2-85
Additional Music on Hold Sources—Configuration Example 2-86
Configuration of Cisco Unified Communications Manager Express in SRST Mode 2-87
Phone Provisioning Options 2-89
Advantages of Cisco Unified Communications Manager Express in SRST Mode 2-90
Phone Registration Process 2-91
Configuring Cisco Unified Communications Manager Express in SRST Mode 2-92
Cisco Unified Communications Manager Express in SRST Mode Configuration Example 2-94
Summary 2-95
References 2-95
Module Summary 2-97
References 2-97
Module Self-Check 2-99
Module Self-Check Answer Key 2-102

Implementing Cisco Unified Communications Manager. Part 2 (CIPT2] v8.0 ©2010 Cisco Systems, Inc
Bandwidth Management and CAC Implementation 3-1

Overview 3-1

Module Objectives 3-1

Managing Bandwidth 3-3

Objectives 3-3
Bandwidth Management Overview 3-4
Cisco Unified Communications Manager Codec Configuration 3-6
Review of Cisco Unified Communications l\ anager Codecs 3-7
Example: Codec Configuration 3-8
Local Conference Bridge implementation 3-10
Example: Implementing Local Conference I ridges at Two Sites 3-11
Transcoder Implementation 3-13
Example: Implementing a Transcoder at the Main Site 3-15
Configuration Procedure for Implementing ranscoders 3-17
Step 1: Add Transcoder Resource in Cisco Jnified Communications Manager 3-18
Step 2: Configure Transcoder Resource in isco IOS Software 3-19
Multicast MOH from Branch Router Flash Implementation 3-21
Multicast MOH from Branch Router Flash: I legion Considerations 3-23
Multicast MOH from Branch Router Flash: , .ddress and Port Considerations 3-24
Multicast MOH: Address and Port Incremer t Example 3-25
Example: Implementing Multicast MOH froi i Branch Router Flash 3-27
Configuration Procedure for Implementing lulticast MOH from Branch Router Flash 3-30
Step 1; Enable Multicast Routing on Cisco OS Routers 3-31
Step 2a: Configure MOH Audio Sources foi Multicast MOH 3-32
Step 2b: Configure Multicast MOH in Cisco|Unified Communications Manager 3-33
Step 2c: Enabling Multicast MOH at the ia Resource Groups 3-34
Step 3: Enable Multicast MOH from Branch!Router Flash at the Branch Router 3-35
Step 4a: Configure the Maximum Hops to Used for MOH RTP Packets 3-36
Step 4b: Use IP ACL at IP WAN Router Ints rface 3-37
Step 4c: Disable Multicast Routing on IP W VN Router Interface 3-38
Summary 3-39
References 3-39

Implementing CAC 3-41

Objectives 3-41
CAC Overview 3-42
CAC in Cisco Unified Communications Manjager 3-43
Standard Locations 3-44
Locations: Hub-and-Spoke Topology 3-45
Locations: Full-Mesh Topology 3-46
Configuration Procedure for Implementing Ijocations-Based CAC 3^17
Locations Configuration Example: Hub-and Spoke Topology 3-48
Step 1: Configure Locations 3-49
Step 2: Assign Locations to Devices 3-50
RSVP-Enabled Locations 3-51
Three Call Legs with RSVP-Enabled Locations 3-52
Characteristics of Phone-to-RSVP Agent Ci II Legs 3-53
Characteristics of RSVP Agent-to-RSVP Agent Call Leg 3-54
How RSVP Works 3-55
Configuration Procedure for Implementing RSVP-Enabled Locations-Based CAC 3-57
Example: RSVP-Enabled Locations Configuration 3-58
Step 1: Configure RSVP Service Parameters 3-59
Step 2: Configure RSVP Agents in Cisco IOS Software 3-63
Step 3: Add RSVP Agents to Cisco Unified Communications Manager 3-65
Step 4: Enable RSVP Between Location Pairs 3-66
Automated Alternate Routing 3-68
AAR Characteristics 3-69
AAR Example Without Local Route Groups and Globalized Numbers 3-70
AAR Example with Local Route Groups and Globalized Numbers 3-72

© 2010 Cisco Systems. Inc. Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0
AAR Considerations 3.74
AAR Configuration Procedure 3-75
Step 1: Configure AAR Service Parameters 3-76
Step 3: Configure AAR Groups 3.77
Step 4: Configure Phones for AAR 3-78
SIP Preconditions 3-80
CAC Without SIP Preconditions 3-81
CAC with SIP Preconditions 3-82
SIP Preconditions Operation 3-83
SIP Preconditions Call Flow Summary 3-85
Fallback from End-to-End RSVP to Local RSVP 3-87
SIP Preconditions Configuration Procedure 3-89
Step 2a: Configure SIP Profile 3-90
Step 2b: Apply SIP Profile to Trunk 3-91
H.323 Gatekeeper CAC 3-92
Example: H.323 Gatekeeper Used for Call Routing (Address Resolution) Only 3-94
Using an H.323 Gatekeeper for CAC 3-96
Example: H.323 Gatekeeper Also Used for CAC 3-98
Providing PSTN Backup for Calls Rejected by CAC 3-100
Configuration Procedure for Implementing H.323 Gatekeeper-Controlled Trunks with CAC 3-102
Summary 3-104
References 3-104
Module Summary 3-105
References 3-105
Module Self-Check 3-107
Module Self-Check Answer Key 3-109

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 ©2010 Cisco Systems, Inc.
CIPT2

Course Introduction

Overview
Implemenling Cisco Unified Communicatioi s Manager, Part 2 (C1PT2) v8.0prepares you for
implementing a Cisco Unified Communications solution in a multisite environment. It covers
globalized call routing.Cisco Service Advertisement Framework (SAF) and Call Control
Discovery (CCD). tail-end hop-off (TEHO), Cisco Unified Survivable Remote Site Telephony
(SRST). and mobility features such as Devi e Mobility and Cisco Extension Mobility.
You will apply a dial plan for a multisite en ironment including TEHO, configure survivability
for remote sites during WAN failure and implement
i solutions toreduce bandwidth
requirements in the IP WAN. You will also mable Call Admission Control (CAC) including
Session Initiation Protocol (SIP) Preconditk ns and automated alternate routing (AAR).

Learner Skills and Knowledge


This subtopic lists the skills and knowledge that learners must possess to benefit fully from the
course. The subtopic also includes recommended Cisco learning offerings that learners should
first complete to benefit fully from this course.
Learner Skills and Knowledge

• Working knowledge of converged voice and data networks


• Working knowledge of the MGCP, SIP, and H.323 protocols
and their implementation on Cisco IOSgateways
• Ability to configure and operate Cisco routers and switches
* Ability to configure and operate Cisco Unified
Communications Manager in a single-site environment

Learner Skills and Knowledge (Cont,)

• Cisco learning offerings:


Implementing Cisco Voice Communications and QoS
(CVOICE) v8.0
Implementing Cisco Unified Communications Manager,
PartT(CIPT1)v8.0

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8 0 >2010 Cisco Systems. Inc
Course Goal and Objectives
This topic describes the course goal and objectives.

"To provide learners with the necessary knowledge and skills


to implement a multisite Cisco Unified Communications
deployment, including new features of Cisco Unified
Communications Manager version 8 0 such as Call Control
Discovery, which is based on the Cisco Service
Advertisement Framework"

!iW!sme'-'i'ng Osco UnfrsdComfrvmcabons Manager, ran 2('CIP[2) v8 0

Uponcompleting this course, you will be able to meet these objectives:


• Describe multisitedeployment issuesand solutions, and describe and configure required
dial plan elements
• Implement call-processing resiliency in remote sitesby using Cisco Unified SRST, MGCP
fallback, and Cisco Unified Communications Manager Express in Cisco Unified SRST
mode

• Implement bandwidth management and CAC to prevent oversubscription of the IP WAN


• Implement Device Mobility and Cisco Extension Mobility
• Describe and implement CCD deployments

© 2010 Cisco Systems. Inc. Course Introduction


Course Flow
This topic presents the suggested flow of the course materials.

Course Flow

s implementation
[Course Introduction [ ; of Features and
. J Multisite Centra Iced Bandwidth 1 AppBcatena far
Aj MJtsite | Deployment CsS-P recessing Management j Multisite
M j Deployment ,. implementation Redundancy and CAC • Deployments
j Implementation , (Cot*.) Implements! on Implementation ; (Cont)
{Cont.) (Cor*) s

CCD

Lunch
Mufti sits Bandwidth
Deployment Management ana
Impiemen tiiofi CAC Implementation;
. MuKsite CCD
(Cont) 8andwkJtn (Cont) j
' ; Deployment (Cont)
M • fmplenientaliort Management Impiementation f
CentrafzerJ and CAC of Features and '
Cal-Processing Implementation Applications for
Redun&ncy Multisite
frnptementation Deplovmerts

The schedule reflectsthe recommended structure for this course. This structure allowsenough
time for the instructor to present the course information and for you to work through the lab
activities. The exact timing of the subjectmaterials and liibs depends on the pace of your
specific class.

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 ©2010 Cisco Systems. Inc
Additional References
This topic presents the Cisco icons and symbols thatareused in this course, as well as
information on where to find additional technical references.

Cisco Icons and Symbols


Cisco Unified Network
Cisco Urified
Communications Cloud
Presence
Manager

Gatekeeper
Cisco Unrty _^^ Cisco Unified
Connection t^H Border Element
Gateway

Cisco Unified
Messaging Voice Router
Gas* a/ Personal
Communicator

Cisco Un ified
Coco Adapt ve Cisco Unified Communications
Secirty Appliance SRST Router Manager Express

Cisco Unified
SAF Enabled Communications
Router Manager Express with
Cisco Unity Express

Cisco Glossary of Terms


For additional information on Cisco terminology, refer to the Cisco Internetworking Terms and
Acronyms glossary of terms at
http;/'docwiki.ciseo.com/wiki.'CatcgoiT:lntcrnctw'orking_"fernis_and_Acronytris_(I'fA).

© 2010 Cisco Systems. Inc. Course Introduction


Your Training Curriculum
This topic presents the training curriculum for this course.

You are encouraged to join the Cisco Certification Community, a discussion forum open to
anyone holdinga valid CiscoCareerCertification (such as CiscoCCIII",CCNA'. CCDA",
CCNP'. CCDP". CCIP". CCVP".or CCSP*). It provides a gathering place for Ciscocertified
professionals to share questions, suggestions, and information about Cisco Career Certification
programs and other certification-related topics. For more information, visit
http://\v\\\\.cisa>.eom;go certifications.

Implementing Cisco Unified Communications Manager,Part 2 (CIPT2) v8 0 © 2010 Cisco Systems, Inc.
Cisco Career Certifications: CCNP Voice

Expand your professional options and advance your career.


Achieve professional-level recognition in voice networking.

Recommended TrawwgThiouBtt
Cisco Leamw*g Partners

implementing Qsco voiceCammunieaBans


and QoS
tmpmmnms Cisco UnlfletS Cormmiricetans
" Manage*. Pa* i
imptormntmg Oseo Unified Communfeafions
Manager, Pari 2
TroiJWMBODflng Cttco Urftea
CamnwrtcaSons ___
'imgn^aseoWllkKlCommunications
Appticatiom
Voice Metw or king
www Cisco com/go/certificatons

Course Introduction
i 2010 Cisco Systems, Inc.
8 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) v8.0 ©2010Cisco Systems, Inc.
Module 1

Multisite Deployment
Implementation
Overview
In a multisite Cisco Unified Communications Manager deployment, special requirements exist
that are not necessary insingle-site deployments. To successfully deploy a multisite Cisco
Unified Communications Manager solution, you need to understand the issues and be aware of
their possible solutions.

This module discusses the issues in a multisite Cisco Unified Communications Manager
deployment, including selective public switched telephone network (PSTN) access and tail-end
hop-off (TEHO).

Module Objectives
Upon completing this module, you will be able to describe multisite deployment issues and
solutions, and describe and configure required dial plan elements.
This ability includes being able to meet these objectives:
• Explain issues pertaining to multisite deployment and relate the issues to multisite
connection options
• Describe solutions for multisite deployment issues
• Configure gateways and trunks in multisite environments
• Implement adial plan to support inbound and outbound PSTN dialing, site-code dialing,
and TL1IO in an international environment
1-2 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems. Inc.
Lesson 1

Identifying Issues in a Multisite


Deployment
Overview
When deploying Cisco Unified Communications Manager in a multisite environment, there are
some unique aspects that pertain only to multisite deployments that you need to consider.
Deploying Cisco Unified Communications solutions among multiple sites requires an
appropriate dial plan, adequate bandwidth between sites, implementation of quality of service
(QoS). and a design that can survive IP WAN failures. This lesson identifies the issues that can
arise in a multisite Cisco Unified Communications Manager deployment.

Objectives
Upon completing this lesson, you will be able to explain issues pertaining to multisite
deployment and relate the issues to multisite connection options. This ability includes bein^
able to meet these objectives:
• Describe issues pertaining to multisite deployments
• Describe quality issues in multisite deployments
• Describe issues with bandwidth in multisite deployments
• Describe availability issues in multisite deployments
• Describe dial plan issues in multisite]dep!oyments
i

• Describe NAT and security issues in multisite deployments


Multisite Deployment Issues Overview
This topic provides an overview about issues pertaining to Cisco Unified Communications
Manager multisite deployments.

Issues in Multisite Deployments


Mam Site

Cisco Unified
Communications
Manager

In a multisite deployment, several issues can arise. Of those issues, here are the most important:
• Quality issues: When real-time traffic like voice or video travels over a packet-switching
network such as an IP network, delay-sensitive packets have to be given priority to avoid
jitter resulting in decreased voice quality
• Bandwidth issues: Cisco Unified Communications solutions can include voice and video
streams, signaling traffic, management traffic, and application traffic, such as rich-media
conferences. The additional bandwidth that is required when deploying a Cisco Unified
Communications solution has to be calculated and provisioned. These tasks ensure thai
classical data applications and Cisco Unified Communications applications do not overload
the available bandwidth. You should optimize bandwidth consumption by eliminating
unnecessary IP WAN traffic.
• Availabilih issues: When you are deploying Cisco Unified Communications Manager
with centralized call processing. IP phones register with the Cisco Unified Communications
Manager over the IP WAN. If gateways in remote sites arc using the Media Gateway
Control Protocol (MGCP) as a signaling protocol, they also depend on the availability of
the Cisco Unified Communications Manager as a call agent. It is important to implement
fallback solutions for IP phones and gateways in scenarios in which the connection to Cisco
Unified Communications Manager is broken because of IP WAN failure.
• Dial plan issues: Directory' numbers are usually unique per site, but they can overlap
across multiple sites. Overlapping directory numbers and other issues,such as numbers that
are not consecutive, have to be solved by the design of a multisite dial plan. Various public
switched telephone network (PSTN)access codes in variouscountries arc anotherexample
of dial plan issues.

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) u8 0 © 2010 Cisco Systems. Inc.
• Network Address Translation (NAT) and security issues: Cisco Unified
Communications Manager and IP phones use IP primarily to communicate within the
enterprise. The use of private IP addresses is very common within the enterprise. When the
system should interact with a public IP network—for instance, when placing calls via an
Internet telephony service provider (ITSP)—then Cisco Unilied Communications Manager
and IP phone IP addresses have to be translated to public IP addresses. This translation
makes them visible on the Internet and, therefore, subject to attacks.

Note The issue of vulnerability when IP addresses are translated to public IP addresses is not
limited to multisite deployments.

)2010 Cisco Systems, Inc. Multisite Deployment Implementation 1-5


Quality Issues
This topic describes quality issues in a Cisco Unified Communications Manager multisite
deployment.

Quality Issues

IP networks are not designed to carry real-time traffic


• Packet-by-packet delivery
• Packets can take different paths.
No guarantee for correct order.
Problem is solved by RTP sequence numbers.
• Bandwidth shared by multiple users and applications
Unpredictable available bandwidth
Dunng peaks, packets need to be buffered in queues.
• Causes variable delays (jitter)
• Packets get dropped in case of buffer congestion.
• Likely on highly loaded links like IP WAN used between sites
in a multisite environment.
Jitter and packet drops impact voice quality

IP networks arc not designed to carry real-time traffic. Because of thenature of the network and
paeket-bv-packet delivery in which each packet could takea different path, there is no
guarantee that packets will arrive in thecorrect order at the destination. You can resolve this
issuebv using Real-Time Transport Protocol (RTP)sequence numbers.
Another issueis the fact that multiple usersand applications share the bandwidth, and the
actual required bandwidth varies significantly evenover short lapses of time. Therefore, the
bandwidth that is available for Cisco Unified Communications Manager traffic is
unpredictable. During peaks, packets need to bebuflered inqueues. Ifthecongestion occurs for
too long, buffers get tilled up and packets aredropped. Higher queuing delays and packet drops
aremore likely on highly loaded, slow links, such as WAN links that areused between sites in
a multisite environment. As a result, quality issues are common and need to be resolved by
implementing QoS. Otherwise, voice packets are subject tovariable delays (jitter) and packet
drops, bothof which impactvoice quality.

1-6 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v80 >2010 Cisco Systems, Inc
Quality Issues Example: Jitter and Packet Drops
The figure illustrates how packets are queued during congestion.

Quality Issues Example: Jitter and


Packet Drops

During congestion, packets are buffered in queues. If


a queue is full, packetsget dropped.

Tail drops cause packet loss Queuing delay causes jitter.


• Voice quality is reduced. Voice quality is reduced.

During peaks, packets cannot be sent immediately because ofinterface congestion, so they have
tobe stored in a buffer ("queued"). The time that the packet waits in such aqueue isreferred to
as the "queuing delay." The length ofthis delay can vary widely. Ifthe queue is full, newly
received packets cannot be buffered, so they get dropped (this action is called "tail drop").
Without any special treatment ofvoice packets, such as a FIFO processing model, the resulting
jitter and packet lossdecrease voice quality.

)2010 Cisco Systems. Inc. Multisite Deployment Implementation


Bandwidth Issues
This topicdescribes bandwidth issuesin a multisite environment.

Bandwidth Issues

Individual sites of a multisite deployment are


separated by an IP WAN:
* All intersite traffic (voice, data, video, etc.) competes for
available bandwidth.
« Bandwidth on IP WAN links is usually limited and costly.
Link bandwidth should be used as efficiently as possible.
No unnecessary trafficshould be sent over the IP WAN.
Default codec (G.711) is not efficient in noncircuit-based
environments.

Voice traffic causes lots of overhead.


• Large headers, small payload
• High packet rate

The individual sites of a multisite deploy ment areusually interconnected bv an IP WAN.


Bandwidth on WAN links is limited and relatively costly. Therefore, the goal is touse (he
available bandwidth asefficiently aspossible. Discourage unnecessary traffic, and consider
implemenling methods forbandwidth optimization.
Voice streams can he verv wasteful, considering that voice is sent in small packets but atavery
high packet rate. And they are particularly wasteful when using default codecs (G.711 requires'
64 kb/s for digitized voice). The overhead of packeli/ation—encapsulating digitized voice into
RTP. User Datagram Protocol (UDP). IP. and a Layer 2 protocol—is extremely high compared
to the size of the pavload. The more (tf these packets thai are sent, the more often the headers
are addedto the actual voice information (the RTPpayload).

Example: Bandwidth Issues


A voice call with default setting's uses the G.71 I codec, anda paeketization period of 20 ms.
The 160 bvtes (equivalent to 20msof voice) areencapsulated into a 12-byte RTP header, an 8
byte UDP header, anda 20-byte IPheader. The header-to-payload ratio is 1:4, and the
bandwidth requirement is 80 kb/s (instead of the 64-kb/s nominal bandwidth of G.711).

Note This calculation considersonlyencapsulation to IP packets. Layer 2 encapsulation (which


vanes depending on the data linkprotocol being used) is not yet considered.

Implementing Cisco Unified Communications Manager. Part 2 (CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Bandwidth Issues Example: VDice and Data Traffic Competing
for Bandwidth
The example illustrates the higher ovdVh ead ofvoice packets when comparing them with file
transfer packets.

Bandwidth Issues Sample: Voice and


Data Traffic Compdt:ing for Bandwidth

In multisite environments, media services such as


music on hold (MOH), conferences, annunciators,
and so on, can cause considerable bandwidth
consumption over the IP WAN.
Voice packets:
• Small size
-wwr
• High packet rate
• Large overhead Vo-ceand data packets are
competing for IP WAN bandwdlh

Data packets:
• Large size
• Lower packet rate
• Small overhead

As shown mthe figure and as already mentioned, voice packets consume lots of bandwidth that
is caused by the overhead ofIP, UDP. and RTP headers that are added to small packets and
sent at ahigh packet rate. Data packets such as afile transfer also add 40 bytes ofoverhead (20
bytes IP and 20 bytes TCP), bu, the payload is as large as possible (filling up the maximum
transrmsston umt. or MTU^ypically about 1500 bytes. Because of the large payload the
packet rate ,s also lower, and overhead is not added, as is often the case with voice packets.
Because ofthe inefficiency of voice packets, all unnecessary voice streams should be kept
away from .he IP WAN. Media resources, in particular, can be optimized in such away that
they do not have to cross the IP WAN all the time, thus conserving valuable bandwidth You
can achieve this optimization by utilizing local media resources.

>2010 Cisco Systems, Inc.


Multisite Deployment Implementation 1-9
Bandwidth Issues Example: Load Caused by Centralized Media
Services
The figure illustrates the bandwidth issue that is caused by acentralized conference bridge.
Bandwidth Issues Example: Load
Caused by Centralized Media Services
The use ofa centralized conference bridge requires RTP streams of
phones that are located at the remote site to cross the IP WAN, even
when only remote phones areparticipating in the conference.
The same problem applies to media termination points (MTPs),
annunciators, and MOH

Cisco Unified
Communications
Manager

in the example, aconference bridge has been deployed at the mam site. 1here >s no conference
bridge at the remote site. If remote IP phones join aconference, their Rl Pstreams are sent
across the WAN to the conference bridge. The conference bridge mixes the received audio
streams and then sends them back again to the IP phones over the IP WAN.
There arc three members in the conference in this example, and all of .hem are physically
locked at the remote site. In total, three RTP streams are flowing toward the coherence bndge.
and three RTP streams are flowing back to the remote site. Assuming ^f^ett.ngs each
RTP stream requires 80 kb/s (ignoring the Layer 2overhead), resulting in 240 kb/s of IP WAN
bandwidth that is required bv this voice conference. If the conference bndge was not located n
life olr side ofthe IP WAN. this traffic would have avoided the WAN link entirely, since all
participants ofthe conference are local to the remote site.

>2010 Cisco Systems, Inc.


1-10
implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0
Availability Issues
This topic describes availability issues in Cisco Unified Communications Manager multisite
deploy ments.

Availability Issues

Availability of the IP network, especially of the IP WAN that


interconnects sites in a multisite deployment, is critical for
several services;
• Signaling
- Remote IPphones registering with centralized Cisco Unified
Communications Manager
- Remote MGCP gateways controlled bycentralized Cisco Unified
Communications Manager
- Signaling to othervblP domains
- CiscoUnified Communications Manager tnterclustertrunks
• SIP trunks
• H.225 trunks
• Media transmission
- RTP streams sent across the IP WAN
• Other services, such as IP phone XMLservices

When deploying Cisco Unified Communications Manager in multisite environments, you


access services over the IP WAN. Affected services include the following:
• Signaling in Cisco Unified Communications Manager multisite deployments with
centralized call processing: Remote IP phones register with acentralized Cisco Unified
Communications Manager server. Remote MGCP gateways are controlled by acentralized
Cisco Unified Communications Manager server thatacts asan MGCP call agent.
• Signaling in Cisco Unified Communications Manager multisite deployments with
distributed call processing: In such environments, sites are connected via H.323
(nongatekeeper-controlled. gatekeeper-controlled, or H.225) or Session Initiation Protocol
(SIP) trunks.
• Media exchange: RTP streams between endpoints that are located in different sites.
• Otherservices: These services include IPphone XML services, access to applications
such asattendant console. Cisco Unified Communications Manager Assistant, and others.
Ifthe IP WAN connection is broken, these services are not available. This unavailability might
be acceptable for some services, but strategic applications such as telephone call services
should bemade available during WAN failure viabackup methods.

) 2010 Cisco Systems, Inc.


Multisite Deployment Implementation 1-11
Availability Issues Example: IP WAN Failure
The figure illustrates an example oflost services during WAN failure.

Availability Issues Example: IP


Failure

IP WAN failure impacts connection to the remote


cluster, phones at remote sites, and access to the
ITSP.

Remote Cluster

Cisco Unified
Communications
Manager

In the example, there is a main site with an inlerclusler trunk to a remote Cisco Unified
Communications Manager cluster. There is also aremote site with IP phones that register at the
Cisco Unified Communications Manager cluster that is located at the main site. ASIP trunk is
used to connect to an ITS!'.

Ifa WAN failure occurs, no calls to the other cluster orto the ITSP are possible. In addition, all
phones that arelocated at the remote site lose registration with Cisco Unified Communications
Manager, sothev do not operate atall. They cannot even place calls within the remote site.

Note Adeployment as shown inthe exampleis badly designedbecause of the lack of IP WAN
backup.

1-12 ImplementingCisco Unified Communications Manager. Part 2 (CIPT2]v8.0 © 2010 Cisco Systems, Inc
Dial Plan Issues
This topic describes dial plan issues in Cisco Unified Communications Manager multisite
environments.

Dial Plan Issues

Dial plans for multisite deployments have to address


several issues:
* Direct inward dial versus attendants
• Overlapping directory numbers
• Nonconsecutive directory numbers
• Variable-length numbering and interdigit timeout handling
- Optimized call routing
- Toll bypass
- Tail-end hop-off
- PSTN backup
• Various PSTN requirements in various countries
- Access codes for PSTN, national, and international dialing
- Number presentation (ISDN TON)
• Scalability

In a multisite deployment, dial plan design requires the consideration of several issues that do
not exist in single-site deployments:
• Direct inward dialing (DID) ranges and E.164 addressing: When you are considering
integration with the PSTN, internally used directory numbers have to be related to external
PSTN numbers (E.164 addressing). Depending on the numbering plan (fixed or variable)
and services that are provided bv the PSTN, these solutions are common:
Each internal directory number relates to a fixed-length PSTN number: In this
case, each internal director; number has its own, dedicated PSTN number. The
directory number can, but does not have to, match the least significant digits of the
PSTN number. In countries with a fixed-numbering plan, such as the North
American Numbering Plan (NANP). the four-digit station codes, for instance, are
used as internal director;' numbers. If these numbers are not unique, digits of office
codes or administratively assigned site codes might be added, resulting in five or
more digits being used for internal directory numbers.

Another solution is not to reuse any digits of the PSTN number, but to simply map
each internally used director.' number lo any PSTN number that is assigned to the
company. In this case, the internal and external numbers do not have anything in
common.

©2010 Cisco Systems. Inc. Multisite Deployment Implementation


If the internally useddirector;' numbermatches the least significant digits of its
corresponding PSTN number, you can set significant digits at the gateway or trunk.
Then you can also configure general external phone number masks, transformation
masks, or prefixes, because all internal director; numbers are changed to fully
qualified PSTN numbers in the same way. The internal directory number can be
composed ot parts of the PSTN number and administratively assigned digits. In that
case, one or more translation rules have to be used for incoming calls, and one or
more calling-party transformation rules (transformation masks, external phone
number masks, prefixes, and so on) have to be configured.
An internal director; number can be composed of site codes with PSTN station
codes, site codes with various ranges (such as PSTN station codes 4100 to 4180 that
map to director; numbers 1100 to 1180), or site codes with completely independent
mappings of internal directory numbers to PSTN numbers.
— No direct inward dialing support in fixed-length numbering plans: To avoid the
requirement of one PSTN number per internal directory number when using a fixed-
length numbering plan, it is common to not allow direct inward dial to an extension.
Instead, the PSTN trunk has a single number, and all PSTN calls that are routed to
that number arc sent to an attendant (or an autoattendant) from where the calls are
transferred to the appropriate internal extension.
Internal director; numbers arc part of a variable-length number: In countries
with variable-length numbering plans, a (usually shorter) '"subscriber" number is
assigned to the PSTN trunk. However, the PSTN routes all calls starting with this
number to the trunk: the caller can add more digits to identify the extension. There is
no fixed number of additional digits or total digits (there is a maximum, however),
which provides the freedom to select the length of directory numbers. A caller
simplv adds the appropriate extension when placing a call to a specific user to the
company's (short) PSTN number. If only the short PSTN number without an
extension is dialed, the call is routed to an attendant within the company. Residential
PSTN numbers are usuall; longer and do not allow additional digits to be added.
The feature that is described here is available only on trunks.
Overlapping numbers: Users that are located at different sites can have the same director;'
numbers assigned. Because director;' numbers are usually unique only within a site, a
multisite deployment requires a solution for overlapping numbers.
Nonconsccutive numbers: Continuous ranges of numbers are important for summarization
of call-routing information. Such blocks can be represented by one or a few entries in a
call-routing table (route patterns, dial-peer destination patterns, voice translation rules, and
so on) and can keep the routing table short and simple. If each endpoint requires its own
entry in the call-routing table, the table gets too large, lots of memory is required, and
lookups take more time. Therefore, nonconsecutive numbers (somenumbers at one site,
and other numbers of the same block at a different site) are not optimal for efficient call
routing.
Variable-length numbering: Some countries have fixed-length numbering plans for
PSTN numbers, while others have variable-length numbering plans. A problem of variable-
length numbers is thatthe length can be determined only by waiting fora timeout. If no
moredigits have been dialed for the specifiedtime, the numberis considered to be
complete. Waiting for the timeout adds to the postdial delay.

1-14 Imolementing Cisco Unified Communications Manager. Part 2 (CIPT2) v8.0 ©2010 Cisco Systems. Inc
• Optimized call routing: An IP WAN between sites with PSTN access allows PSTN toll
bypass. Cisco Unified Communications Manager servers route calls between sites over the
IP WAN instead of using the PSTN (toll bypass). In such scenarios, the PSTN should be
used as a backup path only in the case of WAN failure. Another solution, which extends the
idea of toll bypass,is to use the IP WAN also for PSTN calls: With tail-endhop-off
(THHO), the IP WAN is used as much as possible, and the gateway that is closest to the
dialed PSTN destination is used for the PSTN breakout. Finally, a backup path over the
PSTN should be enabled for when a call cannot be sent over the IP WAN (for example, if
the IP WAN is down or the maximum number of allowed calls is reached).
• Various PSTN requirements: Various countries—and sometimes even various PSTN
providers withinthe same country—can have variousrequirements regarding the PSTN
dial rules. This situation can cause issueswhen calls can be routedvia multiplegateways,
For example, if the requirements of a primary gateway are different from the requirements
of a backup gateway, numbers have to be transformed accordingly.

p,„ The calling number (the Automatic Number Identification, or ANI) ofcalls that are being
^ received from the PSTN can be represented in various ways: as a7-digit subscriber
number, as a 10-digitnumber including the area code, or in international format with the
country code in front of the area code. To standardize the calling number for all calls, the
format that is used mustbe known, and the number has to be transformed accordingly. In
countries where PSTN numbers do not have fixed lengths, it is impossible to detect the type
(local, national, or international) of the number by the number only by looking at its length.
Insuch cases, thetype of number has to be specified in signaling messages (forexample,
by the ISDN type of number, or TON).
• Scalability: In large or very large deployments, dialplanscalability issues arise. When
interconnecting multiple Cisco Unified Communications Manager clusters or CiscoUnified
Communications Manager Express routers viatrunks, it is difficult to implement a dial plan
on an any-to-any basis where each device or cluster needs to know which numbers or
prefixes are found at which other system. In addition to the need to enter almost the same
dial plan ateach system, a static configuration does not reflect true reachability. Ifthere are
any changes, the dial plans ateach system have to be updated. Although there aresolutions
thatallow centralized dial plan configuration (forexample, H.323 gatekeepers), in very
large deployments a dynamic discovery ofdirectory number ranges and prefixes would
simplify the implementation and provide a more scalable solution.

)2010 Cisco Systems. Inc. Multisj,e Dep|0ymen| implementation M5


Example: Variable-Length Numbering, E.164 Addressing, and
DID
The figure illustrates an international deployment with variousnumbering schemes.

Example: Variable-Length Numbering,


E.164 Addressing, and

NANP.
No DID Variable-Length E.164
Aulo-Attendanl Used Addressing with DID

Cisco Unified
Communications
Manager

"fhe example features a main site in the United Slates. The NANP PSTN number is408 555-
1234. DID isnotused. All calls placed to themain site are managed by anattendant. There is a
remote site in Gennanv with a PSf N numberof 149 404 13267. The Cierman location uses
four-digit extensions, and DID isallowed, since digits can be added to the PSTN number.
When calling the German office attendant (not knowing aspecific extension), users in the
United States would dial +9 011 49 404 13267. If they know that they want to contact
extension 1001 dircclK. thev would dial+9 011 49 404 13267 1001.

©2010 Cisco Systems.


1-16 Implementing Cisco Unmeet Communications Manager. Part 2 (CIPT2) v8.0
Fixed vs. Variable-Length Numbering Plans
The table compares characteristics of a fixed numbering plan with characteristics of a variable-
length numbering plan.

Fixed vs. Variable-Length Numbering Plans

Examples:
• Witriir It S : "9 1 408 555-1234" or '1 555-1234" twilrifi Bia same area code)
• U.S to Austria1 "9 011 43 1 12345"

• WitHii Austria: "0 0 1 12345" or "0 1234" (withn the same area code)
• Austria to U.S.. "0 00 1 406 555-1234 " (1 is country code, not national access code)

, _ „ _, VsriSUle-Length Numbing
Components £|*ea Numbering Plan " *

Example MAW Avetiia

Country code 1 43
Area code 3 digit 1-4 (Halt*
3-tfio.texchsng» cads ♦ 3«mor»-<Igflt
Subscriber numoer
^cfigistaawtcoas
PSTN access code 9 "~ 0
National access code 1 0

00 or*
International access code 011
(•+' uwd by e#Jpfion«)

A fixed numbering plan, such as the plan used in North America, features fixed-length area
codes and local numbers. An open numbering plan, such as the plan used in various countries
that have not yet standardized their numbering plans, features variance in the length of the area
code or the local number, or both.

A country code is used to reach the particular telephone system for each country or special
service.

An area code is used within many countries to route calls to a particular city, region, or special
service. Depending on the country or region, it may also be referred to as a Numbering Plan
Area (NPA), subscriber trunk dialing code, national destination code, or routing code.
The subscriber number represents the specific telephone number to be dialed, but does not
include the country code, area code (if applicable), international prefix, or trunk prefix.
A trunk prefix refers to the initial digits to be dialed in a call within the United States,
preceding the area code and the subscriber number.
An international prefix is the code to be dialed before an international number (the country
code, the area code if any, and then the subscriber number).
The table contraststhe NANP and a variable-length numbering plan (the Austrian numbering
plan, in this example).

>2010 Cisco Systems, Irrc Multisite Deployment Implementation 1-17


Detection of End of Dialing in Variable-Length Numbering
Plans
There are three ways of detecting end of dialing in variable-length numbering plans.

Detection of End of Dialing in Variable-


Length Numbering Plans

There are three ways to detect end of dialing in variable-


length numbering plans:
• IntErdigit timeout
- Simple to configure
Least convenient

• Use of # key
Different implementation in Cisco IOS Software (simple) versus
Cisco Unified Communications Manager (complex)
- Convenient

Requires users to be informed aboutthis option


• Use of overlap sending and overlap receiving
-- Convenient
-- Must be supported by PSTN
- Complex implementation, especially when differentPSTN calling
privileges are used

From an implementation perspective, the simplest way to detect end of dialing is to wait for an
interdigit timeout to expire.This approach, however, provides the least comfort to the end user
because it adds postdial delay. In an environment with only few numbers of variable length (for
example, the NANP. where only international calls are of variable length), waiting for the
interdigit timeout ma\ be acceptable. However, even in such an environment, it may make
sense to at least reduce the value of the timer, because the default value in Cisco Unified
Communications Manager is rather high (15 s).

Note In Cisco Unified Communications Manager, the interdigit timer is set by the dusterwide
Cisco CallManager service parameter T302 timer that is found under Device > General.

In Cisco IOS Software, the default for the inlerdigit timeout is 10 seconds. You can modifj this
value using the voice port timeouts interdigit command.
Another solution for detecting end of dialing on variable-length numbers is the use of the # ke\.
An end usercan press the # kej to indicate thatdialing hasfinished. The implementation of the
# kev is different in Cisco Unified Communications Manager versus Cisco IOS Software. In
Cisco IOS gatewa\s. the # is seen as an instruction to stop digit collection. It is not seen as part
of the dialed string. Therefore, the # is not part of the configured destination pattern. In Cisco
Unified Communications Manager, the # is considered to be part of the dialed number, and
therefore its usage hasto be explicitly permitted by the administrator by creating patterns that
include the it. If a pattern includes theit. the # hasto be used; ifa pattern doesnot include the#.
the pattern is not matched if the user pressed the # key. Therefore, it is common in Cisco
Unified Communications Manager to createa variable-length patterntwice: once with the it at
the end and once without the #.

1-18 Implementing Cisco Unified Communications Manager. Part 2 (CIPT2) v8 0 ©2010 Cisco Systems, Inc
An alternative wayof configuring such patterns is to end the pattern with ![0-9#]. In thiscase,
a single pattern supports bothwaysof dialing: withthe # and without the #. However, be aware
ff^ that the use ofsuch patterns can introduce other issues. For example, when using discard digits
instructions that includeTrailing-^(for example, PreDot-Trailing-#). This discard digit
instruction will have an effectonly when there is a trailing # in the dialed number. If the # was
p.,* not used, the discard digit instruction is ignored and hence the PreDot component ofthe discard
IM digit instruction is also not performed.
Allowing the use of the # to indicate end of dialing providesmore comfortto end users than
having them wait forthe interdigit timeout. However, thispossibility has to be communicated
to the end users, and it shouldbe implemented consistently. As mentioned earlier, it is
automatically permitted in Cisco IOS Softwarebut not in Cisco UnifiedCommunications
Manager.
The third way to indicate end of dialing is the use of overlapsend and overlapreceive.If
overlap is supported end-to-end, the digits that are dialed by the end user are sent one by one
over the signaling path. Then the receiving end system can inform the calling device once it has
received enough digits to route the call (number complete). Overlap send and receive is
common in some European countries such as Germany and Austria. From a dial plan
implementation perspective, overlap send and receive is difficult to implement when different
PSTN callingprivileges are desired. In this case, you have to collectenoughdigits locally(for
jte example, in Cisco Unified Communications Manager or Cisco IOS Software) to be able to
decide to permit or deny the call. Only then can you start passing digits on to the PSTN one by
one using overlap. For the end user, however, overlap send and receive is very comfortable,
pw because each call is processed as soon asenough digits have been dialed. Thenumber of digits
§^ that are sufficient varies perdialed PSTN number. Forexample, one local PSTN destination
may be reachable by a seven-digit number, whereas another local number may be uniquely
identified only after receiving nine digits.

>2010 Cisco Systems, Inc. Multisite Deployment Implementation 1-19

L
Optimized Call Routing and PSTN Backup
Using an 1P WAN enables savings on the cost of PSfN calls in a multisite en\ ironment.

Optimized Call Routing and PSTN


Backup

In multisite environments, using the IP WAN for routing


calls to remote destinations allows PSTN cost savings:
• Toll bypass
Calls between sites use the IP WAN instead of PSTN.

PSTN is used as backup in case of IP WAN or CAC failure.


* Tail-end hop-off (TEHO)
- TEHO extends the conceptrjf toll bypass.
• Calls to remote PSTN locations use the IP WAN as much as
possible.
• PSTN breakout occurs at gateway located closestto the
PSTN destination.

Local PSTN breakout is used as backup in case of IP WAN or


CAC failure

"there are two wa\s to save costs for PSTN calls in a multisite deployment:
• Toll bypass: Calls between sites that use the IP WAN instead of the PSTN are toll-bypass
calls. The PSTN is used only when calls over the IP WAN are not possible—either because
of a WAN failure or because the call is not admitted by Call Admission Control (CAC).
• TEHO: TEHO extends the concept of toll bypass by also using the IP WAN for calls to the
remote destinations in the PS'fN. With TIT 10. the IP WAN is used as much as possible and
PSTN breakout occurs at the gateway that is located closest to the dialed PSTN destination.
Local PSTN breakout is used as a backup in case of an IP WAN or CAC failure.

Caution Some countries do not allow the use of TEHO. When implementing TEHO, ensure that the
deployment complies with legal requirements.

When using the IP WAN lo reach remote PS'fN destinations or internal director) numbers at a
different site, it is important to consider backup paths. When the IP WAN is down or when not
enough bandwidth is available for an additional voice call, calls should be routed via the local
PSTN gateways as a backup path.

1-20 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2)v8 0 ©2010 Cisco Systems. Inc
Example: TEHO
The figure illustrates the use of TEHO in a multisite deployment.

Example: TEHO

San Jose Chicago

l^.

403-555-6666

In the example, a call from Chicago to San Jose, California, would berouted inthe following
way:

1. A Chicago userdials9 1 408 555-6666, the number fora PSTN phone thatis located in
San Jose.

2. Thecall is routed from theCisco Unified Communications Manager Express in Chicago to


the Cisco Unified Communications Managercluster in San Jose over the IP WAN.
3. The Cisco Unified Communications Managerin San Jose routes the call to the San Jose
gateway, which breaks out to the PSTN with a (now) local call to the San Jose PSTN.
4. The San Jose PSTN phone rings.

IM

'2010 Cisco Systems, Inc. Multisite Deployment Implementation 1-21


Example: Overlapping and Nonconsecutive Numbers
The figure illustrates a deployment with overlapping and nonconsecutive numbers.

Example: Overlapping and


Nonconsecutive Numbers

Wain Site Remote Site

Cisco Unified
Communications
Manager

1001-1099 •* ••1001-1099

Nonconsecutive
2000-2157 +• -+• 2158-2364
Numbers
2365-2999

Inthe example. IP phones ai the main site use directorv' numbers 1001 to 1099. 2000 to 2157.
and 2365 to 2999. At the remote site. 1001 to 1099 and 2158 to 2364 are used. There are two
issueswith thesedirector, numbers: 1001 to 1099overlap; and thesedirectory numbers exist at
both sites, so they are notunique throughout the complete deployment. Inaddition, the
nonconsecutive use ofthe range 2000 to 2999 (some numbers outof this range areused at the
remote site, and the others are used at the main site) wouldrequire lots of entries in call-routing
tables, since the ranges can hardly be summarized by one (ora few) entries.

Note The solutions to the problems that are listed inthis lesson are discussed inmoredetail inthe
next lesson of this module.

1-22 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) v80 © 2010 Cisco Systems, Inc.
ttM.

Various PSTN Requirements


Various countries can have various PSTN requirements, which make it difficult to implement
dial plans in international deployments.

Various PSTN Requirements

Various countries have various requirements for


PSTN calls:
• Dial rules for the called-party numberon outbound PSTN
calls
- PSTN access code
- National access code
- International access code
• Presentation of called- and calling-party numbers on inbound
and outbound calls
- Length of number and its components
- ISDN number types
- Overlap send and overlap receive
- + prefix on E.164 numbers
• Emergency dialing

One of the issues in international deployments is various PSTN dial rules. For example, in the
United States, the PSTN access code is 9, while in most countries in Europe, 0 is used as the
PSTN code. The national access code in the United States is I, while 0 is commonly used in
Europe. The international access code is 011 in the United States,while 00 is used in many
European countries. Some PSTN provider networks require the use of the ISDN TON, while
others do not support it. Some networks allow national or international access codes to be
combined with ISDN TON. Others require you to send the actual number only (that is, without
any access codes) when setting the ISDN TON.
Thesame principle applies to the calling-party number. As mentioned earlier, in variable-length
numbering plans, the TON cannot be detectedby its length.Therefore, the only way to
determine whetherthe receivedcall is a local,national, or international call is by relying on the
availability of the TON information in the receivedsignalingmessage.
**»
Some countries thathavevariable-length numbering plansuseoverlap sendandoverlap
receive. With overlap send, a numberthat is dialed by an end user is passedon to the PSTN
digit by digit. Then the PSTN willindicate when it has received enough numbers to routethe
call. Overlap receivedescribes the same conceptin the oppositedirection:when a call is
received from the PSTN in overlap mode, the dialed number is delivered digit by digit, andnot
en bloc. Some providers thatuse overlap sendtoward theircustomers do notsend the prefix
that is configured forthe customer trunk, but only the additional digitsthat are dialed by the
user who initiates the call.

When dialing PSTN numbers in E.164 format (that is,numbers thatstart with the country
code), the + sign is commonly prefixed to indicate that the number is in E.164 format. The
advantage of using the+ sign as a prefix forinternational numbers is thatit is commonly
known as a + sign around the world. Incontrast, PSTN access codes suchas 011 (used in the
NANP) or 00 (often used in Europe) areknown onlyin the respective countries.

>2010 Cisco Systems. Inc. Multisite Deployment Implementation 1-23

L
Finally, emergency dialing can be an issue in international deployments. As various countries
have various emergenc\ numbers and various ways to place emergency calls, users are not sure
how to dial the emergency number when roaming to other countries. An international
deployment should allow roaming users to use their home dialing rules when placing
emergency calls. The system should then modify the called number as required at the respective
site.

1-24 Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Issues Caused by Different PSTN Dialing
Different local PSTN dial rules can cause several issues, especially in international
deployments.

Issues Caused by Different PSTN


Dialing

How to store PSTN contacts so that they can be used


from any site?
• Different ways to storeor configure PSTN destinations;
- Speed dials
- Fast dials
- Address book entries
- Call lists
- Automated alternate routing (AAR) targets
- Call Forward destinations
• Stored numbercan be used at multiple sites (countries) because of
roaming users using local PSTN gateways.
- Cisco Extension Mobility
- Cisco Device Mobility
- PSTN backup
- Tail-end hop-off and Least Cost Routing (LCR)

The main problem that needs to be solved in international environments is how telephone
numbers ofcontacts should bestored. Address book entries, speed and fast dials, call list
entries, and other numbers should be in a format that allows them tobe used atany site,
regardless of the local dial rules that apply to the site where the user is currently located.
The same principle applies to numbers that are configured by the administrator—for example,
the target PSTN number for automated alternate routing (AAR) targets. Call-forwarding
destinations should also be in a universal format—a format that allows the configured number
to be used atany site. The main reason for auniversal format is that amultisite deployment has
several features'that make itdifficult to predict which gateway will be used for the call. For
example, aroaming user may use Cisco Extension Mobility or Device Mobility. Both features
allow an end user toutilize local PSTN gateways while roaming. Ifno universal format isused
to store speed dials or address book entries, itwill be difficult for the end user to place aPSTN
call to a number that was stored according to the NANP dial rules while incountries that
require different dial rules. Even when not roaming, the end user can use TEHO orLeast Cost
Routing (LCR). so that calls break out to the PSTN at aremote gateway, not at the local
gateway. Ifthe IP WAN link to the remote gateway is down, the local gateway is usually used
as abackup. How should the number that isused for call routing look in such an environment?
It isclearly entered according to local dial rules by the end user, but ideally itischanged to a
universal format before call routing is performed. Once thecall has been routed and the egress
gateway has been selected, the number could then be changed as required by the egress
gateway.

© 2010 Cisco Systems. Inc. Multisite Deployment Implementation 1-25


Dial Plan Scalability Issues
In large Cisco Unified Communications Manager deployments, it can be difficult to implement
dial plans, especially when using features such as TEHO with local PS'fN backup.

Dial Plan Scalability Issues

Dial plans are difficult to implement in large Cisco Unified


Communications deployments
• Static configuration for multiple sites ordomains isvery complex
because of any-to-any call-routing requirements.
• Centralized H.323 gatekeepersor SIP network services offer dial
plan simplification.
- Less configuration because ofany-to-one call-routing topology.
• Static configuration nevertheless.
• No dynamic recognition of routes
• No automatic PSTN rerouting
No built-in redundancy
• Still no optimal solution for large deployments
- Call Control Discovery allows dynamic learning of dial plans.

The main scalability issue oflarge deployments is that each call routing domain (for example, a
Cisco Unified Communications Manager cluster or aCisco Unified Communications Manager
Express router) needs to be aware of how to getto all other domains.
Such adial plan can become very large and complex, especially when multiple paths (for
example, a backup path for I'EHO) have to be made available. As each call routing domain has
to be aware ofthe complete dial plan, astatic configuration does not scale. For example, anv
changes in the dial plan have to be applied individually at each call routing domain.
Centralized H.323 gatekeepers orSIP network services can be used to simplify ihe
implementation ofsuch dial plans, because there is no need toimplement the complete dial
plan at each call routing domain. Instead ofan any-to-any dial-plan configuration, only ihe
centralized component has tobe aware ofwhere lo find which number. This approach,
however, means thai vou rely on a centralized service. Ifthe individual call-routing entities
have noconnectivity to the centralized call-routing intelligence, all calls would fail. Further, the
configuration isstill static. Any changes atone call-routing domain (for example, new PSTN
prefixes because of changing the PS'fN provider) have to be implemented also at the central
call-routing component.
In addition, these centralized call-routing services do not have built-in redundancy.
Redundancv can be provided, but requires additional hardware, additional configuration, and so
on. Redundancv is not an integrated part of the solution.

1-26 ImplementingCisco Unified Communications Manager. Part 2 (CIPT2]vB.O ©2010 Cisco Systems, Inc.
Answer Key
The correct answers and expected solutions for the activities that are described in this guide
appear here.

Lab 1-1 Answer Key: Implementing Basic Multisite


Connections
fhe solution is part of the activity procedure and verification.

Lab 1-2 Answer Key: Implementing a Dial Plan for International


Multisite Deployments
fhe solution ispart of the activity procedure and verification.

Lab 2-1 Answer Key: Implementing SRST and MGCP Fallback


fhe solution ispari of the activity procedure and verification.

Lab 2-2 Answer Key: Implementing Cisco Unified


Communications Manager Express in SRST Mode
The solution ispart of the activity procedure and verification.

Lab 3-1 Answer Key: Implementing Bandwidth Management


The solution is part ofthe activity procedure and verification.
Lab 3-2 Answer Key: Implementing CAC
The solution ispart of the activity procedure and verification.

Lab 4-1 Answer Key: Implementing Device Mobility


The solution ispart of the activity procedure and verification.

Lab 4-2 Answer Key: Implementing Cisco Extension Mobility


fhesolution is part of the activity procedure and verification.

Lab 5-1 Answer Key: Implementing SAF and CCD


The solution ispart of the activity procedure and verification.

Implementing Cisco Unrfied Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc
router eigrp SAF
service-family ipv4 autonomous-system 2
shutdown

Step 13 Verify that the IP path to all learned patterns is marked unreachable by using the
show voice saf dndb all command.

Activity Verification
You have completed this task when you attain these results:
• The BR-.t router learns patterns by CCD as described in the activity procedure.
. Verifv that calls can be placed to patterns learned by CCD while being in SRST and MGCP
fallback mode.

Step 14 Place calls from your BR-.v site to all other three sites.
• Verifv the path that each call takes by using the debug isdn q931 command at
all four gateways.
• Use site code dialing for calls to the other pod: 8-5 lv-200! or 8-5I r-2002 to
IIQ-v phones and 8-52.V-3001 to the BR-v phone.
• Use four-digit extensions for calls to the local HQ-.t phones: 2001 or 2002.
Note When acall is placed to aphone located at one of the BR sites, the SIP INVITE is sent to
the advertising device (CUCM1-X or CUCM1-y). As the BR sites are in SRST mode, Cisco
Unified Communications Managers will route the calls to their BR gateway via the PSTN
basedon the existing CFUR configuration.

Lab Guide 95
© 2010 Cisco Systems. Inc.
Note This dial peer is required for the CCD PSTN backup calls. The learned toDID rule changes
the internally used site-code numbers from 8 followed by seven digits to E.164 numbers with
a plus prefix The CCD PSTN backup calls then match this dial peer where the + is stripped
and then 011 is prefixed.

The learned pattern 851x-2XXX refers to the HQ-x site. Until now calls between the two
sites of the same pod used four-digit dialing. CCD cannot advertise the HQ-x site with 4
digits to the BR-x SAF client and with site code prefixes to other SAF clients (the SAF clients
of the other pod). Usually, when using CCD, the internally used pattern for a given site has
to be the same at all sites.

However, the problem can also be solved in a way that allows users to continue using 4
digits for intersite calls within the same pod. You need to modify the dialed four- digit number
2XXX at the BR-x router to 851x2XXX before the outbound dial peer is selected.

Step 10 On the BR-.rrouter configure the following number expansion in order to allow
BR-.v users to continue using four-digit intersite dialing towards the HQ site of the
local pod (HQ-.t):

num-exp 2... 851x2...

Note Byconfiguring the number expansion command calls to four-digit numbers starting with 2
(for example 2001) are expanded to site code dialing format (851x2001) before the selection
of the outgoing dial peer. The expanded number is used to select the outgoing dial peer
(dial-peer 8 in this case) which refers to SAF-learned patterns. The BR-xgateway finds a
match in a learned pattern (851x2XXX) that is currently marked unavailable. Therefore, a
PSTN backup call is placed using the learned toDID rule (4:+5551x555). The resulting call to
•••5551x5552001 matches dial peer 999, which sends the call to the PSTN with a called
number of 0115551x5552001.

Simulate IP WAN Failure Between the HQ and the BR Sites


In this section \ou will break MGCP, SCCP. and SAF to simulate an IP WAN failure between
the HQ and BR sites of your pod.
Step11 You hav e to force the BR-.v router into SRST and MGCP fallback mode by breaking
connectivity between the BRsite andCiscoUnified Communications Manager. You
can do that by reapplying the access-list that was already used in an earlier lab task
at the HQ-.r router:
i

interface serial ...


ip access-group 100 in

Note Use the interface that connects the HQ-x route with the BR-x router.

Step12 Break the SAT connection between your HQ router (HQ-.v) and your BR router
(BR-.r) in order to have the IP palhs marked unreachable by enleritig the following
commands in global configuration mode of the \K)-x router:

94 Implementing Cisco UnifieO Communications Manager, Part 2 (CIPT2) v8.D ®2010 Cisco Systems. Inc.
-Jfe

Note The learned pattern 852x-3XXX refers to the BR-x site itself.This pattern will not be used at
a phone that is located at the BR-x site because four-digit dialing is used for internal calls. If
it was dialed, the call cannot use the advertised IP path (to Cisco Unified Communications
Manager CUCM1-x) because the IP WAN link is down. Remember that the BR-x gateway
normallydoes not use a local dial plan as it is configured as an MGCP gateway. It will only
look to its local call routing table when the connection to the HQ site is broken, if a BR-x
user dials a number out of the 8-52x-3XXX range during SRST mode, the BR-x gateway
finds a learned pattern that is currently marked unavailable Therefore, the PSTN backup
path (toDID 4:+6652x555) is used to place a PSTN backup call. When this call is set up by
the BR-xgateway, the PSTN routes the call back to the BR-xgateway. This means that
calling to the own site by site-code dialing works, but it would use two ISDN circuits as the
call is hairpinned at the PSTN

Enable Call Routing for CCD-learned Patterns and for CCD PSTN Backup Calls
Step9 Onthe BR-\ router configure the following dial peersin orderto enable the gatewav
to use CCD-learned patterns and to enable CCD PSTN backupcalls:

dial-peer voice 8 voip


destination-pattern 8.
session target saf

Note Thisdial peer instructs Cisco Unified Communications Manager Expressto look to the CCD-
learned patterns when a user diats 8 followed by seven digits.

The learned patterns 851y-2XXX and 852y-3XXX refer to the other pod. The IP destination
for both patterns is the Cisco Unified Communications Manager of the other pod
(CUCM1-y) However, as the IP WAN is down, the PSTN backup path has to be used
Based on the learned toDID rules (4:+5551y555 for pattern 851y-2XXX and 4:+6652y555 for
pattern 852y-3XXX) the BR-x gateway will placea directcall to the respective gatewayof
the other pod (HQ-yor BR-y).

dial-peer voice 999 potE


destination-pattern +T
voice-port 0/0/0:23
prefix Oil

Lab Guide
) 2010 Cisco Systems. Inc
exit-service-family
i

Step S Configure the SAF Client function on your BR-jr router:


voice service saf
profile trunk-route 1
session protocol sip interface FastEthernetO/0 transport tcp port
5C6C

channel 1 vrouter SAF asystem 1


subscribe callcontrol wildcarded

Step 6 Configure outbound dial peers for intersite calls to use SAP:
dial-peer voice 8 voip
destination-pattern 8
session target saf

dial-peer voice 2 voip


destination-pattern 2...
session target saf

Verify CCD-learned Patterns


Step 7 On the BR-.xrouter enter the show voice saf dndb all command lo view learned
routes. You should have learned a pattern for each of the four sites.
Step 8 On the BR-.v router enter the show voice saf dndb detail 851a2XXX command lo
view details of this specificlearned route. Repeat the command for the other three
teamed patterns.

Caution The X in the pattern of the show voice saf dndb detailcommand is case sensitive.

Note In each pod, Cisco Unified Communications Manager is the call agentthatadvertises the
HQ-x and BR-x patterns. Therefore, at the BR-x router 851x-2XXX and 852X-3XXX should
be listed as reachable bySIPat 10.x 1.1 while 851y-2XXX and 852y-3XXX should be listed
as reachable by SIP at 10.y.1.1.

The BR-x router will never use thelearned SIP path. As long as there isnoIPconnectivity
problem, the ISDN PRl is MGCP-controlled and the BR-x phones are registered to Cisco
Unified Communications Manager. Therefore no call routing occurs at the BR-x gateway
under normal situation.

The learned patterns are only used incase ofIPWAN failure. In this case, however, the IP
path ofthe learned patterns ismarked unavailable andthe BR-x gateway which then
operates in SRSTand MGCP fallback mode will use the learned patterns to placeCCD
PSTN backup calls based on the learned toDID rules.

Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Step 10 Repeat the test calls. Verify thatthe callsarererouted via the local PS'fN gatewa;
mm b\ usingdebug isdn q931 command at bothgateways.

Note Be aware of the call flow in this scenario. After calling a phone of the other pod using site-
code dialing a CCD-learnedpattern is matched. The SAF-enabledSIP trunk is not useO
because the IP path is marked unreachable (dueto shutting down SAF). The ToDID rule is
*•• applied to the matched pattern and a call to the {now globalized) number is placed using the
AAR CSS.

The call matches the intersite pattern, which refers to the non-SAF-enabled SIP trunk as first
option and to the local routegroupas second option. As ihe first option does notwork (due
"•* tothe access list), the call is finally sent via the PSTN using the local gateway.

imm Step 11 Re-enable the SAF connection between the two HQ routers by entering the
following commands in global configuration mode at your HQ~.v router:
<**

router eigrp SAF


mm service-family ipv4 autonomous-system 2
no shutdown

Step 12 Remove the access listfrom the serial interface at yourIIQ-.v router.

*" Task 3: Configure Cisco Unified Communications Manager


^ Express SRST on Branch Router to Learn Routes Using CCD
In this task, you will configure Cisco Unified Communications Manager Express SRST on the
m BR-.v router to learn routes from SAF using CCD. The learned patterns arc used for intersite
calls when the gateway is in SRST and MGCP fallback mode.
* Activity Procedure
Complete these steps:
Step 1 Open a Telnet session to your BR-x router (10.v.5.102).
wm Step 2 loiter the configure terminal command lo access the global configuration mode.
Make the Statically Configured Call Routes at the Cisco Unified Communications Manager
**» Express SRST Router Inaccessible
Step 3 Shutdown ihe following dial peers:
<mm • Dial peer8y2 to destination pattern 85ly2...
• Dial peer8v3 to destination pattern 852y3...
mm

• Dial peer2000to destination pattern 2..,


— Configure the SRST Router toSubscribe toSAF in Order to Learn Routes toOther Sites
Step 4 Configure the SAF Forwarder function onyour BR-x router:
mm router eigrp SAF

-mm service-family ipv4 autonomous-system 1

-imt topology base


exit -sf -topology-

Lab Guide
& 2010 Cisco Systems, Inc
(CUCMl-v) by reapplying the access-list that was already used in earlier lab
exercises in global configuration mode at your HQ-x router:

interface serial .. .

ip access-group 100 in

Note Use the interface that connects the HQ-x route with the HQ-y router.

Caution IP connectivity between the two Cisco Unified Communications Managers needs to be
broken in order to avoid that the CCD PSTN backup call is sent over the (non-SAF-enabled)
SIP trunk that has been created in an earlier lab exercise. Remember that intersite calls
placed to the other pod are not sent via the PSTN but via the IP WAN. The same applies to
TEHO calls placed to PSTN destinations attached to the HQ and BR gateways that are
located in the other pod. By applying the access list the SIP trunk is not operational anymore
and intersite calls placed to the other pod will use the PSTN as a backup path.

Make sure that the access list is applied at the HQ router of both pods. If the access list is
only applied at your local HQ router, you will experience very high post-dial delays when you
try to reach the other pod.

The reason for the post-dial delay is that the originating Cisco Unified Communications
Manager has to wait for a timeout when not being notified that the packet has been dropped.
Ifthe HQ router of the other pod does not drop the SIP INVITE sent by the local Cisco
Unified Communications Manager, then only the response packet that is originated by the
Cisco Unified Communications Manager of the other pod is dropped inbound at your HQ
router In this case only the Cisco Unified Communications Manager of the other pod is
notified that its response packet was dropped. The local, originating Cisco Unified
Communications Manager is not aware of any packet drops and hence has to wait for the
timeout to expire. After timeout expiration it willretry the call setup and the timeout will have
to be waited for again.

When both HQ routers are configured with the inbound access list at their interconnecting
serial interface, then Cisco Unified Communications Manager will always be immediately
aware of the network issue (packet drop) and switch over to the PSTN backup path without
additional delay.

• Break the SAF connection between your HQ router (I IQ-.v) and the IIQ router of
the other pod (HQ-v) by enteringthe following commands in global
configuration mode at your HQ-x router:

router eigrp SAF


service-family ipv4 autonomous-system 2
shutdown

Step 9 Use Cisco Unitied RTMT to verity that the IP paths of the learned patternsare
marked unreachable.

implementing Cisco Unified Communications Manager, Part2 (CIPT2) u8.0 ©2010 Cisco Systems, Inc.
Step 32 Move the SAFSlPTrunk to Selected SAF Trunks.

Step 33 Check the Activated Feature check box and click Save.

Activity Verification
You have completed this task when you attain these results:
• Verify registration of the external SAF client.
Step 1 from the I IQ-.v router, enter the show eigrp service-family ipv4 clients command
in privilege mode to verify that Cisco Unified Communications Manager has
registered with the SAF forwarder.
• Verify the learned patterns by using RTMT.

Step 2 Install and launch Cisco Unified Real Time Monitoring Tool (RTMT) on your
student PC.

• Navigate to Applications > Plugins and click Find.


• Click the Download Link next to the Cisco Unified CM Real-Time
Monitoring Tool - Windows link.
• Install and launch Cisco Unified RI M f on your student PC.
• Enter the IP address of jour Cisco Unilied Communications Manager (10_v. 1.1)
and specify the Administrator ID and password (cucmadmin /cucmpassl).
Step 3 In Cisco Unified RTMT navigate to CallManager > Report > [.earned Pattern.
Step 4 From the Select a Node drop down menu, choose CUOMI-a-.
Step 5 Once the configuration of the other pod has finished, you should see a list of patterns
that were learned by CCD.

Note You should see a pattern of 851/2XXX with a toDIDof 4:+5551y555 and a pattern of
4M
852/3XXX with a toDIDof4:+6652y555 Bothpatterns should be reachable by SIP at IP
address I0.y.1.1.

• Verifv that calls can be placed to patterns learned by CCD.


Step 6 From jour IIQ and BR phones, placecalls to both sites of the other pod by dialing
8-5l.v2001 or8-5ly2002and8-52v3001.

Note Cisco Unified Communications Manager will set up a call to the learned IP address using the
learned protocol (SIP inthiscase). The receiving Cisco Unified Communications Manager
cluster will strip the called numberto the internally used four-digit directory numbers
because the SAFSlPTrunk was configured with significant digits 4.

• Verify that the backup path works.


Step 7 Make sure that all your phones have the AAR CSS set. The AAR CSS isused for
Call Control Discoverj (CCD)backup calls and it should be set to Global.CSS.
Step 8 Simulate an IP WAN failure between the HQ routers ofthe two pods (HQ-.-c and
HQ-y).
• Break IP connectivity between your Cisco Unilied Communications Manager
(CUCMI-.x)and the Cisco Unified Communications Manager of the other pod

©2010 Cisco Systems, Inc Lab Guide


Configure the SAF SIP Trunk in Cisco Unified Communications Manager
Step 10 Navigate to Device > Trunk and click Add New.
Step 11 Choose SIP Trunk, set the Trunk Service Type to Call Control Discovery, and
then click Next.

Step 12 Configure the trunk with the following settings, and then click Save.
• Device Name: SAFSlPTrunk
• Device Pool: Trunks

• Significant Digits: 4
• CallingSearchSpace: Trunk_css.
• SIPTrunk Security Profile: Non Secure SIP Trunk Profile
• SIP Profile: Standard SIP Profile

Configure the Call Routing Information to Be Advertised


Step 13 Navigate to Call Routing >Call Control Discovery >Hosted DN Croup and click
Add New.

Step 14 In the Name field, enterPod-*_DN. Click Save.


Step 15 Na% igate to Call Routing >Call Control Discovery >Hosted DN Pattern and
click Add New.

Step 16 In the Hosted Pattern field, enter 851jc2XXX.


Step 17 From the Hosted DN Group drop-down menu, choose Pod-Jt DN.
Step 18 For PSTN Failover Strip Digits, enter 4, and for PS'fN Failover Prepend Digits
enter +5551jc555. Click Save. '
Step 19 Click Add New.

Step 20 In the Hosted Pattern field, enter 85Zx3XXX.


Step 21 From the Hosted DN Group drop-down menu, choose Pod-:r_DN.
Step 22 For PSTN Failover Strip Digits, enter 4, and for PSTN Failover Prepend Digits
enter +6651r555. Click Save.

Configure the Advertising Service


Step 23 Navigate to Call Routing >Call Control Discovery >Advertising Service and
click Add New.

Step 24 In the Name field, enter CCD Advertising Service I.


Step 25 From the SAF SIP Trunk drop-down menu, select SAFSlPTrunk, and from the
Hosted DN Group drop-down menu, choose Pod-.v DN.
Step 26 Check the Activated Feature cheek box and click Save.
Configure the Requesting Service
Step 27 Na\ igate to Call Routing >Call Control Discovery >Partition.
Step 28 In the Name field, enter CCD_pt. Click Save.
Step 29 Add partition CCD lo the CSS GIobal_css.
Step 30 Navigate to Call Routing >Call Control Discovery >Requesting Service.
Step 31 In me Name field, enter CCD Requester.

Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©20)0 Cisco Systems, Inc.
• Once the configuration ofthe other pod has finished, enter the show eigrp service-family
ipv4 2 neighbors command at your HQ-.v and BR-.r router:
At the HQ-x router you should see the BR-.r router and the HQ-y router as
neighbors.
Atthe BR-.\ router you should seethe IIQ-.v router as neighbor.

Task 2: Configure Cisco Unified Communications Manager as


SAF Client
In this task you will enable CCD by configuring Cisco Unified Communications Manager to
register uith jour pre\ iousK configured SAF forwarder.
Activity Procedure
Complete these steps:
Make the SUtically Configured Call Routes tothe Other Cluster Inaccessible
Step 1 Create a partition called Inaccessible.
Step 2 Change the partition of translation patterns 851y.2XXX and 852y.3XXX from
Global to Inaccessible.
Step 3 VcrifS that intersite calls using site-code dialing (851y2XXX and 852y3XXX) do
not work anymore.

Configure the SAF Forwarder in Cisco Unified Communications Manager


Step 4 Na^ igate to Advanced Features >SAF >SAF Security Profile and click Add
New.

Step 5 Configure the SAF security profile with the following settings and then click Save.
• Name: HQ_SAF_Profile
• Username: SAFl'SER
• Password: SAFPASSWORD

Note The username and password need to match the credentials configured in Task 1

Step 6 Navigate to Advanced Features >SAF >SAF Forwarder and click Add New.
Step 7 Configure the SAF forwarder with the following settings:
• Name: HQ.v_SAF
• Client Label: HQr_SAF

Note The client label needs to match the external client configured at Task 1

• SAF Security Profile: IIQjSAF_Profile


• SAF Forwarder Address: 10jf.250.l01
Step 8
Click Show Advanced Link and move the CM_CUCM-1 Server to the Selected
Cisco Unified Communications Manager field.
StepS Click Save.

Lab Guide 87
© 2010 Cisco Systems, Inc
Task 1: Configure SAF Forwarder Functionality on the HQ-x
and BR-x Router
In this task, you will configure the HQ-.r router to act as an SAF forwarder.
Activity Procedure
Complete these steps:
Step 1 Open a Telnet session to your HQ-.r router(IOjc. 1.10I).
Step 2 Enter theconfigure terminal command to access theglobal configuration mode.
Step 3 Enter the following commands:
i

router eigrp SAF

service-family ipv4 autonomous-system 2


i

topology base
external-client HQx_SAF
exit-sf-topology
exit service-family

service-family external-client listen ipv4 5050


external-client HQx_SAF
username SAFUSER

password SAFPASSWORD

Note Do not use special characters like spacesor dashesfor theexternal client definition.

Step 4 Open a Telnet session to your BR-x router (IO.v. 1. 102).


Step 5 Enter the configure terminal command toaccess the global configuration mode.
Step 6 Enter the following commands:
router eigrp SAF

service-family ipv4 autonomous-system 2

topology base
exit-sf-topology
neighbor 10.x.250.101 LoopbackO remote 16
exit-service-family

Activity Verification
You have completed this task when you attain these results:
• The SAF forwarders have been configured as described in the activity procedure.

86 Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0 ©2010 Cisco Systems. Inc.
Lab 5-1: Implementing Cisco SAF and CCD
Complete this lab activity lopractice what you learned inthe related module.

Activity Objective
In this activity. \ou will implement CCD using Cisco SAF clients and forwarders. After
completing this activity, you will be able to meet these objectives:
• Configure SAF forwarder functionality on the HQ-.t and BR-.r routers
• Contigurc Cisco Unified Communications Manager asan advertising and requesting SAF
client

• Configure Cisco Unified Communications Manager Express onthe BR-.r router asa
requesting SAF client

Visual Objective
The figure illustrates what you will accomplish inthis activity.

Lab 5-1: Implementing Cisco SAF


CCD

Phnnel-* Phane2-'

DHCP 1
4 ICx 30/24 ioy_;y

101

Enable CCD to
leam and advertise
call routing
information
"' Frame S^SS PSTN

s: Enable SAF. configure


SRST gateway to leam
call routing information

J2£
j&

Required Resources
These are the resources and equipment that arc required tocomplete this activitv:
Cisco Unified Communications Manager

Student PC

Cisco IP Phones

Cisco IOS MGCP gateway

H.323 galeway
PSTN with PSTN phone

Lab Guide 85
© 2010 Cisco Systems. Inc.
Step 15 From the Selecta Servicedrop-down menu, choose the EM service. Click Next.
Step 16 Click Subscribe, "fhe Cisco F.xiension Mobility service isdisplayed under
Subscribed Services.

Step 17 Click Save, then close the window.

Step 18 Click Reset in the Phone Configuration window to reset the phone.
Step 19 Repeat the previous steps (enabling Cisco Unified Communications Manager
Fxtension Mobility and subscribing tothe Cisco Extension Mobility IP phone
service) for Phone2-.r and Phone.Vr.

Note As an alternative loperforming steps 3to19 you could have activated the Enterprise
Subscription check box when configuring theCisco Extension Mobility IP phone service.
Enterprise subscriptions apply to all phones and to all device profiles.

Activity Verification
You have completed this task whenyou attain these results:
• You can log in and log out at Phone I-x, Phone2-jr, and Phone3-.r by performing Ihe
following steps:
Step 1 Press the Services button.

Step2 Choose the Cisco Extension Mobility service.


Step 3 Log in with username and PIN.

Step 4 The phone will reset and should (hen be loaded with your device profile, fhe
director, numbershouldchangeto 2405.
Step 5 Place calls to internal and external (PSTN) destination.

Note Cisco Extension Mobility does not modify device level settings such as region and location
ordevice CSS and AAR CSS. These parameters arenot configurable in the device profile.
The line CSS of the phone where a Cisco Extension Mobility user logs misupdated with the
line CSS of the device profile. In this lab. the line CSS isHQ_css. This CSS provides access
to theHQ translation patterns. Therefore, the PSTN dial rules ofthe HQ sitehave to be
used.

• The configured service parameters are working. This can be verified by performing the
following steps:
Step 1 Log in at Phone3-.v and place acall. Then wait for the maximum login timer (3
minutes) to expire. You should be automatically logged out when the timer expires.
Step 2 Log in again at Phone3,v. Verify that the call list was cleared alter logout: use the
Redial softkey and verify that the phone does not remember Ihe last destination.
Step 3 Do not log out. Log in at Phone 1-.t before the 3-minute timer expires. Once you
have logged in at Phone I-.t. you should be automatically logged out at Phone3-.v.
because the multiple login behavior has been set lo auto-logout.

Note After logging out or being logged out of a phone, the phone reconfigures itself to its standard
settings

84 Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Task 4: Add the Cisco Extension Mobility IP Phone Service and
Subscribe to IP Phones and Device Profiles
Inthistask, vou will addthe Cisco Fxtension Mobility IP phone service andsubscribe it to IP
phones and the device profile.

Activity Procedure
Complete these sleps:

Add the Cisco Extension Mobility IP Phone Service


Step 1 Go to Device >Device Settings >Phone Services and click Add New.
Step 2 Define the following fields and click Save:
• Sen. ice Name: EM

• ASCII Service: EM

• Service Description: Extension Mobility Login/Logoff


• Service URL:
hHp://10jc.l.l:8080/emapp/EMAppServlet?tlevice=#DKVICENAME#

Note The service URL is case-sensitive.

Service Category: XML Service


Service Type: Standard IP Phone Service
finable: Check

Note After you click Save, the Parameters pane will appear—Cisco Extension Mobility does not
need any additional parameters to be specified.

Subscribe Device Profiles to the Cisco Extension Mobility IP PhoneService


Step 3 Nav igate to Device >Device Settings >Device Profile and click the Find button.
Step4 Click the device profile andy_dp.
Step 5 At the Related Links, choose Subscribc/linsubscribe Services: then click Go.
Step 6 From the Select aService drop-down menu, choose the EM service. Click Next.
Step 7 Click Subscribe. The Cisco Extension Mobility service is displayed under
Subscribed Services.

Step 8 Click Save, then close the window.


Enable Cisco Unified Communications Manager Extension Mobility atthe Phones and
Subscribe the Cisco Extension Mobility IP Phone Service to IP Phones
Step 9 Nav igate to Device >Phone and click Eind.
Step 10 Open Phonel-a.
Step 11 In the Extension Information pane check the Enable Extension Mobility check box.
Step 12 At the Log Out Profile drop-down menu, choose Use Current Device Settings.
Step 13 Click Save and click OK in the pop-up window.
Step 14 At the Related Links choose Subscribc/linsubscribe Services: then click Co.
Lab Guide
© ;;010 Cisco Systems, Inc
Task 3: Add and Associate an End User with the User Device
Profile
In this task, you will add an end user to Cisco Unified Communications Manager and associate
this user with the newly created device profile.
Activity Procedure
Complete these steps:

Add New User Through Cisco Unified Communications Manager Administration


In Cisco Unified Communications Manager, configure an end user:
Step 1 from PC-.r. access Cisco Unified Communications Manager Administration.
Step 2 Go to Eser Management > End User and click Add New.
Step 3 Configure a user with the attributes that follow, and save the newly created account
by clicking Save at the bottom of" the page or the Save symbol at the top ofthe End
User Configuration window.
• UserID:andy
• Password: password
• PIN:12345

• Last Name: Szoldatics

• First Name: Andreas

Assign the Device Profile to the End User


Step 4 In the t.xtension Mobility pane of the End User Configuration window, from the
Available Profiles list, choose the profile andy_dp and add it to the Controlled
Profiles using the down arrow.
Steps Click Save.

Step 6 In User Management > End User, verify that the end user "andy" has been added to
Cisco Unified Communications Manager.
Activity Verification
You have completed thistaskwhen you attain these results:
• The end user "andv" is configured in User Management > End User as described in the
activity procedure.
• The device profile andy_dp is assigned to the end user as described in the activity
procedure.

82 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc
Task 2: Create a Device Profile for a User
In this task, vou will create a device profile for the user of Phone l-.v.

Activity Procedure
Complete these steps:
Step 1 Nav igate to Device >Device Settings >Device Profile.
Step 2 Click Add New.
Step 3 Tor ihe phone model, choose Cisco 7965. Click Next.
Step 4 Keep the SCCP signaling option and click Next.

Note If your Phonel -x is a different model, usethe model of your phone

Step 5 Filterthe following parameters:


• Device Profile Name: andy_dp
• Description: Device Profile-Andy
• User Hold MOH Audio Source: I-Samplc Audio Source
• User Locale: Knglish, I'nited States
• Phone Button Template: Standard 7965 SCCP

Note The phone button template depends on the phone model that you chose earlier.

• Soflkey Template: Standard User


Step 6 Click Save.
Step 7 In the Association Info pane, click the Line 111 Add anew DN link.
Step 8 lor the director) number, enter 2405.
Step 9 Choose the route partition Internal.
Step 10 Choose the CSS HQ_Phones_CSS.
Step 11 For the Exiemal Phone Number Mask value, enter +5551.v5552X\X.
Step 12 Click Save.

Activity Verification
You nav e completed this task when you attain these results:
• The new profile is configured in Dev ice >Device Settings >Device Profile as described in
the activity procedure.
• Director) number 2405 is associated with the new device profile andy_dp as described in
the activity procedure.

Lab Guide
© 2010 Cisco Systems, Inc
• H.323 gateway
• PSTN with PS'I N phone

Task 1: Activate the Cisco Extension Mobility Service and


Configure the Corresponding Service Parameters
In this task, you will activate the Cisco Extension Mobility service and configure Ihe login
behavior by setting ihe appropriate service parameters for the Cisco Extension Mobility service.
Activity Procedure
Complete these steps:
Step 1 Open Cisco Unified Serviceability.
Step 2 Go to Tools > Service Activation.
Step 3 Check the check box for the Cisco Extension Mobility service and click Save to
activate it.

Note The Cisco Extension Mobility service can be activated on multiple servers
Step 4 In Cisco Unified Communications Manager Administration, navigate to Systc
Service Parameters.

Step 5 From the Serverdrop-down menu, choose ltLv.1.1.


Step 6 From the Service drop-down menu, choose Cisco Extension Mobility.
Step 7 Configure the following parameters:
• Enforce Intra-Cluster Maximum Login Time: True
• Intra-Cluster Maximum Login Time: 0:03

Note
It is acommon configuration error to subscribe to the Cisco Extension Mobility service only
at the IP phone and not also at the device profile. In such a situation, you cannot log out of
the phone anymore once you have logged in. By setting the maximum login time to a
relatively low value, you have a back door for this case, because an auto logout is
performed after expiration of the maximum login time. This is a common setup for a lab
environment.

• Intra-Cluster Multiple Login Behavior: Auto Logout


• Remember the Last User Logged In:True
• Clear Call Log on Intra-Cluster EM: True
Steps Click Save.

Activity Verification
You have completed this task when vou attain these results:
• The Cisco Extension Mobility service parameters in System >Service Parameters tire
configured as described in the lask.

Note Further venfication will bedone in a later task of this lab exercise.

80
Implementing Cisco Unrfied Communications Manager, Part 2(CIPT2) ve.O ©2010 Cisco Systems, Inc
Lab 4-2: Implementing Cisco Extension Mobility
Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this activity. you will implement Cisco Extension Mobility for roaming users. After
completing this activity, you will be able to meet these objectives:
• Configure the sen ice parameters for Cisco Fxtension Mobility
• Create a device profile for a user
• Add an end user
• Associate the end user with the user deviceprofile
• Subscribe IP phones and device profiles to the IP phone service for Cisco Extension
Mobility

Visual Objective
The figure illustrates what vou will accomplish in this activity.

Lab 4-2: !rn


Mobility

=hpne'-< PI>one2
J Allow roaming
users to log in to
HCP ^T^DHCP any phone and
have personal
settings applied

Frame ^Sj PSTN


Relay

Allow roaming users to log


in to any phone and have
personal settings applied

Required Resources
These are the resources and equipment that arc required to complete this activity:
• One Cisco Unified Communications Manager cluster
• Student PC

• Cisco IP Phones
• Cisco IOS MGCP gateway

Lab Guide 79
© 2010 Cisco Systems. Inc
The local route group ofaroaming phone should be updated. Perform the following steps
for verification:

Stepl Nav igate to Device > Phone and click Find.


Step 2 Choose Phone2-.v.

Step 3 At the phone configuration window, click the View Current Device Mobility
Settings link next to the Device Mobility Mode parameter. Awindow will pop up,
show ing ihecurrent configuration of the phone.

Note
The local route group is nol shown in the pop-up window. You cannot verify that the local
route group has been updated by using the View Current Device Mobility Settings link.

Step 4 Log in to the HO-.v router and enable ISDN debugging with the debug isdn q931
command. Make sure to turn onmonitoring with the terminal monitor command.
Step 5 Shut down the ISDN interface at the branch router so that the gatcwav cannot be
used for TEHO calls to the BR PSTN.

Step 6 From the Phonc3-.v (which is currently roaming to the HQ site) place acall to the
BR PSTN by using the home dial rules (for example, 9 5554444). 'fhe call uses the
IIQ-.v gateway. This indicates that the local route group ofthe phone was updated by
the one configured in the roaming device pool.

78
Implementing Cisco Unified Communicatiot ;Manager, Part 2(CIPT2) v8.0
©2010 Cisco Systems, Inc.
Step 17 Click Save.
Step 18 Click Add New and enter the following parameters in the Device Mobility Into
Configuration window:
• Name: BR_dmi
• Subnet: KU.4.0

• Subnet Mask: 24
Step 19 Mov ethe Branch device pool from the Available Device Pools list to the Selected
Dev ice Pools list.

Step 20 Click Save.

Enable Device Mobility Mode for the Cluster


Step 21 Navigate to System>Service Parameters.
Step 22 from the Server drop-down list, choose Cisco Unilied Communications Manager
10-v.l.l.

Step 23 From die Service drop-down list, choose Cisco CallManager


Step 24 In Clusierwide Parameters (Device- Phone), set the Device Mobility Mode to On.
Activity Verification
You have completed this task when vou attain these results:
• Phones can register at different physical locations. Perform the following steps tor
verification:

Step 1 Disconnect Phonc2-.r and Phone3-.v from the switch port.


Step 2 Reconnect Phone2-.r to the port of Phone3--v.
Step 3 Reconnect Phone3-.v lothe port of Phone2-„v.
Step 4 Phone2-.v should register in the branch with its directory number 2002, and Phone3-A
should register in the headquarters with its directory number 300I.
Step 5 Place calls between any ofthe three phones.
• Roaming phones have their roaming-sensitive settings updated based on the configuration
in the roaming dev ice pool. Perform the following steps for verification:
Step 1 Nav igate to Device >Phone and click Find.
Step 2 Choose Phone2-.v.
Step 3 At the phone configuration window, click the View Current Device Mobility
Settings link next to the Device Mobility Mode parameter. Awindow is dtsplaved.
which showsthe currentconfiguration of the phone.
Step 4 Verifv that the headquarters phone adapted lo its new physical location (branch) by
changing the roaming-sensitive settings (such as the location, region, and SRS 1
reference).
Step 5 In order to sec that these updated settings are active, place acall from I'hone2-* lo
Phonel -.v. Press the ?button twice at both phones. The codec that is used tor the cal
should be G.729.

Note When it is in the home location, Phone2-x uses G.722 for calls to Phone1-x.

Lab Guide
i 2010 Cisco Systems. Inc
Task 1: Configure Device Mobility
In this task, vou will configure the Device Mobility feature so that roaming users can use their
home dial rules, but can aiso use the local route group as abackup path for TEHO PSTN calls.
Activity Procedure
Complete these steps:
Configure Physical Locations
Step 1 Nav igate to System > Physical Location and click the Add New button.
Step 2 In the Physical location Configuration window, enter the following parameters:
• Name: HQpl
• Description: Headquarters
Step 3 Click Save.

Step 4 Click Add New and configure another physical location for the branch office, with
the following parameters:
• Name: BR pi
• Description: Branch
Step 5 Click Save.

Note No DMGs are required. When no DMG is set at the roaming device pool and at the home
device pool, the device-mobility-related settings are not updated. In this lab, globalized call
routing is used. Therefore, there is no need to change the device CSS, AAR group, or AAR
CSS,as theyare the same at allphones.

Configure Device Pools


Step 6 Navigate to System > Device Pool andclickthe Find button.
Step 7 Choosethe device pool Default.
Step 8 From the Physical Location drop-down menu, choose IIQ_pl.
Step 9 Click Save and then reset the dev ice pool.
Step 10 In the Related finks pane, select Back To Find/List and then click Ihe Go button.
Step 11 Choosethe device pool Branch.
Step 12 From the Physical Location drop-down menu, choose BR__pl.
Step 13 Click Save and then reset the device pool.
Create Device Mobility Infos
Step 14 Nav igate to System >Device Mobility >Device Mobility Info and click Add New.
Step 15 Enter the following parameters in the Device Mobility Info Configuration window:
• Name: HQ_dmi
• Subnet: 10_v.2.0

• Subnet Mask: 24

Step 16 Move the Default device pool from the Available Device Pools list lo ihe Selected
Device Pools list.

76
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v*0©2010 Cisco Systems. Inc.
Lab 4-1: Implementing Device Mobility
Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this activitv. vou will enable the Device Mobility feature to help mobile users who roam
awav from their home location. After completing this activity, you will be able to meet these
objectives:
• Configure Device Mobility

Visual Objective
The figure illustrates what vou will accomplish in this activity.

Lab 4-1; Implementing Device

Required Resources
These are the resources and equipment that arc required to complete this activitv
• Cisco Unified Communications Manager
• Student PC

• Cisco IP Phones

• Cisco IOS MGCP gateway

• H.323 gateway
• PSTN with PSTN phone

Lab Guide 75
© 2010 Cisco Systems, Inc
Note The SIP trunk does not need to have access to the RSVP Agent media resource. Therefore,
MRGs and MRGLs do not have to be modified.

Step 4 Nav igate to Device >Device Settings >SIP Profile and click the Add button. mm
Step 5 In the Name field, enter SIPPrecondition, and scroll down lo the Trunk Specific
Configuration section. ^
Step 6 From the Reroute Incoming Request toNew Trunk Based On drop-down menu,
select Never. ' |L
Step 7 From the RSVP Over SIP drop-down menu, select E2E and at theSIPRel IXX
Options, choose Send PRACK if Ixx Contains SDP. 'mt
Step 8 Go to the configuration page ofthe existing trunk called SIPJI'runk.
Step 9 From the SIP Profile drop down menu, select SIP_Precondition and click Save and **
Apply.

Configure the RSVP Bandwidth at the IP WAN Interface That Connects to the Other Pod "**
Step 10 At the subinterface that interconnects the headquarters and the other pod, configure jjL
the bandwidth thatcan bereserved by RSVP as follows:
interface Serial... s«-
ip rsvp bandwidth 4 0

Test RSVP SIP Preconditions CAC 'L*

Note Check that the configuration of the other pod is also completed before continuing.

Step 11 Establish one call between your local headquarters phone and the other headquarter
phone at the other pod and keep the call open. Try to set up asecond call by calling
the second headquarter phone for the other pod. The second call should be rerouted
over the PSTN Use the debug isdn q931 command toverify thai the call is sent
through the PSTN. The show seep connections rsvp command can be used toshow
the currently active connections atthe RSVP agent.
Activity Verification
You have completed this task when you attain these results: in
• You configured SIP Preconditions between the two pods as described in the activity
procedure.

You can place one call between the two pods over the SIP trunk and end-to-end RSVP is ^
used for that call as described inthe activity procedure.
When placing an additional call, the PSTN is used as abackup as described in the activity jk
procedure.

Note Make sure lo turn off all of the debug commands at all of the routers (use no debug alt
command).

2.

Implementing Cisco Unified Communications Manager, Part 2(CIPT2) V8.0 ©2010 Cisco Systems, Inc.
Step 19 Repeat the previous steps for Phonc2-* and Phone3-x
Modifying the RSVP Bandwidth So That All Calls Fail
Step 20 Reconfigure the RSVP bandwidth on one of the two routers to avalue below 40
kb/s. This will make all calls between branch and headquarters fail.
Step 21 Try calls between the headquarters and branch. The calls should be rerouted through
ihe PSTN.

Configure One Phone for an Alternate CFNB Destination


Step 22 Change the configuration of the Phonel-.v line so that calls arc forwarded to aPSTN
number if2001 cannot he reached because ofCAC. Set the AAR destination mask
to +556065554444.
Step 23 Try to call 2001 from the branch phone. The call should be sent to the PSTN phone
using the BR gateway.

Allowing Calls over IP WAN Again


Step 24 Change the RSVP bandwidth back to40 on both routers.
Step 25 Verify that one call between the headquarters and branch uses the IP WAN. Keep
that call open. Tr> calling the branch phone from another phone in the headquarters.
You should see an incoming call at the branch phone (which is still in a call) coming
through the PSTN. You can use the debug isdn q931 command to verify that calls
arc using the PSTN path. The show seep connections rsvp command can be used to
s,hou the currently active connections at the RSVP agent.

Cleanup
Step 26 Remov ethe (TNB setting at Phone 1-x by clearing the AAR destination mask at
line 1.

Activity Verification
You have completed this task when vou attain these results:
• When intracluster calls are rejected because there is no available bandwidth, the calls are
rerouted over the PSTN as described in the activity procedure.

Note Make sure to turn off all of the debug commands atall of the routers (use the no debug all
command) ^

Task 4 (Optional): Configure SIP Preconditions


In this task, you will modify the previously implemented RSVP-bascd CAC to implement end-
to-end CAC for calls between pod 1 and pod 2.

Activity Procedure
Complete these steps:
Enable End-to-End RSVP to Be Used for Calls Between the Two Pods Using the SIP Trunk
SIP Preconditions-based CAC should allow one Ci.729 call between the two pods.
Step 1 Cio to the configuration page of the existing location called Trunk.
Step 2 Prom fhe Modifv Settings) to Other Locations pane, select the Iliib_None location,
and from the RSVP Setting drop down menu, choose Mandatory (V ideo Desired).
Step 3 Click Save.
Lab Guide 73
© 2010 Cisco Systems. Inc
Task 3: Configure AAR and CFNB to Route Calls over the PSTN
If They Are Not Admitted by the Deployed CAC Methods
In this task, you will configure a backup path for calls that are rejected by the previously
implemented CAC methods. These calls will be rerouted over the PSTN using AAR and
CFNB.

Activity Procedure
Complete these steps:
Enable AAR

In the following steps, you will enable AAR by setting the Cisco CallManager service
parameter Automated Alternate RoutingEnabled to True.
Step 1 Navigate to System > Service Parameters and choosethe Cisco Unified
Communications Manager(IOjc.1.1).
Step 2 From the Service drop-down menu, choose Cisco CallManager.
Step 3 Locate the Clusterwide Parameters(System—CCM Automated Alternate
Routing) pane.
Step 4 Set the Automated Alternate Routing Enable parameters toTrue.
Step 5 Click Save.

Configure an AAR Group


Step 6 Navigate to Call Routing> AAR groups and click Add New.
Step 7 Enterthe name System_aar.
Step 8 Click Save.

Configuring Phones for AAR


Step 9 Navigate to Device > Phone and click Find.
Step 10 Choose Phonel-x.

Step 11 Click Line 1toget tothe Director) Number Configuration window.


Step 12 In the AAR Settings pane, choose System_AAR for the AAR Group.
Step 13 Verify that the external phone number mask isin globalized format.
Step 14 Click Save.

Step 15 From the Related Links, choose Configure Device and click <;».
Step 16 At the Phone Configuration window, choose Global ess for the AAR CSS.

Note When acall between the HQ and BR sites is not admitted, AAR will be used to place the call
over the PSTN The AAR call will match the Wtranslation pattern first, and then the TEHO
pattern of the local pod. The first option of the route list that is applied to the TEHO pattern is
the TEHO gateway. This, however, cannot be used, because there Is not enough bandwidth
available between the HQ and BR sites. Therefore, the second option of the route list is
used—the local route group.

Step 17 Click Save and then OK in the pop-up window.


Step 18 Reset the phone.

72 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc
Step 19 Click Save.

Put the RSVP Agents Into MRGs


Step 20 Add the HQ-RSVP RSVP agent to the HQ_mrg MRG.
Step 21 Add the BR-RSYP RSVP agent tothe BR-SW-CFB_mrg MRG.
Test RSVP CAC

Note The RSVP configuration has to be performed onboth sides. Unless both sides are
configured for RSVP, the call will fail.

Step 22 Place a call between aheadquarters phone and a branch phone. The call should fail.
Step 23 Use the debug ip rsvp signaling command on the I\Q-x router to see why the
reservation fails. Ilow much bandwidth do you expect to be reserved? How much is
aetuallv reserved0

Note During the call setup phase, the RSVP agents always attempt to reserve an additional 16
kb/s (for signaling). Therefore, in this case, the RSVP bandwidth atthe interface must allow
40 kb/s for the call togothrough. The extra 16 kb/s that that the RSVP agents attempt to
reserve during call setup areimmediately released once the call issetup end-to-end.

Step 24 Change the RSVP bandwidth at the IP WAN interfaces on the IIQ-jc and on the BR-
.i routers to 40 kb/s. Now the calls should go through. If you want, you can retry
with 39kb/s tomake sure that 40 kb/s isthe absolute minimum for one G.729 call to
be allowed. Make surethat youset it back to 40 kb/safterward.
interface serial...
ip rsvp bandwidth 4 0

Note The RSVP bandwidth command has tobemodified on both sides. Unless both sides permit
enough bandwidth for RSVP, thecall will fail. . ^

Step 25 I stablish one call between a headquarters phone and the branch phone and keep the
call open. Try to set up asecond call by calling the branch phone directory number
from the other phone inihe headquarters. The call should fail.
Activity Verification
You have completed this task when you attain these results:
• You modified Cisco Unified Communications Manager CAC between the IIub_None and
the branch locations to use RSVP asdescribed intheactivity procedure.
• RSVP permits one G.729 call between these two locations. Additional calls fail, because of
a lack ofavailable bandwidth asdescribed inthe activity procedure.

Note Make sure to turn off all of the debug commands at all of the routers (use the no debug all
command) ^

Lab Guide
) 2010 Cisco Systems. Inc
dspfarm profile 2 mtp
codec pass-through
rsvp

maximum sessions software 2


associate application SCCP
no shutdown

Configure the RSVP Bandwidth atthe IP WAN Interfaces ofthe Routers


Steps On the main Frame-Relay serial interface, enable fair queuing, as follows:
interface Serial...
bandwidth 2000
fair-queue

Note Use the main interface that is connected to the Frame Relay network (PSTN router).
Step 9 At the subinterface that interconnects the headquarters and the branch router,
configure the bandwidth that is allowed to be reserved by RSVP as follows:'
interface Serial...
ip rsvp bandwidth 24
Step 10 Save the configuration to NVRAM.
Step 11 Repeat the above steps (configure Cisco IOS routers to provide RSVP agent MTP
resources and configure the RSVP bandwidth onthe IPWAN interfaces of the
routers) at your BR-x router. When configuring the media resource, use the name
BR-RSVP instead ofHQ-RSVP in the associate profile command.
Add the RSVP Agents (MTPs) in Cisco Unified Communications Manager
Step 12 In Cisco Unified Communications Manager Administration, navigate to Media
Resources >Media Termination Point and click Add New.
Step 13 Verify that the Media Termination Point Type value isCisco IOS Enhanced
Software Media Termination Point.
Step 14 Enter HQ-RSVP for the Media Termination Point Name value.

Note Tne name ofthe media resource iscase-sensitive.

Step 15 Hnter HQ-* RSVP Agent for the description.


Step 16 Choosethe device pool Default.

Note
The location Hob^None and region HQ are applied to the HQ-RSVP media resource
through the device pool Default.

Step 17 Click Save.

Step 18 Click Copy and change the name to BR-RSVP, the description to HR-a RSVP
Agent, and device pool to BR.

Note
The location Branch and region BR are applied to the HQ-RSVP media resource through the
device pool Branch.

70
implementing Cisco Unmed Communications Manager. Part 2(CIPT2, ,8.0 ' ©2010 Cisco Systems, Inc.
Step 12 Repeat the previous steps lo apply the llub_Nonc location to the MOH.Only
device pool.
Step 13 Repeat the previous steps to apply the Branch location to the BR device pool.
Step 14 Nav igate lo Device >Trunk and click the Find button.
Step 15 Choose the SIP_Trunk.
Step 16 From the location drop-down menu, choose Trunk.
Step 17 Click Save and reset the trunk.

Activity Verification
You have completed this task when you attain these results:
• You have configured and applied locations as specified in the activity procedure.
• You cannot place more than one call to the other cluster using the SIP trunk (by dialing
851 v-2001. 85 ly-2002. or 852v-300l). The G.729 codec should be in use lor ibis call.
• You cannot place more than one call to the branch phone (by dialing 3001). The (G.729
codec should be in use for this call.

Task 2: Configure RSVP-Enabled Locations


In this task vou will change the previously implemented locations-based CAC to use RSVP in
the IP WAN for calls between the Hub^Nonc and Branch locations. 1his will be done bv
deploying RSVP agents at the headquarters and branch sites.
Activity Procedure
Complete these steps:
Enable RSVP to Be Used Between the Hub_None and the Branch Locations
In the following steps, vou will change the branch location so that it uses RSVP toward the
1lubNone location. RSVP should be mandatory between these two locations.
Step 1 Nav igaie to System >Locations and click the Find button.
Step 2 Click Branch.
Step 3 In the Modifv Sctting(s) to Other Locations pane, from the RSVP Setting drop-down
menu, choose the Hub_Nonc location and choose M»ndatory(Vidco Desired).
Step 4 Click Save. You should see the changes in the Location RSVP Settings pane.
Step 5
Click the Resync Bandwidth button to reset all CAC bandwidth usage, and click
OK in the pop-up window.

Note RSVP is configured per pair of locations. The setting applies to both directions. Therefore,
the configuration that you apply to one location automatically updates the other location
accordingly .

Configure Cisco IOS Routers to Provide RSVP Agent MTP Resources


StepG Connect to your HQ-jc router.
Step 7 Configure router IIQ-.v asfollows:
seep ccm group 1
associate profile 2 register HQ-RSVP

Lab Guide 69
© 2010 Cisco Systems. Inc
H.323 gateway
PSTN with PSTN phone

Job Aids
This job aid is available to help you complete the lab activity.

Location Configuration
Name Allowed Bandwidth Applied To Device Applied To Device
Pool

Hub_None Unlimited Default


MOH_0nly
Branch 24 kb/s Branch

Trunk 24 kb/s
SIPJTrunk

Task 1: Configure Locations


In this task you will configure locations-based CAC for calls between the headquarters, branch
and SIP trunk.

Activity Procedure
Complete these steps:
Add Locations to Cisco Unified Communications Manager
Create new locations as described in the "Location Configuration" table in the .lob Aids section.
Step 1 Navigate to System > Location and click the Find button.
Step 2
Click the location name Hub_None to enter the Location Configuration window.
Step 3 Make sure that the Hub^None location has unlimited audio bandwidth.
Step 4 Click the Add New button.
Step 5 Configure anew location with the following parameters:
• Name: Branch

• Audio bandwidth should be limited to 24 kb/s


Step 6 Click Save.
Step 7
Repeat the previous steps to configure the remaining location with the location name
Trunk as described in the "Location Configuration" table in Ihe Job Aids section.
Apply Locations to Devices

Apply the newly created locations to devices, through the device pool or directly, as described
inthe Location Configuration" table in the Job Aids section.
Steps Navigate to System > Device Pool and click the Find button.
Steps
Choose Default to enter the Device Pool Configuration window for device pool
Default. •

Step 10 From the Location drop-down menu, choose HubJSonc.


Step 11 Click Save and reset the device pool.

68
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 >2010 Cisco Systems, Inc.
Lab 3-2: Implementing CAC
Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this ael.v itv. vou will implement CAC by configuring locations and deploying RSVP agents
to prevent WAN bandwidth oversubscription. You will implement AAR to route calls over the
PSTN ifthev were not admitted bv locations-based CAC. Then you will mplement SIP
Precondition's in order to implement end-to-end CAC for the SIP trunk to the other pod. After
completing this activity, you will be able lo meet these objectives:
• Configure standard locations
• Configure RSVP-enabled locations
i Configure AAR to route calls over the PSTN ifthey arc not admitted by the deployed CAC
methods

• Configure SIP Preconditions

Visual Objective
fhe figure illustrates what vou will accomplish in this activity.

Configure
locations. RSVP
agents. AAR, and
' _^- SIP Preconditions

HQ-.

;ۤ

Required Resources
These arc the resources and equipment that are required to complete this activity:
• Cisco Unified Communications Manager
• Student PC

• Cisco IP Phones

• Cisco IOS MGCP gateway

Lab Guide
2010 Cisco Systems. Inc
Enable Multicast MOH from Branch Router Flash at the BR-x SRST Router
Step 51 Configure the branch router as follows: Hi
telephony-service
multicast moh 239.1.1.1 port 16384 route 10.x.4.102 El

Note The moh moh-file-name command that is used to enable unicast MOH in SRST mode -
already configured in an earlier lab exercise.

Step 52 Saveyour configuration to NVRAM.


Verify That Multicast MOH from Branch Router Flash Works
Step 53 Place acall from Phonel-* to Phone3-*, and at Phonel-*, put the call on hold
Phone3-* should play MOH. Keep the call in this state.
Step 54 Pressthe Settings button at Phone3-x
Step 55 Choose option 2 Network Configuration.
Step 56 Press 6orscroll down toget tooption 6 IPAddress.
Step 57 Write down the IP address ofPhone3-*: 10. .4.
Step 58 Using a web browser, browse tothe IP address of Phone3-.v.
Step 59 Click the Stream 1link to see details about the current RTP stream.
Step 60
The local address should be 239.1.1.1/16384, which indicates thai the phone listens
to the multicast MOH stream.

Note The phone now plays the locally generated multicast MOH stream.
' ' . ___ -•*&•

Activity Verification
You have completed this task when you attain these results: Si
• Branch phones can play MOH created by the local SRST router as described in the activity e
procedure. J ^

Note More detailed verification was pan of the Activity Procedure.

Hm%

m*

66
Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0
©2010 Cisco Systems, Inc.
Step 42 Press the Settings button atPhone3-.v.
Step 43 Choose option 2 Network Configuration.
Step 44 Press 6or scroll down to get to option 6. IP Address.
Step 45 Write down the IP address ofPhone3-.v: 10. .4.
Step 46 Using aweb browser, browse to the IP address of Phone3-.r.
Note If you did not enable web access to the phone earlier, you need to enable it now, in order to
be ableto browse to the phone.

Step 47 Click the Stream 1link to see details about the current RTP stream.
Step 48
The local address should be 239.1.1.1/16384, which indicates that the phone listens
to the multicast MOH stream. Keep the call in this stale so that you hear MOH.
PreventMulticast MOH from Being Sent overthe IP WAN
Step 49 At router HQ-.t. disable multicast routing toward the branch by entering the
following commands:
interface Serial...
no ip pim sparse-dense-mode

Note Use the interface that connects to the BR-x router (IP WAN).

Note
As soon as you enter the above commands, Phone3-x should not play MOH anymore Nor
will it play TOH, because Cisco Unified Communications Manager is unaware that the phone
nolonger receives theMOH audio stream _____

Step 50 At router BR-.r. disable multicast routing by entering the following commands:
interface Serial...
no ip pim sparse-dense-mode

Note Use the interface that connects to the HQ-x router (IP WAN)

interface FastEthernet...
no ip pim sparse-dense-mode

no ip multicast-routing

Note Use the interface that connects to the branch phones.

Note
Mullicast MOH in SRST does not require multicast routing. It simply streams permanently at
the interface that is configured to be used by SRST. If the stream is requ.red on adifferent
mterface (for example, when using aloopback for SRST) the interface or interfaces can be
specified using the route option of the multicast moh command (as shown in the next step)

Lab Guide 65
© 2010 Cisco Systems, Inc.
m
At this point, the MOH server shares the same region with all other headquarters devices To
limit calls to these other devices to G.729 but allow G.7I Ibetween the MOH server and the
branch phones, the MOH server needs to be placed into aseparate, dedicated region In
addition, the multicast MOH stream that is generated by the MOH server has to be blocked
from the IP WAN. Then multicast MOH can be enabled at the BR-* SRST router.
Allow G.711 Between the MOH Server and Branch Phones
it
Step 29 In Cisco Unified Communications Manager Administration, navigate to System >
Region and click Add New.
k
Step 30 Enter MOH for the name and click Save.
Step 31 Using the Modify Relationship to other Regions pane, allow the G.722 and G711 &
audio codecs to be used to the region HQ by highlighting the region HQ in the
Regions list and choosing G.722/G.711 from the Audio Codec drop-down menu £.
Click Save. mt

Step 32 Using the same technique, also allow the G.722 and G.711 audio codecs for calls m\
between the region MOH and the region BR and for calls within the region MOH.
Allow G.729 only for calls between the regions MOH and Trunks. m
Note
You must click Save after each change in the Modify Relationship to Other Regions pane
The changes will then appear in the Region Relationships pane.

Note By limiting the audio codec to G.729 for calls between regions Trunks and MOH you
effectively disable MOH for these calls. The reason is that the MOH server is only streaming
G.711 multicast MOH, and a multicast stream cannot be transcoded (which would be
required toward the region Trunks). This is desired, because G.729 MOH has only poor
quality, and G.711 must not be sent over the IP WAN (used by the trunks).

Step33 Navigate to System > Device Pool andclickAdd New.


Step 34 Configure the following parameters for the new device pool:
• Device Pool Name: MOH_Only
• Cisco Unified Communications Manager Group: Default
• DateATime Group: CMLocal
• Region: MOH

• SRST Reference: Disable


Step 35 Click Save.

Step 36 Navigate to Media Resources >Music On Hold Server and click lind.
Step 37 Choose HQ-SVV-MOH.
Step 38 Change the device pool from Default to MOH_Only.
Step 39 Click Save.

Step 40 Reset the MOII server.

Verify That Multicast MOH Now Works to Branch Phones


Step 41 Place acall from Phone I,r to Phone3-x, and at Phone I-x put (lie call on hold
Phone3-.v should play MOH. Keep the call inthis state.
64
Implementing Cisco Unified Communications Manager. Par. 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Verify That Multicast MOH Is Used
Step 20 Place acall from Phonel-* to Phone2-x. and at Phoncl-x. put the call on hold.
Phone2-.v should play MOH. Keep the call inthis slate.
Step 21 Press the Settings button at Phonc2-.v.
Step 22 Choose option 2 Network Configuration.
Step 23 Press 6or scroll down to get to option 6, IP Address.
Step24 Writedown the IP address of Phonc2-.x: 10. .2. _
Step 25 Using aweb browser, browse to the IP address ofPhone2-v.
Note If you did not enable web access to the phone earlier, you need to enable it now, in order to
be able to browse to the phone.

Step 26 Click the Stream I link to see details about the current RIP stream.
Step 27 The Local Address should be 239.1.1.1 /16384. which indicates that the phone listens
lo the multicast MOH stream.
Step 28 Place acall from Phone I-x to Phone3-.v. and at Phone I-x put the call on hold.
Phonc3-.v will play lone on hold only.

Note The reason that Phone3-x will play tone on hold instead of MOH is that the MOH server is
configured for G.711 MOH only (this is the default configuration). However, before changing
to multicast MOH, Phone3-x played MOH. This was possible by using the transcoder media
resource The MOH server is configured with the device pool Default, which applies region
HQ and MRGL HQ_mrgl. This MRGL allows the MOH server to access the transcoder

Such a configuration is not recommended, because if MOH with the G.729 codec should be
permitted, it can be directly enabled on the MOH server (by using the Supported MOH
Codecs service parameter of the Cisco IP Voice Media Streaming Application service)
Using G.729 for MOH, however, is not recommended, because the G.729 codec audio
quality for music is poor; G.729 is designed and optimized for human speech, and does not
work well with music.

Multicast audio streams cannot be transcoded, sobranch phones do not hear MOH
anymore, because the MOH server was configured to use multicast MOH instead of unicast
MOH You will solve this problem by implementing multicast MOH from branch router flash.

Enable Multicast MOH from Branch Router Flash


When using multicast MOH from branch router flash, the branch router locally generates a
multicast MOH stream. This stream must use attributes (destination address -that is. multicast
group address-port numbers, and codec) that are identical to the attributes tor the multicast
MOH stream that is generated by the Cisco Unified Communications Manager MOH server
that is located at the headquarters. This is required because neither Cisco Unified
Communications Manager nor the branch IP phones are aware that the phones listen to astream
generated bv the local SRST gateway. Cisco Unified Communications Manager tel sthe phone
lo listen to its stream (providing the attributes that were mentioned belore) in signaling
messages, and. therefore, the locally generated stream has to look exactly that way.
Because SRST MOH supports only G.711, Cisco Unified Communications Manager also has to
instruct the phone to listen to aG.711 MOH stream. Consequently. G.711 must be enabled
between branch phones and the MOH server in region configuration.
Lab Guide 63
© 2010 Cisco Systems. Inc
Update MRGs to Use Multicast
Step 14 Navigate to Media Resources >Media Resource Group and click the Find button.
Step 15 Choose the Generalmrg MRG.
Step 16 Ifat least one multicast HQ-SW-MOI Iresource is available, cheek the Use
Multicast for HQ-SW-MOH Audio check box in the Media Resource Group
Configuration window.
Step 17 Click Save.

Enable Multicast Routing in the Network


Step 18 At router HQ-*, enable multicast routing using the following commands:
ip multicast-routing

interface FastEthernet...
ip pim sparse-dense-mode

Note Use the interface that connects to the voice server network (CUCM-x).
interface FastEthernet...
ip pim sparse-dense-mode

Note Use the interface that connects to the headquarters phones.


interface Serial...
ip pim sparse-dense-mode

Note Use the interface that connects to the BR-x router (IP WAN).

Step 19 At router BR-*, enable multicast routing using the following commands;
ip multicast-routing

interface Serial...
ip pim sparse-dense-mode

Note Use the interface that connects to the HQ-x router (IP WAN).
interface FastEthernet...
ip pim sparse-dense-mode

Note Use the interface that connects toIhe branch phones.

Note
Multicast routing is now enabled for the voice server network, the headquarters phone
network, the branch phone network, and the link between HQ-x and BR-x (IP WAN).

62
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0
12010 Cisco Systems, Inc.
Stepl Initiate an ad hoc conference from Phone3-jr (adding Phonel-* and Phone2,v>.
Step 2 At each IP phone, press the ?button twice. Phonel-.v and Phonc2-.v should use the
G729 codec and Phone3-j should use the G.711 codec. This is because the
conference bridge is at the branch and G.7I I is only allowed locally at the branch
butnotbetween branch and headquarters. Keep the call open.
Step 3 At BR-.r. enter the show dspfarm cisp all command. You should see three used
connections representing the three conference participants.
Step 4 r.nd the conference. Verifv thai all DSP resources arc freed by entering the sho»
dspfarm dsp all command again.
Step 5 Repeat the previous steps but initiate the conference from Phone I-x or Phonc2-.v.
1his time Phonel-.v and Phone2-Jc should use G.7I I and Phone3,v should use G.729.
The show dspfarm dsp all command will indicate that no conference resources are
used at BR-.v. Issue the same command at I\Q-x and you will see atranscoder
session for the connection of Phone.V.v to the conference bridge.

Task 5: Implement Multicast MOH from Branch Router Flash


In this task vou will first implement multicast MOII. Then you will implement multicast MOII
from branch'routcr Hash. This allows branch users to listen to MOH. but prevents the MOII
streams from being sent over the IP WAN.

Activity Procedure
Complete these steps:
Enable Multicast MOH in Cisco Unified Communications Manager
Step 1 In Cisco Unified Communications Manager Administration, navigate to Media
Resources >Music On Hold Audio Source and click the Find button.
Step 2 Choose the onlv available audio source and verify that the Play Continuously check
box is checked.

Step 3 Check the Allow Multicasting check box.


Step 4 Click Save.
Step 5 Nav igate to Media Resources >Music On Hold Server and click ihe Find button.
Step G Click the only available MOI Iserver (HO-SW-MOH).
Step 7 Under Multicast Audio Source Information, check the Enable Multicast Audio
Sources on This MOH Server check box.
Steps Click Save.
Step 9 Verify the following parameters under Multicast Audio Source Information:
• Base Multicast IP Address: 239.1.1.1
• Base Multicast Port Number: 16384
Step 10 Change the Increment Multicast value from Port Number to IP Address.
Step 11 Under Selected Multicast Audio Sources, set the Max Hops value for the multicast-
enabled audio source to 3.
Step 12 Click Save.
Step 13 Reset the MOII server.

Lab Guide
© 2010 Cisco Systems, Inc.
Step 17 Enter HQ_mrg for the name of the MRG.
Step 18 Enter HQ SW Conference Bridge for the description.
Step 19 From the Available Media Resources pane, add HQ-SW-CFB to the Selected Media
Resources list.

Step 20 Click Save.


mh
Step 21 Repeat the previous steps to add the other two MRGs, as described in the "Media
Resource Group Configuration" table in theJobAids section.
Create MRGLs

In these steps, you will configure dilTerenl MRGLs that allow IP phones to use their local t*
conference bridge.
Step 22 Navigate to Media Resources> Media Resource Group List. **
Step 23 Click the Add Newbutton. __
Step 24 Enter HQ_mrgl for the name of the MRGL.
Step 25 From the Available Media Resource Groups pane, add the HQ-SW-CFB and m,
General_mrg MRGs to the Selected Media Resource Groups list.
Step 26 Click Save. »

Step 27 Repeat the previous steps to add the other MRGL, as described in the "Media
Resource Group List Configuration1" table in the Job Aids section. H
Assign MRGLs to Devices

In these steps, you will assign the newly created MRGLs to devices (phones, trunks and "*
gateways) by configuring the appropriate MRGL in the available device pools. ' m,
Step 28 Navigate to System > Device Pooland click Find.
Step 29 Choosethe device pool Default. tt
Step 30 From the Media Resource Group List drop-down menu, choose IIQ_mrgl.
Step 31 Click Save. W
Step 32 Reset the device pool. m
Step 33 Repeat the previous steps for the other two device pools, assigning the MRGLs as
described in the "Device Pool Configuration" table in the Job Aids section. M
Activity Verification
You have completed this task when you attain these results: •
• BR-.v provides aconference hardware media resource (BR-HW-CFB) lhat is registered m
with Cisco Unified Communications Manager. Perform the following steps at router BR-v ""
to verity the hardware media resource configuration and status-
mh
Step 1 Enter the show seep command. Verify that the Conferencing Oper Stale is ACTIVE
and that the TCP Link Status is CONNECTED. m
Step 2 Enter the show dspfarm profile 1command. Verify the stains, number ofavailable
resources, and the listof supported codecs. m
• Conferences that are initiated by headquarters phones use the software eonlerenee bridge
that ,s located at the headquarters; branch phones use the hardware conference bridge that J£
is located at the branch. Verify this by performing the following steps- "
60 Imptemenflng Cisco Unified Communications Manger, Part 2(CIPT2) v8.0 ©20)0 Cisco Systems, Inc.
Step 3 To configure the router DSP resources that are to be used as ahardware conference
bridge, enter this sequence ofcommands:
voice-card 0

dspfarm
dsp services dspfarm

seep local loopbackO


seep ccm 10.x.1.1 identifier 1 version 7+
seep

seep ccm group 1


associate ccm 1 priority 1
associate profile l register BR-HW-CFB
1
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 2
associate application SCCP
no shutdown

Step 4 Save the configuration to NVRAM.


Add the Cisco IOS Hardware Conference Bridge to Cisco Unified Communications Manager
for the Branch
Step 5 Nav igate to Media Resources >Conference Bridge.
Step 6 Click Add New
Step 7 From the Conference Bridge Type drop-down menu, choose Cisco IOS Fnhanced
Conference Bridge.
Step 8 Inter BR-HW-CFB for ihe name ofthe media resource.

Note Themedia resource name is case-sensitive.

Step 9 Lnter Hardware Conference Bridge at BR-a" for the description.


Step 10 Apply device pool BR to the transcoder. This device pool is configured with the
region BR.
Step 11 Set the device security mode to Non Secure Conference Bridge.
Step 12 Click Save.
Step 13 Reset the newly created conference bridge.
Step 14 Verily the registration status. It should say Registered with Cisco Unified
Communications Manager 10..V.L1.

Create MRGs
Step 15 Nav igate to Media Resources >Media Resource Group.
Step 16 Click the Add New button.

Lab Guide 59
© 2010 Cisco Systems. Inc
Step 6 From the Transcoder Type drop-down menu, choose Cisco IOS Knhanced Media
Termination Point.

Step 7 Enter Hardware Transcoder at HQ-x for the description.


Step 8 Enter HQ-HVV-XCD forthename of themedia resource.

Note The media resource name is case-sensitive.

Step 9 Apply the device pool Default to the transcoder. This device pool is configured with ^
the region HQ.
Step 10 Click Save. j*
Step 11 Reset the newly created transcoder.
Step 12 Verify the registration status. Itshould say Registered with Cisco Unified ""
Communications Manager 10jr. I. I.
Activity Verification **
You have completed this task when you attain these results: §^
• HQ-* provides atranscoding hardware media resource (HQ-HW-XCD) that is registered
with Cisco Unified Communications Manager. Perform the following steps at router HQ-* H
toverify the hardware media resource configuration and status:
Step 1 Enter the show seep command. Verify that the Transcoding Oper State is ACTIVE Bl
and that the TCP Link Status is CONNECTED.
Step 2 Enter the show dspfarm profile I command. Verify the status, number of available &
resources, and the list of supported codecs.
• Branch phones can now join conferences on the G.711-only software conference bridge 1*
even though they are not allowed to use the G.711 codec over the IP WAN. Verify this by
performing the following steps: m
Step 1 Set up an ad hoc conference with Phonel-*, Phone2-*, and Phone3-.v as members.
Step 2 At each IP phone press the ?button twice. Phonel-* and Phone2-.r should show the ^
G.711 codec being used for the call, while Phone3-* shows G.729.
Step 3 At HQ-.v. enter the show dspfarm dsp all command. You should see two used *
connections representing the two call legs ofthe transcoder (G.711 tothe software
conference bndge and G.729 to Phone3-*). §fc
Task 4: Implement a Hardware Conference Bridge m
In this task, you will configure alocal hardware conference bridge at the branch You will
implement MRGs and MRGLs to ensure that IP phones use the local conference media Mi.
resource. am

Activity Procedure jfc


Complete these steps:

Configure aCisco IOS Router as aHardware Conference Media Resource for the Branch
Step 1 Connect to your BR-*. f&
Step 2 Enter configuration mode.

58
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0
12010 Cisco Systems, Inc.
Task 3: Implement Transcoders
In this task vou will implement atranscoder at the headquarters in order lo allow branch users
to join confe'renccs on aG.711-only software conference bridge, even though branch phones
are not allowed to use G.711 over the IP WAN. The transcoder will transcode the (..729 audio
stream that is received from branch phones to aG.711 stream toward the software conference
bridge and vice versa.

Activity Procedure
Complete these steps:
Configure a Transcoder Media Resource in Cisco IOS Software
Configure the IIQ-.v router as a transcoder resource.
Step 1 Connect to \our HQ-.* and enter configuration mode.
Step 2 To configure router DSP resources to be used as atranscoder. enter this sequence of
commands:
voice-card 0
dspfarm
dsp services dspfarm
i

seep local loopbackO


seep ccm 10.x.1.1 identifier 1 version 7+

Note The highest possible SCCP version that can be specified in the seep ccm command
depends on the Cisco IOS Software release that is used on the router.

seep

seep ccm group 1


associate ccm 1 priority 1
associate profile 1 register HQ-HW-XCD

dspfarm profile l transcode


codec g7llulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 2
associate application SCCP
no shutdown

Step 3 Save the configuration to NVRAM.


Add theTranscoder to Cisco Unified Communications Manager
Add the transcoder to Cisco Unified Communications Manager and assign adevice pool that
uses the region HQ.
Step 4 Navigate to Media Resources >Transcoder.
Steps Click Add New.

Lab Guide
)2010 Cisco Systems. Inc
Step 35 Change thedevice pool from Default to BR.
Step 36 Click Save.

Step 37 Reset the gateway in Cisco Unified Communications Manager and reset the MGCP
process at the BR gateway by entering the no mgcp command, followed by the
mgcp
morn command.
rnmmnniH

I*
Note
You already verified the device pool configuration (and hence the region assignment) of the
software media resources in the previous task. All software media resources are configured
with the device pool Default

Activity Verification
You have completed this task when you attain these results:
• Place test calls between the following phones and while on acall press the 7button on the
IP phone two times. The IP phone will display call information that includes the codec thai
is used for the call:

— Phone 1,r or Phone2-* and the PSTN (for example, 0 112): This call should use
G.711.

— Phone I-x or Phone2-j; and any phone that is located in the other pod (for example
dial851y2001):ThiscallshoulduseC..729. '
— Phonel-j and Phone2-.r: This call should use G.722.
— Phonel-.t orPhone2-;r and Phone3-*: This call should use G.729.
— Phone3-.v and the PSTN (for example, dial 9 911): This call should use G.711.
— Phone3-.v and any phone that islocated in the other pod (for cxumnle dial 851 v
2001 ):This call should use G.729.

Tip You can also view information about active calls of an IP phone by using aweb browser to
browse to the IP address of the IP phone. The built-in web server of the phone provides
information about active RTP streams.

The built-in web server is disabled by default. You need to enable it when you want to
examine the information that is provided by the built-in web server. The built-in web server
can be enabled at the phone configuration page: setthe Web Access parameter to
Enabled

Note
You cannot add Phone3-x to aconference anymore. The only available conference bridge
(HQ-SW-CFB) is asoftware conference bridge running on Cisco Unified Communications
Manager. This software conference bridge supports G.711 only, Because Phone3-x is in
region BR and Ihis region is not permitted to use G.711 to region HQ (where the software
conference media resource is in), Phone3-x cannot join conferences anymore

56
implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems. Inc
&
Step 17 Verify that the region issetto HQ.
Step 18 At the relaled links, choose Back To Find/List and click Go.
Step 19 Choose the Branch device pool.
Step 20 Change the region lo BR.
Step 21 Click Save.
Step 22 Reset the device pool.
Step 23 Click the Add New button and configure anew device pool with following
parameters:
• Name: Trunks
• Cisco Unified Communications Manager Group: Default
• Local Route Group: HQrg

Note The local route group at the trunk is required in order to allow received TEHO calls that are
to besent to the BR gateway to bererouted via the backup path (standard local route
group). Until now, the trunk had the device pool Detault applied, which also has the local
routegroup HQ_rg configured. ^^_

• Date-TimeGroup: CM Local
• Region: Trunks
• SRST Reference: Disable

Step 24 Click Save.

Apply Device Pools to Devices


In these steps vou will applv device pools to devices as speci tied in the "Device Pool
Configuration"' table in the Job Aids section. This will assign the appropriate regions to the
devices.

Step 25 Nav igate to Device >Phone and click Find.


Step 26 At the list of phones, verify that Phonel* and Phonc2-x are listed with device pool
Default and Phone3-.v is listed with device pool Branch.

Note Regions cannot be directly applied to devices. You have to create different device pools with
regions and then apply the appropriate device pools to the devices.

Step 27 Navigate to Device >Trunk and click Find.


Step 28 Choose the SIP-Trunk.
Step 29 Change the dev ice pool from Default to Trunks.
Step 30 Click Save.
Step 31 Reset the trunk.
Step 32 Nav igate to Device >Gateway, choose the option to Show endpoints. and click
Find.
Step 33 Verifv that the HO-.vgaleway(lO^.l.lOl) is listed with the device pool Default.
Step 34 Choose the MGCP endpoinl ofgateway BR-x (SO/SUO/OSl-OfflJBR-* or similar).
Lab Guide 55
© 2010 Cisco Systems, Inc
• You can establish ad hoc conferences using the HQ-SW-CFB conference resource Verily
this by creating an ad hoc conference with Phonel*, Phone2-j, and Phone3-* as members.
• When acall is put on hold, the caller hears MOH. Verify this by establishing acall and then
putting the call on hold.

Task 2: Configure Regions


In this task, you will configure regions in order to prevent audio streams that are sent over the
IP WAN from using htgh-bandwidth codecs. Only G.729 will be permitted tor streams that
traverse the IP WAN. Refer to the table -Region Configuration" in the Job Aids section for
more details. The regions are then applied to devices using device pools.
Activity Procedure
Complete these steps:
Create and Configure Regions
Step 1 Navigate to System > Regionandclick Find.
Step 2 Choose the region Default.
Step 3 Change the name to HQ.
Step 4 Verify that G.722/G.7I Iaudio codecs are allowed for calls within region
headquarters.
Step 5 Click Save.

Step 6 Click the Add New button.

Step 7 Enter Trunks for the name ofthe new region and click Save.
Step 8 Using the Modify Relationship to other Regions pane, allow the G.729 audio codec
for calls within region Trunks by highlighting Trunks in the Regions list and
TJ-.»" /Villi- llJltliin Hr^x^-^^.^- T 1.1 I • II- • .• »», -

choosing G.729 from the Audio Codec drop-down menu. Click Save.
•to
Step 9 Using the same technique, allow the G.729 audio codec for calls between region
Trunks and region HQ.

Note
You must click Save after each change in the Modify Relationship to Other Regions pane
The changes will then appear in the Region Relationships pane.

Step 10 Click Add New.

Step 11 Enter BR for the name ofthe new region and click Save.
Step 12 Allow G.722/G.711 for calls within region BR.
Step 13 Allow G.729 for calls between regions BR and Trunks.
Step 14 Allow G.729 for calls between regions BR and HQ.
Create and Configure Device Pools
In these steps, you add anew device pool for the trunks and update the existing device pools
with the new regions, as described in the "Device Pool Configuration" table in .he Job Aids
otciions.

Step 15 Navigate to System >Device Pool and click the Find button.
Step 16 Choose the Default device pool.

54 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 >2010 Cisco Systems. Inc.
Task 1: Enable Software Media Resources on Cisco Unified
Communications Manager
In this task vou will enable the Cisco IP Voice Media Streaming Application service, which
provides several software media resources running on Cisco Unified Communications
Manager. You will change the default names and descriptions of these media resources.
Activity Procedure
Complete these steps:
Verify That the Cisco IP Voice Media Streaming Application Service Is Activated
Step 1 Log in to Cisco Unified Serviceability and navigate to Tools >Control Center-
Feature Services.
Step 2 Verify that the Cisco IP Voice Media Streaming App service is activated and
running at CUCMl-.v.

Note This service provides the following software media resources: Annunciator, Conference
Bridge, Media Termination Point, and Music on Hold Server.

Verify and Configure the Software Media Resources


Step 3 Iog in to Cisco Unified Communications Manager Administration and navigate to
Media Resources >Annunciator and click Find.
Step 4 Verify the status of the media resource. It should be registered with your Cisco
Unitied Communications Manager CUCMI-x (IO.r. I.I).
Step 5 Click the shown Annunciator media resource (ANN_2).
Step 6 Change the Name to HQ-SW-ANN and the description lo Software Annunciator
atCICMl-.Y.

Step 7 Verifv that the Device Pool is Default.


Step8 Click Save.
Step9 Reset the media resource.
Step 10 Repeal the previous steps for the following media resources using the specified
values:

Name
Description
Media Resource

HQ-SW-CFB Software Conference Bridge at


Conference Bridge
CUCMI-x

HQ-SW-MTP Software Media Termination


Media Termination
Point at CUCMI-x
Point

HQ-SW-MOH Software MOH Server at


MOH Server
CUCMI-x

Activity Verification
You have completed this task when you attain these results:
• The Cisco IP Voice Media Streaming Application service is activated.
. The following software media resources are registered with CUCMl-.v: Annunciator.
Conference Bridge. Media Termination Point, and MOH Server.
Lab Guide
J2010 Cisco Systems. Inc.
• H.323 gateway
• PSTN with PSTN phone

Job Aids
These job aids are available to help you complete the lab activity.
Region Configuration

HQ Trunks BR

HQ G.711 G.729 G.729


Trunks G.729 G.729 G.729
BR G.729 G729 G.711

Note Region Default, which exists by default, will be renamed to HQ.

Media Resource Group Configuration


Name Description Included Media Resource
HQ_mrg HQ SWConference Bridge HQ-SW_CFB
BR_mrg BR HWConference Bridge BR-HW-CFB &
General_mrg HQ SW Annunciator, MOH and HQ-HW-XCD
MTP; HQ HW Transcoder HQ-SW-ANN
HQ-SW-MOH
HQ-SW-MTP

Media Resource Group List Configuration


Name Contains I
ContainsMedia Resource Groups
HQ_mrgl HQ_mrg
General_mrg
BR_mrgl BR_mrg
Generaljnrg

Device Pool Configuration


Device Pool Region Media Resource List Applied to Device
Default HQ HQ_mrgl Phone 1-x
Phone2-x
HQ-x
HQ-SW-CFB
HQ-SW-MTP
HQ-SW-MOH
HQ-SW-ANN
HQ-HW-XCD m
Trunks Trunks HQ_mrgl SIP_TRUNK
BR BR BR_mrgl Phone3-x

BR-x (MGCP endpoint)


BR-HW-CFB

52
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems. Inc.
Lab 3-1: Implementing Bandwidth Management
Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this activitv. vou will configure multicast MOH from branch router flash, regions, local
conference bridges, and Iranseoders to reduce bandwidth requirements on the IP WAN. After
completing this activ ity. you will be able to meet these objectives:
• fnable software media resources on Cisco Unified Communications Manager
• Configure regions
• Implement transcoders
• Implement a hardware conference bridge
• Implement multicast MOH from branch router flash

Visual Objective
The figure illustrates what vou will accomplish in this activity.

Lab 3-1: Implementing Bandwidth


Management

Implement
conference bridge
and transcoder

Use low-bandwidth
codecs only in WAN

Use low-bandwidth
codecs only in WAN.
Implementlocalconference bndge;
npiement multicast MOH from branch
router flash

Required Resources
These arc the resources and equipment that are required to complete this activity:
• Cisco Unified Communications Manager
• Student PC

• Cisco IP Phones

• Cisco IOS MGCP gateway

Lab Guide
© 2010 Cisco Systems. Inc
Step 4 When prompted for the IP address of the FTP server, enter the IP address you wrote
down in Step 2.
Step 5 For the source filename, enter moh.au.
Steps Confirm the destination filename (moh.au) and wait for the file to be copied.
Step 7 Verify that the moh.au file isstored in flash by entering the show Hash command.
Enable MOH in SRST Mode
Step 8 Enable MOH at the branch by entering the following commands at BR-.v (in
configuration mode):
telephony-service
moh moh.au

Step 9 Savethe router configuration to NVRAM.


Activity Verification
You have completed this task when you attain these results:
• Branch phones can listen to MOH when put on hold. This can be verified by performing
the following steps:

Step 1 Place a call between aheadquarters phone and the branch phone.
Step 2 At the branch phone (Phone3-^). putthecall on hold.
Step 3 The headquarters phone should play MOH coming from the branch router.
Note
When you are finished, make sure to remove the access-list that you entered in an earlier
task to break the connection between BR-x and CUCMI-x from the serial interface atrouter
HQ-x. Verify that the Phone3-x re-registers with Cisco Unified Communications Manager.

&

50
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 >2010 Cisco Systems, Inc.
Activity Verification
You have completed this task when you attain these results:
• To verify the SRST Fallback configuration, enter the show telephony-service command on
the branch router BR-.v.
• To verity that the current flies are accessible to IP phones, enter the show telephony-
servicetftp-bindings command.
• To verify that SRST isworking, follow these steps:
Step 1 Break connective lo Cisco Unified Communications Manager by reapplying access
list 100 in the incoming direction atthe interface ofthe HQ-.r router that connects to
the BR-.v router.

Step 2 Place acall from aheadquarters phone to the branch phone (300I). The call should
work: the calling party number should be the 10-digit PSTN number ofthe
headquarters phone.
Step 3 Place acall from Phone3-.r to aheadquarters phone (use internal dialing: 2001 or
2002). The call should work: the calling party number should be the I0-digit PS IN
number of the branch phone.
• lo verifv that ihe learned configuration was saved, display the configuration ofthe router:
— Enter the show running-config command and verify that you see an cphone-dn and
cphonc in the configuration.

Note The next time the phone registers with Cisco Unified Communications Manager Express.
Cisco Unified Communications Manager Express uses the stored configuration instead of
learning the phone configuration using SNAP. In order to configure a phone with features
that cannot be learned by SRST. you can preconrigure the ephone-dn only (and then the
ephone is learned) or ephone-dn and ephone _

Task 2: Configure MOH on Cisco Unified Communications


Manager Express
In this task, vou will configure Cisco Unified Communications Manager Express to provide
MOH lo Cisco IP phones.

Activity Procedure
Complete these steps:

Copy an MOH Audio File to the SRST Router


To use MOH with Cisco Unified Communications Manager Express in SRST mode, the MOII
file must be stored on the router flash.
Step 1 At PC-v. navigate to Start >Run and enter the cmtl command.
Step 2
In the command-line window, enter the ipconflg command to find out the IP address
of the PC. The IP address must be in network 10^.3.0/24. Write down the IP address
here:
10. -3.
Step 3
Vour instructor reinstalled and preconfigured an FTP server at PC-*. AMOH audio
file was stored at PC-.v and made accessible via FTP for anonymous user. Copy this
tile to the Hash of vour BR-.v router by entering the copy ftp flash command:
Lab Guide
2010 Cisco Systems, Inc
• H.323 gateway
• PSTN with PSTN phone

Task 1: Configure Cisco Unified Communications Manager


Express in SRST Fallback Mode
In this task you will change from standard SRST to Cisco Unified Communications Manager
Express in SRST fallback mode.

Activity Procedure
Complete thesesteps:
Remove SRST Configuration from the Branch Router
Step 1 Log in tothe BR-j router and enter configuration mode.
Step 2 Delete the SRST command by entering the following command:
no call-manager-fallback

Note The dial peers and translation profiles that are configured in the standard SRST lab will be
reused for Cisco Unified Communications Manager Express in SRST Fallback mode.

Configure Cisco Unified Communications Manager Express in SRST Mode on the Branch
Router

In these steps, you will configure Cisco Unified Communications Manager Lxpress in SRST
mode for the branch router.
Step 3 Enable Cisco Unified Communications Manager Express in SRSI mode by entering
the following commands:
telephony-service
ip source-address 10.x.250.102 port 2000
system message CUCME in SRST Mode
max-ephones 5
max-dn 5

srst mode auto-provision all

Note The keyword all at the end of the srst mode auto-provision command causes the router to
save the learned ephone and ephone-dn configuration.

srst dn line-mode dual

srst ephone description SRST learned


create cnf-files

Note The create cnf-files command makes the router generate configuration files that,
required by SCCP phones.

end

Step4 Save the router configuration.

48
Implementing Cisco Unrfied Communications Manager. Part 2(CIPT2>v8.0©2010 Cisco Systems, Im,
Lab 2-2: Implementing Cisco Unified
Communications Manager Express in SRST
Mode
Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this activitv vou will configure Cisco Unified Communications Manager Express in SRST
mode to provide basic telephony services lo phones that lost the connection to Cisco Unified
Communications Manager. In addition, you will enable MOII. After completing this activity,
you will be able to meet these objectives;
• Configure Cisco Unified Communications Manager Express in SRST fallback mode
• Configure MOI 1on Cisco Unified Communications Manager Express

Visual Objective
The figure illustrates what you will accomplish in this activity.

Lab 2-2: Implementing Cisco Uni fsed Communications


Manager Express in SRST Mode

Required Resources
These are the resources and equipment that arc required to complete this activity:
• Cisco Unified Communications Manager
• Student PC

• Cisco IP Phones

• Cisco IOS MGCP gatewa;

Lab Guide
& 2010 Cisco Systems, Inc.
Step 16 Place atest call to the branch phones of the other pod using site-code dialing (852v
300I).

Step 17 Save your configuration changes.


Activity Verification
You have completed this taskwhen you attain these results:
• You can receive calls at Phone3-jr when the calls are placed to the PSTN number of
Phone3-.v.

• You can place outgoing calls to the PSTN from Phone3-x The calling party number should
always be shown as 10-digit PSTN number at the PSTN phone. Make sure to place test
callsto the following types of destinations:
— Local destinations, for example by dialing 9-555-5678
— National destinations, for example by dialing 9-1-606-555-1234
— International destinations, for example by dialing 9-011-44-555-666-7777
— Emergency (911 and 9-911)
• You can call Phone3-.r from headquarters phones by using the internal directory number of
Phone3-.T(300I).

Note CFUR, which is required at the main site in this scenario, was already configured in the
previous task. In this task you enabled incoming PSTN calls sothat received CFUR calls
can be routed to the internal number of Phone3-x.

From Phone3,v. you can use the internal numbering plan to reach sites within the pod .
the other pod asdescribed in the activity procedure.

Note Detailed verification was part of the activity procedure.


Caution When you are finished, make sure to remove the access list at HQ-x that you entered in an
earlier task to break the connection between BR-x and CUCMI-x from the serial interface at
router HQ-x. Verify that the Phone3-x re-registers with Cisco Unified Communications
Manager.

46
implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems. Inc.
Si
Configure Digit Manipulation at the Branch SRST Router for Outgoing Calls
In these steps, you will configure digit manipulation to ensure that PSTN format is used for the
calling partv numbers onoutgoing calls.
Step 7 Configure atranslation profile, which adds 52r555 to the four-digit directory
numbers starting with 3by entering the following commands:
voice translation-rule 2
rule 1 /'3/ /52X5553/
exit
voice translation-profile pstn-out
translate calling 2
exit
Step 8 Bind the translation rule to the voice port that connects to the PSTN by entering the
following commands:
voice-port 0/0/0:23
translation-profile outgoing pstn-out
exit

Step 9 Save your configuration changes.


Step 10 Verily that the calling number ofthe outgoing calls is now placed with the PSTN
number of Phone3-.v (52r 555 3001).
Configure Digit Manipulation at the Branch SRST Router to Allow Internal Dialing for
Intersite Calls
In these steps, vou will configure the SRST gateway in such away that users can place calls to
other sites using internal numbers instead ofPSTN numbers.
Step 11 Configure an outgoing dial peer that matches the internal directory numbers of
headquarters phones and adds the appropriate prefix:
dial-peer voice 2000 pots
destination-pattern 2...
port 0/0/0:23
prefix 0115551x5552
Step 12 Place atest call to one ofthe headquarters phones using its four-digit internal
directory number.
Step 13 Configure an outgoing dial peer that matches internal site-code dialing toward the
headquarters of the other pod and modifies the called number appropriately:
dial-peer voice 8y2 pots
destination-pattern 851y2...
port 0/0/0:23
prefix 0115551y5552
Step 14 Place atest call to one ofthe headquarters phones ofthe other pod using site-code
dialing (851 v2001 or851 v2002).
Step 15 Configure an outgoing dial peer that matches internal site-code dialing toward the
branch ofthe other pod and modifies the called number appropriately:
dial-peer voice 8y3 pots
destination-pattern 852y3...
port 0/0/0:23
prefix 152y5553

Lab Guide
© 2010 Cisco Systems. Inc
at
Configure the Branch SRST Router toAllow Outgoing Calls
In these steps, you will add adestination pattern to the existing POTS dial peer Iin order to S*
allowoutgoing PSTN calls.
Step 5 At BR-.t. enter the following commands in configuration mode: •
dial-peer voice 2 pots
destination-pattern 9011T Ifc
prefix Oil
port 0/0/0:23 Jfe

dial-peer voice 3 pots ^L


destination-pattern 911
prefix 911 m
port 0/0/0:23

dial-peer voice 4 pots


destination-pattern 9911 ,»,
prefix 911 ••
port 0/0/0:23

dial-peer voice 5 pots


destination-pattern 91[2-9] .. [2-9] K
prefix 1
port 0/0/0:23 ||L

dial-peer voice 6 pots ?*


destination-pattern 9 [2-9]
port 0/0/0:23 a*.

interface serial 0/0/0:23 m.


isdn map address "Oil* plan unknown type unknown

Note
The ISDN switch type that is used at BR-x is primary-ni. This switch type automatically sets
the number type to international when the called number starts with 011 and has 12 more
digits, which can be the case in this lab. The PSTN, however, does not allow the type of
number to be used atthe BR site; only prefixes should be used. The shown isdn map
address command instructs the BR-x gateway not to automatically set the type of number to
international.

Step 6 Verify that outgoing calls are working by calling 9011 55 Six 5552001 from
Phone3-.r. Also try placing acall to the PSTN phone by dialing any valid PSTN
number (for example, 91606 555 4444). Note that the calling party number
displayed on the PSTN phone is the four-digit internal directory number olThoncl-v

Note At this stage, branch phones are able to place calls to the PSTN. This includes calls to
headquarters phones if the headquarters phones are dialed by their PSTN numbers The
caU'ng party numbers of outbound PSTN calls use internal directory number format

44
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2D10 cisco Sys(emSi ,nc
Step 2 Verifv using the debug isdn q931 command whether the call hits the HR-* gateway.
The call arrives at BR-.v. but DID is not enabled and the called party number is a 10-
digit number and not a4-digit director) number.
Note Gateway BR-x accepts the call and, because DID is not enabled, it waits for dialed digits
(two-stage dialing) If you manually enter 3001 at this stage, Phone3-x will ring

Task 4- Implement a Dial Plan at the SRST Gateway Supporting


Inbound and Outbound Calls When in MGCP Fallback or in
SRST Mode or Both
In this task vou will configure adial plan at the SRST gateway that allows incoming calls that
are placed to the F 164 PSTN number of the branch phones to be sent to the appropriate
directorv number. In addition, you will implement PSTN access for branch users, finally, vou
will allow branch users to place calls to headquarters phones over the PS INby dialing internal
director, numbers.

Activity Procedure
Complete these steps:
Configure the Branch SRST Router toAllow Incoming Calls
In these steps. >ou will configure an inbound dial peer to allow incoming calls to be routed
correcllv.
Step 1 l.nable DID for the voice port that connects to the PSTN by entering the following
commands:
dial-peer voice 1 pots
incoming called-number 52x5553...
direct-inward-dial
port 0/0/0:23
Step 2 Configure atranslation profile to manipulate the incoming called number from the
PSTN (the complete PSTN number 52.x 55530(11) to the four-digit directorv number,
bv entering the following commands:
voice translation-rule 1
rule 1 /*52x5553/ /3/
exit
voice translation-profile pstn-in
translate called l
Step 3 Bind the newly created translation profile to the voice port that connects lo the
PSTN bv entering the following commands:
voice-port 0/0/0:23
translation-profile incoming pstn-in

Note
At this stage, branch phones are reachable by their PSTN numbers. CFUR from the
headquarters should now work

Step 4 Verifv that incoming calls are working by calling 3001 from PhoneKt or Ph0nc2,v.
Note 'that the calling parly number that is displayed at Phone3,v is the PS IN number
of the calling phone.

Lab Guide
© 2010 Cisco Systems. Inc
Task 3: Implement a Dial Plan in Cisco Unified
Communications Manager Supporting Outbound Calls Durina
SRST Mode y
In this task, you will configure CFUR for remote phones to allow phones that are located at the
main siteto call remote phones viathe PS'fN in SRST mode.
Activity Procedure
Complete these steps:
Adjust CFUR Service Parameters
In these steps, you will adjust the CFUR-Max-Hop-Counter service parameter.
Step 1 Navigate to System >Service Parameters and choose the Cisco Unilied
Communications Manager publisher (IOjc.1.I).
Step 2 From the Service drop-down menu, choose the Cisco CalfManager service.
Step 3 In the Clusterwide Parameters (Feature—Forward) pane, change Ihe Max Forward
UnRegistered Hops toDN parameter to2 (default is0).
Step 4 Click Save.

Configure CFUR for the Branch Phone


Step 5 Navigate toCall Routing >Directory Number and click the Find button.
Step 6 From the result list, click directorv number3001, which is in the Internal partition.
Step 7 Scroll to the Call Forward and Call Pickup Settings pane and enter the following
parameters in the Forward Unregistered Internal and in the Forward Unregistered
Fxternal rows:

• Destination: +6651x5553001
• CSS: GlobaI_css
Step 8 Click Save.

Step 9 Reset the directory number.

Note SRST mode will be active when IP connectivity between HQ and BR sites is broken. Calls
from HQ to BR will use the configured CFUR settings (destination and CSS). The CFUR
destination will match the VH translation pattern first, and then the \+6652x[2-9]XXXXXX
TEHO pattern. The first option of the route list that is applied to the TEHO pattern is the BR
gateway This, however, cannot beused, because IP connectivity between HQ and BR is
broken {the MGCP gateway isdown) Therefore, the second option of the route list is
used—the local route group.

Activity Verification
You have completed this task when you attain these results:
• To verify that Cisco Unified Communications Manager routes calls to the unregistered
numbers of phones that are in SRST mode, perform the following steps:
Step 1 Place acall from one ol'your headquarters phones to 300I. The call will fail.

42
Implementing Cisco Unified Communications Manager, Part 2<CIPT2)v8.0 ©2010 Cisco Systems, Inc.
Step 2 Enter the following commands to enable and configure the SRST feature:
call-manager-fallback
ip source-address 10.x.250.102
max-dn 1 dual-line
raax-ephones 1

Configure the Gateway for MGCP Fallback Support


Step 3 hntcr the following command to enable the gateway fallback feature:
ccm-manager fallback-mgcp
Step 4 Specify with the following command that the default voice application (H.323) takes
over if the MGCP application is notavailable:
application
global
service alternate Default
Step 5 Save vour configuration changes using the copy running-config startup-con fig
command.

Activity Verification
You have completed this task when you attain these results:
• To verifv that SRSI' isworking on your branch router, perform the following steps:
Step 1 i; nter the debug ephone register command to start debugging.
Step 2 Fnter the terminal monitor command.
Step 3 To break connectivity to Cisco Unified Communications Manager, enter the
following commands at HQ-.v in global configuration mode:
access-list 100 deny ip any host 10.x.1.1
access-list 100 permit ip any any

interface serial ...


ip access-group 100 in

Note Use the interface that connects the HQ-x route with the BR-x router

Step 4
Your Cisco IP phone in the branch should register with the BRI-jc SRST router. This
is indicated by the text "CM Fallback Service Operating" at the bottom of the phone
display.
Step 5 At the BR-.t gateway, you will see debug output indicating that the phone registered
with the SRST gateway. The last message should be "ephone-
l|l]:SkinnyCompleteRegistration."
Step 6 When you are finished, turn off all ofthe debug commands at all of the routers
using the nodebug all command.

Lab Guide
© 2010 Cisco Systems, Inc.
• HJ23 gateway
• PSTN with PSTN phone

Task 1: Configure SRST Gateways in Cisco Unified


Communications Manager
In this task, you will add an SRST reference, configure adevice pool with the SRST reference
and apply the device pool toremote phones.
Activity Procedure
Complete these steps:

Add aNew SRST Reference in Cisco Unified Communications Manager


Step 1 Create anew SRST reference with the following parameters.
• Name: BR-x

• Port: 2000 (default)


• IP Address: 10jt.250.102 (loopbackO)
Configure the BR Device Pool withthe New SRST Reference
Step 2 At the BR device pool, set the SRST reference to BR-x.
Step 3 Reset the device pool.
Activity Verification
3j£
You have completed this task when you attain these results:
• Anew SRST reference is configured in System >SRST as described in the activity m,
procedure. mm
• The SRST reference is assigned to the branch IP phone. This can be verified at Ihe phone gL
by performing the following steps:

Step 1 Press the Settings button. fife


Step 2 Choose option 3 Device Configuration. »>
•fr
Step 3 Choose option I CallManager Configuration.
Step 4 The second entry should read "CallManager 2SRST," and when you choose Select h
the IP address of the loopback interface ofBR-* (10jc.250.I02) should be shown.
Task 2: Configure a Cisco IOS Gateway for MGCP Fallback and *
SRST ^
In this task, you will configure SRST and MGCP Fallback support at aCisco IOS gateway.
Activity Procedure lb
Complete these steps: «.
m
Configure the Gateway for SRST
Step 1 Log in to your BR-x router and enter configuration mode. M*

40
Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Lab 2-1: Implementing SRST and MGCP Fallback
Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this activ itv vou will configure Cisco Linified SRST to provide call survivability for Cisco
IP phones, and MGCP fallback for gateway survivability. After completing this activity, you
will be able lo meet these objectives:
• Configure SRSI gateways in Cisco Unified Communications Manager
• Configure aCisco IOS gateway for MGCP fallback and SRST
. Implement adial plan in Cisco Unified Communications Manager supporting outbound
calls during SRST mode
• Implement adial plan at the SRST gateway supporting inbound and outbound calls when in
MGCP fallback or in SRST modeor both

Visual Objective
The figure illustrates what you will accomplish in this activity.

Lab 2-1; implementing SRST and MGCP


Fallback

Required Resources
These are the resources and equipment that are required to complete this activity:
• Cisco Unified Communications Manager
• Student PC

• Cisco IP Phones

• Cisco IOS MGCP gateway

Lab Guide 39
>2010 Cisco Systems, Inc
Configure Calling Party Transformations for TEHO Calls
Step 2 Create calling party transformation patterns for the HQ gateway. Refer to the
"Localization ofCalling Party During Call Egress for Outbound TE110 Calls" table
of the Task Job Aids.

Note The gateway isalready configured with a calling party transformation CSS that has access
to the partition that you applied to the newly created transformation patterns.
Step 3 Place test calls to TEHO PSTN destinations located at the other pod. Use the debug
isdn q93I command at the gateways ofthe other pod to verify that the TEHO
gateway is used. Make sure that for TEHO calls through the HQ gateway, the calling
number isthe number ofthe actual caller (in international format ifthe call comes
from the BR site ofthe other pod and in national format ifthe call comes from the
HQ site ofthe other pod) while the calling number for TEHO calls through Ihe BR
gateway isalways the number ofthe BR attendant (52^5553001).
Verify PSTN Backup for TEHO to the Other Pod
Step 4 Shut down the serial interface that connects your pod with the other pod.
Step 5 Repeat placing TEHO test calls from the HQ site and from the BR site to Ihe PSTN
destination located at the other pod. Although IP connectivity is broken, the calls
should still work, because they are rerouted via the second option ofthe route list:
the local route group. Use the debug isdn q931 command to verify that the call is
set up using the local PSTN gateway.
Step 6 Usethe no shutdown command on the serial interface.
Activity Verification
You have completed this taskwhen you attain this result:
• You can place TEHO calls to the other pod as described in the activity procedure.
• When IP connectivity between the two pods is broken, the local gateway is used as a
backup asdescribed intheactivity procedure.

38
Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0 ©2010 Cisco Systems. Inc.
Task 6: Implement TEHO Between Pods
In this task, vou will configure TEHO between your pod and the other pod.
Task Job Aids
These job aids arc av ailable to help you complete the lab task.
Route Patterns for Outbound TEHO Calls

Route Pattern Configuration

V+5551yf2-9]XXXXXX Partition; System


Description TEHO to +55 51y(remote HQ)
UrgentPriority: deactivated
Gateway/Route List intersite _rl

H6652yf2-9]XXXXXX Partition: System


Description TEHO to +66 52y(remote BR)
UrgentPriority: deactivated
Gateway/Route List: Intersitejl

Localization ofCalling Party During Call Egress for Outbound TEHO Calls
Calling PartyTransformation Pattern Configuration

\+55.51y5552XXX Partition. xfornvcg_HQ-out


Description: HQ (from remote HQ)
Discard DigitsInstructions: PreDot
Number Type: National

\+.6652y5553XXX Partition: xform-cg__HQ-out


Description: HQ (from remote BR)
Discard DigitsInstructions: PreDot
Number Type. International

Note
The HQ PSTN allows remote calling numbers to be sent. The BR PSTN does not allow
other calling numbers than the number that is assigned to the PSTN line. Therefore, TEHO
calls from the other pod to HQ are configured to use the numbers of the other pod for the
calling number while calls going through the BR gateway have already been configured in
the previous task to use the number of the BR attendant (3001) for the calling number it the
calling number is not in the locally assigned DID range. Further, the HQ PSTN requires
number types to be set, while the BR PSTN expects 10-digit calling numbers without
number types ^ ___

Activity Procedure
Complete these steps:

Configure TEHO Route Patterns


Step 1 Create route patterns for TEHO calls. Refer to the "Route Patterns tor Outbound
TEHOCalls" table of the Task Job Aids.

Lab Guide
2010 Cisco Systems. Inc
Configure TEHO Route Patterns
Step 3 Create route patterns for TEHO calls. Refer lo the "Route Patterns for Outbound
TEHO Calls" table of the Task Job Aids.

Configure Calling Party Transformations for TEHO Calls


Step 4 Create calling party transformation patterns for the HQ and BR gateways. Refer to
the••Localization of Calling Party During Call Egress for Outbound TEHO Calls"
table of the Task Job Aids.

Note The gateways arealready configured with a calling party transformation CSSthathas
access tothe partition that you applied tothe newly created transformation patterns.

Step 5 Place test calls toTEHO PSTN destinations. Use the debug isdn q931 command to w
verify that the TEHO gateway is used. Make sure that for IEl 10 calls through the mt
HQ gateway, the calling number is the number ofthe BR phone (in international wWi
format) while the calling number for TEHO calls through the BR gateway isnot the Mb
IIQ number but the number ofthe BR attendant (52x5553001).
Verify PSTN Backup for TEHO Within the Pod 8
Step 6 Shut down the ISDN interface at the IIQ gateway and try placing aTEI10 call from m
the BR phone. Because the primary path (through the TEHO gateway) does not •"
work, the local gateway (BR) should beused asa backup.
Step 7 Use the no shutdown command on the ISDN interface. 8
Step 8 Shut down the ISDN interface at the BR gateway and try placing aTEHO call from *&
the HQ phone. Because the primary path (through the TEHO gateway) does not '*im
work, the local gateway (HQ) should be used as a backup.
Step 9 Use the no shutdown command on the ISDN interface. m
Activity Verification w
You have completed this task when youattain this result:
• You can place TEHO calls within your pod as described in the activity procedure. 8
• When IP connectivity between the two siles is broken, the local gateway is used as a B
backup as described in the activity procedure. %m

36
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems, lire
Task 5: Implement TEHO Within Your Pod
In this task, you will configure TEHO within your pod.

Task Job Aids


These jobaids arc available tohelp you complete the lab task.
Route Patterns for Outbound TEHO Calls

Route Pattern Configuration

\+5551x[2-9]XXXXXX Partition. System


Description TEHO to +55 51x (local HQ)
Urgent Priority deactivated
Gateway/Route List TEHO-HQ_rl

\+6652x[2-9jXXXXXX Partition: System


Description: TEHOto +66 52* (local BR)
Urgent Priority: deactivated
Gateway/Route List TEHO-BR_rl

Localization of Calling Party During Call Egress forOutbound TEHO Calls


Calling Party Transformation Configuration
Pattern

\+.6652x5553XXX Partition: xform-cg_HQ-out


Description: HQ (from BR)
Discard Digits Instructions: PreDot
Number Type. International

Partition xform-cg_BR-out
Description: BR (from HQ)
Calling PartyTransform Mask: 52x5553001

Note The HQ PSTN allows remote calling numbers to be sent. The BR PSTN does not allow
other calling numbers than the number that is assigned to the PSTN line Therefore, TEHO
calls from BR to HQ are configured to use the BR number as the calling number while calls
going through the BR gateway are configured to use the number of the BR attendant (3001)
for the calling number if the calling number is not of the locally assigned DID range. Further,
the HQ PSTN requires number types to be set while the BR PSTN expects 10 digit calling
numbers without number types ^

Activity Procedure
Complete these steps:
Configure Route Lists with the TEHO Gateways as First Option and the Local PSTN
Gateway as Backup
Step 1 Create aroute list that is called TEHO-HQ_rl and add the HQj-g and the Standard
Local Route Group item to the route list. Make sure that the HQ_rg is listed first.
Step 2 Create aroute list that is called TUIO-BR.rl and add the BR_rg and the Standard
focal Route Group item to the route list. Make sure that the BR_rg is listed first.

Lab Guide 35
© 2010 Cisco Systems. Inc
Step 11 Make sure that the callingnumberis shown with the internally used directory-
number and a site-code dial prefix at the receiving phone (85 ly-2001 and 851v-2002
for calls that are received from HQ phones of the other pod and 852_y-300l for calls
that are received from the BR phone of the other pod).

Verify PSTN Backup for the SIP Trunk


Step 12 When the test calls between your pod and the other pod have finished you can start
testingthe PSTN backup path. Shutdown the serial interface that connects your IIQ
router (HQ-*) to the HQ router of the other pod (HQ-_y).

Note This is the serial interface at the HQ router that is configured with IP address 10.zx.101 and
subnet mask 255.255.0.0.

As mentioned earlier, x is the number of your pod, and y is the number of your partner pod
(in the same group). Groups are pods 1 and 2, pods 3 and 4, pods 5 and 6, and pods 7 and
8. A z in an IP address stands for the pod numbers of your pod and your partner pod. They
are listed in ascending order. Examples: for pod 1, x=1, y=2, and z=12; for pod 2, x=2, y=1,
and z=12; for pod 3, x=3, y=4, and z=34, for pod 4, x=4, y=3, and z= 34, and so on.

Step 13 Continue placing test calls from the HQ site and from the BR site to the other pod
using intersite dialing, Although IP connectivity is broken, the calls should still
work, because they are rerouted via the second option of the route list: the local
route group. Use the debug isdn q931 command to verify that the call is set up
using the local PSTN gateway. Verify that the calling number is still shown with the
internally used directory number and a site-code dial prefix.
Step 14 Use the no shutdown command on the serial interface.

Activity Verification
You have completed this task when you attain this result:
• You can place calls to and receive calls from the other pod using site-code dialing as
described in the activity procedure.
• When IP connectivity between the two pods is broken, the PSTN is used as a backup as
described in the activity procedure.
• The calling number is always shown with the intemally used directory number and a site-
code dial prefix as described in the activity procedure.

i.

34 Implementing CiscoUnified Communications Manager, Part 2 (CIPT2) v8.0 © 2010CiscoSystems.Inc.


Configure Route Patterns for Globalized Intersite Calls Using the Previously Created
Intersite Route List
Step 4 Create route patterns for intersite access. Refer to the "Route Patterns for Outbound
Intersite Calls" tabic of the Task Job Aids.

Configure Translation Patterns for Inbound Calls

Note At this stage, you are ready to send calls to the other pod using globalized called and calling
numbers, in order to process the calls that are received from the other pod, you have to
change the received called number from globalized format to the internally used directory
number

This called number format change could be done with significant digits set to 4, configured
at the SIP trunk. However, as you want to use the SIP trunk also for TEHO in a later lab
task, the called number cannot be reduced to a four-digit number in general, only if the call
was placed to an internal phone and not when the call was placed to a TEHO destination.
Therefore, you will use translation patterns to modify the called number of inbound calls that
are received through the SIP trunk.

Step 5 Create translation patterns for received intersite calls. Refer to the "Changing the
Called Number of Calls Received Through the SIP Trunk" table of the Task Job
Aids,

Configure the SIP Trunk with a CSS That Has Access to Internal Phones
StepS Apply the CSS Ininkjjss to the SIP trunk.
Step 7 Reset the trunk.
Step 8 When the configuration of the other pod has finished, you can start placing test calls
using intersite dialing. Dial 8-51v-2001 and 8-5ly-2002 to reach the HQ phones of
the other pod. dial 8-52v-300l to reach the BR phones of the other pod.

Note When receiving calls from the other pod, you will see the calling number in globalized format
(+55-51y-555-2001 and +55-51y-555-2002 for calls from the HQ phones of the other pod
and +66-52/-555-3001 for calls from the BR phone of the other pod).

In order to indicate that the call is coming from an interconnected site, the configuration will
be changed in the next steps so that the calling number is shown with the internally used
site code.

Configure the Calling Number of Intersite Calls to Be Shown with Site Codes
Step 9 Create calling party transformation patterns for IIQ and BR phones. Refer to the
"Localization of Calling Party DuringCall Egress for Inbound Intersite Calls" table
of the Task Job Aids.

Note The phones are already configured with a calling partytransformation CSS that has access
to the partition that you applied to the newlycreated transformation patterns.

Step 10 Place lest callsbetween thetwo pods using intersite dialing. Make surethatyou
place calls in both directions. Dial 8-5!v-2001 and8-5l.y-2002 to reach the IIQ
phones of the otherpod. dial 8-52v-300l to reach the BRphones of the otherpod.

© 2010 Cisco Systems. Inc Lab Guide


Changing the Called Number of Calls Received Through the SIP Trunk

Translation Pattern Configuration

\+5551x555 2XXX Partition: Internal

Description: SIP (to local HQ)


CSS Trunkcss
Urgent Priority: deactivated
Discard Digits Instructions: PreDot

\+6652x555.3XXX Partition: Internal

Description: SIP (to local BR)


CSS: Trunk_css
Urgent Priority: deactivated
Discard Digits Instructions: PreDot

Localization of Calling Party During Call Egress for Inbound Intersite Calls

Calling Party Transformation Pattern Configuration

\+5551y555 2XXX Partition: xform-cgJHQ-phones


Description: HQ-Phones {other pod HQ}
Discard Digits Instructions: PreDot
Prefix: 851y555

\+5551y555 2XXX Partition: xform-cg_BR-phones


Description: BR-Phones (other pod HQ)
Discard Digits Instructions: PreDot
Prefix 851y555

\+6652y555 3XXX Partition: xform-cg_HQ-phones


Description: HQ-Phones (other pod BR)
Discard Digits Instructions: PreDot
Prefix: 852/555

\+6652y555.3XXX Partition: xform-cg_BR-phones


Description: BR-Phones (other pod BR)
Discard Digits Instructions: PreDot
Prefix: 852y555

Activity Procedure
Complete these steps:

Configure a Route Group for the SIP Intercluster Trunk


Step 1 Create route group SIP_rg and add the SIP trunk to the route group.
Configure a Route List with the SIP Trunk as First Option and the PSTN as Backup
Step 2 Create a route list that is called lntersite_rl and add SIP_rg and the Standard I.ocaI
Route Group item to the route list. Make sure that SIP_rg is listed first.
Configure Translation Patterns to Globalize Intersite Calls
Step 3 Create translation patterns for intersite access, Refer to the "Globalization of Called
and Calling Parties During Call Ingress for Outbound Intersite Calls" table of the
Task Job Aids.

32 Implemenling Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 © 2010 Cisco Systems. Inc.
Task 4: Configure Intersite Calling
In this task, you will configure intersite calling over the SIP trunk using site codes.

Task Job Aids

These job aids are available to help you complete the lab task.

Globalization of Called and Calling Parties During Call Ingress for Outbound
Intersite Calls

Translation Pattern Configuration

851/2XXX Partition: Global


Description: Intersite to HQ
CSS System__css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party Discard Digits Instructions: PreDot
Called Party Prefix Digits: +5551/555

852y.3XXX Partition. Global


Description: Intersite to BR
CSS System_css
Urgent Priority deactivated
Calling Party: Use external phone number mask: activated
Called Party Discard Digits Instructions: PreDot
Called Party Prefix Digits: +6652/555

Route Patterns for Outbound Intersite Calls

Route Pattern Configuration

\+5551y Partition: System


5552XXX Description HQ of other pod
Urgent Priority: deactivated
Gateway/Route List: lntersite_rl

H6652/ Partition System


5553XXX Description: BR of other pod
Urgent Priority: deactivated
Gateway/Route List. Intersite_rl

© 2010 Cisco Systems, Inc Lab Guide


Note The calls fail because a callback is placed to the number as it was before localization took
place at the phone during call egress. Before localization, the number was in global format,
because the calling number received from the PSTN was globalized during call ingress.

In order to allow callbacks to globalized numbers, you have to add a \+! translation pattern.
The translation pattern will not change the called number, but only modifies the calling
number by applying the external phone number mask. Further, the translation pattern has a
CSS that has access to the \+! route pattern.

By adding such a translation pattern, you make sure that the calling number of the outbound
callback is globalized during call ingress and that you then match the \+! route pattern.
Applying the external phone number mask at the route pattern instead of the translation
pattern does not work before the configured global transformations are based on globalized
numbers. Digit manipulation that is configured at the route pattern and at the route list is
ignored by global transformations. Global transformations are based on the pre-transformed
number (that is, the number as it looks when hitting the route pattern), not on the
transformed number {that is, the number as it looks after route pattern or route list digit
manipulation has been applied).

Configure a Translation Pattern for Calls That Are Natively Using Globalized Format
Step 22 Create a translation pattern that is used by the HQ phones with the following
settings:
• Translation Pattern: \+!

• Partition: Global

• Description: Calls to Globalized Numbers


• CSS: System_css
• Urgent Priority: activated

Note Translation patterns are urgent by default. Make sure that you do not disable Urgent Priority.

• Calling Party: Use external phone number mask: activated


Step 23 Retry placing callbacks from the HQ and BR phones by using the entries of the
received calls list. The calls should work this time. Make sure that the calling
number shown at the PSTN phone is using the correct format. Calls from the two
HQ phones should show a calling number of 5552001 and 5552002: calls from the
BR phone should show a calling number of 52.X5553001.
Activity Verification
You ha\e completed this task when you attain this result:
• You can receive calls from the PSTN at HQ and BR phonesas described in Iheactivity
procedure.

• PSTN calling numbers are shown in localized format as described in the activity procedure.
• Callbacks can be placed from \iQ and BR phonesto the PSTN. The calling number for
callbacks is set as described in the activity procedure.

30 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) v8.0 © 2010 Cisco Systems, Inc.
Verify Inbound PSTN Calls to the HQ Site
Place test calls from the PSTN to an HQ phone. Use the local, national, and inlemalional line of
the PSTN phone for the test calls.
Step 15 When placing a call from the local line of the PSTN phone, the caller ID shown on
the display of the HQ phone should be 5554444.

Note You can call the HQ phones by any valid PSTN number, regardless of the line of the PSTN
phone that you use Valid numbers are: 555-2001 and 555-2002, 0-51x-555-2001 and 0-
51x-555-2002, 00-55-51X-555-2001 and 00-55-51X-555-2002.

Step 16 When placing a call from the national line of the PSTN phone, the caller ID shoun
on the display of the HQ phone should be 06065554444.
Step 17 When placing a call from the international line of the PS'fN phone, the caller ID
shown on the display of the I IQ phone should be +776065554444.

Verify Inbound PSTN Calls to the BR Site


Place test calls from the PSTN to a BR phone. Use the local, national, and international line of
the PS'fN phone for the test calls.
Step 18 When placing a call from the local line of the PSTN phone, the caller ID shown on
the display of the BR phone should be 5Zy555444.

Note You can call the BR phone by any valid PSTN number regardless of the line of the PSTN
phone that you use. Valid numbers are: 555-3001, 1-52x-555-3001, and 011 -66-52x-555-
3001

Step 19 When placing a call from the national line of the PSTN phone, the caller ID shown
on ihe display of the BR phone should be 6065554444.
Step 20 When placing a call from the international line of the PSTN phone, the caller ID
shown on the display of the BR phone should be +776065554444.

Verify Callbacks
Step 21 Place callbacks from the IIQ and BR phones by using the entries of the received
calls list. The calls will fail.

©2010 Cisco Systems, Inc


Step 3 Sa\e \our configuration changes using the copy running-config startu p-con fig
command.

Configure Routing to the Internal Directory Number at the HQ Gateway


Step 4 Configure the HQ gateway with significant digits set to 4, and set the CSS to
Trunkcss.

Configure Globalization of Calling PSTN Number During Call Ingress at the HQ Gateway
Step 5 Configure the HQ gateway with the following incoming calling party prefixes based
on the number type:
• Unknown: +

• Subscriber: +555U'

• National: +55

• International: +

Step 6 Reset the gateway.

Configure Routing to the Internal Directory Number at the BR Gateway


Step 7 Configure the BR gateway with significant digits set to 4, and set the CSS to
Trunk_css.

Configure Globalization of Calling PSTN Number During Call Ingress at the BR Gateway
Step 8 Configure the BR gateway with the following incoming calling party prefixes based
on the number type:
Unknown: +

Subscriber: +665Xv

National: +66

International: +

Step 9 Reset the gateway. Make sure that you also reset the MGCP process at the branch
router by entering the no mgcp command, followed by the mgcp command.
Configure Localization of Calling PSTN Number During Call Egress
Step 10 Create calling party transformation patterns for HQ phones. Refer to the table of the
Task Job Aids.

Step 11 Apply calling party transformation CSS xform-cg_HQ-phones ess to the IIQ
phones. Make sure that you clear the Use Device Pool Calling Party Transformation
CSS check box.

Step 12 Create calling party transformation patterns for BR phones. Refer to the table of the
Task Job Aids.

Step 13 Apply callingparty transformation CSS xform-eg_BR-phones_css lo the BR phone.


Make sure that you clear the Use Device Pool Calling Party Transformation CSS
check box.

Step 14 Reset all phones.

28 Implementing Cisco Unified Communications Manager. Part 2 (CIPT2) v8.0 ©2010 Cisco Systems, Inc.
— National call: dial any valid national number, for example 9 1 888 666 444. The
National line at the PS'fN phone should ring: the called number that is shown in the
debug output should be 1888666444. and the number type should be unknow n.
— International call: dial any valid international number, for example 9 011 88 222
3.33 4444. The Intemtl line at the PSTN phone should ring; the called number that is
shown in the debug output should be 911882223334444. and the number type
should be international.

Task 3: Configure Inbound PSTN Calls


In this task. >ou will configure inbound PSTN calls.

Task Job Aids

This job aid is a\ailable to help you complete the lab task.

Localization of Calling Party During Call Egress for Inbound PSTN Calls

Calling Party Transformation Pattern Configuration

\+5551xXXXXXXX Partition: xform-cg_HQ-phones


Description HQ-Phones (Local)
Discard Digits Instructions: PreDot

\+55 XXXXXXXXXX Partition: xform-cgJHQ-phones


Description. HQ-Phones (National)
Discard Digits Instructions: PreDot
Prefix: 0

\+66 XXXXXXXXXX Partition: xform-cg_BR-phones


Description: BR-Phones (Local, National)
Discard Digits Instructions: PreDot

Note At the HQ site, end users expect to see local PSTN callers seven-digit numbers, national
callers with their national numbers and national access codes (0), and international callers
with a + prefix. Because allcaller IDs are globalizedat ingress, there is no need to modify
the caller ID of international callers when sending the call to the phone.

At the BR site, end users expect to see 10-digit caller IDs for local and national callers, and
see international callers with a + prefix (just like at the HQ site).

Activity Procedure
Complete these steps:

Configure the H.323 Gateway to Support Inbound PSTN Calls


Step 1 Reconfigure the existing POTS dial peerto support inbound PSTN calls:
dial-peer voice 2 pots
direct-inward-dial
incoming called-number .
Step 2 Reconfigure the existing VoIP dial peerlo support inbound PSTN calls:
dial-peer voice 1
destination-pattern T
session target ipv4:10.x.1.1

Lab Guide
©2010 Cisco Systems Inc
Step19 Reset the BRgateway in Cisco Unified Communications Manager. Make surethat
you alsoresetthe gateway itselfby entering the no mgcpcommand and then the
mgcp command at the BR gateway.

Configure Localization of the Calling Number During Call Egress


Step 20 Create callingparty transformation patterns for the HQ gateway. Referto the
"Localization of Calling Party During Call Egress for Outbound PSTN Calls" table
of the Task Job Aids.

Step 21 Apply callingparty transformation CSS xfonn-cg_HQ-out_css to the IIQ gateway.


Makesure that you clear the Use Device Pool Calling PartyTransformation CSS
check box.

Step 22 Reset the HQ gateway in Cisco Unified Communications Manager.


Step 23 Applycallingparty transformation CSS xform-cg BR-out_css to the BR gateway.
Make sure that you clear the Use Device Pool Called Party Transformation CSS
check box.

Step 24 Reset the BR gateway in Cisco Unilied Communications Manager. Make sure that
you also reset the gateway itself by entering the no mgcp command and then the
mgcp command at the BR gateway.

Activity Verification
You have completed this task when you attain this result:
• You can place calls to the PSTN from HQ phones. The HQ gateway is used for PSTN
access. Use the debug isdn q931 command for verification of the called and calling
numbers for all types of calls. The calling number should always be seven digits (555 2001
or 555 2002) with number type subscriber. The called number differs per destination:
— Emergency calls: dial 112 and 0 112. The Emergency line at the PSTN phone
should ring; the called number that is shown in the debug output should be 112, and
the number type should be unknown.
— Local call: dial any valid local number, for example, 0 333 4444. Ihe I,ocal line at
the PSTN phone should ring; the called number that is shown in the debug output
should be 3334444, and the number type should be subscriber,
— National call: dial any valid national number, for example, 0 0 888 666 444. The
National line at the PSTN phone should ring; the called number thai is shown in the
debug output should be 888666444, and the number type should be national.
— International call: dial any valid international number, for example 0 00 88 222
333 4444. The Intemtl line at the PSTN phone should ring; the called number that is
shown in the debug output should be 882223334444, and the number type should be
international.

• You can place calls to the PSTN from the BR phone. The BR gateway is used for PSTN
access. Use the debug isdn q93l command for verification of the called and calling
numbers for all types of calls. The calling number should always be 10 digits (5Zv555
3001) with no number type set (unknown). 'Ihe called number differs per destination:
— Emergency calls: dial 911 and 9-911. The Emergency line at Ihe PSTN phone
should ring: the called number that is shown in the debug output should be 911, and
the number type should be unknown.
— Local call: dial any valid local number, for example 9 333 4444. The Local line tit
the PSTN phone should ring: the called number that is shown in the debug output
should be 3334444, and the number type should be unknown.

26 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2)v8.0 © 2010 Cisco Systems, Inc.
Step 4 Save your configuration changes using the copy running-config startup-config
command.

Configure a System Route List Used for PSTN Access


Step 5 Create a route list that is called System_rl and add the Standard Local Route Group
item to the route list.

Configure Site-Specific Route Groups


Step 6 Create route group HQ_rg and add the HQ gateway to the route group.
Step 7 Create route group BR_rg and add the BR gateway to the route group.

Configure Site-Specific Device Pools and Set the Local Route Group
Step 8 Configure the default device pool with local route group HQ_rg.
Step 9 Create a new device pool that is called BR, and configure the device pool with local
route group BR_rg.
Step 10 Apply the ncuK created device pool BR to the BR phone.

Configure Globalization of Called and Calling Number During Call Ingress


Step 11 Configure all phones with an external phone number mask using globalized formal.
Use +555 Lv5552XXX for the HQ phones and +6652.V5553XXX for the BR phone.
Step 12 Create translation patterns for HQ PS'fN access. Refer lo the "Globalization of
Called and ("ailing Parties During Call Ingress for Outbound PS IN Calls Placed
from HQ Phones" table of the Task Job Aids.
Step 13 Create translation patterns for BR PS'fN access. Refer to the "Globalization of
Called and Calling Parties During Call Ingress for Outbound PSTN Calls Placed
from BR Phones" table of the Task Job Aids.

Configure Call Routing Based on Globalized Numbers


Step 14 Create a route pattern with the following sellings:
• Route Pattern: \+!

• Route Partition: System


• ( Description: PSTN_Access
• Urgent Priority: activated
• Gateway/Route List: System_rl

Configure Localization of the Called Number During Call Egress


Step 15 Create called party transformation patterns for the IIQ gateway. Refer to the
"Localization of Called Party During Call Egress for Outbound PSTN Calls" table
of the Task Job Aids.

Step 16 Apply called party transformation CSS xform-cd_IIQ-out_css to the IIQ gateway.
Make sure that you clear the Use Device Pool Called Party Transformation CSS
cheek box.

Step 17 Reset the HQ gateway in Cisco Unified Communications Manager.


Step 18 Apply called party transformation CSS xform-cd_BR-oul_css to the BRgateway.
Make sure that >ou clear the Use Device Pool Called Party Transformation CSS
check box.

)2010 Cisco Systems, Inc. Lab Guide


Note Because the HQ gateway (H.323) has a dial peer with destination pattern OT, PSTN access
code 0 has to be sent to the H.323 gateway; it will be stripped at the H.323 gateway when
the call is sent out to the PSTN. The PSTN expects the HQ gateway to send ISDN number
types; the called numbers must not include any prefixes.

For the BR gateway (MGCP) all digit manipulation is performed in Cisco Unified
Communications Manager. The PSTN expects the BR gateway not to use ISDN number
types; national and international calls have to have the corresponding prefixes.

Localization of Calling Party During Call Egress for Outbound PSTN Calls

Calling Party Transformation Pattern Configuration

\+5551x5552XXX Partition: xform-cg_HQ-out


Description: HQ (Local)
Discard Digits Instructions: PreDot
Calling Party Number Type: Subscriber

\+66 52x5553XXX Partition: xform-cg_BR-out


Description: BR (Local)
Discard Digits Instructions: PreDot

Note The calling party number that is sent to the PSTN at the HQ site should use the shortest
possible format (subscriber). The type of number must be set appropriately. The calling
party number that is sent to the PSTN at the BR site should be the 10-digit national number.
The type of number must not to be set.

Activity Procedure
Complete these steps:

Configure the H.323 Gateway to Support Outbound PSTN Calls


Step 1 Configure a codec voice class that allows G.711 and G.729 lo be used:
voice class codec l

codec preference 1 g711ulaw


codec preference 2 g711alaw
codec preference 3 g729r8

Note At this time, all calls that are sent to the HQ-x gateway use G.711 only. However, in the next
lab exercise, TEHO will be enabled. At that time, G.729 will be used for TEHO callers.
Therefore all applicable codecs are configured now.

Step 2 Configure a VoIP dial peer for outbound PSTN calls:


dial-peer voice 1 voip
incoming called-number .
voice-class codec 1

Step 3 Configure a POTS dial peer for outbound PSTN calls:


dial-peer voice 2 pots
destination-pattern OT
port 0/0/0:15

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 >2010 Cisco Systems, Inc.
Note Only translation pattern 9.911 should be configured with urgent priority. AN other patterns
are unique and therefore urgent priority is not needed. Translation pattern 9.911 could also
match pattern 9[2-9]XXXXXX and is configured with urgent priority so users dialing 9.911
do not have to wait for the interdigit timeout to expire.

Localization of Called Party During Call Egress for Outbound PSTN Calls

Called Party Transformation Pattern Configuration

\+5551xXXXXXXX Partition: xform-cd_HQ-out


Description HQ (Local)
Discard Digits Instructions: PreDot
Prefix 0

Called Party Number Type: Subscriber

\+55. XXXXXXXXXX Partition: xform-cd_HQ-out


Description: HQ (National)
Discard Digits Instructions: PreDot
Prefix: 0

Called Party Number Type: National

\+.! Partition xform-cd_HQ-out


Description HQ (Intl)
Discard Digits Instructions: PreDot
Prefix: 0

Called Party Number Type: International

\+.112 Partition xform-cd_HQ-out


Description: HQ (Emergency)
Discard Digits Instructions: PreDot
Prefix: 0

Called Party Number Type: Unknown

\+S652x XXXXXXX Partition xform-cd_BR-out


Description: BR (Local)
Discard Digits Instructions: PreDot

\+66 XXXXXXXXXX Partition xform-cd_BR-out


Description: BR (National)
Discard Digits Instructions: PreDot
Prefix 1

\+ l Partition: xform-cd_BR-out
Description: BR (Intl)
Discard Digits Instructions PreDot
Prefix 011

\+.911 Partition: xform-cd_BR-out


Description: BR (Emergency)
Discard Digits Instructions: PreDot

Lab Guide
© 2010 Cisco Systems, Inc
Globalization of Called and Calling Parties During Call Ingress for Outbound
PSTN Calls Placed from BR Phones

Translation Pattern Configuration

9011.! Partition: BR_PSTN


Description: BR (Intl, timeout)
CSS System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot
Called Party Prefix Digits: +

9011 !# Partition: BR_PSTN


Description: BR (Intl, #)
CSS: System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot Trailing-*
Called Party Prefix Digits: +

91[2-9)XX Partition BR_PSTN


[2-9]XX Description: BR (National)
XXXX
CSS: System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot
Called Party Prefix Digits: +66

9 [2-9]XX Partition. BR_PSTN


XXXX
Description: BR (Local)
CSS: System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot
Called Party Prefix Digits: +6652x

911 Partition: BR__PSTN


Description: BR (Emergency)
CSS: System_css
Urgent Priority: deactivated
Calling Party. Use external phone number mask: activated
Called Party Prefix Digits: +

9.911 Partition BR_PSTN


Description: BR (Emergency)
CSS: System_css
Urgent Priority: activated (default setting)
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot
Called Party Prefix Digits. +

22 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 ©2010CiscoSystems, Inc.
Translation Pattern Configuration

0.112 Partition HQ_PSTN


Description: HQ (Emergency)
CSS: System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party Discard Digits Instructions PreDot
Called Party Prefix Digits: +

©2010Cisco Systems, Inc Lab Guide


• You assigned partitions and CSSs to your IP phones. Each IP phone should still be able lo
call the other two IP phones. Verify this by placing test calls.

Task 2: Configure Outbound PSTN Calls


In this task, you will configure outbound PSTN calls using globalized call routing.

Task Job Aids

These job aids are available to help you complete the lab task.

Globalization of Called and Calling Parties During Call Ingress for Outbound
PSTN Calls Placed from HQ Phones

Translation Pattern Configuration

000.! Partition: HQ_PSTN


Descnption: HQ (Intl, timeout}
CSS: System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot
Called Party Prefix Digits: +
000 !# Partition: HQ_PSTN
Description: HQ (Intl, #)
CSS. System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot Trailing-*
Called Party Prefix Digits: +
00.[2-9]XX Partition: HQ_PSTN
[2-9]XX
Description: HQ (National)
XXXX
CSS: System_C5S
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot
Called Party Prefix Digits: +55
0.[2-9]XX Partition: HQ_PSTN
XXXX
Description: HQ (Local)
CSS: System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party: Discard Digits Instructions: PreDot
Called Party Prefix Digits: +5551x
112 Partition: HQ_PSTN

Description: HQ (Emergency)
CSS: System_css
Urgent Priority: deactivated
Calling Party: Use external phone number mask: activated
Called Party Prefix Digits. +

20 Implementing Cisco Unified Communications Manager. Part 2 (CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Step 5 Enter the following parameters in the Calling Search Space Configuration window:
• Name: HQ-Phones_css
• Description: HQ Phones
Step 6 In the A\ ailable Partitions pane, choose the following partitions and use the down
arrow below the Available Partitions pane to move the highlighted partition to the
Selected Partitions pane. The order of the partitions is not relevant in this lab
exercise:

• Internal

• IIQ_PSTN
Step 7 Click Save.

Step 8 Repeat these steps to add the remaining partitions as they are listed in the "CSSs"
tabic of the Task Job Aids section.

Assigning Partitions and CSSs to IP Phones


In these steps, you will assign the appropriate partitions and CSSs to your IP phones.
Step 9 Na\ igate to Device > Phone and click the Find button.
Step 10 Click the IP phone with the directory number 2001 (Phonel-.v) to open the Phone
Configuration window.
Step 11 From the left column, click Line |l]—2001 (no partition) to access the Directory
Number Configuration window.
Step 12 Choose Internal for the Route Partition.
Step 13 Assign CSS HQ_Phoncs_css to the line.

Note Make sure that you assign this CSS to the line level of the phone.

Step 14 from Related Links, chooseConfigure Deviceand click Go to get back lo the
Phone Configuration window.
Step 15 Assign CSS Global_css lo the phone.

Note Make sure that you assign this CSS to the device level of the phone

Step 16 Click Save and then, in the pop-up window, click OK.
Step 17 Repeat these steps to for Phone2-.v.
Step 18 Repeat the above steps for Phone3-.v. butapply CSS RR Phones_css to the fine level
instead of CSS H()_Phoncs_css.
Step 19 Reset all three phones.

Activity Verification
You have completed this task when you attain this result:
• You ha\e created thepartitions thatarelisted inihe"Partitions" table of the task Job Aids
section.

• You ha\e created the CSSs that arc listed in the "CSSs" tabic of the Task Job Aids section.

Lab Guide
) 2010 Cisco Systems. !nc
CSSs

CSS Name Description Contains Partitions Assigned to Devices

HQ_Phones_css HQ phones Internal HQ Phone lines

HQ_PSTN

BR_Phones_css BR phones Internal BR Phone lines

BR_PSTN

Global_css General external Global All Phones (device level)


access

Trunk_css Calls received over Internal SIP trunk


SIP trunk
System

System^css Route patterns System Translation patterns


(globalized)

xform-cd-HQ- XF called, HQ out xform-cd_HQ-out HQ gateway


out_css

xform-cg-HQ- XF calling, HQ out xform-cg_HQ-out HQ gateway


out_css

xform-cd-BR-out_css XF called, BR out xform-cd_BR-out BR gateway

xform-cg-BR-out_css XF calling, BR out xform-cg_BR-out BR gateway

xform-cgJHQ- XF calling, HQ xform-cg_HQ-phones HQ phones


phones_css phones

xform-cg_BR- XF calling, BR xform-cg_BR-phones BR phones


phones_css phones

Activity Procedure
Complete these steps:

Configure Partitions
In these steps, you will configure the partitions lhat are listed in the "Partitions" table of the Job
Aids section.

Step 1 In Cisco Unified Communications Manager Administration, navigate to ("all


Routing > Class of Control > Partition, and click Add New.
Step 2 Fnter the partition names and the descriptions as listed in the Job Aids section using
this format:

Internal, Internal IP phones


Global, General patterns

Note Make sure to include all partitions as listed in the Job Aids section.

Step 3 Click Save.

Configure CSSs
In these steps, you will create the CSSs listed in the "CSSs" table of Ihe Task Job Aids section.
Step 4 Na\ igate to Call Routing > Class of Control > Calling Search Space, and click
Add New.

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc.
Task 1: Configure Partitions and CSSs
In this task. \ou will configure all partitions and CSSs that arc required for the following tasks.
You will assign partitions and CSSs to phones and phone directory numbers.

Task Job Aids

These job aids are available to help \ou complete the lab task.

Partitions

Partition Name Description Assigned to Phones or Patterns

Internal Internal IP phones Directory numbers of phones

Global General patterns Translation patterns that are used


for sile-code dialing and natively
dialed globalized numbers

HQ_PSTN PSTN as dialed by HQ users Translation patterns that are used


for HQ PSTN dialing

BR_PSTN PSTN as dialed by BR users Translation patterns that are used


for BR PSTN dialing

System System patterns Route patterns in globalized format


that are used for PSTN access,
TEHO, and intersite calls

xform-cd_HQ-out XF called, HQ out Called party transformation patterns


that are applied to the HQ gateway
for outbound calls

xform-cg_HQ-out XF calling, HQ out Calling party transformation patterns


that are applied to the HQ gateway
for outbound calls

xform-cd_BR-out XF called, BR out Called party transformation patterns


that are applied to the BR gateway
for outbound calls

xform-cg_BR-out XF calling, BR out Calling party transformation patterns


that are applied to the BR gateway
for outbound calls

xform-cg_HQ- XF calling, HQ phones Calling party transformation patterns


phones that are applied to HQ phones for
inbound calls

xform-cg_BR- phones XF calling, BR phones Calling party transformation patterns


that are applied to BR phones for
inbound calls

© 20' 0 Cisco Systems. Inc Lab Guide


• Cisco IOS MGCP gateway
• H.323 gateway
• PSTN with PSTN phone

Job Aids
Thesejob aids are available to help you complete the lab activity.

Phone Numbers

Location IP Phone E.164 Number with + Prefix

HQ-x Phonel-x +55 51x555 2001

Phone2-x +55 51x555 2002

BR-x Phone3-x +66 52x 555 3001

HQ-y Phonel -y +55 51/555 2001

Phone2-y +55 51/ 555 2002

BR-y Phone3-y +66 52/555 3001

Intersite Dialing

Site IP Phone Intersite Dialing

HQ-y Phonel-y 8 51/2001

Phone2-y 8 51/2002

BR-y Phone3-y 8 52/ 3001

PSTN Access Codes and Emergency Numbers

Location PSTN Access Code National Access International Access Emergency

HQ 0 0 00 112,0112

BR 9 1 011 911,9 911 •to

Note For additional information regarding the PSTN, refer to the Dial Plan Information section at
the beginning of this document

16 Implementing Cisco Unrfied Communications Manager, Part 2 (CIPT2) v8.0 >2010 Cisco Systems, Inc.
Lab 1-2: Implementing a Dial Plan for
International Multisite Deployments
Complete this lab activity to practice what you learned in the related module.

Activity Objective
In ibis activity, you will implement a dial plan to support inbound and outbound PSTN calls,
site-code dialing. TFIfO. and PSTN backup. After completing this activity, you will be able to
meet these objectives;
• Configure partitions and CSSs
• Configure inbound PSTN calls
• Configure outbound PSTN calls using H.323 and MGCP gateways
m • Configure site codes tor intercluster calls
• Configure PSTN backup for intercluster calls
• Configure TEHO with local backup

Visual Objective
The figure illustrates what you will accomplish in this activity.

Lab 1-2: Implementing a Dial Plan fc


International Multisite Deployments

Configure call
routing and digit
manipulation lor a
H 323 PSTN
gateway

Configure intercluster calls


using site codes, configure
PSTN backup for intercluster
calls, implement TEHO

Configure call
routing and digil
manipulation at
CUCMI-x for
MGCP PSTN
gateway

Required Resources
These arc the resources and equipment that are required to complete this activity:
• Cisco Unified Communications Manager

• Student PC

• Cisco IP phones

) 2010 Cisco Systems. Inc. Lab Guide


Note Further verification will be done in the next lab exercise.

Task 5: Configure a SIP Trunk in Cisco Unified


Communications Manager
In this task. >ou will add a SIP trunk between the two pods.

Activity Procedure
Complete these steps:
Add a SIP Trunk in Cisco Unified Communications Manager
Step 1 In Cisco Unified Communications Manager Administration, choose Device >
Trunk.

Step 2 Click the Add New button.


Step 3 From the Trunk Type drop-down menu, choose SIP Trunk.
Step4 FortheTrunk Service Typedropdownmenu, leave None(Defaull). Click Next.
Step 5 In the Trunk Configuration window, enter the following parameters:
• Device Name: SIP_Trunk
• Description: SIP Trunk to POD/
• Device Pool: Default

Step 6 In the SIP Information pane, enter the IP address of the other pod's Cisco Unilied
Communications Manager server: \0.y.\A.
Step 7 Make sure that the Destination Address is an SRV box is not checked.
Step 8 From the SIP Trunk Security Profile drop-down menu, choose Non Secure SIP
Trunk Profile.

Step 9 From the SIP Profile drop-down menu, choose Standard SIP Profile.
Step 10 Click Save, and then, in the pop-up window, click OK.
Step 11 Reset the newly added SIP trunk.

Activity Verification
You have completed this task when you attain these results:
• The SIP trunk appears in the list when you choose Device > Trunk and then click the Find
button in Cisco Unified Communications Manager Administration.

Note Further verification will be done in the next lab exercise.

14 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 © 2010 Cisco Syslems. Inc.
Reduce the Utilized B-Channels from 23 to 8
Step 11 Disable the configuration server byentering the following command in global
configuration mode:
no ccm-manager config
Step 12 In global configuration mode, enter the following commands to shut down the voice
port that is associated with the Tl PRI:
voice-port 0/0/0:23
shutdown

Step 13 Disable PRI backhauling on the HI I) channel:


interface serial 0/0/0:23
no isdn bind-13 ccm-manager
Step 14 Remo\ c the auloconfigured PRI group and add a new one:
controller t l 0/0/0
shutdown

no pri-group timeslots 1-24 service mgcp


pri-group timeslots 1-8 service mgcp
no shutdown

Step 15 Re-enable PRI backhauling:


interface serial 0/0/0:23
isdn bind-13 ccm-manager
end

Note Because you deactivated the configuration server feature, the MGCP process at the Cisco
IOS gateway is not automatically reset anymore when you reset the gateway in Cisco
Unified Communications Manager. You have to manually reset the MGCP process at the
Cisco IOS gateway every time after you reset the gateway in Cisco Unified Communications
Manager Enter the no mgcp command, followed by the mgcp command, in order to reset
the MGCP process at the Cisco IOS router.

Activity Verification
You have completed this task when you attain this result:
• Your MGCP gateway is successfully registered with Cisco Unified Communications
Manager. This successful registration can be verified at the gateway as follows:
LIsc the show ccm-manager hosts command. The status should show Registered.
— Use the show mgcp endpoint command. All controlled ISDN PRI cndpoinl ports
should be up.
— Use the show mgcp command. The Admin State and ihe Opcr State should be
active.

Use the show isdn status command. Ihe Layer 2 slate should be
MUI.TIPI.FJ:RAMFS F.STABUISIIF.D.
• Verify that the MGCP gateway and the MGCP endpoinls are registered in Cisco Unified
Communications Manager:
Step 1 Navigate lo Device > Gateway.
Step 2 Choose the option lo Shaw endpoinls and click Find. The status of the endpoint
should be registered with IO.v.I.I.

©2010 Cisco Systems Inc LabGuide 13


Activity Verification
You ha\e completed this task when you attain this result:
• When youchoose Device > Gateway, choose theoption to Show endpoints. and click
Find, ihe MGCP gateway andits endpoints appear on the list.

Note Further verification will be done in the next task.

Task 4: Configure an MGCP Gateway


In this task, you will configure a Cisco IOS MGCP PSTN gateway thatis located at ihebranch
to register with Cisco Unified Communications Manager.

Activity Procedure
Complete these steps:

Log in to BR-x
Step 1 From PC-.v. connectto your headquarters router(HQ-x) using Telnet to
10_v.250.l02. Log in using the password cisco and switchto enable mode(using the
password cisco again).

Discover the Current Gateway Configuration and Verify IP Connectivity


Step 2 Display the currentrouterconfiguration by enteringshow running-config.

Note The gateway is currently not configured with any MGCP commands. The T1 or E1 controller
is not configured with a PRI group command. There is no ISDN PRI.

Step 3 Display the network interfaces and their IP configurations by entering Ihe show ip
interface brief command.

Step 4 Display the IP routing table by entering the show ip route command.
Configure the Cisco IOS Gateway for MGCP Using the Configuration Server Method
Step 5 Fnter the terminal monitor command to display the debug output that is generated
by the router.
Step 6 Enter the debug ccm-manager con fig-down load events command to debug the
configuration server feature events.
Step 7 In global configuration mode, enter the following commands:
ccm-manager config server 10.x.1.1
ccm-manager config
Step 8 Monitor the debug output to verify the operation of the configuration server feature.
Turn off all debugging by entering the no debug all command.
Step 9 Fnter the show running-config command. Your gateway should be configured for
MGCP, "fhe configuration that was added by the configuration server feature
includes MGCP, controller, and ISDN PRI settings.
Step 10 Save your configuration changes using ihe copy running-config startup-config
command.

12 Implementing Cisco UnrfiedCommunications Manager, Part 2 (CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Note Further verification will be done in the next lab exercise.

Task 3: Add an MGCP Gateway to Cisco Unified


Communications Manager
Inthistask. >ou will addan MGCP gateway to Cisco Unified Communications Manager.
Activity Procedure
Complete these steps:

Configure an MGCP Gateway in Cisco Unified Communications Manager

Note These steps are platform-dependent. Cross-check with your instructor to find out the actual
hardware that is used for your MGCP gateway. This lab guide is based on the Cisco 2811
Integrated Services Router platform with a VW1C2-1MFT-T1E1-T1 in slot 0/0. You can also
use the show diag command at your router to display its hardware configuration.

Step 1 In Cisco Unified Communications Manager Administration, choose Device >


Gateway and click the Add \cw button.
Step 2 From the Gateway l ype drop-down menu, choose the gateway platform (for
example, a Cisco 2811 Integrated Services Router) that is used for Cisco IOS MGCP
gateway BR-.r. Click Next.
Step 3 From the Protocol drop-down menu, choose the protocol type MGCP and click
Next

Step 4 [{nterthe following parameters in the Gateway Configuration window, and then
click Save:

• Domain Name: BR-.v(in which x is your pod number)


• Description: BR-.v, Branch PSTN Gateway (MGCP)
• Cisco Unified Communications Manager Group: Default
• Module in Slot 0: NM-4VWK-MBRD

• Global ISDN Switch Type: NI2

Add MGCP Endpoints by Selecting Modules and Voice Interface Cards


Step 5 In ihe Configured Slots, VICs and Lndpoints pane, from Subunit 0 in Slot 0. choose
the module VWIC2-1MFT-T1F.I-T1. Click Save.

Step 6 Click the port icon on the right of the displayed endpoint 0/0/0.
Step 7 In the Gateway Configuration window, enter the following parameters:
• Description: BR-*, Branch PSTN Gateway (MGCP): ISDN PRI
• Device Poo!: Default

• PRI Protocol Type: PRI NT2


• Channel Selection Order: Top Down
Step 8 Click Save and. when the pop-up window appears, click OK.
Step 9 Reset the newh added MGCP endpoint.

<§ 20' 0 Cisco Systems. Inc Lab Guide


HQ-.t. voice servers network: IOjc.1.101

HQ-x phone netwo k: IOjt.2.101


HQ-x data network 10.x3.I01
HQ-x serial interfaie to BR-x IOjt.6.102
HQ-x. serial interface to HQ-y: 10.z-.jc.101
BR-.r. loopback: Kjc.250.102
BR-x phone netwerk: IOjt.4.102
BR-xserial inter!a ;e to HQ-x 10.x6.102

CUCMl-y: lO.v.l.l
HQ-y. loopback: 10 v.250.101
HQ-y. voice servers network: lO.y.1.101
HQ-y. phone netwo -k: IO.v.2.101
HQ-y. data network: lO.v.3.101
HQ-y. serial interface to BR-y: I0.y.6.102
HQ-v. serial interfa> e to HQ-x- 10.z.y. 101
BR-y. loopback: I0v.250.102
BR-y. phone network: lO.y.4.102
BR-.v. serial interface to HQ-y: 10.y.6.102

Note As mentioned earlier, x is the number of your pod, and y is the number of your partner pod
(in the same group). Groups are pods 1 and 2, pods 3 and 4, pods 5 and 6, and pods 7 and
8 A z in an IP address stands for the pod number of your pod that is followed by the number
of your partner pod. The z parameter is compounded in ascending order. Examples: for pod
1,x = 1, y = 2, soz = 12; for pod 2, x = 2,y= 1, soz= 12; for pod 3, x= 3. y = 4, soz = 34,
for pod 4, x = 4, y = 3, so z = 34, and so on.

Set the H.323 Interface


Step 7 Set the loopback interface of the router to be the source interface for all H.323
packets. Your configuration should look like the following (in which x is your pod
number):
interface loopback 0
h323-gateway voip interface
h323-gateway voip bind sreaddr 10.x.250.101

Note Additional configuration will be configured in the next lab activity.

Step 8 Save jour configuration changes using copy running-con tig start up-con fig.
Activity Verification
You have completed this task when you attain these results:
• Verity that H.323 is enabledon the headquarters router on the loopback interlace:
Enter the show running-config interface loopback 0 command to verify the 11.323
interface configuration df the HQ-.r router.

10 Implementing Cisco Unified Communications Mansger, Part 2 (CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Add an H.323 Gateway to Cisco Unified Communications Manager
Step 2 Navigate to Device > Gateway to display the find and List Gateways window.
Step 3 Click the Add New button.

Step 4 from the Gateway '1 ype drop-down menu, choose 11.323 Gateway.
Step 5 Click Next.

Step 6 In the Gateway Configuration window, enter and choose the following parameters:
• Device Name: 10_v.250.101

Note An x in device names or IP addresses stands for your pod number. Ask your instructor if you
are not sure which pod number to use.

• Description: HQ-x IIQ PSTN Gateway (11.323)


• Device Pool: Default

Step 7 Leave all other parameters at their default settings, and then click Save.
Step 8 In ihe pop-up window, click OK, and then reset the newly added gateway.

Activity Verification
You have completed this task when you attain these results:
• You ha\e added a new H.323 gateway in Device > Gateway.

Note Further verification will be done in the next lab exercise.

Task 2: Configure an H.323 Gateway


In this tusk. \ou will configure a Cisco IOS H.323 gateway for connecting to the PSIN at
headquarters.

Activity Procedure
Complete these steps:

Log in to HQ-x
Step 1 From PC-x connect to your headquarters router (HQ-x) using Telnet to
I0_v.250.l01. If prompted, log in using the password cisco and changelo enable
mode (using the password cisco again).

Discover the Current Gateway Configuration and Verify IP Connectivity


Step 2 Display the current router configuration by entering the show running-config
command.

Step 3 Display the status of your ISDN PRI by entering theshowisdnstatuscommand.


Step4 Display the network interfaces andtheir IP configurations by entering the show ip
interface brief command.

Step5 Display the IP routing table by entering Ihe show ip route command.
Step 6 Test IP connectivity to the following IP addresses using the ping or trace command:
• CUCMI-x 10-t.I.I

• HQ-x loopback: I0_t.250.10I

)2010 Cisco Systems, inc Lab Guide


• H.323 gateway
• PSTN with PSTN phone

Job Aids
Thesejob aids are available to help you completethe lab activity,

Cisco Unified Communications Manager Information

Cisco Unified IP Addr (as Function Login Administration User and


Communications Password
Manager Name

CUCM-x 10.x. 1.1 Publisher cucmadmin, cucmpassl (for Cisco


Unified Communications Manager
Administration)
admin, adpassl (for Cisco Unified
Communications Manager Operating
; System administration)

Cisco IOS Gateway Information


Cisco IOS Gateway IP Addrpss Function Login Password and Enable Secret
Name

HQ-x 10x.25<).101 HQ cisco, cisco


gateway

BR-X 10x.250.102 BR cisco, cisco


gateway

Cisco IP Phones Overview

Cisco IP Phone Name IP Address Directory Location


Number

Phonel-x DHCP subnet 10.X.2.0/24 2001 Headquarters

Phone2-x DHCP subnet 10.X.2.0/24 2002 Headquarters

Phone3-x DHCP subnet 10.X.5.0/24 3001 Branch office

Task 1: Add an H.323 Gatew iy to Cisco Unified


Communications Manager
In this task, you will add the HQ-.v -1.323 gateway to Cisco Unified Communications Manager

Activity Procedure
Complete these steps:

Access Cisco Unified Communications IV anager Administration


Step 1 From PC-.v. browse to h tps://10.v.Ll/ccniadmin and log in lo Cisco Unified
Communications Manaf er Administration using the information provided in the
Cisco Unified Commun cations Manager Information table that is located in Ihe Job
Aids section of this guic s.

Implementing Cisco Unified Communications Manager. Part 2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc.
Lab 1-1: Implementing Basic Multisite
Connections
Complete this lab activity to practice what you learned in the related module.

Activity Objective
In ihis activily. you will implement an H.323 gateway and an MGCP gateway for connecting to
the PSI'N and a SIP trunk for connecting to the other pod. AHercompleting this activity, you
will be able to meet these objectives:
Add an H.323 gateway to Cisco Unified Communications Manager
Configure an H.323 gateway
Add an MGCP gateway to Cisco Unified Communications Manager
Configure an MGCP gateway
Configure a SIP trunk in Cisco Unified Communications Manager

Visual Objective
'] he figure illustrates what you will accomplish in this activity.

Lab 1-1: Implementing Basic tVlultisi


Connections

Required Resources
fhese are the resources and equipment that arc required lo complete this activity:
• Cisco Unified Communications Manager
• Student PC

• Cisco IOS MGCP gateway

© 2010 Cisco Systems, Inc. Lab Guide


The figure pros idesa summary of (hedial plan.

Dial Plan Summs ry


intiyCode: 55
5552XXX 5552XXX
HQ-I PSTN Access Code 0
51*S552XXX 51y5552XXX HQ-y
2 XXX Mati al Access Code: 0 55 51/5552XXX zxxx
55 5U555 2XXX
Access Coda I

:; »;xx x iiS5..XXX
b [2^:X< [i."•';>* xtxx ;;-?jxx \: U.^.-J55-3XXX
00-55-51 <-55S-£XX>;
G 'nTf' [2 u'XX *Xi* 55S-3XXX
'i :.ffi p.-j;xx <xx< 0-«i-555.3XXX
00*9 Ml-5 5.1-3 XXX

.Tf P'l

5!. 5 2 XXX
i [2 y)y.t 1 51iE5!)?XXX
(HIMMlBSSiXXX
1 80C [J • 5SXXXX 5553XXX
1 i'OO [2- <X*XXX 1 52* 555 3XXX
011 SB 521 555 3XXX

y Code: 66
5553XXX 555 3XXX
52I5553XXX j Access Code: 9 52/555 3X XX
66 521 555 3XXX Ial Access Code: 1 66 52y 555 3XXX
nal Access Code: 011

Note The blue text boxes towards PSTN-Phone-x indicate how thenumber isdialed by HQ-x and
BR-x users (leftblue box£s)
;s) and how the number has to be sent to the PSTN on the PRI
(right blue boxes)

The orange text boxes tctwards the HQ-x and BR-x sites indicate how the number is dialed
by the PSTN user. The fll ure does not show how the numbers are delivered to the HQ-x
and BR-x gateways on It 3 PRI.

Implementing Cisco Unified Communications Manager. Part 2 (CIPT2) vfl.O 12010 Cisco Systems, Inc.
As shown in the table, thecalling number that isused by the PSTN phone depends on the
PSf N phone line that is used to place the call.

Calling Number Presentation of Calls Placed from PSTN-Phone-x

PSTN-Phone-x Line Calling Number Presentation

Local 556 4444, TON - subscriber

National 606 555 4444, TON = national

Intemtl 77 606 555 4444, TON = international

800 "PSTN"

Premium none (CLIR)


Emergency 112. TON = unknown (when call is placed to HQ
sites)
911, TON - unknown (when call is placed to BR
sites)

Note When calls are placed from line 800, the calling number is not provided, the calling name
"PSTN" is presented instead of a calling number.

When calls are placed from line Premium, CLIR is used.

fhe ISDN PRIs have to be configured as shown in the table.

ISDN PRI Configuration

HQ-x Gateways BR-x Gateways

Controller type E1 T1

Framing crc4 esf

Line code hdb3 b8zs

Clock source line line

Timeslot range 1-8, 16 1-8.24

ISDN switch type primary net5 pnmary-ni

©2010 Cisco Systems, Inc Lab Guide


Calls Sent to PSTN-Phone-x

Received from HQ-x Sites Received from BR-x Sent to PSTN-

Sites Phone-x Line

Local calls [2-9JXX XXXX [2-9]XXXXXX


Local
TON = subscriber

National calls [2-9JXX [2-9JXX XXXX, 1 [2-9]XX 2-9]XX National


TON = national XXXX

international calls (E.164 number of any length), 011 {E.164 number of Intemtl
TON = international any length)

Toll-free calls 800 [2-9]XX XXXX, 1 800 [2-9]XX XXXX 800


TON = national

Premium calls 900 [2-9JXX XXXX, 1 900 [2-9]XX XXXX Premium


TON = national

Emergency calls 112, 911 Emergency


TON = Unknown

Note The PSTN at the HQ sites allows remote calling numbers to be sent (for example in case of
TEHO or device mobility) The calling number that is sent to the PSTN through HQ
gateways should always be in the shortest-possible format. Calls originating at the local HQ
site should use local format, calls originating at the HQ site of the other pod should use
national format, and calls originating at one of the two BR sites should use international
format

The PSTN at the BR sites does not allow remote calling numbers to be sent. The calling
number that is sent to the PSTN through BR gateways should always be in national format.
Calls originating at any remote site (BR site of the other pod, one of the two HQ sites)
should use the number of the local BR attendant (52x-555-3001).

Calls to the HQ and BR sites can be placed from PSTN-Phone-*, as shown in the table:

Calls That Can Be Placed from PSTN-Phone-x

Number Dialed at PSTN- Number Dialed at PSTN-


Phone-x, Sent to HQ-x Site Phone-x, Sent to BR-x Site

Local calls 555 2XXX 555 3XXX

National calls 0 51X555 2XXX 1 52x 555 3XXX

International calls 00 55 51x 555 2XXX 011 66 52x555 3XXX

Note The table shows the valid numbers that can be dialed at PSTN-Phone-x. No PSTN access
code is dialed from the PSTN phone. The presentation of the called number for these calls is
different The called number is always presented to the HQ and BR gateways without
prefixes and the TON is always set.

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc
The table pro\ ides an overview of the dial plan that is in use.

Dial Plan Overview

HQ-x Site BR-x Site

Internal directory number range 2XXX 3XXX

PSTN range in local (subscriber) format 555 2XXX 555 3XXX

PSTN range in national format 51x555 2XXX 52x 555 3XXX

PSTN range in international format 55 51* 555 2XXX 66 52x 555 3XXX

PSTN access code 0 9

National access code 0 1

International access code 00 011

Note The x is a variable indicating your pod number.

The PSTN accepts calls from the HQ and BR sites as shown in the table.

Calls Accepted by the PSTN

Received from HQ-x Sites Received from BR-x Sites

Local calls [2-9]XX XXXX, [2-9]XX XXXX


TON = subscriber

National calls 51x[2-9]XXXXXX. 1 52x [2-9]XX XXXX


TON - national

International calls (E 164 number of any length), 011 (E.164 number of any
TON = international length)

Toll-free calls 800 [2-9JXX XXXX, 1 800 [2-9]XX XXXX


TON = national

Premium calls 900 [2-9]XX [2-9]XXX, 1 900 [2-9]XX XXXX


TON - national

Emergency calls 112, 911


TON = Unknown

Note When HQ gateways are sending calls to the PSTN, the gateways are required to set the
ISDN TON for the called number (see the table for details); national and international
prefixes must not be used.

When BR gateways are sending calls to the PSTN, the gateways are required to send
prefixes for national and international calls; the TON must not be set (it must be set to
Unknown).

The used PSTN numbenng plans do not fully represent the actual numbering plans that are
used in North America or Europe They only use some components of these PSTN
numbering plans.

Ifa dialed number matches the range that is used at one of the HQ or BR sites, the PSI'N routes
the call to that sile. All other valid calls are sent lo PSIN-Phone-.*. as shown in the table:

>2010 Cisco Systems. Inc. Lab Guide


Lab Topology
The figure illustrates the labtopology andIP addresses.

Lab IP Network Overview

Phone 1-* Ptione--x Phone2-y Phone 1-y

^^TJHCP ^^^DHCP DHCPf*^ DHCPP*^


Note _ - x, 10 y 2 0/24
followed by y (in
ascending order)

101 10y30J2J | DHCP


DHCP t , 101 10700/16 ^101

10. 1 0/24 10yHQ1-J HQ1-y\ "• 10y10C4


10 >_50 101/32 10 10 y 250 101/32

BR_y Ptione3-y
10 y.250.102/3 4_ffiL_
1011 0/24 iA~-* (PSI^? 10jj4 0/24 T*'
*-_* M02 DHCP
Pody

Ihe x in the figure indicates your pod number. They in the figure indicatesthe numberof the
pod that will work together with you.

Dial Plan Information


The dial plan is based on two pods,each of which has two sites. The headquarters sites of both
pods (HQ-.v and HQ-y) are located within the same country. The country code of the HQ sites is
55. The branch sites of both pods (BR-x and BR-y) are located within the same country (which
is different from the country that the HQ sites are in), 'fhe country code of Ihe BR sites is 66.
All sites use a fixed-length numbering plan that is like the one used in the NANP. The area
code is three digits long, followed by seven digits of subscriber numbers (grouped into three
and four digits).
The PSTN dial rules at the HQ sites are like the ones that are used in most European countries.
The PSTN dial rules in the country where the BR sites are located are like the ones that are
used in the NANP.

Implementing Cisco Unrfied Communications Manager. Part 2 (CIPT2) v8.0 © 2010 Cisco Systems. Inc.
CIPT2

Lab Guide

Overview
1 his guide presents the instructions and other infonnation concerning the lab activities for this
course. You can find the solutions in the lab activity Answer Key.

Outline
This guide includes these activities:
Lab 1-1 Implementing Basic Multisite Connections
Lab 1-2 Implementinga Dial Plan for Internalional Multisite Deployments
lab 2-1 Implementing SRST and MGCP fallback
Lab 2-2 Implementing Cisco Unified Communications Manager Kxpress in SRSI" Mode
Lab 3-1 Implementing Bandwidth Management
Lab 3-2 Implementing CAC
Lab 4-1 Implemenling Device Mobility
Lab 4-2 Implemenling Cisco Fxtension Mobility
Lab 5-1 Implementing Cisco SAP and CCD
Answer Ke\
Lab 3-2: Implementing CAC 67
ActivityObjective 67
Visual Objective 67
Required Resources 67
Job Aids 68
Task 1: Configure Locations 68
Task 2: Configure RSVP-Enabled Locations 69
Task 3: Configure AAR and CFNB to Route Calls over the PSTN If They Are Not Admitted by the
Deployed CAC Methods 72
Task4 (Optional): Configure SIP Pre[x>nditions 73
Lab 4-1: Implementing Device Mobility 75
Activity Objective 75
Visual Objective 75
Required Resources 75
Task 1: Configure Device Mobility 76
Lab 4-2: Implementing CiscoExtension lability 79
Activity Objective 79
Visual Objective 79
Required Resources 79
Task 1: Activate the Cisco Extension Mobility Service and Configure the Corresponding Service
Parameters 80
Task 2: Create a Device Profile for a User 81
Task 3: Add and Associate an End U ser with the User Device Profile 82
Task 4: Add the Cisco Extension Mollility IP Phone Service and Subscribe to IP Phones and
Device Profiles 83
Lab 5-1: Implementing Cisco SAF and CI ;D 85
ActivityObjective 85
Visual Objective 85
Required Resources 85
Task 1: Configure SAF Forwarder Fu ictionality on the HQ-x and BR-x Router 86
Task 2: Configure Cisco Unified Corr nunications Manager as SAF Client 87
Task 3: Configure Cisco Unified Corr nunications Manager Express SRST on Branch Router to
Leam Routes Using CCD 91
Answer Key 96
Lab 1-1 Answer Key: Implementing Basic Multisite Connections 96
Lab 1-2 Answer Key: Implementing a Dial Plan for International Multisite Deployments 96
Lab 2-1 Answer Key: Implementing RST and MGCP Fallback 96
Lab 2-2Answer Key: Implementing (Jisco Unified Communications Manager Express in SRST
Mode 96
Lab 3-1 Answer Key: Implementing Ejandwidth Management 96
Lab 3-2 Answer Key: Implementing CAC 96
Lab 4-1 Answer Key: Implementing Cevice Mobility 96
Lab 4-2 Answer Key: Implementing Cisco Extension Mobility 96
Lab 5-1 Answer Key: Implementing . AF and CCD 96

Implementing Cisco Unified Communications Manager. Part 2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc.
Table of Contents
Lab Guide
Overview 1
Outline 1
Lab Topology 2
Dial Plan Information 2
Lab 1-1: Implementing Basic Multisite Connections 7
Activity Objective 7
Visual Objective 7
Required Resources 7
Job Aids 8
Task 1: Add an H.323 Gateway to Cisco Unified Communications Manager 8
Task 2: Configure an H.323 Gateway 9
Task 3: Add an MGCP Gateway to Cisco Unified Communications Manager 11
Task 4: Configure an MGCP Gateway 12
Task 5: Configure a SIP Trunk in Cisco Unified Communications Manager 14
Lab 1-2: Implementing a Dial Plan for International Multisite Deployments 15
Activity Objective 15
Visual Objective 15
Required Resources 15
Job Aids 16
Task 1: Configure Partitions and CSSs 17
Task 2: Configure Outbound PSTN Calls 20
Task 3: Configure Inbound PSTN Calls 27
Task 4: Configure Intersite Calling 31
Task 5: implement TEHO Within Your Pod 35
Task 6: Implement TEHO Between Pods 37
Lab 2-1: Implementing SRST and MGCP Fallback 39
Activity Objective 39
Visual Objective 39
Required Resources 39
Task 1: Configure SRST Gateways in Cisco Unified Communications Manager 40
Task 2: Configure a Cisco IOS Gateway for MGCP Fallback and SRST 40
Task 3: Implement a Dial Plan in Cisco Unified Communications Manager Supporting Outbound
Calls During SRST Mode 42
Task 4: Implement a Dial Plan at the SRST Gateway Supporting Inbound and Outbound Calls
When in MGCP Fallback or in SRST Mode or Both 43
Lab 2-2: Implementing Cisco Unified Communications Manager Express in SRST Mode 47
ActivityObjective 47
Visual Objective 47
Required Resources 47
Task 1: Configure Cisco Unified Communications Manager Express in SRST Fallback Mode 48
Task 2: Configure MOHon Cisco Unified Communications Manager Express 49
Lab 3-1: Implementing Bandwidth Management 51
Activity Objective 51
Visual Objective 51
Required Resources 51
Job Aids 52
Task 1: Enable Software Media Resources on Cisco Unified Communications Manager 53
Task 2: Configure Regions 54
Task 3: Implement Transcoders 57
Task 4: Implement a Hardware Conference Bridge 58
Task 5: Implement Multicast MOHfrom Branch Router Flash 61
5-74 Impiementing Cisco Unified Communications Manaj :f, Part 2(CIPT2) v8.0 >2010 Cisco Systems, Inc.
Module Self-Check Answer Key
OD D.G

y_) h.L)

04) The toDID ruledescribes how to manipulate thelearned UN pattern in order to gelto thenumber h.
should be used for a PSTN backup call if the CCD path is unavailable.
(.)>) i:

06) D

Call Control Discovery


©2010 Cisco Systems. Inc
06) Which CSS isused for CCD PSTN backup calls? (Source: Implementing SAF and
CCD)

A) line CSS of the originating phone


B) device CSS of the originating phone
C) CSS of the SAF trunk
D) AAR CSS of the originating phone
at*
K) CSS of the PSTN gateway

5-72 Implementing Cisco Unitied Communications Managt -, Part 2 (CIPT2) vB.O 12010 Cisco Systems, Inc.
Module Self-Check
Use the questions here to re\ iew what \ou learned in this module, fhe correct answers and
solutions are found in the Module Self-Check Answer Key.
Ql) Which two ofthe following devices do not support CCD? (Choose two.) (Source:
Implementing SAF and CCD)
A) Cisco Unified SRST
B) Cisco IOS gateway
C) Cisco Unified Border Element
I)) Cisco IOS gatekeeper
F.) Cisco Unified Communications Manager
F) Cisco Unified Communications Manager Express
G) Cisco IOS Catalyst switches
Q2) Which two statements are true about SAF? (Choose two.) (Source: Implementing SAF
and CCD)
A) SAF forwarders interpret the SAF header and SAF service data.
B) An internal SAF client is allocated with a SAF forwarder.
C) An internal SAF client resides in Cisco Unified Communications Manager.
D| SAF clients do not have to be Layer2-adjaccnt.
1.) SAF requires FIGRP tobeused as the IProuting protocol.
Q3) Which two statements arc not true about CCD? (Choose two.) (Source: Implemenling
SAF and CCD)
A) Call routing information is learned by the CCD requesting service.
B) Call routing infonnation is advertised by the CCD advertising service.
C) Load balancing occurs among trunk protocols and learned remote IP addresses.
D) Learned call routing information can be placed into different partitions that are
based on the remote call control identity.
F) Learned call routing information can be placed into different partitions that are
based on the remote IP address.
Q4) What is the purpose of the toDID rule in CCD? (Source: Implementing SAF and CCD)

Q5) Which of the following is not aconfiguration step when implementing SAF in Cisco
Unified Communications Manager? (Source: Implementing SAF and CCD)
A) Configure SAF forwarder.
B) Configure SAF trunk.
C) Configure CCD advertising and requesting service.
D) Configure hosted DN group and hosted DN pattern.
F) Configure DN blockprofile.
F) Configure blocked learned patterns.

Call Control Discovery 5-71


) 2010 Cisco Systems. Inc
5-70 Implementing Cisco Unrfied Communications Manaj er, Part 2 (CIPT2) v8.0 J2010 Cisco Systems, Inc.
Module Summary
This topic summarizes the key points that were discussed in this module.

Module Summary

CCD allows separate calf routing domains such as Cisco


Unified Communications Manager clusters and Cisco Unified
Communications Manager Express to utilize a SAF-enabled
network for dynamic exchange of call-routing information.

This module started with a description of Call Control Discovery (CCD). which is a feature that
allows callagents to advertise andlearn dial plan information to and from a CiscoService
Advertisement Framework (SAF)-enabled network. It showed how SAF" works, how CCD
utilizes SAF. and how SAF and CCD are implemented in a Cisco Unified Communications
solution.

References
For additional infonnation. refer lo these resources:

• Cisco S\ stems. Inc. Cisco Unified Communications System 8.x SR\D. April 2010.
hup:. \sww.cisco.eom/cti/US/docs/voice ip_eomm/euem/snid/S*/ue8\.html
• Cisco Systems. Inc. Cisco Unified Communications Manager Administration Guide
Release 8.0/1). February 2010.
lmp:;www.eisco.com.'en.'LS/docs/\'oicc ip comni/cucm/admin/8 OLccnicfg/hccm-801
cm.html

Call Control Discovery 5-69


© 2010 Cisco Systems. Inc
Summary
This topic summarizes the key points that were discussedin Ihis lesson.

Summary

• Dynamic distribution ofcall-routing information simplifies dial plan


implementation in large or very large networks.
• SAF allowsany services to be advertised to and learned from a
SAF-enabled network.

• CCD allows call agents toadvertise theinternal directory numbers that


they serve, along with the appropriate PSTN numbers, using SAF.
1When a learned VoIP route toa directory number becomes invalid, the
call is automatically rerouted over the PSTN.
SAF and CCD implementation includes the configuration of SAF
forwardersand SAF clients. SAFclients can be internal or external to the
Cisco IOS router used as a SAF forwarder.
Special considerations thatrelate to SAF and CCD implementation
include deployments using SRST, TEHO, globalized call routing, and
environments that have a SAF SIP trunk as well as a SAF H.323 trunk

References
For additional infonnation. refer to tlicse resources:
Cisco IOS Service Advertisemen Framework Configuration Guide 15.1 at
http://www .cisco. com/en/US/dt /ios/saf/configura£ion/guide/saf_cg _ps 105')2_TSD_Prod
uctsC'onfiguration GuidcC haft':er.html.
Cisco Systems. Inc. Cisco Unifiid
Uniji Communications System 8.x SRND, April 2010.
htlp:'V\\w\\.cisco.(jom/en/US.'''do s/voicejp eomm/cuem/sntd/8xAic8\.himl
CiscoSystems. Inc. Cisco Unifi
ifiei Communications Manager Administration Guide
Release 8.0(1). February 2010.
http://w ww.cisco.com/en.T ;S/doc s/voice_ip_comin/eucm/admin/8_0 l/ccmcig/hccin-801-
cm.html

Implementing Cisco Unified Communications Manage -. Part 2(CIPT2) v8.0 »2010 Cisco Systems, Inc.
Other SAF and CCD Considerations
This subtopic describes additional issues that you need to consider when implementing CCD in
Cisco Unified Communications Manager.

Other SAF and CCD Considerate

If you do not assign a trunk when you configure the CCD


requesting service, Cisco Unified Communications Manager will
not subscribe to hosted DN service from SAF network; there is no
learned pattern inside the system.
Each hosted DN pattern must be unique.
If a trunk is assigned to a route group or is associated with a route
pattern, you cannot enable SAF onthe trunk, and vice versa.
You cannot enable SAF on SIP trunks that use authenticated or
encrypted security profiles

Ifvou do not assign atrunk when you configure the CCD requesting service. Cisco Unified
Communications Manager uill not subscribe to the SAF forwarder. No routes will be learned.
Each hosted DN pattern must be globally unique.
Ifatrunk is assigned to aroute group or is associated with aroute pattern, you cannot enable
SAF on the trunk, and vice \ ersa.
You cannot enable SAF on SIP trunks that use authenticated or encrypted security profiles.

Call Control Discovery


©2010 Cisco Systems. Inc
Cisco Unified Communications Manager Clusters and CCD
Configuration Modes
This subtopic describes considerations regarding Cisco Unified Communications Manager
CCD configuration modes.

Cisco Unified Communications


Manager CCD Configuration Modes
• Basic configuration mode:
- All Cisco Unified Commurjications Manager servers use the same
primary or secondary SAP forwarders.
• Advanced configuration mode:
- Multiple sets of forwarder^ can beconfigured and individually applied to
Cisco Unified Communications Managerservers.
- This mode is required whe|n clustering overtheWAN deployment model
is used.

Single-Site Cluster c ^ Clustering ovpr the WAN Cisco Unified


Communications
Manager Cluster

Primary Secondary Primary Secondary


SRF Forwarder SAF Forwarder SAF Forwarder SAFForwarder

When you are configuring aCisco Unified Communications Manager cluster with one ormore
SAF forwarders, by default, all Cisao Unified Communications Manager nodes that are applied
to the SAF-enabled trunk or trunks Via the device pool will register with the configured SAF
forwarder.

First, you have to make sure that each local node uses adifferent SAF client ID. You can easily
check the nodes by using a SAF client name that ends with @. In this case, each node will
utilize the configured name that is followed by @and aunique node ID. At the SAF forwarder,
you have toadd the basename keyword tothe end ofthe SAF external-client client-ID
command, or you have to manually ^onfigure all names that are used by the nodes in your
cluster.

In some cases,you may not want all nodes that should use SAF register with all configured
SAF forwarders. For example, as shbwn in the figure, when youuse clustering overthe WAN,
you typically want to registernodes only with their local SAF forwarders. For that
configuration, click the Show Advanced link at the SAF forwarder configuration page.
At the advanced configuration mode page, you can associate individual members of the cluster
selectively with the configured SAF forwarders.

5-66 Implementing Cisco Unified Communications Managbr, Part 2(CIPT2) v8.0 12010 Cisco Systems. Inc.
Trunk Considerations When Using Globalized Call Routing
This subtopic describes considerations regarding the different trunk types when using
globalized call routing.

Trunk Considerations When Using


Globalized Call Routing

• OneSAF SIPtrunk andone SAF H323trunk can be configured


for CCD
- If both are configured, load-sharing occurs.
• with globalized call routing, PSTN numbers areto be dialed in E.164
format with + prefix
TEHO calls received via SAF are assumed to have +in called number.
Hosted directory number isin globalized format with +prefix.
- H 323 trunks do not send + (+ is stripped).
- Requires incoming called-party prefix to be configured at H323 trunk
(prefix +).
- Otherwise, received TEHO call cannotbe routed outto PSTN.
- Difficult totroubleshoot when H.323 and SIPtrunks are configured
for SAF.
• Half of the callswork (SIP), and half ofthe callsfail (H.323)

As mentioned earlier, vou can configure one SAF-enabled SIP trunk or one SAf-enabled H.32.^
trunk in Cisco Unified Communications Manager and in Cisco IOS Software. II both types of
trunk are used bv the advertising SAF client and both are used at the requesting SAF client,
then all routes are learned twice—once per protocol. When placing acall to such aroute, load-
sharing will occur, This means that half of the calls are setup using SIP, and half of the calls
are signaled by H.323.
When implementing TEHO and using globalized call routing, TFHO calls are expected to be
received with a- prefix. The reason is that they are advertised that way and the incoming VoIP
call can be routed back out to the PSTN at the TEHO gateway when the called number is in
globalized format.
II 323 trunks however, do not send the +sign. When acall is received (or placed) through an
H.323 trunk and the called number includes a+. the +sign is stripped. This does not happen on
SIP trunks.
When vou rclv on the +to be received through the H.323 trunk, you have to configure
incoming called-partv settings at the 11.323 trunk. Consequently, the +is prefixed before the
received called-party number is matched in the call-routing table without the +.
If vou have aSIP and an 11.323 trunk, and you do not prefix the 4- at the H.323 trunk due to the
load-sharine algorithm, even' second call would fail (H.323) while the other halfofthe calls
would work (SIP). Such apparently inconsistent errors are difficult lo troubleshoot.
Note When you expect to receive VoIP calls to internal directory numbers as well as to globalized
(PSTN) numbers, make sure that your incoming called-party settings prefix only the +to the
called numbers where it is required. You can either refer to the ISDN type of number or use
global transformations in order to control which called-party numbers you can modify.

Call Control Discovery 5-65


©2010 Cisco Systems, Inc
TEHO Considerations
This subtopic describes how CCD can be used to advertise TEHO routes.

TEHO Considerations

1TEHO destinations are located atthe PSTN and do not exist intemally.
• Advertised hosted DNis PSTNdestinationand not internal DN.
IfSAF-leamed TEHO route becomes unavailable, ToDID number is usedfor
automatic backup call.
- Typically, both numbers are identical (ToDID rule is 0:) anduse E 164format
with + prefix.

If no ToDID is advertised, calljfails until learned TEHO route is completely removed.


Learned route is removed only after expiration ofCCD PSTN Failover Duration
(default: 48 hours).
Cisco IOS Software can advertise +only in global patterns (which do not support
ToDID).
Avoid the use of global patterns in Cisco IOS Software.
• If - isrequired for TEHO implementation andlocal backup isdesired donot
advertise TEHO routes at'sites that use internal SAFclients.

TEHO destinations are located at tfye PSTN only; they do not exist internally at all. The
advertised directors' number is aP^TN number. When globalized call routing is enabled, this
number has to be in E. 164 format vvith a + prefix.
Calls toPSTN destinations will match the learned directory' number and are therefore sent to
the TEHO site over the IP WAN. lit case the IP WAN is down, the local gateway should be
used as a backup. This situation reduires having aToDID rule of0:. With this rule, the CCD
PSTN backup number is identical tp the learned directory number. When the IP path is marked
as unreachable, the same number would be called using the AAR CSS ofthe calling phone.
In Cisco Unified Communications Manager, generate aToDID rule of0: by checking the Use
Hosted DN as PSTN Failover check box. In Cisco IOS Software, you cannot set the ToDID to

Further, ifglobalized call routing is to be used, you are forced to use global patterns, which do
not allow any ToDID rule to be advertised.

When TEHO pattern is advertised without aToDID rule, local TEHO backup does not work
You could only configure static local backup routes by putting similar patterns into partitions
that are listed later in the phone CSS. Ilowever. such patterns are used only after the learned
pattern has been purged completely. By default, this process occurs after the expiration of the
CC DPSTN Failover Duration timer, which is 48 hours by default.
Based on these issues, it is recommended that you not advertise TEHO patterns from Cisco IOS
Software ifthe + is required and local backup is desired.

gg.
5-64
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 »2010 Cisco Systems, Inc.
Solution for PSTN Backup Advertised in E.164 Format Without
Leading +
['his subtopic describes the workaround for CCD PS'fN backup calls lo PSTN destinations that
are in E.164 format without a •+ prefix.

Solution for PSTN Backup Advertis*


E.164 Format Without Leading +

Standard AAR Call


Called Number
Composed Irom
Destination Phone
Called DN External DN and hxlirriUl
Phone Number Mask • Si..
2G01. -MC8S5Sv.XaX 52001 Route Pattern
Pattern \+'
Partition AAR
Urgent Pnority
AAR CSS
Route List
Partitions AAR
PSTN

CCD PSTN Backup


Call
Called Number ~J The +isprefixed for
Composed from \ callsplaced with
Learned DN Pall em ^ AAR CSS ifthe
and 1c _'•[} F<"re called number does
not include +
already

It would be vcrv cumbersome to add all possible E. 164 numbers lo the overall dial plan of
Cisco Unified Communications Manager. However, because CCD PSTN backup calls are
always placed with the use of the AAR CSS of the calling phone, you can add one translation
pattern ' to apartition that is accessible only from the AAR CSS. At that pattern, you can prefix
a+to the called-party number and set the CSS of the translation pattern to aCSS that has
access to the global PS'fN route pattern (\+!).
That process solves the issue with CCD PS'fN backup calls. Ilowcver. ifAAR is enabled, it
will break AAR. assuming that the AAR implementation is based on globalized call routing. IS
the external phone number mask of the destination phone is in E. 164 format with a+prefix,
then AAR calls would not work anvmore. The reason is that they use the same CSS and
therefore would also match the !translation pattern that prefixes a+. In this case AAR calls
would be placed to E. 164 numbers with two +signs. In order to also make AAR CSS cal s
work vou have to add asecond translation pattern into the same partition that is accessible
from the AAR CSS onh -This second translation pattern \+! is not configured with any digit
manipulation but uses the same CSS as the other translation pattern (!). As aconsequence.
AAR calls are passed on to the V+! route pattern without any digit manipulation (by matching
the more specific \+! translation pattern, which docs not prefix a+). CCD PS 1Nbackup calls
do not match the Vi-! translation pattern and are therefore routes, as explained earlier.

Note
The described solution is a workaround only. The implementation of advertised patterns in
Cisco IOS Software may be changed in the future so that +can be configured in the
advertised pattern and in the ToDID rule. If so, you should change from the described
workaround to the solution that allows CCD PSTN backup calls to be placed to globalized
numbers. .

Call Control Discovery 5-63


i_010 Cisco Systems,
Cisco IOS SAF Client Considerations When Using Globalized
Call Routing
This subtopic describes the limitations ofCisco IOS SAF clients regarding the use of the +sign
in advertised routes.

Cisco IOS SAF Client Considerations


When Using Globalized Call Routing

Cisco IOS internal SAF clients have limited support for +


sign when advertising patterns:
Solution for PSTN backup of internal DN:
- Advertise PSTN backup number in E.164 formatwithout +.
- Add + by translation pattern used forAAR calls to numbers
that do not start with +.

Cisco IOS Configuration DN Pattern


and ToDID

p-atlla da-tlock 1 i l l u -
P-.-~_ 197.555 4XXX
• The+ not supported In-lias-prefix or extension.
p«e-«B l tj-» uiuuios 0:1972555 • PSTN backup canrroi be advertised with +.

profil. da-block 2 • The + is added lo patternsconfigured with type


P_tt«rn 1 type global ♦ 14087071222 global,
H0470712-S (noToDID) •Global patternsalways have ToDID unset.
•There is no PSTN backupforglobal patterns

Cisco IOS internal SAF clients have limited support regarding the +sign in advertised routes.
In fact, the +sign cannot be configured in either the directory number pattern or the ToDID
rule, "fhe only way to advertise apattern with +is to use the pattern tag type global command
instead the pattern tag type extension command. In this case, however, Ihe ToDID is always
unset, regardless ofthe configured alias prefix at the directory number block profile.
When aCCD-enabled Cisco Unified Communications Manager uses globalized call routing for
PST Naccess, the mentioned limitation ofCisco IOS internal SAF clients causes issues because
the backup PSTN number is not in a format that Cisco Unified Communications Manaeer can
route to the PSTN.

The workaround is to make sure that CCD PSTN backup calls can be routed to the PSTN even
if the number that results from the ToDID rule does notstart with the+.

Note
Cisco IOS Software has limitations only in advertising patterns that include the +sign. Cisco
IOS Software can process received patterns that include a +sign without any problems or
limitations.

5-62
Implemenling Cisco Unified Communications Manager, Part 2(CIPT2) V8.0 ©2010 Cisco Systems, Inc.
CCD and Static Routing Integration Considerations
This subtopic describes how CCD can be integrated with static routing in Cisco Unified
Communications Manager.

CCD and Static Routing Integration


Considerations

All routes that are learned by CCDare put intothe same partition.
If partition islisted first in CSS. il has pnority tor equally qualified matches
Partition allows learned routes tolake precedence over statically configured
backup routes.
Make surethatbackup routes in later partitions are not more specific than
learned hosted DNs
Routes in later partition areconsidered only after learned entry iscompletely
deleted
• The learned IP path istried until CCD Learned Pattern IPReachable
Durationexpiration (default is 60 seconds)
IftheIPpathdoesnot work during this time, thecall fails.
• ToDID is usedas backup after expiration ofCCD Learned Pattern IP
Reachable Duration until expiration ofCCD PSTN Failover Duration (default
is 48 hours)
IfnoToDID is configured, the callfailsduring this time.
• The learned pattern iscompletely removed only after expiration ofCCD
PSTN Failover Duration.
Static backup patterns are now considered.

All routes that are learned bv CCD are put into the same configurable partition. Ifthis partition
is listed first in the CSS ofthe calling phones, ithas higher priority for equally qualified
matches than partitions that arelisted later.
Such aconfiguration allows learned routes to take precedence over statically configured backup
routes You have lo make sure that backup routes in later partitions are not more specific than
learned routes, because the order ofpartitions is relevant only ifthe matches are equally
qualified.
Be aware that routes in later partitions arc considered only after learned routes are removed
from the call-routing table.
When Cisco Unified Communications Manager loses IP connectivity to its SAF forwarder, it
wails for 60 seconds until it considers the IP path to be unavailable. You can configure this
time by using the CCD learned Pattern 11' Reachable Duration CCD feature parameter. During
that time, and calls to learned patterns fail.
Once the timer has expired. Cisco Unified Communications Manager starts another timer, the
CCD PSTN Failover Duration. The default value for this timer is 48 hours. During this time
Cisco Unified Communications Manager tries to place aCCD PSTN backup call. 11 no loDID
has been advertised. Cisco Unified Communications Manager assumes that there is no ISIN
backup path and that therefore calls will fail.
The learned route is purged only after the expiration of the timer. Then another (statically
configured backup) pattern, which is in apartition that is listed after the CO) partition, can be
matched If vol, want to use locally configured static backup patterns, etther disable t CO
PSTN backup b> setting the CCD PSTN Failover Duration timer to 0. or set the timer to a
lower value than the default {twodays).

Call Control Discovery


© 2010 Cisco Systems, Inc
When auser dials 89491000 while the gateway is in SRST mode, the IP path is marked
unreachable due to the loss of IP connectivity. Therefore, the ToDID rule is applied: it strips
the first four digits and then adds the prefix +1949222 so that the number that is used for the
PSTN backup call is +19492221000.
The only static configuration that is required at the Cisco Unified SRST gateway is an
outbound dial peer that routes calls starting with + toward the PSTN.

Hfc

5-60 Implementing Cisco Unified Communications Manager, Pari 2(CIPT2) vB.O 12010 Cisco Systems, Inc.
SRST Considerations
This subtopic describes how CCD can be implemented at Cisco Unified SRST gateways.

SRST Considerations

SRST subscribes to the CCD New Yort( SRST Routing Table


service but does not publish DN Pattern TaDiDRule . Protocol
any patterns.
During WAN failures, SRST 840BXXXX **14S855&' ;10©V BlP

uses learned patterns to B416XXXX 4:»14lB777- fC®'1 SIP


transparently reroute calls over SIP
the PSTN.

ACisco Unified SRST gateway does not need to advertise any internal directory numbers
because the SRST site is reachable only via the PSTN. It is the responsibility ofCisco Unified
Communications Manager to know how to route calls lo cluster-internal directorv' numbers
when they arenot reachable overthe IP WAN.
However the Cisco Unified SRST gateway needs a local dial plan that allows end users to
place calls to other sites b\ dialing the internal directory number ofthe other site. Cisco linified
SRS r then must transform the internally used directory numbers to the corresponding PS1N
numbers so that the call can be rerouted over the PSTN. This local dial plan does not have to be
configured manually when CCD is used. Instead, Cisco Unified SRST can subscribe to SAf
and hence learn all internallv known DN ranges and the corresponding ToDID rules. Cisco
Unified SRST learns these routes while there is no network problem. At this time, the learned
patterns are not utilized because the Cisco Unified SRST gateway does not route any calls:
Cisco Unified Communications Manager is in control ofall IP phones and performs call-
routing sen, ices.
Once IP connectivity is broken. IP phones fall back to the Cisco Unified SRST gateway, and
once roistered, the Cisco Unified SRST gateway has to route calls. Because the gateway has
learned all available internallv used directory numbers with the corresponding ToDID rules, it
can now route to the respective PSTN number any calls that are based on the dialed internal
directory number.
In the example, the Cisco Unified SRST gateway learned three patterns while IP connectivity
was working: 8408XXXX with aToDID rule of4:+l408555, 8415XXXX with aToDID rule
of4:+l8415. and 8949XXXX with a ToDID rule of4:+l949222.

Call Control Discovery 5-59


)2010 Cisco Systems. Inc.
CCD PSTN Backup—CSS
This subtopic describes which CSS is used for PSTN backup calls.

CCD PSTN Backup—CSS

When PSTN backup is invoked, HQ Learned Routes


the number that is built based on
the DN and the ToDID rule is called.
The AAR CSS of the calling phone
is used for PSTN backup call. Strip 0 digits, prefix +1972555
to directory number pattern
I4XXX) (or PSTN number.

Call Placed to +19725554001 witfi


AAR CSS of Calling Phone

When a learned pattern is marked unreachable anda ToDID has been advertised withthe
pattern,a PSTN backup call is placed. The CSS that is used for this call is the AAR CSS.
Make sure that the AAR CSS is set atall phones, so that PS'fN backup calls for CCD-learned
patterns will work. Also ensure that the number that is composed ofthe directory number
pattern and the ToDID rule isroutable (in other words, that a route pattern that matches the
number exists).

Note PSTN backup for CCD iscompletely independent from AAR. AAR isused toplace PSTN
backup calls for cluster-internal destinations when the IP path cannot be used because of
insufficient bandwidth as indicated by CAC.

It is only the AAR CSS that is reused for CCD PSTN backup. Otherwise, CCD PSTN backup
does not interact with AAR at all. For example, CCD PSTN backup works even when AAR is
globally disabled by the corresponding Cisco CallManager service parameter.

5-58 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 !> 2010 Cisco Systems, Inc.
Monitoring Learned Routes in Cisco Unified Communications
Manager Express
"Ihis subtopic describes how to monitor learned routes in Cisco linified Communications
Manager Express.

Monitoring Learned Routes in Cisco


Unified Communications Manager Express

BR2#shc sf dndb all

Last successful DB update 8 .010:03:12 16:03:27:838

........ private Dialplan Partition ********

Pattern - 2XXX
Primary Trunk-Bouts(B> ID : 273 274
Aliaa-Routels) Prefix/Strip-Lan : -.498952121/0

Pattern - 3XXX
Primary Trunk-Route(s) ID : 270 269
Alias-Route(B) Pretix/Strip-Len : ♦44228822/0

,,,,,... global (E164) Dialplan Partition •*•««*'

Pattern - *4420>
Trunk-Route!-} ID •- 271 272

Pattern - .16505051234
Trunk-Fouta(g) ID : 270 269

The figure shows how to display the SAF-leamed routes in Cisco IOS Software. Note that onl_
acall agent can interpret SAF service data; SAF forwarders cannot interpret SAF service data.
Therefore, this command works only on Cisco IOS routers that arc internal SAF clients as well
as SAF forwarder.
The output shows two types ofpatterns: extensions (with aToDID) that were learned from a
de\ ice other than aCisco IOS device, and global patterns, which include a+sign and no
ToDID infonnation (most likely advertised by another Cisco IOS internal client).

Call Control Discovery 5-57


) 2010 Cisco Systems, Inc
Monitoring Learned Routes in Cisco Unified Communications
Manager
This subtopic describes how to monitor learned routes in Cisco Unified Communications
Manager.

Monitoring Learned Routes in Cisco


Unified Communications Manager
«SAF-learned routes are not displayed in route plan reports
and cannot be viewed from Cisco Unified Communications
Manager Administration,
• Cisco Unified RTMT has to be used.

Oump-n

iM-rt-N. ctnuw-i -,
JraSBf„ a*» .Eatm _-j»<*
'3HMJ1118563) Reich**
nitMi(fflio)
!408707131; ?3f»3n!iS«3] Rotfuc* H323 tnunci?:oi
2matw2W()j:7 RtmaM SlttidWnKMlr 0151t(SM(i
SUnrnkiwCluslH 015 IH3J143f t>-umm
M(lW)ni1SSS3J HM!hj»
oiuiiaowj tSWKW
;ji«oiriis»ij rium
01132 tci?.ai
331*0*1185(3; Rsjuuw Stan-UcneriLisiBi 01511(5060)
_H1OTJM1J1» 35 Reichit* HSM SWkWWwCIusIb. ai.tici.t43t

SAF-leamed routes are not visible by any tool of the Cisco Unified Communications Manager
Administration web page. The only way to view SAF-leamed routes is by using the Cisco
Unified Real-Time Monitoring Tool (RTMT).
The figure shows an example ofSAF-leamed routes that are displayed by Cisco Unified
RTMT. The ToDID rule 0: means that the '-internal" pattern and the pattern that is used for
PSTN backup are the same pattern. This principle usually applies when advertising TEHO
patterns are advertised. The ToDID rules that are empty mean that there is no PSTN backup
path forthe respective learned patterns.

5-56
Implemenling Cisco Unified Communications Manager, Part 2<CIPT2) v8.0 >2010 Cisco Systems, Inc.
CCD Considerations
This topic describes important issues that you need lo consider when implementing CCD and
SAF.

CCD Considerations Overview

• Monitoring SAF-leamed routes


• CSS used for PSTN backup calls
• SRST implementation with CCD
• CCD integration with static routing
• Cisco IOS SAF client limitations when advertising +
• TEHO implementation with CCD
• Globalized call routing and trunk types
• SAF in Cisco Unified Communications Manager clusters that
use clustering over the WAN
• Other SAF and CCD considerations

This topic includes these CCD and SAF-related considerations:


• Monitoring SAF-learncd routes
• CSS used for PSTN backup calls
• SRST implementation with CCD
• CCD integration with static routing
• Cisco IOS SAF client limitations when advertising +
• TIJIO implementation with CCD
• Globalized call routing and trunk types
• SAF in Cisco Unified Communications Manager clusters that use clustering over th. WAN
• Other SAF and CCD considerations

Call Control Discovery 5-55


i2010 Cisco Systems. Inc
Step 6: Configure VoIP Dial Peer
The figure shows the configuration ofadial peer that refers to SAF-leamed routes in Cisco IOS
Software.

Step 6: Configure VoIP Dial Peer


rout.t «lgrp SAP

• •Evic.-fM.ily lpv» u tonohoua-ay•c•

. f - i n t . r f . c . F«.tl[
topology £•••
•Kit-at-topology
ult-»rvlca- Cully

Boic. l . t v i g . ,.(
prof 11a trunk-rout*
••••Ion protc • lp intarfaca loopbmckl tr.ui.port top pot
iflla da-block 1 allaa-pratlx 1972555
P» 1 typa «t«n»ioQ 4111

icollli c.llt
da-jarvlca
trunk.tout*
da-block 1

cbumal 1 vrc Sir ••yjtan 1


•ubacrib* ci ntrol wildc*rdad
VoIP dial peer for
publish c.ll roj 1 outbound calls using SAF.
I
dial-paar ,OK !IH5 voip

The configuration ofthis dial peer is like the configuration ofadial peer that refers to asession
target ras command when an H.323 gatekeeper isused. The destination pattern .Tstands for
all learned routes. The rest ofthe dial peer configuration is used as atemplate for the outgoing
dial peer that is irsed on outbound SAF calls, and for the incoming dial peer that is used on
inbound SAF calls.

Ifyou have other dial peers that also represent learned routes, the preference command will be
used to detemiine which dial peer should be treated with higher priority.

5-54
Implementing Cisco Unified Communications Manager. Part 2(CIPT2) vB 0 >2010Cisco Systems, Inc.
Step 5: Configure Requesting Service
"fhe figure shows the configuration of the advertising service in Cisco IOS Sotlware.

Step 5: Configure Requesting Service


router eigrp SAF

Bervice-family ipv4 autonomous-system 1

si-interface PastEtherriStO/0
topology base
exit-sf-topology
exit-service-faaily

profile trunk-route 1
Bession protocol sip interface loopbackl transport tcp port 5060
profile dn-block 1 alias-prefix 1972555
pattern 1 type extension 4XXX
I
profile callcontrol 1

trunk-route 1
dn-block 1

SAF client is enabled for


channel 1 vrouter SAF asysten 1 learning (subscribe).
subscribe callcontrol wildcards
publish callcontrol 1 J

You can also configure the requesting service under channel tag vrouter EiGRP-ID asystcm
-IS Use the subscribe callcontrol wildcarded command to enable the learning ofroutes that
are advertised by the SAF process that matches the autonomous system number that is specified
at the channel configuration level.

Call Control Discovery 5-53


i2010 Cisco Systems. Inc
Step 4: Configure Advertising Service
The figure shows the configuration ofthe advertising service in Cisco IOS Software.

Step 4: Configure Advertising Service


router eigrp SAP

servi -e-family iPv4 autonomous ayst

s£-i terface FaetEthernetO/0


topo ogy base
exit of-topology
exit- ervice-family

ervice saf
pro fi e trunk-route 1

ip interface loopbackl transport tcp port 5060


rofila dn-block 1 olias-prnfin 1972555
pattern 1 type extension 4XXX

rofile callcontrol 1
Actual SAF client, which you can enable
dn-service foradvertising (shown here)and learning
trunk-route 1 (shownin nextfigure). Advertising service
dn-block 1 (publish) refers to call control profile.
channel 1 vrouter SAF asyste Refers to EIGRP process and
publish callcontrol 1
autonomous system number.

You configure the advertising and requesting services under channel tag vrouter E/GRP-ID
asystem AS. "fhe EIGRP-ID argument refers to the name that was assigned to the router EIGRP
process (SAF. in the example shown). The AS argument is the autonomous system number that
wasassigned to the EIGRP service family.
To enable the advertising service itself, you use the command publish callcontrol tag The tag
argument refers to the tag that was applied to the previously configured call control profile
Effectively, you configure the call control profile (which determines which directory numbers
should be advertised by which trunk protocol) by the SAF process that is identified by the
autonomous svstem number.

5-52 Implementing Cisco Unifier) Communications Manager, Part 2(CIPT2) vS.O © 20)0 CiscoSystems, Inc.
Step 3: Configure Call Control Profile
The figure shows the configuration ofthe call control profile in Cisco IPS Software

Step 3: Configure Call Control Profile


router eigrp SAF

service-family ipv4 autonomous-system 1

sf-interface FastEthernet0/0
topology base
exit-sf-topology
exit-service-family

voice service saf


profile trunk-route 1
session protocol sip interface loopbackl transport top port 5060
1
profile dn-block 1 alias-prefix 1972555
pattern 1 type extension 4XXX
The profile refers to
profile callcontrol 1 directory number blocks
dn-service and trunk.
trunk-route 1
dn-block 1

fhe call control profile refers to one or more directory number blocks and to atrunk. 1he call
control profile will be used in the next step to specify that the listed directory number blocks
should be advertised at the specified trunk or trunks (if two ofthem are used). Another
command that xou can enter under dn-smice is site-code site-code extension-length length. It
allows asite code to be prefixed to all configured extensions referenced by the call control
profile The extension-length argument sets the number ofdigits (starting with the least
significant digit) that should be preserved from the configured extension before the site code is
added.

Call Control Discovery 5-51


© ;010 Cisco Systems. Inc.
Step 2: Configure Directory Number Blocks
The figure shows the configuration ofdirectory number blocks in Cisco IOS Software.

Step 2: Configure Directory Number Blocks

router eigrp SAF

service-family ipv4 autonomous-system 1


1

sf-lnterface FastEthernet0/0
topology base
exit-sf-topology
exit-service-family
1

voice service saf


profile trunk-route 1
session protocol sip interface loopbackl transport top port 5060
profile dn-block 1 alias-prefix 1972555
pattern 1 type extension 4XXX

Internal Directory Number and


Prefix for External PSTN Number

Each directory number block is configured globally with aToDID that is applied to all
extensions that are listed later. The command to configure adirectory number block is profile
dn-block tag alias ToDID-prefix strip ToDID-strip. The subsequent command toadd
extensions is pattern lagtype extension pattern.

Note The ToDID-strip argument stands for the number of digits to be stripped; the ToDID-prefix
argument stands for the prefix tobeadded tothe internal number after stripping digits.

Neither the ToDID-prefix argument nor the pattern argument support the use of the +sign. If
you want to advertise anumber with a+sign, you have to use the command pattern tag type
global pattern. Again, you cannot enter the +sign in the pattern argument; however, due to the
type global, a+sign is prefixed to the configured pattern. The ToDID ofglobal patterns is
always unset.

5-50
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 i* 2010 Cisco Systems, Inc.
Step 1: Configure Trunk Profile
The figure shows the configuration ofatrunk profile in Cisco IOS Software.

Step 1: Configure Trunk Profile


router eigrp SAF

service-family ipv4 autonomous-system 1


1
sf-interface FastEthernetO/O
topology base
exit-sf-topology
exit-service-family

voice service saf


profile trunk-route 1
session protocol sip interface loopbackl transport tcp
port 5060

Interface will be used for call


setup (signaling) of SAFcalls.

The trunk profile is con figured with the interface that should be used for call signaling. It is
configured also with the protocol type (in this case. SIP) and the transport parameters (I CP
versus UDP. and port number).
You can configure one SIP trunk or one 11.323 trunk.

Call Control Discovery 5-49


© 2310 Cisco Systems, Inc.
Internal SAF Client Configuration Procedure
This subtopicshowsthe configuration procedure of an internal SAF client.

Internal SAF Client Configuration


Procedure

1 Configure trunk profile.


2 Configure directory number blocks to be advertised.
3 Configure call control profile.
4 Configure advertising service.
5 Configure requesting service.
6 Configure VoIP dial peer referring to SAF.

The configuration steps that are listed in the figure are steps thai you can do multiple times, if
multiple SAF forwarder processes are configured in separate autonomous systems. Each SAF
client channel that is configured with the advertising and the requesting service has to refer to
anotherSAF autonomous system.
The CCD advertising service ofasingle SAF client channel can refer to multiple call control
profiles. This capability allows the configuration oftwo trunk profiles (one SIP and one H.323
trunk per call control profile). Only one trunk isrequired.

5-48 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 S2010 Cisco Systems. Inc.
CCD PSTN Failover Duration: This parameter specifies the number ofminutes that calls
that are placed to learned patterns that have been marked unreachable are routed through
PSTN faikner and are then purged from the system. For the duration that isspecified in
this parameter to start counting down, another service parameter, CCD Learned Pattern IP
Reachable Duration must first have expired. Theexpiration of thatparameter indicates that
IP connectivih is down between the SAF forwarder andCisco Unified Communications
Manager, and that all learned patterns are marked unreachable. Then, when the duration in
this parameter. CCD PSI'N Failover Duration, expires, all learned patterns are purged from
the system. Also, calls to purged patterns are rejected (the caller hears a reorder tone or a
"This number is unavailable" announcement). Setting this parameter lo 0 means that PSTN
failover is disabled. If the SAF forwarder cannot be reached for the number of seconds
defined inthe CCD Learned Pattern IP Reachable Duration service parameter, and no
failo\er options are provided through the PSTN, then calls to learned patterns will
immediateK fail. Setting this parameter to525600 means that PSTN failover will never
expire and.'as aresult, learned patterns will never be purged due to loss of communication
with the SAF forwarder, "fhe default is 2880 minutes (48 hours).
Issue Alarm for Duplicate Learned Patterns: This parameter determines whether Cisco
Unified Communications Manager issues an alarm called DuplicateLearnedPattern when it
learns duplicate patterns from different remote call control entities on the SAF network.
The default value is False.
(CD Stop Routing On Unallocated I nassigncd Number: ihis parameter determine*
whether Cisco Unified Communications Manager continues to route calls to Ihe next
learned call control entitv (ifadvertised by multiple call agents) when the current cail
control entitv rejects the call with the cause code for Unallocated/Unassigned Number. An
unallocated number represents a hosted directory number that does not exist in the current
call control entit\ . The default value is True.

Call Control Discovery 5-47


© 21)10Cisco Systems, Inc
Step 9: Configure CCD Feature Parameters
The figure shows the configuration ofCCD feature parameters in Cisco Unified
Communications Manager.

Step 9; Configure CCD Feature Parameters

fli" ^s*«a

® **• ****!

••n-ajva.

l»H.*S£™ '.!< If.LfcUc ,m^ tsffitra" |FW>


~3 F"k*
~3 T,"«

Here are the configurable CCD feature parameters:


• CCD Maximum Numbers ofLearned Patterns: This parameter specifies the number of
patterns that this Cisco Unified Communications Manager cluster can learn from the SAF
network. The higher the number ofallowed learned patterns, the more memory and CPU
processing power that is required. Balance the need for the number oflearned patterns in
your system with the resources ofyour deployment hardware components to guide you in
setting the value in this parameter. When Cisco Unified Communications Manager attempts
to leam more patterns than are allowed by the value that is set in this parameter, the alarm
CCDLeamedPatternLimitReached is issued. The default value is20000.
• CCD Learned Pattern IP Reachable Duration: This parameter specifies the number of
seconds that learned patterns stay active (IP reachable) before Cisco Unified
Communications Manager marks those patterns as unreachable. PSTN failover occurs
when Cisco Unified Communications Manager cannot communicate with the SAF
forwarder because of IP connectivity issues for the duration that is specified in this
parameter. For example, this parameter is set to20seconds. When Cisco Unified
Communications Manager cannot communicate with the SAF forwarder after more than 20
seconds, all calls to learned patterns will failover to the PSTN according to the learned
ToDID rule. PS TN failover continues until IP connectivity to the SAF forwarder is
restored. Cisco Unified Communications Manager automatically detects the restored
connects ity to the SAF forwarder. Cisco Unified Communications Manager then falls back
to the IP path of routes as soon as the routes have been received with the appropriate
reachability infonnation again. When the time that is specified by this parameter has
elapsed. Cisco Unified Communications Manager marks the learned patterns as
unreachable. Ifenabled, the CCD PSTN Failover Duration service parameter timer starts
which allows patterns that have been marked as unreachable through IP to instead be
reached through PSTN failover. The default value is60seconds
5-46
Implementing Cisco Unified Communications Manager, Part 2{CIPT2) v8.0
©2010 Cisco Systems, Inc.
Step 8: Configure CCD Blocked Learned Patterns
The figure shows the configuration of the CCD blocked learned patterns in Cisco Unified
Communications Manager.

Step 8; Configure CCD Blocked Learned


Patterns

Blocked wanted Pattern configuration


-Purge»""> ttock S*FCCD Learned Route* Intormat
Le»rnesJ Pattern

Lesrres Ssttetn Prefix

Remote Call Control Identity

Remote IP

Patterns can be blocked based


on remote call control ID, remote
IP. and learned pattern or
learned prefix (the last two are
exclusive!

Multiple blockingrules can be


configured. Ifa learned pattern
matches any rule, it is blocked

CCD blocked learned patterns are optional. If CCD blocked learned patterns are configured, all
routes that match any of the configured criteria arc blocked. As aresult, they are not added to
the call-routing table.
You can configure afilter that is applied to received routes in order to deny the learning of
routes, using these criteria:
• [earned pattern: The received pattern is checked in its entire length. If it matches ihe
configured learned pattern, it will not be added to the local call-routing table.
• 1earned pattern prefix: The received patterns arc compared with the configured prefix,
sorting with the left-most digit. By using alearned pattern prefix for blocking received
routes you can filter internally used numbers by their leading digits-tor example, by their
site code.
. Remote call control identity: Each call agent has aso-called SAF client ID By setting the
remote call control identity, you can filter received routes that are based on the ID of the
ad\ertising call agent.
• Remote IP: B> setting this filler, you can block routes that arc based on the advertising IP
address.

Call Control Discovery 5-45


© £010 Cisco Systems, Inc
Step 7: Configure CCD Requesting Service and Partition
The figure shows the configuration ofthe CCD requesting service in Cisco Unified
Communications Manager.

Step 7: Configure CCD Requesting


Service and Partition

Alllearned routes are put into


the specified partition.

Make sure that all devices


thai should be able to reach
SAF-leamed destinations
have this partition included in
their CSS,

You can configure only one CCD requesting service. You have to enter the partition that all
learned routes should be put into. You must first create the partition as shown in the figure.
In addition to creating the partition, you can configure the CCD requesting service with a
learned pattern prefix and aPSTN prefix. These prefixes are applied to all learned DN patterns
and to all learned ToDID rules, respectively.
Finally, the CCD that isrequesting service isreferred tothe SAF-enabled SIP or to the SAF-
enabled H.323 trunk.

Ifyou associate the CCD requesting service with only one type oftrunk, all received routes that
are reachable by the other (unconfigured) protocol type are ignored. They are not added to the
call-routing table.

5-44 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ;>2010 Cisco Systems, Inc.
Step 6: Configure CCD Advertising Service
The figure shows the configuration of the CCV> advertising service in Cisco Unified
Communications Manager.

Step 6: Configure CCD Advertising Service

^Sr» X1™" O0™ <£}*•• 'V"""*"


The advertising service
refers to trunks and
one hosted DN group
> uri.fe-l.i)*) <.™ii« Inf. -

SVHIH*™-.. , p

You need to configure one CCD advertising service for each eonligured hosted DN group. ^
bach CCD advertising sen ice can use the SAF-enabled SIP trunk or the SAF-enabled H.323
trunk. One trunk has to be specified. Multiple CCD advertising (and the CCD requesting
sen ice)can refer to the same SAF-enablcd trunks.

Call Control Discovery


© 2010 Cisco Systems, Inc
Step 5: Configure Hosted DN Pattern
The figure shows the configuration ofahosted DN pattern in Cisco Unified Communications
Manager.

Step 5: Configure Hosted DN Pattern

Is-* X**" D0" sQ>*mmn

®'-
- Hotted ON PMttra rrrfo •
Ho««fl »*t»re '

DeiciDbon

Hosted im Group"

If no ToDID rules are


configured, ToDID rules of
hosted DN group are
If set here or at hosted DN applied.
group, configured hosted
partem is also ToDID
number.

Hosted DN patterns refer to ahosted DN group. As mentioned earlier, ifthe parameters at the
hosted DN pattern are unset, the parameters ofthe hosted DN group are applied. When the
PSTN Failover Strip Digits field is set to 0and the PSTN Failover Prepend Digits field is
empty, both fields are considered tobe unset. The configuration example that isshown in the
figure does not generate aToDID rule of 0:, but it applies the settings of the configured hosted
DN group.

At the hosted DN group, the same logic applies. Ifthe PSTN Failover Strip Digits field is set to
0and the PSTN Failover Prepend Digits field is empty at the hosted DN pattern and at the
hosted DN group, then the no ToDID rule is advertised. As aresult, there is no PSTN backup
when the IP path is unavailable.
If you want to advertise aToDID rule of 0:, the number that should be used for backup is
identical to the internally used number (for example, when TEHO patterns are advertised)
Therefore, you have to check the Use Hosted DN as PSTN Failover check box.

5-42 Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0


>2010 Cisco Systems. Inc.
Step 4: Configure Hosted DN Group
The figure shows the configuration ofahosted DN group in Cisco Unified Communications
Manager.

Step 4; Configure Hosted

J^s.™ X0** D0"" &***"•

®-
The ToDID rules used for
- ltDflcd DN Sr
PSTN backup are applied to
hosted DN patterns only if not
Tconfigured at DNpattern
05™ ItJuvtK SOB DIOJIS 0

'.iUil HJiMOO" «! PSTN F*ltft>

if set at hosted DN pattern


configuration,hosted DN
group configurationis
ignored

The hosted DN group will be referenced from hosted DN patterns. Ifall—or at least most—of
the associated hosted DN patterns share the same ToDID rules, you can configure the ToDID
rule at the hosted DN group. The settings of the hosted DN group arc applied to the hosted DN
patterns if the hosted DN pattern parameters areunset.
The Use Hosted DN as PS'fN Failover check box instructs Cisco Unified Communications
Manager to create aToDID rule of 0:. As aresult, the number that is to be used for PSTN
backup is identical to the internally used number. Usually, this result occurs only when tail-end
hop-off (TF. HO) patterns are advertised.

Call Control Discovery 5-41


) 2010 Cisco Systems, Inc.
Step 3: Configure SAF Trunk
The figure shows how to add aSAF trunk in Cisco Unified Communications Manager.

Step 3: Configure SAF Trunk

^^^^^^^^^j SAF SIP trunk is shown. SAF


H.323 trunk is also supported.

-- -"- - ' in
S!>T.ur* I

[*™ tow'

You can configure one SAF-enabled SIP trunk (as shown in the figure) and one SAF-enabled
H.323 trunk. With aSAF-enabled H.323 trunk, you have to first add astandard nongatekeeper-
controlled ICT and then check the Fnable SAF check box. Once the check box ischecked, the
IP address field is disabled. The reason is that the configured trunk does not refer to aparticular
destination IP address but instead acts as a template for adynamically created trunk once a SAF
call isplaced. The destination IPaddress isthen taken from the learned SAF service data.
The same concept applies to the SAF-enabled SIP trunk. The only difference is that the SAF-
enabled SIP trunk is a special trunk service type, which isselected before the trunk
configuration page isshown. Therefore, there isno extra check box like there is atthe
nongatekeeper-controlled ICT. The SAF-enabled SIP trunk also does not have adestination IP
address field.

You can have one SAF-enabled H.323 oroneSAF-enabled SIPtrunk.

5-40
Implementing Cisco Unified Communications Manager, Part 2{CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Step 2: Configure SAF Forwarder
The figure shows how to add aSAF forwarder to Cisco Unified Communications Manager.

Step 2; Configure SAF Forwarder

Client label must match SAF


client ID configured at SAF
forwarder.

IPAddress of SAF Forwarder. i

The destination IP address has to match the one ofthe interface that is specified with the sf-
interfaee command at the SAF forwarder.
If you want to register with more than one SAF forwarder, click the Show Advanced link. This
link allows you to configure multiple SAF forwarders and to associate individual members oi
the cluster selectively with the configured SAF forwarders.

Note If you want to allow multiple nodes of aCisco Unified Communications Manager clusier to
act asSAF clients, each of them needs a unique client name. You can either configt re each
of them individually with separate node names or use aSAF client ID in Cisco Unified
Communications Manager, which is ctient-ID@ The @sign instructs Cisco Unified
Communications Manager to add a unique node number sothat the actual client IDs are
client-ID@1, client-ID@2, and so on.

At the SAF forwarder, you can either create individual entries or add the keyword basename
to the external-client client-ID command. Do not specify the @sign at the SAF forwarder:
only add the keyword basename to the external-client command, and the specifieo client
ID will bepermitted with any suffixes of @followed by a number.

Call Control Discovery 5-39


©2010 Cisco Systems, Inc
Step 1: Configure SAF Security Profile
The figure showshow to configure a SAF securityprofile.

Step 1: Configure SAF Security Profile

©«
This must match the usemame
and password configured at the
(trqitiw.
SAF forwarder.

Make sure that the username and the password match the username and password that were
configured at the SAF forwarder.

5-38 implementing Cisco Unified Communications Manager, Pari 2(CIPT2) v8.0 >2010 Cisco Systems, Inc.
External SAF Client Configuration Procedure
This subtopic shows the configuration procedure ofan external SAF client.

External SAF Client Configuration


Procedure

1 Configure SAF security profile.


2 Configure SAF forwarder.
:> Configure SAF trunk.
4 Configure hosted DN group.
5 Configure hosted DN pattern.
6 ConfigureCCD advertising service.
7 Configure CCD requesting service and partition.
8 Configure CCD blocked learned patterns (optional).
\i Configure CCD feature parameters (optional).

"fhe last two configuration steps are optional. You do not have to configure the CCD
advertising sen ice and the CCD requesting service ifyou want only lo advertise or leam call
routes (exclusively).

Note All stepsare performed at Cisco Unified Communications Manager.

Call Control Discovery 5-37


© 2010 Cisco Systems. Inc
Step 2: Configure SAF Forwarder to Support External SAF
Clients
The figure shows how lo configure a SAF forwarder to support an external SAF client.

Step 2: Configure SAF Forwarder to


Support External SAF Clients

router aigrp SAF

service-family Lpvi outoac


1

sf-interface FastEthernet This must match the SAF client


topology base IID configured at theexternal
e»it-Bf-topology SAF client.
external-oliont HQSAP

service-family external-eli at listen ipv4 5050


external-client HQSAP
UBername SAFUSEK
password SAFPASSWORD
IUsername and password must match
the settings at the external SAF client.

External client ID refers to the


appropriate SAF process and
autonomous system above.

Fach allowed exiemal client has to be listed in the service-family section. In addition, the
username and password that should be used by the external client have to be specified in the
service-family external client section.

Note If you want to allow multiple nodes of a Cisco Unified Communications Manager cluster to
act asSAF clients, each of them needs aunique client name. You can either configure each
ofthem individually with separate node names oruse a SAF client ID in Cisco Unified
Communications Manager, which isclient-ID@. The @sign instructs Cisco Unified
Communications Manager to add a unique node number sothat the actual client IDs are
client-ID®-}, client-ID@2, and so on.

At the SAF forwarder, you can either create individual entries or add the keyword basename
to the external-client client-ID command. Do not specify the @sign atthe SAF forwarder;
only add the keyword basename to the external-client command, and the specified client
ID wjjl bepermitted with any suffixes of@followed by a number.

5-36
Implementing Cisco Unifiea Communications Manager, Part 2(CIPT2) v8.0 32010 Cisco Systems, Inc.
Step 1: Configure SAF Forwarder
he figure shows the SAF forwarder configuration.

Step 1: Configure SAF Forwarder

EIGRP process \0 has only


local significance.

router eigrp SAF

service-family ipv4 autonomous-systew^^

sf-interface FastEthernetO/0
Autonomous system must be
topology base
the same on all SAF forwarders
exit-sf-topology
that should exchange data
exit-service-family
"~l

IP of specified interface is used


, by SAFforwarder:

In the example, aSAF forwarder is configured with autonomous system I. All SAF forwarders
that should exchange information with each other have to be in the same autonomous system.
You use the sf-interface command to bind the SAF process to the specified interface. Ifthe
router has multiple interfaces, if is recommended that you use aloopback interface.

Call Control Discovery 5-35


>2010 Cisco Systems. Inc
SAF Forwarder Configuration Procedure
This subtopic shows the configuration procedure of the SAF forwarder.

SAF Forwarder Configuration Procedure

1 Configure SAF forwarder,


2 Configure SAF forwarder tosupport external SAF client (if
used).

The configuration ofthe SAF forwarder consists oftwo steps: the SAF forwarder configuration
(mandatory) and the support ofan external SAF client (if used).

5-34 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Relationships of Internal SAF Client Configuration Elements
This subtopic describes the relationships ofinternal SAF client configuration elements.

Relationships of Internal SAF Client


Configuration Elements

SAF Client

DN Block DN Block
SAF CH«« "Charmer Profile Profile

CCD Recjueslmg
Service
Call Control Profile
CCD Advertising
Service

Trunk Profile

The figure illustrates how internal SAF client configuration elements relate to each other.
Note The configuration that is shown in the figure is one that you can do multiple times, if multiple
SAF forwarder processes are configured in separate autonomous systems. Each SAF client
"channel" has to refer to another SAF autonomous system

The CCD advertising service of a single SAF client channel can refer to multiple call control
profiles This capability allows the configuration of two trunk profiles (one SIP and one H.323
trunk per call control profile). Only one trunk isrequired.

Call Control Discovery


© 2010 Cisco Systems, Inc
Internal SAF Client Configuration Elements
This subtopic describes the configuration elements of an internal SAF client.

Internal SAF Client Configuration Elements

Configuration
Element Name Configuration Element Function

Trunk profile profiletrunk-route: Configured withinterfacewhose IP


addressshould be usedforsignaling when setting upSAF calls.
DN block profile profile dn-block: Configured withpatterns to be advertised
(internal number and number used for PSTN backup).
Call control profile profilecallcontrol: Refersto DN block profiles and trunk
profile.

channel: Configuredwith SAF client IDand autonomous


SAF client -channel' system. Advertising and requesting services areenabled; the
advertising service refersto the callcontrol profile.
dial-peer voice:Configured with destination-pattern .Tand
0(81 f>e& session target saf. This isthe incoming and outgoing dial peer
for a caHsent to or received from SAF trunks.

The table shows the configuration elements ofan internal SAF client, their functions, and the
ways that they interact with each other.

Note You can configure the advertising service and the requesting service independently of each
other.

5-32
Implementing Cisco Unified Communicalions Manager, Part 2(CIPT2) v8.0 >2010 Cisco Systems. Inc.
Relationship of External SAF Client Configuration Elements
This subtopic describes the relationship ofexternal SAF client configuration elements.

Relationship of External SAF Client


Configuration Elements

The figure illustrates how external SAF client configuration elements relate to each other.

Note
You can configure only a single CCD requesting service in your cluster. You can configure
mu
Itiple blocked learned patterns, SAF forwarders, and SAF security profiles. You a n
co
nfigure one CCD SIP trunk and one CCD H.323 trunk. Only one trunk is required

Call Control Discovery 5-31


© 2010 Cisco Systems. Inc
External SAF Client Configuration Elements
This subtopic describes the confiiuralion elements ofan external SAF client.

External SAF Client Configuration Elements

SAF security profile


Catena *musernameBiWpasBV«n).Reienmc«J(tomSAFtOnWidar.
SAF forwarder
Points to a AFforwarder Configured with IP addressof SAF forwarder Refers
to SAF sec nty profile

SAFtrur*s
One SAF trunk andone SAF H323 twr* canbeconfigured. Ttiey arenot
configure
configured' Hti
ti a destination IPaddress.Therest ofthe confaurafjon isstrraiar
to normals 3andH323r/uni».

Nested DN group Configured nthi PSTN laitover stripdigrtsand PSTN failover prepend diaits
1 DN patterns

Directory ot directory number raneetoBeadvetttned. Configured wth


Hosted DN pattern PSTN pdiojaj andPSTN faliover prepaid aigHs; ifnotonofigwad
hosted DN i •wipeonriguratlonriiH«).Appli8dtDhosted DNB'OUO
CCD advertising service Refersto hoptedDNgroup, SAFSIPtrunk, and SAFH.323trunk

CCD requesting service Configured<iitti route partition, teamed pattern prefix, and PSTN prefix. Refers to

Blocked learned patterns Configurediith remote IP. remote call control identity, and learned pattern or
learned pre! ;

The table showsthe configuration elements of anexternal SAF client, their functions, and the
ways that they interact with each o :her.

Note You can configure the C<


< ;d advertising service and theCCD requesting service
independently of each ot ler.

Theconfiguration ofbloc ;ed learned patterns is optional.

«*

5-30
Implementing Cisco Unified Communications Mana jer, Part 2(CIPT2) v8.0 >2010 Cisco Syslems, Inc.
High-Level Configuration Overview (Cont)
Implement external SAF client:
• Add external SAF client (Cisco Unified Communications Manager) to SAF
forwarder:
Specify SAF ID, username, and password of external client.
Map external SAF client toSAF autonomous system.
• Add SAF forwarder (Cisco IOS router) toSAF client (Cisco Unified
Communications Manager).
- Specify SAF ID. username, and password asconfigured at SAF
forwarder.
• Configure CCD at external SAF client.
Configure SAF trunks
- Configure hosted DN patterns andhosted DN groups.
ConfigureCCD advertisingservice.
Configure CCD requesting service and partition for learned patterns.

When implementing external SAF clients, you must perfonn these high-level configuration
tasks:

Stepl At the SAF forwarder (Cisco IOS router), add the external SAF client (Cisco
Unified Communications Manager):
• Specif\ the SAF ID. username. and password ofthe external client.
• Map the external SAF client to the SAF autonomous system.
Step 2 At the external SAF client (Cisco Unified Communications Manager), add the SAF
forwarder (Cisco IOS router):
• Specify the SAF ID. username. and password as configured at the SAI
forwarder.

Step 3 Contigurc CCD atthe external SAF client:


• Configure a SAF SIP ora SAF H.323 trunk.
• Configure the hosted DN patterns and hosted DN groups.
• Contigurc the CCD advertising service.
• Configure the CCD requesting service and the partition to be used for learned
patterns.

Call Control Discovery 5-29


i 2010 Cisco Systems, Inc
SAF and CCD Implementation
This topic describes how to impl ment SAF in Cisco IOS routers. It alsodescribes howto
implement CCD in Cisco Unifiel Communications Manager and in Cisco IOS call agents such
as Cisco Unified Communicatior s Manager Express.

High-Level Configuration Overview

Configure SAF networf


• Configure SAF forwarde s on Cisco IOS routers.
- Specify same autono nous system on all SAF forwarders,
Implement internal SAI client:
• Configure trunk profilew:h IP to be used for call setup,
• Configuredirectorynuml er blocks to be advertised,
Configure call control profile referring to directorynumber blocks
and trunk to be used.
Configureactual CCDrpn »cess (channel) referring to SAF forwarder
by autonomous system n jmber.
- Enable advertising servicebyreferring to callcontrol profile, *»

- Enable requesting se
ConfigureVoIP dial peer eferring to SAF.

The first main configuration task : ;to enable SAF inthe network. You have toconfigure SAF
forwarder functionality on a Cisoc IOS router. All SAF forwarders must share the same SAF
autonomous system number. You :an specify the interface thatshould beused bytheSAF
forwarder.

Whenusing internal SAF clients, •ou mustperform these main configuration tasks:
Step 1 Configure a trunk prof e and specify the interface and theprotocol to beused for
call signaling.

Note The IP address (interfaci) that is used for call signaling can be different from the IP address
that is used by theSAF forwarder.

Step 2 Configure the directoryjnumber blocks to be advertised.


Step 3 Configure acall controljprofile that refers to the directory number blocks and the
trunk profile to be used.
Step 4 Configure the actual cqD process ("channel") that refers to the SAF forwarder by
its autonomous system dumber. Then perfonn these tasks:
• Fnable the CCD advertising service by referring to the call control profile.
• Fnable the CCD requesting service.
Step 5 Configure a VoIP dial pier that refers to the SAF.

5-28
Implementing Cisco Unified Communications Mans per, Part 2(CIPT2) v8.0 12010 Cisco Systems, Inc.
Note if the leamed pattern was removed when the IP path became unavailable, the originating
site would not know what PSTN number to use for the backup call. By default, a route is
completely removed only if it has not advertised for 48hours.

Call Control Discovery 5-27


© 2010 Cisco Syslems. Inc
CCD—Call from HQ to BR During Link Failure
This subtopic describes the call $ow for acall from the HQ site to the BR site during a link
failure at the BR site.

CCD—Call frorri HQ to BR during Link


Failure

BR Learned Routes

XKtX Q>.«a953tS1 101.5.10

- PSTtt • Cal1 Placed lo +19725554001


" UsingPSTN

When a user at the HQ site dials I00I during the link failure at the BRsite, the called numberis
still found in the call-routing tabl of the HQ Cisco Unified Communications Manager cluster.
However, the IP path is marked i ireachable, and therefore the call cannot besetup over the IP
network with the use of a SIP tru ik

Cisco Unified Communications M anager now checks whether there is a ToDID rule that is
associated with the leamed patte i. In this case, a ToDID rule of 0:+1972555 has been learned.
Cisco Unified Communications Manager does not strip any digits {because ofthe 0 in front of
the : [column]), but adds the pref +1972555 to the dialeddirectorynumber 4001. The
resulting number +19725554001 s now matched in the call-routing table of Cisco Unified
Communications Manager, when a match is found in a PSTN routepattern.

Note The CSS that is used fo • the PSTN


backup call istheAAR CSSofthecalling phone. The
route pattern, route list,
oute group, and gateway for PSTN access has to be in place in
order for PSTN backup o work. Further, the PSTN route pattern has to be in a partition that
is reachable from the AAR CSS of the calling phone.

In the example, the ToDID rule results in globalized PSTN numbers (E.164 format with a +
prefix) Therefore, a PSTN route pattern that matches this format (for example, \+.!) has to
bein place. If all sites share the same PSTN dial rules-for example, all sites arewithin the
North American Numbering Plan (NANP)—then you could also configure ToDID rules that
result in PSTN patterns with a PSTN accesscode, followed by a national accesscode
followed by the 10-digit PSTN number. In this case, your PSTN route pattern would have to
be91[2-9]XX[2-9]XXXXXX.

The call is now set up over the PSTN.

5-26 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 © 2010 Cisco Systems, Inc.
CCD—Link Failure at BR
This subtopic describes how CCD manages a link failure between the SAF client and its SAF
forwarder at the BR site.

CCD—Link Failure at

HQ Learned Routes BR learned Routes

«M 0«1WI559 B0« r);M0R6il!1 ' WI.S.10 SIP


Marked Unreachable

•- - PSTN-
•49S953i2ixxxx>s:;:::;;

HQ 101510

SAF-Enabled
IP Network

When the connection between the SAF client and the SAF forwarder at the BR site isbroken,
the SAF forwarder atthe BR site detects this problem that is based on the missing keepalives of
the registered SAF client.
The BR SAF forwarder sends an update throughout the SAF-enabled network so that all SAF
forwarders are aware that the IP path to4XXX is currently unavailable. Other than in IP
routing, the learned route is not removed, but only the IP path is marked unreachable.
All SAF forwarders that have registered SAF clients now pass this update on totheir SAF
clients, so that all SAF clients in the network can mark the IP path lo4XXX as unreachable.
As shown in the figure, the call-routing table at the HQ site also gets updated accordingly.

Call Control Discovery


© 2010 Cisco Systems. Inc
CCD—Call from HQ to BR
This subtopic describes the call flow for a call from the HQ site tothe BR site.

CCD—Call from HQ to BR

BR Learned Routes

WWt »*48WS3«1 W13.10

Call placed to 4001 using SIP trunk to 10.1.7.10.

PSTN;

The HQ site dials 4001. The called number is found in the call-routing table ofIhe IIQ Cist
Unified Communications Managercluster.

Note All learned routes are put into the same configurable partition The CSS of the calling phone
must have access to this partition in order for the call towork. If the calling phone does not
have access to the partition that includes all learned patterns and there isno match in any
other partition, the call fails.

Cisco Unified Communications Manager identifies the matched pattern as aCCD-learned


pattern. According to the learned route, the call has to besetup through a SAF-enabled SIP
trunk, which is dynamically created tothe destination IP address as leamed by CCD (in this
case. 10.1.7.10).
The call is now set up over the IP network.

5-24 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 >2010 Cisco Systems, Inc.
CCD—Propagation of BR Routes
This subtopic describes how BR routes are propagated to the IIQ site.

CCD—Propagation of BR Routes

HQ Learned Routes BR Learned Routes

W&nmmmWmMmW mmnV^&mmmmmn^R Mf

0-*!B7M65 10.1 T.10 SIP ao« «»«0M»iai, 10.iS.1tt BIP

Learn hosled DN range and ToDID


rule and store in memory

Advertise hosted DN range


PSTN
(4XXX) and ToDID rule
(0+1972555).
M972555XXXX

SAF-Enabled
IP Network

The Cisco Unified Communications Manager cluster atthe BR site advertises its direeto >
number range 4XXX with aToDID rule of0:+1972555 to its SAF forwarder, fhe SAF
network propagates this new route throughout the network, and the SAF forwarder at the HQ
site sends the information to the HQ Cisco Unified Communications Manager cluster. The call-
routing table of the HQ cluster is populated with the directory number pattern 4XXX and a
ToDID rule of 0:^1972555.
Again, onh aSIP trunk has been associated with the CCD advertising service at the originating
site. Therefore, the IIQ cluster learns the route only forSll\
The network is in a converged state. All sites know about the routes ofall other sites.

Call Control Discovery 5-23


) 2010 Cisco Systems, Inc
CCD—Propagation of HQ Routes
This subtopic describes how HQ routes are propagated tothe BR site.

CCD—Propagation of HQ Routes
HQ Learned Routes BR Learned Routes

WW &MW85S1S1 W.J5.10" " ~W

Learn hosted DNrange


and ToDID rule and store
in memory.

97255SXXXX

Advertise hosted DN
range (2XXX) and ToDID
rule (0:^-498953121

The Cisco Unified Communications Manager cluster at the HQ site advertises its directory
number range 2XXX with a ToDID rule of0:+49895312I to itsSAF forwarder. The SAF
network propagates this new route throughout the network, and the SAF forwarder atthe BR
site sends the information to the BR Cisco Unified Communications Manager cluster. The call-
routing table ofthe BR cluster ispopulated with the directory number pattern 2XXX and a
ToDID rule of 0:+498953121.

At the advertising site, only aSIP trunk has been associated with the CCD advertising service.
Therefore, the BR cluster learns the route only for SIP.

5-22
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 >2010 Cisco Systems. Inc.
CCD Operation
This topic describes how CCD works for on-net calls and how CCD reroutes calls to the PSTN
if the IPpath is notavailable.

CCD—Base Configuration

HQ Learned Routes BR Learned Routes

The figure shows the base configuration. There are two sites, each with aCisco Unified
Communications Manager cluster. One site (••HQ" in the figure) is located in Germany, and it
has -i DID ran°e of +4989^3121 XXXX. Intemally, range 2XXX is used. The other site ("BR )
is in the United States: it has a DID range of+ I972555XXXX. Internally, the directory number
range 4XXX is used.
m

Call Control Discovery


12010 Cisco Systems. Inc
All learned routes are put into one configurable partition. All devices that should have access to
leamed routes need that partition to be included in their calling search space (CSS). Sometimes
the IP path tor alearned route may not be available, and aToDID rule may have been
advertised with the hosted directory number. In that situation, acall to the transformed number
(a ToDID rule that is applied to the advertised pattern) is placed with the automated alternate
routing(AAR) CSS of the callingdevice.

Note
PSTN backup for CCD is completely independent from AAR. AAR is used to place PSTN
backup calls for cluster-internal destinations when the IP path cannot beused because of
insufficient bandwidth as indicated by Call Admission Control (CAC).

It is only the AAR CSS that is reused for CCD PSTN backup. Otherwise, CCD PSTN backup
does not interact with AAR atall. For example, CCD PSTN backup works even when AAR is
globally disabled by the corresponding Cisco CallManager service parameter.

5-20 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems. Inc.
Processing Received Routes in Cisco Unified Communications
Manager
This subtopic describes how received routes are processed in Cisco Unified Communications
Manager,

Processing Received Routes in


Unified Communications Manager

Administrator can block received routes based on;


• Learned pattern prefix
• Learned pattern
• Remote call control identity
* Remote IP

Load balancing occurs for learned routes:


• Round robin between protocols, among local trunks (SIP and
H 323), and learned remote IP addresses
Partitions and CSS:
• All learned patterns are put into oneconfigurable partition.
• All devices that should have access to learned routes need
access to that partition from their CSS
• AAR CSS is used for PSTN backup calls.

You can configure afilter that is applied to received routes in order to deny the learning of
routes, using these criteria:
• Iearned pattern prefix: The received patterns are compared with the configured prefix,
starting with the left-most digit. By using alearned pattern prefix for blocking receiv ed
routes, you can filter intemally used numbers by their leading digits—lor example, by their
site code.
• 1earned pattern: The received pattern is checked in its entire length. If it matches the
configured learned pattern, it will not be added to the local call-routing table.
• Remote call control identity: Each call agent has aso-called SAI-' client ID. By setting the
remote call control identity, you can filter received routes that are based on the ID o. the
advertising call agent,
. Remote IP: By setting this filler, you can block routes that are based on the advertising IP
address.

You can configure one or more criteria when setting up afilter. However, as soon as one
criterion ismatched, the learned route is filtered.
The same destination number can be learned multiple times. It may be advertised by different
call agents. It mav allow SIP and 11.323 to be used for setting up the call (both signa ing
protocol capabilities are advertised separately). It also may be reachable at multiple IP
addresses (of the same call agent, in the case of aCisco Unified Communications Manager
cluster). Ifa route is learned multiple times, Cisco Unified Communications Manager™! load-
share the outbound calls to the corresponding destination among all possible paths (that is. t>>
protocol and remote IP addresses).
Call Control Discovery
S 2010 Cisco Systems. Inc
Note Like thetrunks that areassociated with CCD advertising services, thetrunks thatare
associated with theCCD thatis requesting services are not used to learn patterns via SIP or
H323. They determine theoutbound capabilities for calls thatare placed tolearned
destinations. If the CCD that isrequesting service isassociated only with an H.323 trunk,
learned routes that areto bereached via SIP are not added to the call-routing table of the
receiving Cisco Unified Communications Manager.

The Cisco Unified Communications Manager nodes of the cluster that ispermitted to place
outbound calls to learned routes are determined by the device pool that isapplied to the
trunk that is associated with the CCD requesting service.

mm

5-18 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 >2010 Cisco Systems, Inc.
CCD Services in Cisco Unified Communications Manager
This subtopic describes the two CCD services that exist in acall agent such as Cisco Unified
Communications Manager.

CCD Services in Cisco Unified


Communications Manager

CCD advertising service


* Responsible for advertising:
-- Hosted DN ranges
- PSTN failover information (ToDID rule)
- Trunk information
• Configured with one or two trunks (one SAF CCD SIP trunk and
one SAF-enabled H.323 ICT supported)

CCD requesting service


• Responsible for learning DN ranges from the SAF network
* Exists only once per Cisco Unified Communications Manager
cluster
• Configured with one or two trunks (one SAF CCD SIP trunk and
one SAF-enabled H.323 ICT)

fhe CCD advertising sen ice is configured with the directory' numbers that are to be advertised.
In Cisco Unified Communications Manager, they are configured by so-called hosted DN
(directorv number) ranges. Fach hosted DN range is configured with its PSTN failover
information (the ToDID rule for the hosted DN range). In addition, the signaling protocol and
the IP addresses ofthe call agents have to be advertised. They are configured by a trunk. The
trunk can be a SAF-enabled H.323 intercluster trunk (ICT) ora SAF CCD SIP trunk. CCD
advertises call routes with one ormore call agent IP addresses. 1he IP addresses tobe
advertised are determined bv the device pool that isapplied tothe SAF-enabled trunk.

Note The trunk is not used to advertise call routes Call routes are advertised by CCD and SAF
and not via H323 orSIP. The trunk is used todetermine the IP addresses ofthe call agents
and the supported signaling protocols, in case another call agent wants to establish a call to
a learned call route

The CCD that is requesting service is responsible for subscribing to call-routing infonnation
from its SAF forwarder. It allows Cisco Unified Communications Manager to leam routes from
the SAF-enabled network. Onlv one CCD that is requesting service exists per Cisco Unified
Communications Manager cluster. However, like the advertising service, it can be configured
to accept patterns that are reachable via SIP or H.323. depending on the associated trunk or
trunks.

Call Control Discovery


)2310 Cisco Systems. Inc
• Number ofdigits to be stripped: The first part ofaToDID rule is the number of digits to
be stripped from the intemally used number. For example, ifsite code dialing is used and
the internally used number to reach ablock ofdirectory numbers is 8-408-2XXX, you may
want to strip the leading 8408 before prefixing the necessary digits to directory number
range 2XXX. In this case, your ToDID rule would start with 4: (because the four leading
digits should bestripped).
• Prefix to be added to the (deflated) internal number: The second part ofaToDID rule is
the prefix that should be added to the intemally used number after digit stripping has been
performed. In the previous example, ifthe PSTN direct inward dialing (DID) range of the
intemally used directory number range 2XXX (dialed as 8-408-2XXX from other sites) is
408 555-2XXX, the prefix would be 408555. Usually E.164 format with a+prefix is used
to represent the PSTN number, so the configured prefix would be+140855.

In the given example, the complete ToDID rule would be 4:+1408555, because the numbers to
be stripped and the prefix are separated by a column.
By advertising only the locally present internal numbers and the corresponding ToDID rule at
each call agent, the dial plan implementation oflarge networks is extremely simplified. Ifthere
are any changes at acall agent, you have to change only the advertised number (range) and its
ToDID mle at the affected call agent. All other call agents will dynamically leam the changes

5-16
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 >2010 Cisco Systems, Inc.
CCD Characteristics
Ihis subtopic explains the main characteristics ofCCD.

Call Control Discovery Characteristics

• CCD enables call agents to exchange call-routing information:


•- Dial plan information
Reachability information (IP address ofcall agents)
• Allows dynamic routing based on information learned through SAF
- No need for full-meshedcall-routing configuration
No need for centralized gatekeepers
Only local number ranges that should beadvertised must be
configured
• Propagated dial plan information has two components:
Enterprise-owned, internally used numbers
External (PSTN) numbersfor PSTN backup
• Simplifies dial plan implementation in large networks

CCD enables call agents to exchange call-routing information. The infonnation that is relevant
consists of these components:
• Dial plan information: Dial-plan infonnation includes internally used directory numbers
(potentially with internal prefixes such as site codes), the IP addresses ofthe respective call
agents and the signaling protocol that will be used by the call agents. Ali ofthis
information is advertised by call agents that is propagated throughout the network by SAP.
and then learned by other call agents.
• Reachability information: This dynamic routing for call reachability infonnation
drastically simplifies dial plan implementations in large networks. There is no need lor a
static full-mesh configuration and no need even for the configuration of acentralized call-
routing sen-ice (such as an H.323 gatekeeper or aSIP network service). You have tc
configure onlv the internal number range that should be advertised per call agent at the
respective call agent. CCD and SAF then ensure that the locally known numbers are
distributed among all call agents.

When rerouting over the PSTN is desired, call agents are configured not only to ^crtise their
internallv used number ranges, but also with the corresponding PSTN numbers, Hie PS 1N
number is not advertised as adistinct number, but it is advertised by aPMNtailovcr digit
transformation rule that is known as aToDID rule. AToDID rule describes how he mtemally
used number has to be manipulated to get to the associated PS TN number. AIoDID rul.
consists of two components:

Call Control Discovery 5-15


© 2010 Cisco Systems, Inc.
CCD Characteristics
This topic describes the characteristics ofCCD and how CCD forwarding and requesting that
services are used in Cisco Unified Communications Manager.

CCD Overview

Cisco Unified SAF clients generate call-routinginformationand send it as SAF


Co mmunica lions service data to their SAF forwarders.
Manager
SAF forwarders propagate information to olher SAF forwarders
only considering SAF header.
SAF forwarders send information to SAF clients, which process
SAF service data (call-routing information).

SAF Service Oata (CCD


information) as Sent lo
and from SAF Client

SAF External Clianl Cisco IOS

SAF Advertisement as Exchanged


Between SAF Forwarders

CCD is a function ofcall agents. Itallows call agents to advertise locally known internal
directory numbers and the corresponding PSTN numbers to other CCD-enabled call agents.
CCD utilizes SAF for distributing call-routing infonnation over the SAF-enabled network.
ACCD-enabled call agent is configured to send its locally configured directory number range
as a SAF service to a SAF forwarder. The CCD SAF client generates SAF service data (call
reachability information) and passes iton to the SAF forwarder that will propagate the
information within the SAF network. All SAF forwarders that have SAF subscribing clients
that are attached send the SAF service data to their clients. From aCCD perspective, all SAF
clients exchange SAF service data (call-routing information).
You can compare the SAF service data with the TCP or the User Datagram Protocol (UDP).
which establishes an end-to-end communication between IP endpoints. Likewise, CCD-enabled
call agents exchange call-routing infomiation via the end-to-end service data exchange.
The SAF header can be compared to the IP header. It is also interpreted at intermediate nodes
(SAF forwarders), while these intermediate network nodes do not process the payload (that is.
the SAF service data).

5-u Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 © 2010 Cisco Systems, Inc.
SAF Client and SAF Forwarder Functions
This subtopic describes SAF client and SAF forwarder functions.

SAF Client and SAF Forwarder Functions

SAF client functions:


• Register to the network
• Publish services
• Subscribe to services
• Send keepalives

SAF forwarder functions:


* Propagate updates received from SAF clients to other SAF
forwarders
• Send hellos to other SAF forwarders
• Propagate updates to SAF clients

SAF clients register to the network, more precisely lo aSAF forwarder. They can publish
sen ices (that is. advertise infonnation) to the SAF network or subscribe to services (that is.
request infonnation) from the SAF network. In order to allow the SAF client and the SAF
forwarder to quickly detect dead peers (for example, ifthe device was powered off), they
exchange keepalives.
SAF forwarders propagate updates that are received from SAF clients that publish sen ices to
other SAF forwarders. Thev send updates to SAF clients, which subscribe to services. Ir.
addition. SAF forwarders exchange hellos with other SAF forwarders in order to detect dead
peers.

Call Control Discovery


© 2010 Cisco Systems. Inc.
SAF Neighbor Relationships
This subtopic describes how SAF forwarders can be connected to each otht

SAF Neighbor Relationships

Two options for neighbor relationships:


• Layer 2 adjacent
- " k k- ?(with dynamic discovery)
- Unicast (with static configuration)
• Non Layer 2 adjacent
- Static configuration

SAF forwarders can be. but do not have to be, directly neighboring devices. If they are Layer 2
adjacent, there are two configuration options:
• Multicast: When multiple SAF forwarders are connected via abroadcast-capable medium
like a LAN using Fthernet, they can communicate toeach other via multicasts. This
communication allows adynamic neighbor discovery because there is no need to statically
configure the Layer 2 adjacent neighbors.
• Unicast: When it is not desired that all SAF devices on abroadcast-capable medium
automatically discover each other. SAF forwarders can be configured to send updates only
to statically configured neighbors via unicast messages. In the figure, the lower-left
example shows three routers that are connected to an Fthemct. However, other than in the
upper-right example, they should not build adjacencies among each other in a full-mesh
fashion. Instead, they should communicate only in ahub-and-spoke fashion (one router
communicates with both ofthe others, and the other two routers do not communicate
directly with each other).

When SAF forwarders are not Layer 2adjacent—that is, when there are one or more IP hops
between them—these nonadjacent neighbors have to be statically configured. No discoverv is
possible. See the Hlustration in the lower-right comer of the figure for an example of non-L aver
2 adjacent SAF forwarders.

5-12
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8 0 H2010 Cisco Systems. Inc.
SAF Routing Characteristics
This subtopic describes the main characteristics ofSAF routing.

SAF Routing Characteristics

• SAF-FP uses features and functions of EIGRP, including:


- Bandwidth percent
Hello interval
Hold time

- Split horizon
Authenticated updates
- Incremental updates (only when changes occur)
• Independent of IP routing protocol
Static
• Dynamic (EIGRP. OSPF, BGP, and so on)

The SAF-FP uses features and functions of the Enhanced Interior Gateway Routing Protocol
(F1GRP) for SAF routing. Features and mechanisms that are utilized and known from EIGRP
include the DifTusing Update Algorithm (DUAL) to prevent loops, reliable transport over IP (IP
protocol 88). support for authenticated updates, and incremental, event-triggered updates tor
fast convergence and low -bandwidth consumption. Configurable parameters that relate to these
FIGRP-derived features include bandwidth percent, hello interval, holdtime. split horizon,
maximum hops, andmetric weights.
Although SAF routing is verv like EIGRP, it is independent of the used IP routing protocol,
SAF works over static routing, as well as in networks that use dynamic routing protocols such
as FIGRP Open Shortest Path First (OSPF). and Border Gateway Protocol (BGP).

Call Control Discovery


i 2010 Cisco Systems. Inc
SAF Message Components
This subtopic shows the two components of a SAF message.

SAF Message Components

Relevant to SAF forwarders Relevant to SAF clients


Identifies service type and Service-specific
unique instance information
Used by forwarders to Transparent to forwarders
propagate advertisements
Client data depends on
Metrics used to avoid loops service type

A SAF message consists of two components:


• SAF header: The SAF header is relevant mainly to SAF forwarders. It identifies the
service type (for example, CCD) and includes information that is relevant for the dynamic
distribution of SAF services, such as metrics and loop detection information.
• SAF service data: SAF service data is relevant only to the SAF client. A SAF forwarder
cannot interpret the SAF service data. SAF service data includes the IP address and port of
the advertising SAF client and detailed client data that describes the advertised service.
With CCD. client data includes call-routing information such as directory numbers, the IP
address of the call control device, the signaling protocol to be used to communicate with
the call control device. PSTN prefixes, and so on.

5-10 ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)v8.0 )2010 Cisco Systems, Inc.
SAF Client Types
This subtopic describes the two available CCD SAF client types.

SAF Client Types

SAF forwarder is always Cisco IOS router. Cisco Unified


Communications
Two types of SAF clients:
Manager
External SAF clients
* SAF client and SAF forwarder are
different devices.

« SAF client is Cisco Unified


Communications Manager.
Internal
* SAF-CPisused. API

• Internal SAF clients

• SAF client and SAF forwarder are


colocated functions within the
same device.
* SAF clients are Cisco Unified
Communications Manager
Express, Cisco Unified SRST,
Cisco Unified Border Element,
and Cisco IOS gateways.
• Internal API is used

A SAF forwarder is alwavs a Cisco IOS router. Remember that SAF forwarders do not process
the propagated service infomiation. Their function is to propagate the information within the
SAF network and lo pass it on to SAF clients.
SAF clients then interpret the service infomiation. With CCD. the SAF client is a call control
device, which sends and receives call-routing infomiation. Depending on the type of call
control device, the CCD device can be an internal or external SAF client:
*• • External SAF client: The SAF client and the SAF forwarder are two different devices.
They use the SAK-C1' for communication. An exampleof a CCD externalSAF client is
Cisco Unified Communications Manager.
• Internal SAF client: The SAF client and the SAF forwarder arc two different functions
within the same device—a Cisco IOS router. They use an internal application programming
interface (API) for communication. Examples of CCD internal SAF clients are Cisco
Unified Border Element. Cisco Unified SRST. Cisco Unified Communications Manager
Express, and Cisco IOS gateways.

©2010 Cisco Systems, Inc Call Control Discovery


SAF Characteristics
This topic describes the characteristics of SAF.

SAF Components
Cisco Unified Cisco Unified
SAF supports any service
lo be advertised Communications Communications
Manager Manager
CCD is the first Cisco application
using SAF to advertise services
(call routing)
SAF network components.

• Exchange service
information among
each other

• Use the SAF Forwarding


Protocol (SA^-^PI

Advertise services lo and


leam services from SAF
forwarders

Use SAF Client Protocol


(. ."I to interact with
SAF forwarders

(With CCD) serve as call


agents

SAF is a network-based, scalable, bandwidth-efficient, real-time approach to service


advertisement and discovery.
SAF can be used to advertise and learn any service to and from the SAF-enabled network. CCD
is the first Cisco application that utilizes SAF. As mentioned earlier, the devices within the SAF
network are SAF forwarders. They have the responsibility to propagate services within the
network. SAF forwarders do not interpret the service information itself; they only guarantee
fast and reliable exchange of the information. SAF forwarders use the SAF Forwarding
Protocol (SAF-FP) between each other.

SAF forwarders can interact with SAF clients. A SAF client is an entity thatprocesses SAF
service data.A SAF client can independently advertise (generate) SAF service information to
be propagated in the network, or subscribe to (receive) SAF service information. A SAF client
communicates with oneor more SAF forwarders by the SAF Client Protocol (SAF-CP). With
CCD. the SAF client is a call agent such as Cisco Unified BorderElement, Cisco Unified
SRST. Cisco Unified Communications Manager, Cisco Unified Communications Manager
Express, and Cisco IOS gateways.

5-8 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) vfl.O ) 2010 Cisco Systems, Inc.
Call Control Discovery Overview
This subtopic provides an overview of CCD.

CCD Overview

CCD-enabled call agents


advertise to and leam from
"the network"
SAF is used to distribute
information within the network.
SAF forwarders interact with
CCD-enabled call agents
(SAF clients)
- SAF forwarder learns
information from SAF client
•- SAF forwarders exchange
information with each other.
SAF forwarder advertises
all learned information to
SAF client. CallAgent Catl/

With CCD.each CCD-enabled call agent advertises locally found directory numbers or
director.' number ranges and their corresponding PS'FN numbers or prefixes to theSAF-
enabled network. In addition, each CCD-enabled call agent learnscall-routing infonnation from
the network.
SAF isused to propagate infomiation within the SAF-enabled network. SAF forwarders
interact with CCD-enabled call agents (thatis. SAF clients). A SAF forwarder learns
infonnation from a SAF client. SAF forwarders exchange learned call-routing information with
each otherso that the SAF-enabled network is aware of all learned call routes. SAF forwarders
do not onh leam from SAF clients, but they alsoadvertise all learned information lo SAF
clients, fhat way. all SAF clients are aware of all available call-routing information—internal
director, numbers and their corresponding PSTN numbers.

Call Control Discovery


©2010 Cisco Systems. Inc
Scalable Dial Plan Solution for Large Networks
This subtopic describes a scalable dial plansolution for large networks.

Scalable Dial Plan Solution for Large Networks

Solutions for dynamic exchange of routing information exist.


- Dynamic IP routing protocols.
• Routers have local networks attached.
• Routers advertise local networks to other routers.
• All routers leam all available networks and how lo gel there.
Same concept can be used for call-routing information.
- Call-routing domains advertise telephone numbers or number ranges.
• Internal numbers and IP address for VoIP
• External numbers for PSTN backup
Call Control Discovery has been introduced with Cisco Unified Communications
Manager Version 8.
- Call agents can advertise and leam call-routing information using
• Cisco Unified Communications Manager
• Cisco Unified Communications Manager Express
• Cisco Unified SRST
• Cisco Unrfied Border Element
• Cisco IOS gateway

The problem of dynamically distributing reachability information is known also in areas other
than call routing. In IP networks, for example, routing has changed from simple static routing
to large, fully dynamic clouds, such as the Internet.
The solution for scalable IP routing is provided by dynamic routing protocols. IP routers have
local networks that are attached. They advertise these locally known networks to other routers
so that all routers can leam about all available networks and the path to get to those networks.
The same concept can be used to distribute call-routing infonnation. Each call-routing domain
advertises locally known telephone numbers or number ranges. Because local numbers are
typically used by internal patterns (using VoIP) as well as via the PSTN, each call-routing
domain advertises both the internally used numbers and the corresponding external PSTN
numbers.

Cisco CCD. a new feature that was introduced with Cisco Unified Communications Manager
Version 8. provides exactly such a service. It allows Cisco Unified Border Element. Cisco
Unified SRST. Cisco Unified Communications Manager, Cisco Unified Communications
Manager Express, and Cisco IOS gateways to advertise and leam call-routing information in
the form of internal directory numbers and PSTN numbers or prefixes.

5-6 Implementing Cisco Unrfied Communications Manager, Part 2 (CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Dial Plan Scalability Issues in Large Networks
The main scalability issues in targe networks are caused by the fact that call-routing
infonnation has to be configured separately at each call-routing domain.

Dial Plan Scalability Issues m Large Networks

• Call-routing information between separate call-routing domains


has to be manually configured:
Full-mesh configuration
• Extremely complex, suitable only for small networks
Hub-and-spoke configuration when centralized call-routing
entities (SIP network services or H.323 gatekeepers) are used
• Scales better than full-mesh topologies
• Requires redundant deployment of central services
• Changes have to be manually configured.
• PSTN backup has to be implemented independently at each call-
routing domain.
• No dynamic exchange of call-routing information and no
automatic PSTN backup.

Without centralized services (such as H.323 gatekeepers or SIP network services), a full-mesh
configuration is required. In other words, each call control domain has to be configured with
call-routing information toward all other call-routing domains. This implementation model does
not scale at all and therefore is suitable only for smaller deployments.
In a hub-and-spoke deplovment model, call-routing information for each call-routing domain is
eonligured onk once at the centralized call-routing entity. This eentrali/ed call-routing entity
can be a SIP network service or an H.323 gatekeeper. Such a solution scales better than full-
mesh topologies: however, it introduces a single point of failure and therefore requires
redundant deployment of the centralized service. In addition, the centralized call routing still
has to be manually configured. For example, if telephone number ranges or prefixes are
changed at one of the call-routing domains, these changes also have to be manually performed
at the centralized call-routing service. Further, PSTN backup has to be implemented
independently at each call-routing domain.
In summary, there is no dynamic exchange of call-routing infomiation between call-routing
domains, and there is no automatic PSTN backup.

mm
i 2013 Cisco Systems, Inc. Call Control Discovery
SAF and CCD Overview
This topic prov ides an overviewabout SAFand CCD.

Dial Plans in Large Networks

Dial plans in large networks are difficult to implement and maintain.


Centralized call-routing intelligence improves scalability but still
does not scale well in very large networks.

Cal Asent Call tgtrl Call AOent_sia_Call Agent

Call Agent
Call Agem

Call Agent Call Agent


Call Agent Call Agent CaHAgent Call Agent

In large networks with several call agents—such as Cisco Unified Communications Manager
Express. Cisco Unified Communications Manager, Cisco Unified Border Element, Cisco
Unified SRST. and Cisco IOS gateways—the implementation and maintenance of dial plans
can be very complex.
The use of 11.323 gatekeepers or Session Initiation Protocol (SIP) network services reduces the
complexity. However, dial plan implementation still does not scale well in very large
deployments.

5^ Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 J2010 Cisco Systems, Inc.
Lesson 1

Implementing SAF and CCD


Overview
With the increasing deployment of Cisco Unified Communications solutions, dial planshave
become more complex to implement, especially in largeenterprises that consistof numerous
call control devices. Some examples of these call control devices arc Cisco Unified Border
Element. Cisco Unified Survivable Remote Site Telephony (SRST), Cisco Unified
Communications Manager. Cisco Unitied Communications Manager Express, and Cisco IOS
gateways.

To simplifv dial plan implementation in large deployments, it is desirable thatcall control


devices dynamically exchange call-routing infonnation so that no any-to-any static
configuration is required. Cisco Service Advertisement Framework (SAF) allows services to be
propagated through SAF-enabled network devices. Cisco Call Control Discovery (CCD) is the
first application that utilizes SAF to advertise services: the reachability of internal director.'
numbers and publicswitched telephone network (PS'fN) backupnumbers.
This lesson explains how SAF works, describes its components, andshows how to configure it.
The lesson also describes how CCD utilizes SAF to dynamically exchange call-routing
infonnation and how you can implement CCD in Cisco Unified Communications Managerand
in Cisco IOS Software.

Objectives
Upon completing ihis lesson, you will beable to describe and implement SAF clients and
forwarders in an environment with CCD. This ability includes being able to meet these
objectives:
Describe what SAF is. what CCD is. and how CCD utilizes SAF

Describe the characteristics of SAF

Describe the characteristics of CCD

Describe how CCD works

Describe how to implement SAF and CCD


Describe special considerations for using SAF and CCD
Implementing Cisco Unified Communications Manager, Part 2 (C1PT2) v8.0 © 2010 Cisco Systems, Inc
Module 5

Call Control Discovery


Overview
In large deployments with many call agents, dial plan implementation can be very'complex.
Cisco Service Advertisement Framework (SAF) and Call Control Discovery (CCD) allow call
agents to propagate call-routing infonnation to the network and to learn routes from the
network. Thus. SAF and CCD facilitate the deployment of very large Cisco Unified
Communications solutions by greatly simplifying dial plan implementation.
This module explains how SAF and CCD work and how you can implement SAF and CCD to
allow the duiamic discover) of call-routing information.

Module Objectives
Upon completing this module, you will be able lo describe and implement CCD deployments.
I his ability includes being able to meet this objective:
• Describe and implement the SAF client and forwarder in an environment with CCD
Module Self-Check Answer Key
QU B

Q2) C. D.G

03) A.C

Q4) C

Q5) B

06) B

Q7) A

Q8) CD

09) A. D. E

Q10) A, D

Oil) A, B

4-74 Implementing Cisco Unitied Communications Manager. Part 2 (CIPT2) v8.0 © 20t0 Cisco Systems, Inc.
Oil) Which two statements describe the result when theuser logs into a device but is still
logged in to another device? (Choose two.) (Source: Implementing Cisco Extension
Mobility)
A) If the multiple login behaviorserviceparameter is set to disallowed, the login
fails.
B) If the multiple login behaviorservice parameter is set lo auto-logout, the user is
automatically logged out of the other device.
C) If the multiple login behaviorenterprise parameter is set to allowed, the login
succeeds and the user also remains logged in at the other device.
D) If the multiple login behaviorenterprise parameter is set lo prompt, the user is
given the option to log out of the other device first.
E) fhe login fails.

2010 C sco Systems, inc. Implementation of Features and Applications for Multisite Deployments
Q6) If no physical location is configured at the device pool, the physical location that is
configured at the phone is used. (Source: Implementing Device Mobility)
A) true
B) false

Q7) Which of the following is not a problem when users roam between sites? (Source:
Implementing Cisco Extension Mobility)
A) The phones that they use have the wrong location and region settings.
B) Users get the wrong extensions on their phones.
C) Users get the wrong calling privileges.
D) Users do not have speed dials available.
Q8) Which two settings cannot be updated when Cisco Extension Mobility is used?
(Choose two.) (Source: Implementing Cisco Extension Mobility)
A) phone button template
B) softkey template
C) device CSS
D) network locale
E) phone service subscriptions
F) phone lines and speed dials

Q9) Which three configuration elements are not relevant for Cisco Extension Mobility
configuration? (Choose three.) (Source: Implementing Cisco Extension Mobility)
A) location
B) phone
C) end user
D) device security profile
F) device pool
F) device profile
Ci) phone service
010) Which two of the following are recommended approaches to implementation of calling
privileges when Fxtension Mobility is used? (Choose two.) (Source: Implementing
Cisco Extension Mobility)
A) Configure the line or lines of the device profile of the user with a CSS that
includes blocked route patterns for the destinations that the user should not be
allowed to dial.
B) Do not configure a device CSS.
C) Do not configure a line CSS.
D) Configure the device with a CSS that includes all PSTN route patterns pointing
to die local gateway.
E) Configure the line or lines of the physical phone with a CSS that includes
blocked route patterns for the destinations that the user should not be allowed
to diai.

4-72 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 © 2010 Cisco Systems, Inc.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.

Qi) Which setting is not modified when a user is roaming between sites with a device1!
(Source: Implementing Device Mobility)
A) region
B) directorv number
O location
D) SRST reference

021 Which three of the following are device mobility-related settings in Device Mobility?
(Choose three.) (Source: Implementing Device Mobility)
A) Region
B) SRST Reference
C) AAR Calling Search Space
D) Device Mobility Calling Search Space
F.) Media Resource Group List
F) Location
Ci) AAR Group

03) Which two statements are correct about (he relationship between Device Mobility
configuration elements? (Choose two.) (Source: Implementing Device Mobility'.
A) Device Mobility Infos refer to one or more device pools.
B) Device pools refer to one or more physical locations.
C) Device pools can refer to one device mobility group,
D) Device pools can refer to one Device Mobility Info.
E| Physical locations refer to device mobility groups.

Q4) Which statement is not correct about Device Mobility operation? (Source:
Implementing Device Mobility)
A) A dev ice pool is selected basedon the IP address of the device.
B) If the selected device pool is the home device pool, no changes are made.
C) If the selected device pool is in a different device mobility group than the home
dev ice pool, the device-mobility-related settings of the roaming device poolare
applied.
D) If the selected device pool is in a different physical location than the home
dev ice pool, the roaming-sensitive settingsof the roaming device pool are
applied.

05) Which statement is not correct about the interaction of Device Mobility and globalized
call routing? (Source: Implementing Device Mobility)
A) The user of a roaming phone can use the home dial rules.
B) Fhe user of a roamingphone can use the homedial rules, but then the home
gateway is used all of the time.
C) The user of a roaming phone can use the roaming gateway.
D) The same device mobility group can be used at all devicepools.

©20'0 ico Systems. Inc Implementation of Features and Applications for MultisiteDeployments
4-70 Implementing Cisco Unified Communicalions Manager, Part 2 (CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Mo lule Summary
This lopic summarizes the kev points that were discussed in this module.

Module Summary

• Device Mobility allows users to roam between sites with their


phones.
• Cisco Extension Mobility allows users to log in to any phone
in a Cisco Unified Communications Manager cluster and
have a personal profile applied to the phone.

fhismodulebegins with a description of Device Mobility. Itdescribed how Device Mobility


can be implemented in environments with and without globalized call routing, fhen the -nodule
described the operation and implementation ofCisco Extension Mobility that allows Cisco
! Unified Communications Manager users to log into an IP phone and have their personal profile
j applied, regardless ofthe device and physical location that they are using.

Rel frences
For additional infonnation. refer to these resources:

• Cisco Systems. Inc. Cisco Unified Communications System 8.x SRND, April 2010.
hup: www.cisco.conVen/I IS/docvYoiee ip comm/cucm/srnd/Kx/iicSx.htmi
• Cisco Systems. Inc. Cisco Unified Communications Manager Administration Guide
Release 8.0(1). February 2010.
!itlp:.:\\\\w.ei^co.conv'cn/US''docs;voiceJp_comm/cucm/admin/K_0 I.ecmcfg'bccn-SOl-
em.html

• Cisco Systems. Inc. Cisco Unified Communications Manager Features and Services Guide.
Release'8.0{i). March 2010.
imp: www.cisL'o.coin't'iiT^.'docs/voice ip comm/eucm/admin/8 0 l/ccmfeat/fsg^-801-
cm.html

;isco Systems. Inc Implementing Features and Applications for Multisite Deployments 4-69
Summary
This topic summarizes the key points that were discussed in this lesson.

Summary

The Device Mobility and Cisco Extension Mobility features of


Cisco Unified Communications Manager allow users to roam
between sites,

Cisco Extension Mobility enables users to log into IP phones


and apply their profiles, including extension number, speed
dials, services, MWIstatus, and calling privileges.
The device profile of the user is used to generate the phone
configuration in the login state.
Seven steps are needed to configure Cisco Extension
Mobility.

References
For additional information, refer to these resources:

• Cisco Systems. Inc. Cisco Unified Communications Svstem Release 8.x SRND. San Jose,
California. April 2010.
http:/.'www. cisco.com/en/lJ S/docs/voiee_ip_comm/eucm/srnd/8x/ue8.\srnd.pdf.
• Cisco Systems. Inc. Cisco Unified Communications Manager Administration Guide
Release 8.0(2). San Jose, California, March 2010.
http:.'/v\ww.cisco.com''en/US/docs/voice ip comni/cuem/admin/8 0 2/ccmcfg/bccm.pdf.
• Cisco Systems. Inc Cisco Unified Communications Manager Features andServices Guide
Release 8.0(2). San Jose, California, March 2010.
http://vvw\\xisc().com/en/US/docs/voice__ip_comm/cucni/admin/8J)_2/cciiifeal/fsgd.pdf'.

4-68 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc
Step 7b: Subscribe Phone to Cisco Extension Mobility Phone
Senvice
The last step of Cisco Extension Mobility configuration is to subscribe the IP phoneto the
Cisco Extension Mobilitv phone service.

Step 7b: Subscribe Phone to Cisc<


Extension Mobility Phone Service

In the Phone Configuration window, choose


Subscribe/Unsubscribe Services from Related Links to open
the Subscribed Cisco IP Phone Services window.
Subscribed Qgn IP Phone Services tor SeptMH4C**551S6 2 Enter the service
rScnrtte lnfonnaMon name as rt should
appear at the phone.

1 Logon 1 LcbjI'
FM Lngfm ' Loaon'
FM logon / '-v^fflt

-Sulrairlbed Scrvic
1 Choose the Cisco
Exlension Mobility
-| rvcxl I Close
phone service by
using the name
assigned in Step 3 3. Click Subscribe.
Then, click Next Then, click Save

The process ofsubscribing the IP phone tothe Cisco Extension Mobility service isthe same as
the process that was explained in Step 5. in which the device profile was subscribed tothe
Cisco Extension Mobility service. Inthe Phone Configuration window, use the related link
Subscribe/Unsubscribe Services to open the Subscribed Cisco IP Phone Services window and
subscribe to the sen ice.

) 2010 Cisco Systems, Inc Implementation ofFeatures and Applications for Multisite Deployments 4-67
Step 7a: Configure Phones for Cisco Extension Mobility
Finally, the phone must be enabled for Cisco Extension Mobility and subscribed to the Cisco
Extension Mobility phone service. The figure shows the first part—enabling Cisco Extension
Mobilitv on a phone.

Step 7a: Configure Phones for Cisco


Extension Mobility

Cisco Unified Communication ManagerAdministration: Device >

kJ Oct* rt I.

Enable or disable Cisco


Extension Mobility;
choose specific device
profile or use current
device settings for logout
state.

In the PhoneConfiguration window(which you can access from Cisco Unified


Communications Manager Administration by choosing Device > Phone), check the Enable
Extension Mobility check box to enable Cisco Extension Mobility. Then choose a specific
device profile or the currently configured device settings to use during the logout state. The
recommendation is to use the currentdevice settings.

B*.

4-66 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) v8.0 >2010 Cisco Systems, Inc.
Step 6: Associate Users with Device Profiles
This step describes how to associate users withdevice profiles.

Step 6: Associate Users with Device


Profiles

Cisco Unified Communications Manager


Administration: User Management > End User

1 1
Usei ID and PINaie
l™" —1
] used for Cisco
~< ===== J Extension Mobility login
1

-fr.--.o-* «j-t*f
Associate user
-

/ device profiles,
optionally, set
VA default profile
(if moielhan
one controlled
A

profile exists)

Inthe End User Configuration window (which you can access from Cisco linified
Communications Manager Administration by choosing User Management > End User), choose
the device profile orprofiles that you want to associate with the user in the list of Available
Profiles. Click the down arrow to add them lo the list of Controlled Profiles.

©2010 Cisco Systems. Inc


Implementation ofFeatures and Applications for Multisite Deployments 4-6S
Step 5b: Subscribe Device Profile to Cisco Extension Mobility
Phone Service
The next step is to subscribe the configured device profileto the Cisco Extension Mobility
phone service.

Step 5b: Subscribe Device Profile to


Cisco Extension Mobility Phone Service

In the Device Profile Configuration window, choose


Subscribe/Unsubscribe Services from Related Links to open the
Subscribed Cisco IP Phone Services window.

ESmmmmmm^LmmmW 2. EnlerBie service


name as it should
appear at the phone.
Sew* a £erv-c*' EH Lo^on ; Lagotf
5ei-Lic« Des^ripfic Not Selected -
Sen.-*
0* mo5e<v«

otion: EM Logon / Logoff

EM Logon .' Logoff

1. Choose the Cisco EM Logon / Logoff

Extension Mobility
- Subscribed Services
phone service by
using the name
assigned in Step 3. 3. Click Subscribe.
Then, cick Next. Then, click Save,

In the Device Profile Configuration window, choose Subscribe/Unsubscribe Services from


the Related Links field and click Go. Then choose the phone service that you added in Step 3.
Click Next, and enter the name with which the phone service should be displayed in the list of
phone services on the IP phone after the Services button is pressed. Click Subscribe, and then
click Save. The device profile is now subscribed to the Cisco Extension Mobility service.

Caution If the device profile is not subscribed to the Cisco Extension Mobility service, users do not
have access to Cisco Extension Mobility phone service after they log in and their device
profile has been applied. As a result, users can no longer log out of Cisco Extension Mobility
at the phone. Therefore, make sure that you do not forget to subscribe the phones (see Step
7b)—and the device profiles—that you use for Cisco Extension Mobility to the Cisco
Extension Mobility phone service.

Since Cisco Unified Communications Manager version 7, an enterprise subscription can be


enabled at each phone service. If an enterprise subscription is enabled, the corresponding
phone service applies to all phones and device profiles.

mm

4-64 ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)vfl.O >2010 Cisco Systems, Inc.
Step 5a: Create Device Profiles
The next step is the configuration of device profiles.

Step 5a: Create Device Profiles

Cisco Unified Communications Manager Administration: Device


> Device Settings > Device Profile

5 modeiand
protoccrf.

PKor n.*-™ TrPijtn.E*


IK^
Enter device
Setter Tcmcla-rB
profile name and
description.

Configure phone [g-.=rr Configure user-


lines and buttons. 1 (Default) Profile l«lfOrM*lkirl-
specific phone
parameters.

To configure device profiles, in Cisco Unified Communications ManagerAdministration,


choose Device > Device Settings > Device Profile. After choosing the phone model and
protocol, vou can configure user-specific deviceconfiguration parameters. Afteryou configure
the phone button template, you can configure the appropriate buttons.

© 2010 Cisco Systems. Inc Implementation of Features and Applications for Multisite Deployments 4-63
Step 4: Create Default Device Profiles
If multiple phone models are used for Cisco Extension Mobility, default device profiles should
be enabled.

Step 4: Create Default Device Profiles

Cisco Unified Communications Manager Administration: Device


> Device Settings > Default Device Profile
1 Select phone
J modeland
™"

Set default phone


configuration for
the selected phone
type.

To configure a default device profile, in Cisco Unified Communications Manager


Administration, choose Device > Device Settings > Default Device Profile. Choose the
product type (phone model) and device protocol first. You can then configure the default device
profile for the chosen phone model and protocol.

Note The available configurationoptions depend on the chosen phone model and protocol. The
default device profiledoes not include phone button configuration (for example, lines or
features buttons) but does include the phone button template.
«M

4-62 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 52010 Cisco Systems, Inc.
Step 3: Add the Cisco Extension Mobility Phone Service
fhe next step is to add the Cisco I'xlension Mobility phone service.

Step 3: Add the Cisco Extension


Mobility Phone Service

Cisco Unified Communications Manager


Administration: Device > Device Settings > Phone
Services
IP Ptwne Servke*, Configuration

Enter service name and


S»rvi£P Name' EH Logon ,' LogcC
service description;
A5CTI Service f*a'n EH Logon ,J LOQOt*
enter Cisco Extension
S=rv>cc Descfipt.oi

<l
Extension Mcbilil. ..ckju Uicif 5trv.c
Mobility service URL.
Semce UHL htrp ''101 i.i.eoeoien OPC'EWAnpSt vlet'devic c-tDI

^?rMrj Catega

Enable the Cisco


Extension Mobility IP
phone service.

Setvice URL
htlp /:Server_IP_Aa<t-ess S0SO'emBpp/EMAppServlePdevice=#OEVICENAMEB

Cisco fxtension Mobility is implemented as a phone service, fherefore,you must add this
service to the available phoneservices in Cisco Unified Communications Manager. To add the
Cisco Extension Mobility phone service, in Cisco Unified Communications Manager
Administration, choose Device> DeviceSettings > Phone Services. Configure the Cisco
Fxtension Mobility service with a service name anddescription, andthenenterthe service
URI.:http:'.V/'rt'r IP ,-W(//-csj:8080.'cinapn/l:MAppScrv!cl?dc\icc=rfI)l'.VICFNAMI;.S.

Note The service URL is case-sensitive and can be found in the Cisco Unified Communications
Manager Help pages.

© 2010 Cisco Systems, Inc Implementation ofFeatures andApplications for Multisite Deployments 4-61
Step 2: Set Cisco Extension Mobility Service Parameters
The Cisco Extension Mobility service has several configurable service parameters.

Step 2: Set Cisco Extension


Service Parameters

Cisco Unified Communications Manager


Administration: System > Service Parameters

Cisco Fxtension Mobility can be configured with the following service parameters.
If the Enforce Intra-cluster Maximum Login Time parameter is set to True, the user is
automatically logged out after the Intra-cluster Maximum Login Time expires. The Intra-cluster
Multiple Login Behavior parameter specifies how to process users who log into a device but are
still logged in at another device. There are three options: Login can be denied, login can be
allowed, or the user can be logged out automatically from a phone on which the user logged in
earlier and did not log out.
Alphanumeric User ID can be enabled or disabled, and the last logged in username can be
remembered (and presented as a default on the next login) by setting the Remember the Last
User Logged In parameter to True. Call lists can be preserved or cleared at logout, depending
on the setting of the Clear Call Logs on Intra-Cluster EM service parameter.

Note All of these parameters are clusterwide service parameters of the Cisco Extension Mobility
service and can be accessed from Cisco Unified Communications Manager Administration mm

by choosing System > Service Parameters.


mm.

4-60 Implemenling Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 >2010 Cisco Systems, Inc.
Step 1: Activate the Cisco Extension Mobility Service
fhe first step is to activate the Cisco Extension Mobility feature service.

Step 1: Activate the Cisco Extensh


Mobility Service

Cisco Unified Communications Manager


Serviceability: Tools > Service Activation
I Control Center - feature Services -
m
Select Serve*

Se • do

C'CCl 10 Snr,ltC5

CMSenhw
: Tiimn Umii MK<HBMil**W
Cisco CalWanswer Ace rated
ActivateCisco Extension
CISCO Tttp Activated
Mobility service.
Cisco Messaging IrtprTicp Oe actuated
CKfo unrfifd Mobile Vane fides? Ser.-c Attested
Cisco ]P Vo<e. Media Streamy Aoo Ac! vsted

LZ Cisco Entensran MeMitY *««t™ (^


Cisco Eflenri^d Finlftiorrf 'dilated
Cisco Dialed PfljmDei Analyser Deadly ate d
Cisco CHCP Menrto- Swv.™ I>e actuated

lo enable Cisco Extension Mobility, you must activate the Cisco Extension Mobility feature
service from Cisco Unified Serviceability. To do so, click Tools > Service Activation.

Note Starting with Cisco Unified Communications Manager Version 6.0, Cisco Extension Mobility
is considered a User Facing Feature and can be activated on any server in a Cisco Unified
Communications Manager cluster, to provide a redundant Cisco Extension Mobility
environment

*>

© 2010 Cisco Systems. Inc. Implementation of Features and Applications for Multisite Deployments 4-59
Cisco Extension Mobility Configuration
This topic describes how to configure Cisco Extension Mobility.

Cisco Extension Mobility Configuration


Steps

1 Activate the Cisco Extension Mobility service.


2 Set Cisco Extension Mobility service parameters.
3 Add the Cisco Extension Mobility phone service.
A Create default device profiles for all phone models used
(optional).
5. Create device profiles and subscribe them to the Cisco
Extension Mobility phone service.
6 Create end users and associate them with device profiles.
7. Enable Cisco Extension Mobilityfor phones and subscribe
phones to the Cisco Extension Mobilityservice.

The figure lists the steps that are required to configure Cisco Extension Mobility in Cisco
Unified Communications Manager. The following topics explain these steps in detail.

4-5S Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 12010 Cisco Systems, Inc.
Alternatives for Mismatching Phone Models and CSS
Implementations
To avoid issues with mismatching IP phone models or with calling privileges when the
traditional approach for implementing partitions andCSSs is used, multiple device profiles can
be configured per user.

Alternatives for Mismatching Phone


Models and CSS Implementations

Alternative to using the default device profile and the (applicable)


settings of the user device profile.
Create multiple device profiles for the user (one per phone
model family).
Alternative ts applicable only ifusers use Cisco Extension
Mobility across phone model families that do not support feature
safe

Alternative to line/device CSS approach in multisite environments.


Create multiple device prof les for the user (one per physical
location), giving each profile the appropriate CSS to enforce CoS
and to choose the conect gateway.
Neither alternative scales well.

Using Local Route Groups is recommended ifthe traditional CSS


approach (CSS applied at the line) is followed.

When different phone model series are used, issues can arise when the settings of the default
device protlle are applied. DilTerenl users might require different settings. This problem can be
solved by creating multiple device profiles peruser. When you configure and associate one
device profile (per phone model) with a username, Cisco Unified Communications Manager
displavs this list ofprofiles after successful login. The user can choose a device profile that
matches the phone model ofthe login device. Ilowever. ifmany users need touse Cisco
E\tension Mobility and many different phone models arcused, this solution does notscale
well.

The same concept can be used as an alternative tothe line/device approach for implementing
CSSs. Aseparate device profile can be created per site and is configured with the appropriate
CSS to allow local gatewa> s to be used for external calls. Again, the user chooses the
corresponding device profile after logging in. and the correct CoS and gateway choice are
applied without depending on a separate line and device CSS. The recommendation, however,
isto use the line/device approach in a multisite environment, because that approach simplifies
the dial plan and scales belter.

Note When using thetraditional CSS approach with only oneCSS applied at theline, use Local
Route Groups to prevent gateway-selectionproblems.

© 2010 Cisco Systems. Inc


implementation ofFeatures and Applications for Multisite Deployments 4-57
Cisco Extension Mobility and CSSs
This subtopicdescribes how Cisco F.xiension Mobility interacts with CSSs.

Cisco Extension Mobility and CSSs

• Cisco Extension Mobility does not modify the device CSS.


• Cisco Extension Mobility modifies the line CSS:
- When using the line/device CSS approach (recommended for CoS
implementation).
• Line CSS of user device profile is applied; CoS settings of the user
are enforced

• Device CSS is not modified; local gateway selection is allowed,


depending on used device (at any location).
• When using the traditional CSS approach (only one CSS at phone), the
same CSS is used all the time, causing problems in multisite
environments with different classes of sen/ice for users.

- For proper gateway selection, use Local Route Groups if the CSS is
applied at the phone line.
• AAR CSS is configurable only at the device and is never updated by Cisco
Extension Mobility, so local gateway can be used for AAR calls.

Cisco Extension Mobility does not modify the device CSS or the automated alternate routing
(AAR) CSS (both of which are configured at the device level). Cisco Extension Mobility does
replace the line CSS or CSSs that are configured at the phone with the line CSS or CSSs that
are configured at the device profile of the logged-in user.
Thus, in an implementation that uses the line/device approach, the following applies:
• The line CSS of the login device is updated with the line CSS of the user. This update is
used to enforce the same class of service (CoS) settings for the user, independent of the
physical device to which the user is logged in.
• The device CSS of the login device is not updated, and the same gateways (those gateways
that were initially configured at the phone before the user logged in) are used for external
route patterns. Because the phone did not physically move, the same local gateways should
be used for PSTN calls, even when a different user is currently logged into the device.

If the traditional approach is used to implement partitions and CSS, the following applies:
• If only device CSSs are used, the CSS is not updated, and no user-specific privileges can be
applied. The user inherits the privileges that are configured at the device that is used for
logging in.
• If only line CSSs are used, the line CSS that is configured at the device profile of the user
replaces the line CSS of the login device. In a multisiteenvironment, this configuration can
cause problems in terms of gateway choice because the same gateway is always used for
external calls. To avoid gateway selection problems in such an environment, you should
use Local Route Groups.

4-56 ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)v8.0 © 20t0 Cisco Systems, Inc.
2. The phone button template and the softkey template of the default device profile are
applied to the Cisco Unified IP Phone 7905.

3. The user has access to the phone services that are configured in the Cisco Unified IP Phone
7905 default de\ ice profile.

mm

) 2010 Cisco Systems, Inc Implementation ofFeaturesand Applications forMullisite Deployments 4-55
How Cisco Extension Mobility Handles Phone Model
Differences
This subtopic describes the phone configuration process when Cisco Extension Mobility isused
with different phone models.

How Cisco Extension Mobility Handles


Phone Model Differences

When a phone model mismatch is identified, Cisco


Extension Mobility works as follows:
• Device profile:
- Copy all dev ice-independent parameters from the device profile
of the u ser

• Default device profile:


- Apply devtce-dependentparameters, such as phone button and
softkey template, from the default device profile.
• Device profile
- Copy device-dependent parameters that can be applied (such as
phone lines and feature buttons, ifsupported by the applied
phone button template).
- Apply phone service subscriptions from the device profile of the
user (if phone services are supported at the phone that is used).

After successful authentication, if the phone model series of the device protlle does not match
the phone model series of the used phone, the following happens:
1. Device-dependent parameters, such as phone button template and softkey template, from
the default device profile are applied lo the phone.

2. Then the system copies all device-independent configuration settings (user hold audio
source, user locale, speed dials, and line configuration, except for the parameters that are
specified under I inc Setting for This Device) from the device profile to the login device.
3. Next, the applicable device-dependent parameters of the device profile of the user are
applied. These parameters include buttons(such as line and feature buttons) that are based
on the phone button template that has been applied from the default device profile.
4. Finally, if supported on the login device, phone service subscriptions from the device
profile of the user are applied to the phone.

5. If the device profile of the user does not have phone services that arc configured, the
system uses the phone services that are configured in the default device profile of the login
device.

For example, the following events occur when a user who has a device profile for a Cisco
Unified IP Phone 7960 logs into a Cisco Unified IP Phone 7905:
I. The personal user hold audio source, user locale, speed dials (if supported by the phone
button template that is configured in the Cisco Unified IP Phone 7905 default device
profile), and directory number configuration of the user are applied to the Cisco Unified IP
Phone 7905.

4-54 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) vB.O >2010 Cisco Systems, Inc.
Default Device Profile and Feature Safe
This subtopic describes the feature safe functionality of Cisco Extension Mobility.

Default Device Profile and Feature Safe

The default deviceprofile is applied only if


the phone model series is different
(feature safe) Cisco Unified IP
Phone 7945
Phones can use any phone button
template that has the number of line
buttons that the phone model supports
Log In
Series 794x models are equivalent
and can share a Cisco Extension
Mobiity profile.
Series 796x models are equivalent
Phone model
and can share a Cisco Extension
User Device is similar
Mobiity profile.
Prose tor User dewce
Series 797x models are equivalent CISCO profile is
and can share a Cisco Extension Unified fP used
Mobiity profile Prone 7940
No administration tasks are required to
activate a Cisco Extension Mobility feature
safe
Cisco Extension Mobility feature safe is
protocol independent.

Ihe default deuce profile is applied only ifa users device profile and the phone on which the
user tries to log in are of a different phone model scries (for example, Cisco Unified IP Phone
Scries 794x. 796x. or 797x).

When the phone model scries of the physical phone and the user device profile are the same,
the feature safe function allows different phone models lo be used for user device profiles and
physical phone models.
for example, a user with an associated device profile for a Cisco Unified IP Phone 7940 phone
can log into a Cisco Unified IP Phone 7945 phone without having the default device profile
applied.
No administrative tasks are required to enable feature safe. Feature safe is independent of the
used signaling protocol (SIP or SCCP).

© 2010 Cisco Systems. Inc Implementation of Features and Applications for Multisite Deployments
Issues in Environments with Different Phone Models
This subtopic describes issues with mixed IP phone environments.

Issues in Environments with Different


Phone Models

Device profile configu ration ineludes phone


mobel inform at on.
Cisco unified IP
Different conigu ration parameters are available,
depending on the phone model lhal is selected Phone 7945

What ifa user logs into a different phone model


than Ihe model tiat s conlgured in the device
profile of the user' Log In
Default device profiles can be configured
- Default device profiles contain default
phone-con figuration parameters for the Phone model
large! phone:
series is different
• Phone button template User Dovfcs Default device
• Softkey template PmBftfor profile for Cisco
Cisco Unified IP Phone
• 0etaiilt values for parameters that might
Unified IP 7945 is used.
not be available at the device profile of
Phone 7965
the user (if fhe phone model specified
there supports fewer features)
• Ooes not include lines or feature buttons

When different IP phone models are used in a Cisco Unified Communications Manager cluster
for which Cisco Extension Mobility is enabled, an end user may log into an IP phone that is of
a different model series than the one that is configured in the device profile of the user.
Different phones support different features. Therefore, when a user logs into a phone that
supports more features than are supported by the model that is associated with the user, the
default device profile is used to apply the parameters that the target phone supports but that are
not included in the device profile of the user. The default device profile includes phone
configuration parameters such as phone button templates, softkey templates, phone services,
and other phone configuration settings. However, the profile does not include button
configuration (including line buttons).

4-52 ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)v8.0 >2010 Cisco Systems, Inc.
5. The IP phone is reset and loads the updated configuration.

Now. the phone can be used as it would be used in the home location. Directory' numbers,
speed dials. MWI. and so on. are all correct, regardless of the location and the IP phone that is
used.

Users can log out of Cisco Extension Mobility by pressing the Services button and choosing
Logout in the Cisco Extension Mobility service. If users do not logout themselves, the system
automatically logs them out after the expiration of the maximum login lime (if the appropriate
sen ice parameter has been configured accordingly).
The user is also automatically logged out of a phone when the user logs into another phone and
when Cisco Unified Communications Manager is configured for auto-logout on multiple
logins. Another option is that the next user of the phone logs out a previous user so that the new
user can log in and have the phone that is updated with the settings of that new user. After
logout. Cisco Unified Communications Manager reconfigures the phone either with the
standard configuration of the IP phone or by using another device profile (as specified in the
Phone Configuration window).

© 2010 Cisco Systems. Inc. Implementation ofFeatures andApplications for Multisite Deployments 4-51
Cisco Extension Mot ility Operation
This topic describes how Cisco I xtension Mobility works, how phone model mismatches are
processed, and how calling scare l spaces (CSSs) and partitions areupdated when Cisco
Extension Mobilitv is used.

Cisco Extension Mobility Login Process

User presses the Sen ices button


on an IP phone and selects the
Cisco Extension Mobi ity service.
The user is authenticated by user
ID and PIN

After successful authentication,


Cisco Extension Mobility selects the
deviceprofile associated with the
user (prompts user to choose, if
multiple associations e'xist).
The IP phone configurjation is
updated with the configuration
parameters from the device profile.
The phone is reset and loads the Cisco Unified
updated configuration. Communications
Manager Database

When a userwants to log into a phone, the following sequence of events occurs:
1. The userpresses the Services button on the phone andchooses the CiscoExtension
Mobility service from the list of phone services that are available onthe phone.
2. The Cisco Extension Mobility service requires the user to log inby using a user ID and
PIN. The user enters the required data.

3. Ifthe entered user ID and PIN are correct, Cisco Extension Mobility chooses the device
profile that is associated with the user.
m
Note If a user isassociated with more than onedevice profile, all associated profiles are
displayed andthe user must choose thedesired profile. Assigning multiple profiles toa user m
meansthatthe useris provided a separate device profile per site. This approach is common
when thetraditional approach is used toimplement CSSs. Cisco Extension Mobility updates
mm
onlythe lineconfiguration (including the line CSS), not the device CSS. To allowthe choice
ofa local gateway, a different (line) CSS must be applied persite. In such a scenario, the
userchoosesa site-specific device profile thatdiffers from the device profile thatis usedat
other sites in theline CSS. The line CSS ofsuch site-specific profiles gives accessto route
patterns that route public switched telephone network (PSTN) calls tothe appropriate (local)
gateway

4. Cisco Unified Communications Manager updates the phone configuration with the settings
ofthe chosen device profile. User-specific device-level parameters, lines, and other phone
buttons areupdated with user-specific settings.

4-50 Implementing Cisco Unified Communications Manager, Part 2 (C1PT2) v8.0 ) 2010 Cisco Systems, Inc
Relationship of Cisco Extension Mobility Configuration
Elements
The figure shows how the Cisco Extension Mobility configuration elements relate toeacl
other.

Relationship of Cisco Extension


Mobility Configuration Elements

'••'tm&k —
Device
Profile: A
Cisco Extension
MobilityPhone
Service
Oevice
Stilt N— Profile: B

\
\
Device
Profile: C

Cisco Unified IP Cisco Unified IP Cisco Unified !P Cisco Unified IP


Phone 7940 Phone 7940 SIP Phone 7065 SIP
SCCPDef&ft OefeuS Device SCCP Default Default Device
Device Profile Device Proffle Profits

As the figure shows, an end user isassociated with one ormore device profiles. For each
possible IP phone model and protocol (SCCP and SIP), adefault device profile can be
configured. Because Cisco Extension Mobility is implemented as aCisco IP Phone Seniee. all
phones that should support Cisco Extension Mobility must be subscribed to the Cisco
Extension Mobility phone service, loallow a user to log into the phone. In addition, each
mm
device profile must be subscribed to the Cisco Extension Mobility phone service; this
subscription isrequired to allow a user to logoutof a phone.

©2010 Cisco Systems, Inc.


Implementation ofFeatures andApplications for Multisite Deployments 4-49
Note The default device profileis not applied ifa device profileof a user and the phone on which
the user tries to log in are of the same phone model series; for example, Cisco Unified IP
Phone 7960, 7961, or 7965.

Note Cisco Unified Communications Manager automatically creates a default device profile for a
specific phone model and protocol, as soon as Cisco Extension Mobility is enabled on any
phone configuration page for this phone model.

4-48 Implementing Cisco Unified Communications Manager, Pari 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc
Cisco Extension Mobility Configuration Elements
Thistopic describes the configuration elements thatCisco Extension Mobility uses.

Cisco Extension Mobility Configuration


Elements

Configuration Configuration Element Function


Element Name

SB res configuration of physicalphones. Conlguration parameters include device-


specificphone parameters (such as deviceCSS,location,or MRGL). user-specific
phoneparameters(such as userMOHaudiosource, DND, or soflkBy template),
and (oser-specifc) buttonconfiguration (suchas linesor speed dais).
The end user is associated with one or more device profiles The user IDand the
prj are used to log into a phone withCisco Enlension Mobility

Stores user-specific phoneeoniguraflon in logical proSles. ContDuration


parametersinclude user-specific phone and button {lines, speed dials,etc.)
Device profile parameters.The parametersof the deviceprofle art appliedtoa physicalphone
ater a user logs intothe phone using Cisco Extension Mobility.

Cisco ExtensionMobility is implementedas a phone service. Hardwarephones


Phone service
and deuce prof les need to be subscribed to the serwce

Stores tie default device-configuration parameters thai should be appliedwhen


the phonemode* offie deviceprofileofa user isUrfferert than the phonemodelof
Default device profile [he phone ^ wMW) fte usw |(jgs |(| ^ ^^ ^^ ^ ^ js^Av!f,ai ,s;ty
ci^ired lor«vetvphone mwlBlihaS hasCiKoExiensie'R MosilMy activated

The figure lists the configuration elements that are related toCisco Extension Mobility and
describes theirfunction. Theconfiguration elements that are introduced with Cisco Extension
Mobility are the device profile and the default device profile.
The device profile isconfigured with all the user-specific settings that are found althe device
level ofan IP phone (user MOH audio source, phone button templates, softkey templates, user
locales. DND and privacy settings, and phone service subscriptions) and all phone bulto.s
(lines, speed dials, and so on). One ormore device profiles are applied toan end user. ir> the
End User Configuration window.
The default dev ice profile stores default device configuration parameters thatCisco Extension
Mobilitv applies when there isa mismatch ofthe phone model series on which the user logs in
and the phone model series that is eonligured in the device profile ofthe user. The default
device profile exists once per phone model type and per protocol (Session Initiation Protocol
[SIP] and Skinny Client Control Protocol [SCCP]). All ofthe parameters that cannot be applied
from the device profile of the user are taken from the default device profile.
Eor example, a user is associated with adevice profile for aCisco Unified IP Phone 7945 that
runs SCCP. Ifthis user logs in toa Cisco Unified IP Phone 7965 that runs SIP. some features
(configuration parameters) that exist on the target phone are not configurable on the Cisco
Unified IP Phone 7945 dev ice profile. Inthis case, theconfiguration parameters that arc
unavailable onthe device profile of the user are taken from the default device profile ofthe
Cisco Unified IP Phone 7945 SCCP.
Ifadevice profile includes more parameters than the target phone supports, the additional
settings are ignored when the target phone with the user-specific settings is reconfigured.

© 2010 Cisco Systems. Inc.


Implementation ofFeatures and Applications for Multisite Deployments 4-47
Cisco Extension Mobility: Dynamic Phone Configuration by
Device Profiles
The figure illustrates how user-specific settings roam with the user when the user logs out of
one phone (for example, at the home location) and then logs into any other phone at any other
location.

Cisco Extension Mobility: Dynamic


Phone Configuration by Device Profiles

Cisco Unified
Communications
Remote
Manager
Gateway

Logout Login

Device Profile of Roaming User Device Profile of


User Andy: Andy
Login User User Andy:

H[
UMTUKda
Iter yOHAufe Sara and PIN UwrMOH AMID South
Ftcru tUscr, Timvlm ftm* fcltwt'r«iwl*»
SetmTtmme

NJ
Unicss \limeas

As shown in the figure, the user-specific parameters (that is, some device-level parameters and
all phone button settings, including line configuration) are configured in device profiles. Based
on the user ID that is enteredduring login,Cisco Unilied Communications Manager can apply
the personaldevice profileof the user and can reconfigure the phone with the configuration
profile of the user who logs in.
With Cisco Extension Mobility, CiscoUnified Communications Manager is aware of the end
userof a device andapplies the appropriate user-specific configuration, according lo a device
profile that is associated with the logged-in user.

4-46 Implementing CiscoUnified Communications Manager, Part 2 (CIPT2) vfi.O >2010 Cisco Systems, Inc.
Cisco Extension Mobility: Dynamic Phone Configuration
Parameters
Ihis subtopic describes the parameters that arc updated when a user logs in to a phone wnen
using Cisco Kxtension Mobility,

Cisco Extension Mobility: Dynamic


Phone Configuration Parameters

Cisco Extension Mobility can apply two types of phone


configuration parameters:
• User-specific, device-level parameters-
User MOH audio source
• Phone button template
Softkey template
User locale
-- DND and privacy settings
Phone service subscriptions
• Other
• Complete configuration of all available phone buttons:
Includes lines (directory numbers) and feature buttons such
as speed dials, service URLs, Call Park, and others
(depending on phone model)

There arc two types of configuration parameters that aredynamically configured when Cisco
Extension Mobility is used:
• User-specific de\ice-le\el parameters:
— fhese user-specific phone configuration parameters include user Music on Hold
(MOH) audio source, phone button templates, softkey templates, user locales. Do
Not Disturb (DND) andprivacy settings, and phone service subscriptions. All these
parameters are configured at the device level of an II' phone.
• Configuration of phone buttons(including lines):
— Cisco Extension Mobility updates all phone buttons -not only the button types that
are specified inthe phone button template but also the complete configuration of the
phone buttons. This update includes all configured lines, with all the line
configuration settings, speed dials, service UKUs. Call Park buttons, and any other
buttons that are configured in the device profile lhal is to be applied.

©2010 Cisco Systems Inc Implementation ofFeatures and Applications for Mullisite Deployments 4-45
Cisco Extension Mobility
Characteristics (Cont.)

At login, the phone configuration is updated with parameters


that are stored in the device profile of the user:
- Ifthe user ID is associated with multiple device profiles,
the user must choose the device profile that should be
used at login time.
- For duplicate logins, one of the following can be
configured:
• Allow multiple logins
• Deny login
• Auto-logout
At logout, another device profile (configured logout profile) is
applied, or the standard phone configuration is restored:
- Logout is performed manually by the user or enforced
after expiration of a configurable maximum login time.

If a user logs in with a user ID that is still logged in at another device, one of the following
options can be configured:
• Allow multiple logins: When this method is configured, the user profile is applied to the
phone on which the user is logging in. The same configuration remains active at the device
on which the user logged in before. The line number or numbers become shared lines
because they are active on multiple devices.
• Deny login: Whenthis optionis configured, the user receivesan error message. Login is
successful only after the user logs out of the other device on which the user logged in
before.

• Auto-logout: Likethe preceding option,this optionensuresthat a user can be logged in at


only one device at a time. However, this option allowsthe new login by automatically
logging out the user of the other device.

On a phone that is configured for Cisco Extension Mobility, anotherdevice profile (a logout
device profile) canbe applied, or theparameters that are configured on the phone are applied.
The logoutcan be triggered by the user or enforced by the system after expiration of a
maximum login time.

4-44 Implementing CiscoUnified Communications Manager, Part2 (CIPT2) v8.0 >2010 Cisco Systems, Inc.
Cisco Extension Mobility Overview
This topic describes the keycharacteristics and features of Cisco Extension Mobility.

Cisco Extension Mobility Characteristics

- Allows users to log into any phone and have their user-specific
phone configurations applied to the phone
• Makes users reachable at their personal extensions,
regardless of their locations and the physical phones they use
« Is implemented as a phone service; works within a Cisco
Unified Communications Manager cluster
- Stores user-specific phone configuration in device profiles

Cisco Extension Mobility allows users to log in to any phone and have theirindividual, user-
specific phone configuration that isapplied tothat phone. Thus, users can be reached at their
personal directory number, regardless of their location or the physical phone that they are
using, Cisco Extension Mobility is implemented asa phone service and works within a Cisco
Unilied Communications Manager cluster.
The user-specific configuration is stored in device profiles. After successful login, the phone is
reconfigured with user-specific parameters; other (device-specific) parameters remain the same.
Ifa user is associated with multiple device profiles, the user must choose which device profile
to use.

© 2010 Cisco Systems, Inc. Implementation ofFeaturesand Applications forMultisite Deployments


Cisco Extension Mobility Solves Issues of Roaming Users
Cisco Extension Mobility offers functionality that is designed to enhance the mobility of users
within a Cisco Unified Communications Manager cluster.

Cisco Extension Mobility Solves Issues


of Roaming Users

issue Without Cisco Extension Cisco Extension Mobility Feaiure that-


Mobiiily Solves the Issue

Extensions are bound to physical devices. Extension* am bound b device profile*.

Speed dials are assigned lo physical devices. Spaed dials are assigned to device profiles.

Services are assigned tophysicai devices. Services are assigned to device prolles.

MWIslaluss defined ror physical devrces.


..,.,... . .,.= .,. •_ - ,j -
Extension ^ ^
MWI status is updated during Cisco

casng privileges are delned for phytic*! ^ »*'*«••'**>* "™ mar9a *lln9
devices andlocations tttttoa.* Wevfce-based) Bfldptiyscal device
oevicej analocaons. umg.s(locatiCKKef*«d).

The figure shows which issues Cisco Extension Mobility solves.


Although the device is not the homedevice of the user, it is reconfigured with user-specific
settings that are stored in profiles. This action allows the separation of user-specific parameters
(which are stored in profiles)from the device-specific parameters that are still stored in the
phone configuration (along with default values for user-specific settings). The phone willadapt
someof its behavior, according to the individual user who is using the phone.
A userlogin, in which the useris identified by user IDand PIN, triggers the configuration
changes. When the userstops using the phone, the userlogsout andthe default configuration is
reapplied. Thus, the phone configuration adapts to the user.

4-42 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) vB.O ) 2010 Cisco Systems, Inc.
Issues of Roaming Users
Using guest phones at remote sites leads to several issues.

Issues of Roaming Users

Ifa user uses a different phone in a different site:


* Extensions are traditionally bound to constant devices.
» User gets the wrong extension on that phone.
* User gets the wrong calling privileges.
• User has no speed dials available.
* User has wrong services assigned.
• MWI status does not work with different extension.

The figure lists the most common issues that arise when users use any available guest phone at
sitesto which they have traveled. These issues include wrong extension numbers andcalling
privileges, other speed-dial configuration and phone-sen.'ice assignments, and no MWI status
for the actual number of the user.

For correct settings, the user requires Cisco Unified Communications Manager to reconfigure
the used phone with user-specific configuration instead ofhaving device-specific settings that
are applied to the phone.

© 2010 Cisco Systems, Inc Implementation otFeatures and Applications for Multisite Deployments 4-41
Issues with Users Roaming Between Sites
This topic describes the issues that can occur when users temporarily change their workplaces
and roam between sites.

Roaming Users

Roaming users do not travel with a device


(softphone) but use any available phone at the
current location.

Cisco Unified
Communications
Remote
Manager
Gateway

Roaming User
- - - - . : - _ . u—

Whenusers roam between sites and do not have their phone with them (for example, via Cisco
IP Communicator), they might want to use any available phone at the site to which they have
traveled.

4-40 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 12010 Cisco Systems. Inc.
Lesson 2

Implementing Cisco Extension


Mobility
Overview
Some users roam between office desks or sites on a regular basis. Such users, who use phones
that are provided at the sites that they visit, would like to (but cannot) use their personal
settings, such as directory number, speed dials, calling privileges, and Message Waiting
Indicator (MWI). A professional Cisco Unified Communications solution needs to solve this
problem.
This lesson describes Cisco Extension Mobility, a feature of Cisco Unified Communicat oris
Manager. Cisco Extension Mobility allows Cisco Unified Communications Manager us..rs to
log into an IP phone and have their personal profile applied, regardless of the device and
physical location that they are using.

Objectives
Upon completing this lesson, you will be able to describe how Cisco Extension Mobility works
and how it is implemented. This ability includes being able to meet these objectives:
Identity the issues when users roam between sites
Describe the Cisco Extension Mobility feature

Describe the Cisco Extension Mobility configuration elements and their interaction
Describe Cisco Extension Mobility operation
Implement Cisco Extension Mobility

m
4-38 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 © 2010 Cisco Systems, Inc.
References
I'or additional infonnation. refer to these resources:

• Cisco Systems. Inc. Cisco Unified Communications System 8.xSRND. April 2010.
hup: '.www.cisco.coni en US/doesAoice_ip comm/aicm/srn<l/8,\/uc8x.html
• Cisco Systems. Inc. Cisco Unified Communications Manager Administration Guide
Release 8.0(1). February 2010.
hup: 'www.cisco.com en US/docs/\oice ipcoin nv'cu em/admin/8 0 l/ccmcfg/beem-XOI
cm.html

)2010 Cisco Systems. Inc Implementation of Features and Applications for Multisite Deployments
Summary
'ITiis topic summarizes the key points that were discussed in this lesson.

Summary

• Issues with roaming devices include inappropriate region,


location, time zone, and SRST reference configuration. PSTN
calls are using the home gateway instead of the local gateway
at the roaming site.
• Device Mobility allows roamingdevices to be identified by their
IP addresses, and configuration settings to be applied that are
suitable for the current physical location of the device.
• Device Mobility configuration elements are device mobility
groups, physical locations,device pools, and device mobility
infos.

Summary (Cont.)

• You apply roaming-sensitive settings to devices that roam


between physical locations. In addition, you apply Device
Mobility-related settings to devices that roam within the same
device mobility group.
1Implementation and operation of Device Mobility are optimized
when globalized call routing and local route groups are used.
Afterconfiguring device mobility groups, physical locations,
device pools, and device mobility infos, you must enable Device
Mobility eitherdusterwide as a service parameter or individually
per phone.

4-36 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) v8.0 52010 Cisco Systems, Inc.
Step 5b; Set the Device Mobility Mode for Individual Phones
The fig jrc shows how to set the Device Mobility mode for each phone.

Step 5b: Set the Device Mobility Mode


for Individual Phones

Cisco Unified Communications Manager Administration:


Device > Phone

This is the home device pool of the EH£- SL


phone ^=^ Dev :e p™r n(j .|.|> -

There are overlapping settings at the


device pool and at the phone; they " " =•" - s"'" s"» -

have higher prioritythan settings at


the home device pool but are
replaced by settings from the roamng
device pool
r-

H
Set the phone device mobilitymode: .

the default applies the service


parameter setting

In the I'honc Configuration window, you enable ordisable Device Mobility for each phoie by
cither setting Device Mobility Mode to On orOff or leaving the default value as Default. If
Device Mobilitv Mode is setto Default, the Device Mobility mode that is setat theCisco
CallManager serviceparameteris used.
The figure also shows the configuration ofthe overlapping parameters (these arc parameters
that can be configured at the phone and at the device pool). The overlapping parameters for
roaming-sensitive settings are Media Resource Group List, Location, and Network Locale. The
overlapping parameters for the Device Mobility-related settings are Calling Search Space
(called Device Mobility Calling Search Space atthe device pool), AAR Group, and AAR
Calling Search Space. Overlapping parameters that are configured at the phone have higner
prioritv than settings at the home device pool, and lower priority than settings at the roaming
device pool.

© 2010 Cisco Systems. Inc


Implementation ofFeatures and Applications for Multisite Deployments 4-35
Step 5a: Set the Device Mobility Mode Cisco CallManager
Service Parameter
The figure shows how to set the system default for the Device Mobility mode.

Step 5a: Set the Device Mobility Mode


Cisco CallManager Service Parameter

Cisco Unified Communications Manager Administration:


System >Service Parameter >Cisco CallManager

£( '.'.;-.i,;i[i;: * off u c«
Qt- -s!•;!f.. 1SJ* " n„ ,«|
^u^^, A
y\
Set the default Device Mobility
mode for all phones.

Device Mobility is turned off by default and is configurable for eachphone. To set the default
for the Device Mobility mode (ifit isnot setdifferently atthe phone), choose System >
Service Parameter. ChooseCisco CallManager, and in the Clusterwide Parameters
(Device—Phone) section, set Device Mobility Modeto On or Off (OtTis the default).

4-34 Implementing Cisco Unified Communications Manager. Part2 (CIPT2) v8.D >2010 Cisco Systems. Inc.
Step 4: Configure Device Mobility Infos
The figure shows how to configure device mobility infos.

Step 4; Configure Device

Cisco Unified Communications Manager Administration:


System >Device Mobility >Device Mobility Info

. I"".. Mobil II, IMd li.f.rm.1".*

Enter name, subnet, and subnet |


mask.

..I. lnrH.ll w u l u Mobility Into-

Assign device mobilityinfo to


one or more device pools w

Io configure device mobility infos, choose System > Device Mobility >Device Mobility-
Info. They are configured with aname, a subnet, and a subnet mask. Then they are associated
with one or more device pools.

© 20'0 Cisco Systems. Inc.


Implementation of Features and Applications for Multisite Deployments 4-33
Step 3: Configure Device Pools
The figure shows how to configure adevice pool when using Device Mobility.

Step 3: Configure Device Pools

Cisco Unified
Communications
Manager Ad ministration:
System > Device Pool

ConGguteroaming-
sensitive sellings mat <
be applied lo Ihe ptione
configuration The Local
Route QOLp ib also a
roaming -sens itiveset! ing'

Choose physical location


ana device mobilitygroupto
determine vi»>ettier tc apply
roa m mg-sens ilive s etlings
and Device Mobility-related
settings

Configure Dev.ce Mobility-


related sett ngs The Called
Party Transtormaton CSS
is no Device Mobility-related
selling1

You configure a device pool with aname and a Cisco Unified Communications Manager
group. The configuration includes roaming-sensitive settings and Device Mobility-related
settings. (You configure the Device Mobility-related settings in the Device Mobility-Related
Information section.) You configure both the physical location and the device mobility group in
the Roaming-Sensitive Settings section. You use both of those configurations todecide which
settings to apply to a phone: nosettings, the roaming-sensitive settings only, orthe roaming-
sensitive settings and the Device Mobility-related settings. Thephysical location and the device
mobility group themselves arenotapplied to the configuration of a phone, butareused to
control which settings to apply.

4-32 Implementing Cisco Unified Communicalions Manager, Part 2 (CIPT2) vS.O >2010 Cisco Systems, Inc.
Steps 1 and 2: Configure Physical Locations and Device
Mobility Groups
fhe figure shows the configuration of physical locations and device mobility groups.

Steps 1 and 2: Configure Physical


Locations and Device Mobility Groups

Cisco Unified Communications Manager Administration:


System > Physical Location

••- • •

Entername arid description. L^_ "'""' "'>-"'

Cisco Unified Communications Manager Administration:


System > Device Mobility > Device Mobility Group

I1»IIU« HiUUh. I:—..,. 1-h.Pm.M—


Entername and description <~

To configure physical locations, choose System > Physical Location, for each physical
location, you configure a name and a description. To configure device mobility groups, choose
System > Device Mobility > Device Mobility Group. For each device mobility group, you
configure a name and a description.

Note Device mobility groups are not necessary when there is no need to change the device level
CSS, AAR CSS, and AARgroup This principle applies also when local route groups are
used in an environment where all sites share the same dial rules or in an environment where
globalized call routing is implemented

© 2010 Cisco Systems, Inc Implementation of Features and Applications for Multisite Deployments
Device Mobility Configuration
This topic describes how to configure Device Mobility.

Device Mobility Configuration Steps

1 Configure physical locations.


2 Configure device mobility group.
3 Configure device pools.
4 Configure device mobility infos (IP subnets).
5 Set the Device Mobility mode by using:
a. A Cisco CallManager service parameter to set the
default for all phones
b The Phone Configuration window for individual
configuration per phone

"Die figure lists the required steps for implementing Device Mobility. As discussed in the
previous topics, device mobility groups are not required when you implement Device Mobility
in an environment where globalized call routing is used.

4-30 Implementing CiscoUnified Communicalions Manager, Part 2 (CIPT2) v8.0 >2010 Cisco Systems. Inc.
Example: Globalized Call Routing
The figure shows an example of Device Mobility in an environment where globalized call
routing is implemented. Also, gateway selection is performed by the local route group feature.

Example: Globalized Cail Routing


HQ Translation Patterns Device Pool
(Partition HQ, CSS. System: HQ
000 ' -> DDI PreDot, Prefix + Physical
00 i -> DDI PreDot. Prefix +49 Location HQ
DDI PreDot, Prefix +4940 Local Route
Group >~'j
Route Pattern \+'
Partition System

Single Route List.


Default Local Roule Group
Device Pool. E
Physical
BR Translation Patterns Location BR
(Partition BR. CSS. System| CSS BR]
91 [2-9)XX[2-9JXXXXXX -> DDI Local Route
PreDct, Prefix+1 Group. BR
9 [2-9]XXXXXX -> DDI PreDot,
Prefix+1408
9011 !-> DDI PreDot. Prefix +

Normalization of localized call ingress is in place


BR user roaming to HQ uses NANPdial rules and uses HQ gateway

Theexample in the figure is based on the previous scenario: IIt) is in Europe. BRis in the
United States. A BR user will roam to Europe.
However, in this example, globalized call routing has been implemented. Therefore, the (line)
CSS of BR phones provides access to translation patterns thatconvert localized call ingress at
the phone (NANP formal) to global E.I64 formal. EU phones have access to translation
m
patterns that cotwert HI] input to global K.164 fonnat.
A single PSTN route pattern (\(!) is configured: it is in a partition that is accessible by all
translation patterns.
When a BR user roamsto the IIQ. the lineCSS is not modified; no device CSS is configured at
the phone or at the device pool. Thedevice mobility groups arc alsonotset (or areset
differently).
As a result, there is effectively no change in matching the translation patterns: The BRuserstill
uses NANPdial rules (like at home), fhe numberis converted to international format by-
translation patterns and matches the (only) PSTN roule pattern. The route pattern refers to a
route listthat is configured to use thedefault local route group. The default local route group is
taken from the roaming device pool. Therefore, if the phone is physically located in the BR
office, the local route group is BR; if the phone is roaming to the HQ site, the local route group
is HQ. As a result, the local gateway is always used for a PSTN call.
IfTEHO was configured, there would be aTEHO route pattern in E.I64 format with a leading
+sign. The TEHO pattern would refer toa site-specific route list in order toselect the correct
gateway for PSTN egress. The backup gateway would then again be selected by the local route
group feature.

) 2010 Cisco Systems. Inc Implementation of Featuresand Applications for Multisite Deployments 4-29
Example: No Globalized Call Routing—Same Device Mobility
Group
The figure shows an example of Device Mobility with identical device mobilitv groups in an
environment where globalized call routing is not implemented. Also, gateway selection is
performed by the device CSS ofthe IP phone.

Example: No Globalized Call Routing-


Same Device Mobility Group

Device Pool HQ
Physical
Location. HQ
Device Mobility
Group; World
Device Mobility
CSS' HQ

| BR user roaming to HQ has lo use EU dial rules and uses HQ gateway [

This example is identical to the previous example with one exception: This time the device
mobility group ofthe home and the roaming device pool are the same.
When a BR user roams to the HQ, the device CSS ofthe phone is updated with the device CSS
of the roaming device pool. In the example, CSS BR is changed to HQ. As aconsequence the
phone has access to the HQ partition that includes PSTN route patterns in EU dialing format
Therefore, the roaming user has to follow EU dial rules. Calls to 9.@ are not possible anymore
However, this configuration allows the BR user to use the HQ gateway when roaming to the
HQ.

•fe

4-28
Implemenling Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 ^2010 Cisco Systems, Inc.
Example: No Globalized Call Routing—Different Device
Mobility Group
The figure shows an example of Device Mobility with dilTerenl device mobility groups in an
em ironment where globalized call routing is not implemented. Also, gateway selection is
performed b\ the device CSS ofthe IP phone.

Example: No Globalized Call Routing-


Different Device Mobility Group

Route Pattern Device Pool HQ

«49 40 552XXX 01 Physical


Location i C
Device Mobility
Group HQ
Route List (Device Mobility
Route Group HQ-GW CSS. HQ)

Device Pool BR
Route Pattern Physical
9® Location1 Lit*
Partition Branch Device Mobility
Group. BR
(Device Mobility
Route List CSS. BR)
Roule Group. BR-GW
HQ: EU Numbering
Plan
UR. NANP

| BR user roaming lo HQ uses NANP dial rules and uses BR gateway |

In the example, there are two sites. The main site ("I IQ" in the figure) is in Europe, the branch
site ("BR"' in the figure) is in the United States. Separate route patterns (representing the
different dial rules) are configured in different partitions. The CSS of HQ phones provides
access to the HQ gateway, the CSS ofBR phones provides access to the RR gateway.
Device Mobilitv is configured with different device mobility groups. This configuration allows
BR users who arc roaming with their phones to the HQ to use the home d.al rules. Ihe device
CSS is not updated by Device Mobility, and therefore, the CSS still provides access to the BR
route pattern (9,ff). Howler, as aconsequence, the BR gateway ,s used tor all PS fN calls.

Implementation of Features and Applications for Multisite Deployments


© 2010 Cisco Systems. Inc.
Advantages of Using Local Route Groups and Globalized Call
Routing
Device Mobility benefits from globalized call routing and local route groups, especially when
implemented in international environments.

Advantages of Local Route Groups and


Globalized Call Routing

Cisco Unified Device Mobility benefits from globalized call


routing and local route groups:
• Updates ofroaming sensitive settings still apply {no changes)
- Local route group is a roaming sensitive setting
• Globalized call routing and local route groups allowsthe
combination of two features, which are exlusive otherwise:
~ Roaming gateway can be used
- Home dial rules can be used
• No updatesofdevice mobility-related settings (device CSS, AAR
CSS, and AAR group) required
• Functionality ofdevice level CSS(device/line approach) is
replaced by local route group in route list
• Different AAR groups andAAR CSS not required
• Eliminates need fordevice mobility groups

When Device Mobility with globalized call routing is used, there are no changes in the
roaming-sensitive settings. Their application always makes sense when roaming between sites
Iliey have no influence on the gateway selection and the dial rules that auser has to follow.
The dial plan-related part of Device Mobility, however, changes substantially with globalized
call routing. It allows aroaming user to follow the home dial rules for external calls and
nevertheless utilize the local gateway ofthe roaming site.
This situation is possible because globalization of localized call ingress at the phone occurs
1his function is provided by the line CSS of the phone. It provides access to phone-specific
translation patterns that normalize the localized input ofthe user to global format. The device
CSS that was used for gateway selection is obsolete, because gateway selection is now
performed by the local route group feature.
The AAR CSS and AAR group that are configured at the device level can be the same for all
phones as long as the AAR number is always in global format. (You can ensure that it is always
in global format by configuring either the external phone number mask orthe AAR
transformation mask to E. 164 format.) In this case, no different AAR groups arc required
because there is no need for different prefixes that are based on the location of the two phones
Further, there is no need for different AAR CSS, because the gateway selection is not based on
d.fferent route lists (referenced from different route patterns in different partitions) Instead it
is based on the local route group that was configured at the device pool of the calling phone.
In summary, when using globalized call routing is used, Device Mobility allows users lo use
local gateways at roaming sites for PSTN access (or for backup when TEHO is configured)
while utilizing their home dial rules. There is no need to apply different device CSS AAR CSS
and AAR groups, and hence, device mobility groups are no longer required

Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0


32010 Cisco Systems, Inc.
Note If TEHO isused, there areno suboptimal paths when using Device Mobility with different
device mobility groups. However, when local route groups and globalized call routing arenot
being used, TEHO implementation can be very complex, especially when local PSTN
backup is desired and when TEHO is implemented in international deployments.

In summarv. unless TEHO is used, the implementation ofDevice Mobility without globalized
call routing leads to this situation: Either the home gateway has to be used (when allowing the
user touse the home dial rules) orthe user is forced touse the dial rules ofthe roaming site (in
orderto use the local gateway of theroaming site).

m*

implementation otFeatures and Applications for Multisite Deployments 4-25


>2010 Cisco Systems, Inc
Device Mobility Interaction with Globalized Call
Routing
This topic describes the interactions of globalized call routing and local route groups with
Cisco Unified Device Mobilitv.

Device Mobility Review Without Local


Route Groups and Globalized Call Routing
As discussed earlier, there are two types of device pool settings
for Device Mobility:
• Roaming-sensitive settings (location, region, SRST reference, MRGL, etc.)
are always updated when device roams to different physical location.
• Device Motility-related settings (device CSS, AAR CSS, and AAR group) are
updated based on device mobility group:
- Different device mobility group:
• Noupdateof devceCSS.AARCSS.artd AARgroup
• No changes to dial odes, but use of home gateway
- Same device mobility group:
• UpdateofdeviceCSS.AARCSS.andAARgroup
• Use of roaming gateway but changes to dial rules
Required only when gateway selection is based on CSS (that is, local
mute group and globalzed cal routing are not used)

Local route groups have been introduced with Cisco Unified Communications Manager
Version 7. When local roule groups—and globalized call routing, which utilizes local route
groups—is not used or supported. Device Mobility is typically implemented:
• Roaming-sensitive settings are always updated when the device roams between different
physical locations. These settings are location, region, SRST reference, MRGL, and other
parameters that do not affect the selection of the PSI'N gateway or the local rules.
• Device Mobility-related settings can be appliedin addition to the roaming-sensitive
settings (which meansthat a phone has to roam between differentphysical locations). The
Device Mobility-related settings are device CSS, AAR CSS, and AAR group. The
configuration of the device mobility group shoulddetermine your decision about whether
to apph the Device Mobility-related settings.
— If the device roams between different device mobility groups, the Device Mobility-
related settings arenot updated with the values that were configured at the roaming
de\ ice pool. This configuration hasthe advantage thatusers do not have to adaptto
different dial rulesbetween homeand roaminglocation (if they exist).The
disadvantage is that all PS'fN calls will use the homegateway that can leadto
suboptima! routing.
— Ifdie device roams within the same device mobility group, the Device Mobility-
related settings areupdated with the values of the roaming device pool. This
configuration has the advantage that all PSTN calls will use the local (roaming)
gateway, which is typically desired for roamingusers. However, the users will have
to use to the local dial rules.

4-24 Implementing CiscoUnified Communications Manager, Part 2 (CIPT2) v8.0 >2010 Cisco Systems, Inc.
For the next three scenarios, the assumption is that the home device pool and the roaming
device pool are assigned to different DMGs. As a result, the Device Mobility-related settings
are not applied. Therefore, calls that are placed from the roaming device are routed in the same
way as when the device is in its home location.
• If the user places a call to a UK PS'fN destination, the call will use the IP WAN to the
London site and break out to the PSTN at the London gateway with a local or national call.
This solution is the optimal one from a toll perspective.
• If the user places a call to a PSTN destination that is close to the roaming location (for
example, a U.S. PSTN number) and TEHO is not configured, the call will use the IP WAN
from the U.S. office to the I .ondon site. It wilt break out to the PSTN at the London
gateway to place an international call back to the United States. From a toll perspeebve,
this is the worst possible solution, because the call first goes from the United States to
London over the IP WAN (consuming bandwidth) and then goes back from London to the
United States via a costly international call.
• If the user places a call to a PSTN destination that is close lo the roaming location (for
example, a U.S. PSTN number) and TEHO is configured, the U.S. gateway is used for a
local or national call. This event is optimal from a loll perspective.

Note In these three examples, the user has to dial PSTN destinations by following the dial rules of
the home location (Great Britain).

In summary, when you allow the Device Mobility-related settings to be applied (by using the
same device mobility group), calls to the home location will use a local PS'fN gateway to place
a long-distance or international call when not implementing TEI10.All othercalls areoptimal.
When the Device Mobility-related settings arc not applied (by using different device mobility
groups) and TEHO is not used, calls to the roaming location will first usethe IP WAN to go
from the roaming location to the home location, fhe calls then use the home gateway to place a
long-distance or international call back to the roaming location. All othercalls areoptimal.
The discussed scenarios assume that globalized call routing and local routegroupsare not used,
fhe impact of globalized call routing and local route groups is discussed inthe next topic.

©2010 Cisco Systems, Inc. Implementation ofFeatures and Applications for Multisite Deployments 4-23
Examples of Call-Routing Paths Based on Device Mobility
Groups and TEHO
The table shows how calls are routed in different Device Mobility scenarios.

Examples of Different Call-Routing Paths


Based on Device Mobility Groups and TEHO

Same device mobity group, call lo PSTN Cal use* local PSTN gateway at roaming
destination close id dome location, no TEHO. location for a long-distance PSTN cal.

Same device mobility group, call lo PSTN Cal uses IP WAN to gateway at home location
destination close D home location, TEHO. for a local PSTN call.

Same device mobity group, call to PSTN Cal uses local PSTN gateway at roaming
destinalIon close b roamhg location. location for a local PSTN call.

Different device motility group, call to PSTN Cal uses IP WAN to gateway at dome local on
destination close lo home location. for a local PSTN call.

Different device mobility group, call lo PSTN Cal uses IP WAN to gateway at home location
destination close Id roaming location, no TEHO. tor a king-a stance PSTN caK.

Different 0evice mobility group, call lo PSTN CaB uses local PSTN gateway at roaming
destination close to roammg location, TEHO. location for a local PSTN call.

Calls are routed differently depending on the configuration of DMGs (whether Device
Mobility-relatedsettings are applied or not), the dialed destination, and the use of tail-end hop-
off (TEHO). In some scenarios, calls might take suboptimal paths.
The example in this discussion assumes that a user from London roams to the U.S. office (for
simplicity, it is assumed that there is only one U.S. office). This user uses Cisco IP
Communicator.

Forthe first three scenarios, the assumption is that the home devicepool and the roaming
devicepool are assigned to the same device mobility group.Therefore, Device Mobility applies
Device Mobility-related settings. As a result, PSTN calls that are placed from the roaming
device are treated like PSTN calls of standard U.S. phones.
• If the user places a call to a PSTN destination that is close to the home location (for
example, a UK PSTN number) and TEHO is not configured, the call will use the local
(U.S.) PSTN gateway for an international PSTN call, from a toll perspective, this is a
suboptimal solution, because the IP WAN is nol used as much as it could be used when
implementing TEHO. This factor applies not only to the roaming user, but also to U.S.
users who place calls to PSTN destinations in Great Britain.
• If the user placesthe same call (to a UK PSTN number) and TEHO is configured, the call
will use the IP WAN to the London site and breakout to the PSTN at the London gateway
with a local call. This solution is the optimal one from a toll perspective.
• If the user places a call to a U.S. destination number, the U.S. gateway is used fora local or
national call. This event is optimal from a toll perspective.

Note In all ofthe examples that are shown inthe table, the user has to dial PSTN destinations by
following the U.S. dial rules (North American Numbering Plan [NANP]).

4-22 Implementing Cisco Unified Communicalions Manager, Part 2 (CIPT2) v8.0 © 2010 Cisco Systems, Inc.
The line/device approach is recommended when you are implementing CoS in a multisite
environment. Here is a description of the operation of the line/device approach:
• The line CSS implements CoS configuration by permitting internal destinations (other
phone director; numbers, and access to features such as call part and Meet-Me
conferences). The line CSS also blocks PSTN destinations. Because the line CSS is not
changed by Device Mobility. CoS settingsof the device are kept when the device is
roaming.
• I he de\ice CSS is modified when the device is roaming within the same device mobility
group. In this case, the device CSS that is used at the home location is replaced by a de\ ice
CSS that is applicable for the roaming location. This device CSS will refer to the local
gateway of the roaming site instead of to the gateway that is used at the home location.

If the traditional approach is used (only one CSS. combining CoS and gateway choice), the
device CSS must be used. The reason is that Device Mobility cannot modify the line CSS. and
the line CSS has priority over the device CSS (which can be modified by Device Mobility).
The AAR CSS is configurable only at the device level and therefore is always correctly
replaced when the device roams between physical locations within the same device mobility
group.

Note When using globalizedcall routing and local route groups, there is no need for site-specific
device-level CSS. More information about the interaction of globalized call routing and
Device Mobility is provided in a later topic of this lesson.

>2010 Cisco Systems. Inc Implementation of Features and Applications for Multisite Deployments 4-21
Device Mobility and Calling Search Spaces
This subtopic describes how CSSs are processed when Device Mobility is used.

Device Mobility and Calling Search


Spaces

• Line CSS is nevermodified by Device Mobility.


• Device CSS is modified only when device roams between
physical locations and within the samedevice mobility group:
- Operation when using the line/device CSS approach
(recommended forCoS implementation);
• Line CSS is not modified; CoS settings are kept.
• Device CSS is modified; itallows local gateway
selection by applying CSS ofroaming device pool.
- When using the traditional CSS approach (only one CSS
at phone), use the device CSS, instead ofthe line CSS, to
allow the CSSto be modified by Device Mobility.
• AAR CSS is configurableonly at the device and therefore is
always correctly modified when the device roams between
physical locations and within thesamedevice mobility group.

Review of Line and Device CSS


An IP phone can be configured with aline CSS and adevice CSS. Ifboth CSSs exist, the
partitions ofthe line CSS are considered before the partitions ofthe device CSS when a call is
being routed.

fhese two CSSs allow the use of the line/device approach for implementing calling privileges
and the choice ofalocal gateway for PSTN calls. With the line/device approach, all possible
PS INroute patterns exist once per location and are configured with asite-specific partition
This partition is included in the device CSS ofthe phones, and therefore itenables the use ofa
local gateway for PSTN calls. To implement class ofservice (CoS), PSTN route patterns that
should not be available to all users (for example, international calls, long-distance calls or all
toll calls) are configured as blocked route patterns. These blocked route patterns arc then
assigned to separate partitions. The line CSS ofaphone now will include Ihe partitions of those
route patterns that should be blocked for this phone. Because the line CSS has priority over the
device CSS. the blocked pattern will take precedence over the routed pattern that is found in a
partition that is listed at the device CSS.

Device Mobility and CSSs


Device Mobility never modifies the line CSS ofaphone. It does change the device CSS and
AAR CSS of aphone when the phone is roaming between different physical locations within
the same device mobility group.

4-20
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) u8.0 ©2010 Cisco Systems, Inc.
Gemian users who roam with their softphoncs tothe United Stales might beconfused when
they obtain their home extensions, but they have to use U.S. dialing rules (access code 9instead
of6. or011 instead of00 for international numbers, and so on). Ifyou want to avoid such
behavior, vou need to suppress the application of Device Mobility-related settings. You
suppress the settings by assigning device pools that are to be used at sites with different dialing
rules into different device mobility groups (and in different physical locations). When a user
now roams with a device from Germany tothe United States, all the roaming-sensitive settings
are applied to use local media resources and Cisco Unified SRST gateways. Also, codecs and
CAC settings are applied correctly, but the Device Mobility-related settings arc not applied.
The result is that the phone will use the PSTN gateway and dial rules ofits home location even
though the user has moved to another site. The user does not have to adapt to the dial rules of
the local site to which the phone was moved.

Note The preceding statements regarding call routing and dial behavior that are based on Device
Mobility-related settings do not apply when globalized call routing is used. Alater topic in
this lesson presents more information about the interaction of globalized call routing and
Device Mobility

Ho10 Cisco Systems. Inc. Implementation of Features and Applications for Multisite Deployments 4-19
Device Mobility Considerations
This subtopic describes key facts that you need to consider when implementing Device
Mobility.

Device Mobility Considerations

• Roaming-sensitive settings:
- Ensure the use of local media resources and SRST references.
- Ensure correct use of codecs and CAC between sites.
- Shouldalways be applied to roaming devices
• Settings relatedto Device Mobility affect call routing:
- WhatgatewaytouseforPSTNaccessandAAR PSTN calls(device CSS
andAAR CSS),and how to composethe AAR number(AAR group)?
- Changes may result indifferent dialing behavior (forexample, different
PSTN accesscodes, different PSTN numbering plans, and so on).
- Users might getconfused byhaving their home extensions and yet being
required to follow dial rules of roaming site.
- tfthisis notdesired, suppress application of settings related to Device
Mobility by assigningdifferent device mobility groups.
- Not applying settings related to Device Mobility might lead to suboptimal
call-routng paths.

Roaming-sensitive settings ensure that local media resources and SRST references are used by
the roaming device. Inaddition, they ensure the correct use ofcodecs and CAC between sites.
Typically, this is always desired when adevice roams between different sites. It is not required
when the device moves only between IPsubnets within the same site. Therefore, the
recommendation isto assign all device pools that are associated with IPsubnets (device
mobility info) that are used atthe same site tothe same physical location. This action results in
phone configuration changes only when the phone roams between sites (physical locations) and
notina situation where a phone is moved only between different networks of thesame site.
Device Mobility-related settings affect call routing. By the application ofthe device CSS. AAR
group, and AAR. CSS calls can be routed differently depending on the site where the phone has
roamed to. The settings at the roaming device pool determine which gateway will be used for
public switched telephone network (PSTN) access and AAR PSTN calls (based on the device
CSS and AAR CSS) and how the number to be used for AAR calls is composed (based on the
AAR group).

Such changes can result in different dialing behavior. For instance, when roaming between
different countries, the PSTN access code might be different and PSTN numbering plans (for
example, how to dial international calls) might apply. As an example, in order to dial the
Austrian destination +43 699 18900009 from Germany, users dial 0.0043 699 18900009. while
users in the United States have to dial 9.01143 699 18900009.

4-18 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 © 2010 Cisco Systems, Inc.
7. The roaming-sensitive settings ofthe chosen device pool (that is. the roaming device pool)
arcused to update the configuration of thephone.

Note In this case, overlapping settings (that is,settings thatexist at the phone as well as at the
device pool, namely, MRGL, Location, and Network Locale) ofthe roaming device pool have
priority over the corresponding settings atthe phone. This behavior isdifferent from the
default behavior (see Step 10).

8. Ifthe dev ice mobility groups ofthe chosen device pool and ihe home device pool are the
same, the phone configuration isupdated by applying the Device Mobility-related settings:
otherwise continue.

Note In this case, all settings are overlapping settings (that is, all Device Mobility-related settings
exist atthe phone as well as at the device pool), and the parameters of the roaming device
pool have priority over the corresponding settings atthe phone. This behavior isdifferent
from the default behavior (see Step 10).

9. Where the phone configuration has been updated (either with the roaming-sensitive settings
onh orwith the roaming-sensitive settings and the Device Mobility-relalcd settings), the
phone is reset in order for the updated configuration to be applied to the phone.
Caution This is the end of the process: do not continue to Step 10. Step 10 was directly referenced
from previous steps in certain conditions and does not apply after Step 9.

10. Here is adescription ofthe default behavior. First, the settings ofthe home device pool
(that is. the device pool that is configured at the phone) are applied. Some configuration
parameters of the device pool can also be set individually at the phone. These overlapping
phone configuration parameters are MRGL Location. Network Locale. Device Mobility
CSS (which is called simply CSS at the phone). AAR CSS, and AAR Group. Ifthese
parameters are configured at the phone (that is. are not set lo [None]), the phone
configuration settings have priority o\er the corresponding setting at the device pool.

m*

^D10 Cisco Systems. Inc implementation of Features and Applications for Mulfsite Deployments 4-17
Device Mobility Operation: Flowchart
The figure illustrates Device Mobility operation in a flowchart.

Device Mobility Operation: Flowchart


I No I
hi ^m Apply roamtng-
ssnsttiua sellings
from selected device
pool.

Slop- Apply Device-


Mobiifty-related
settings from

| DP - device pool. DWG =device mobility group, DMI - flevice mobility info |

Here is how a phone registers with Device Mobility:


1. Adevice attempts to register with Cisco Unified Communications Manager.
2. Cisco Unified Communications Manager checks whether Device Mobility is enabled for
the device.

— Ifit is not enabled for the device, the default behavior applies (go to Step 10);
otherwise continue.

3. Cisco Unified Communications Manager checks whether the IP address ofthe IP phone is
found inone of the device mobility groups.
— Ifit is not found, the default behavior applies (go toStep 10); otherwise continue.
4. The device pool to be used is chosen.

— Ifthe home device pool isassociated with the device mobility info in which the IP
address of the phone was found, the home device pool ischosen.
— Ifthe home device poo! is not associated wilh the device mobility info in which the
IP address ofthe phone was found, the device pool ischosen based on a load-
sharing algorithm (ifmore than one device pool is associated with the device
mobility info).

5. Ifthe chosen device pool is the home device pool, the default behavior applies (go to
Step 10); otherwise continue.

6. Ifthe physical locations of the chosen device pool and the home device pool are the same
the default behavior applies (goto Step 10); otherwise continue.

Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 )2010 Cisco Systems, Inc.
In summary, the roaming-sensitive parameters are applied when the physical location ofthe
current device pool is different from the physical location ofthe home device pool (thai .s.
when roaming between physical locations). The Device Mobility-related settings are applied in
addition to the roaming-sensitive parameters when the physical locations are different and the
dev ice mobility groups are the same (that is, when roaming between physical locations within
the same device mobility group).
As a result, physical locations and device mobility groups should be used in two ways:
• Physical locations: Configure physical locations in such away that codec choice and CAC
truh reflect thecurrent location of the device. Hnsurc thatlocal SRST references and local
media resources atthe roaming site are used instead ofSRST references and media sources
that are located atthe (currently remote) home network. Depending upon the network
structure andallocation of services, vou may define physical locations that arebased upon
a cit\. an enterprise campus, or a building.
• Device mobility groups: Adevice mobility group should define agroup ofsites with
similar dialing patterns or dialing behavior. Device mobility groups represent the highest-
lev el geographic entities in your network. Depending upon ihe network size and scops,
your device mobilitv groups could represent countries, regions, states or provinces, c.ties,
or other entities. Because Device Mobility-related settings (which areapplied only v hen
roaming within the same device mobility group) affect call routing, different device
mobilitv groups should be set up whenever roaming users should not be forced to adapt
their dialing behavior. In this case, as in roaming between different device mobility groups,
the phone configuration parameters that affect call routing (that is. the Device Mobility-
related settings) arc not modified.

Note When using globalized call routing and local route groups, device mobility groups aru
irrelevant Thereason isthatthere is no need tochange thedevice-level CSS, theAAR
CSS, and the device-level AAR group. More information about the interaction of globalized
call routing and Device Mobility isprovided in a later topic of this lesson.

** ~ 10 C|sco Systems, mc implementation of Features and Applications for Muttisite Deployments 4-15
Device Mobility Operation
This topic describes how Device Mobility works.

When and How Is the Phone


Configuration Modified?

1 Each phone is configured with a device pool (that is, the home
device pool).
IP subnets are associated with device pools,
Ifthe IP address of the phone matches a configured IP subnet
one ofthe associated device pools is selected (load-shared).
Ifthe selected device pool is different from the home device pool
of the device, these settings of the two device pools are
checked:
- If the physicallocationsare not different the phone
configuration is not modified.
- If the physical locationsare different, the roaming-sensitive
settings of the roaming device pool are applied.
- Additionally, ifthe device mobility groups are not different
the Device Mobility-related settings of the roaming device
pool are also applied.
In all other cases, the home device pool configuration is applied.

As discussed earlier, each phone isconfigured with a device pool. This device pool isthe home
device pool of the phone.
IP subnets are associated with device pools (by configuring device mobility infos).
Ifa phone for which Device Mobility isenabled registers with Cisco Unified Communications
Manager and has an IP address that matches an IP subnet that is configured in a device mobility
info, these actions occur:

• The currentdevice pool is chosen.


— Ifthe device mobility info is associated with the home device pool ofthe phone, the
phone is considered to be in its home location; Device Mobility will not reconfigure
the phone.

— Ifthe device mobility info isassociated with one ormore device pools other than the
home device pool ofthe phone, one ofthe associated device pools ischosen based
on a load-sharing algorithm (round robin).
• Ifthe current device pool is different from the home device pool, these checks arc
performed:

— Ifthe physical locations are not different, the configuration ofthe phone is not
modified.

— Ifthe physical locations are different, the roaming-sensilive parameters ofthe


current (that is. the roaming) device pool are applied.
— If(in addition to different physical locations) the device mobility groups are the
same, the Device Mobility-related settings are also applied (in addition to the
roaming-sensitive parameters).

Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0 >2010 Cisco Systems. Inc.
In summarv. the U.S. device mobility group consists oftwo physical locations: San Jose and
New York.'ln San Jose. IP subnets 10.1.1.0/24. 10.1.2.0/24. and 10.1.3.0/24 arc used: New
York uses IP subnet 10.3.1.0/24. and London is configured with IP subnet 10.10.1.0/24.
Basedon the IP address of an IP phone. Cisco Unified Communications Managercan
determine oneor more associated device pool or pools and the physical location anddevice
mobility group ofthe device pool orpools. Ifan IP phone uses an IP address ofIP subnet
10.1.3.6/24. there are two candidates for the device pool. However, inthis example, the
physical location and the device mobility group are the same for these two device pools.

>201D Cisco Systems, Inc. Implementation of Features and Applications for Multisite Deployments 4-13
Relationship of Device Mobility Configuration Elements
The figure illustrates how the Device Mobility configuration elements relate to each other.

Relationship of Device Mobility


Configuration Elements

1 SJ1 dmi SJ_A_ dp


(10 1.1 0/24) (Building A) c--.^
^ ^
i
!
SJ2_dmi SJ_B1_ dp _.*! SJ_pl j N

(10.1.2.0/24) (Buiding B) \ i (SJ-campus) I


s ,4\ US dmg !
/ Jr " • ~i s,,\ 1
i
i
SJ3 dmi sU SJ_B2_ dp
(10 1.3.0/24) (Building B)
i
* **
i
*
NY dmi mv r '
i
NY_dp
(10.3 1.0/24) j (NY-campus) j
i

W. .> _ •. _ _ _

LON dmi
LON_ dp —• LON_pl j i GB_dmg , i
(10.10.1.0/24) (LON-campus) j

.

Theexample in the figure shows five device mobility infos. They are configured as follows:
• SJl_dmi: The IP subnet of this device mobility info is 10.1.1.0/24. This device mobility
info is used at Building A of the San Jose campus and is associated with device pool
SJ_A_dp.

• SJ2_dmi: The IPsubnet of this device mobility info is 10.1.2.0/24. This device mobility-
info is used at Building Bof the San Jose campus and is associated with device pool
SJ_Bl^dp.

• SJ3_dmi: The IPsubnet of this device mobility info is 10.1.3.0/24. Like SJ2_dmi, this
device mobility info isused at Building Band isassociated with device pool SJ_Bl_dp. It
is also associated with devicepool SJ_B2_dp.
• NY_dmi: The IPsubnet ofthis device mobility info is 10.3.1.0/24. This device mobility
info is used at the New York campus and is associated with device pool NY _dp.
• LON_dmi: The IPsubnet of this device mobility info is 10.10.1.0/24. This device mobility
info is used atthe London campus and is associated with device pool LON_dp.
Device pools SJ_A_dp. SJ_B1 jjp. and SJ_B2_dp are configured with the same physical
location (SJ_pl) because they are used for devices that are located at the San Jose campus.
Device pool NY_dp. serving the New York campus, is configured with physical location
NY_pl. and device pool LON_dp, serving the London campus, isconfigured with physical
location LON_pI.
All device pools that are assigned with a U.S. physical location (that is, SJ_A_dp, SJ_Bl_dp,
SJ_B2_dp, and NYjJp) are configured with device mobility group US_dmg. This setting
means that all U.S. device pools are in the same device mobility group. The London campus is
in a different device mobility group: GB_dmg.

4-12 Implementing Cisco Unrfied Communications Manager, Part 2 (CIPT2) v8.0 »2010 Cisco Systems, Inc.
Device Mobility Configuration Elements
This topic describes the configuration elements that arc used by Device Mobility.

Configuration Element Functions

Configuration
Configuration Element Functon
Element Name

Defines a set of common characteristics for devices. The device


poolcontans onlydevice-and location-related information. One
device pool has to be assigned to each device.

Specifies an IP subnet and associates it withone or more device


Deuce MoNiy Info pools. Multiple device mobility inlos can be associated with one
device pool

Tliephysical location Is a teg assignedto one or moredevice


Physical Location pools.It is used io identify whethera deviceIs roaming wiSiin a
physicallocation or between physicallocations.
The device mobility group is a tag assigned to one or more
device pools. 11 is used lo identify whether a device is roaming
Device MoDdKy Group willnna device mobility group or between device mobility
groups

The table lists the Dev ice Mobility-related configuration elements and describes their function,
fhe newlv introduced elements arc device mobility infos, the physical location, and the device
mobility group.
The dev ice mobilitv info isconfigured with a name and an IP subnet and isassociated with one
ormore device pools. Multiple device mobility infos can be associated with the same device
pool.
The physical location and the device mobility group are just lags: they are configured with a
name onlv and do not include any other configuration settings. Both arc nonmandatory device
pool configuration parameters: tti3t is. at the device pool, no physical location or one physical
location and one (or no) device mobility group can be chosen. They are used todetermine
whether two device pools are at the same physical location and in the same device mobility
group.

& 20 10 Cisco Systems, Inc


Implementation ofFeatures and Applications for Multisite Deployments
Devi :e Mobility—Dynamic Configuration by Location-
Dependent Device Pools
This subtopic describes where location-dependent configuration is stored in the Cisco Unified
Communications Manager database and how the applicable set of parameters is chosen.

Device Mobility—Dynamic Configuration by


Location-Dependent Device Pools

Main Site Remote Site

Device Pool Remote


- Region
Local'on • Location
SRST Reference • SRST Reference
Device Motility CSS • Deuice Mobility CSS
AAR CSS • AAR CSS
MR Group • AAR Group

As shown in the figure, the location-dependent parameters (that is, roaming-sensitive settings
and Device Mobility-related settings)are configured at device pools. Basedon the IP subnet
that is used by the phone (which is associated with a device pool), Cisco Unified
Communications Manager canchoose the appropriate device pooland apply the location-
dependent parameters. With Device Mobility, Cisco Unified Communications Manager is
aware of the physical location of a device andapplies the appropriate location-specific
configuration by selectingthe corresponding device pool.

4-10 Implementing Cisco Unitied Communications Manager, Part2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc.
Note The physical location and device mobility group parameters are used to determine which
settings should be applied to a roaming phone (none, the roaming-sensitive settings only, or
the roaming-sensitive settings and the settings that are related to DeviceMobility). They are
not phone configuration parameters themselves, so therefore, they are not applied to the
phone configuration like the other listed roaming-sensitive settingsare. Theyare used only
at the decision to change the phone configuration and how to change it. Consequently, they
cannot be overlapping and are configurable only at device pools.

Local Route Group


Device Mobilitv -related settings

Device Mobilitv CSS

AAR CSS

— AAR Group
— Calling Party Iransformation CSS

Note All listed DeviceMobility-related settings are overlapping parameters, that is, they are
configurable at phones and at device pools. However, the Device Mobility CSSis called
CSS only inthe Phone Configuration window. Itis notoverlapping with the CSS that is
configured at the line level.

Roaming-sensitive settings are settings that do not have an impact oncall routing. Device
Mobilitv -related settings, however, may have animpact on call routing because they modify the
dev ice CSS. AAR group, and AAR CSS. Depending onthe implementation of Device
Mobilitv. roaming-sensitive settings only—or bolh roaming-sensitive settings and Device
Mobilitv -related settings—can be appliedto a roaming phone.
The GUI does not show the local route group in the roaming-sensitive settings pane.
Nevertheless, the local roule group is a roaming-sensitive setting and is updated when the
physical locations ofthe home device pool and the roaming device pool are different. The
called party transfoniiation CSS is shown in the Device Mobility-related settings pane ofthe
GUI. but this setting does not apply toIP phones and hence isno Device Mobility-related
m
setting, although shown as such in the GUI.

©2010 Cisco Systems. Inc Implementation otFeatures and Applications for Multisite Deployments
Device Mobility—Dynamic Phone Configuration Parameters
This subtopic shows the two types ofphone configuration parameters that can be dynamically
assigned by Device Mobility.

Device Mobility—Dynamic Phone


Configuration Parameters

Two types of phone settings can be applied by Device Mobility.


• Roaming-sensitive settings:
• Local Roule Group
- Date/Time Group
Region
SRST Reference
Media Resowce Group I iat
• Locat-oi!

- Netw:);k Locale
- Physical Locations
Device MobilityGroup
• Device mobility-related settings:
• Dew.e Mobihiy CSS
•V.RCRS
- A/.RGi^ir.
- L?.-ii':n,) Party Ti30»fi.imsai!O!i CSS

Device Mobilitv can reconfigure site-specific phone configuration parameters that are based on
the physical location ofthe phone. Device Mobility does not modify any user-specific phone
parameters or any IPphone button settings such as directory numbers.
The phone configuration parameters that can be dynamically applied todie device
configuration are grouped into two categories:
• Roaming-sensitive settings:
— Date/Time Group
— Region
— Location

Note The Date/Time Group, Region, and Location are configured at device pools only.
m

— Network Locale

— SRST Reference

— MRGL

Note The Network Locate, SRST Reference, and MRGL are overlapping parameters. That is, they
areconfigurable at phones and atdevice pools.

— Physical Location
— DeviceMobility Group

Implementing Cisco Unified Communications Manager, Pan 2(CIPT2) v8.0 ©2010CiscoSystems. Inc.
Device Mobility Overview
This topic describes the key characteristics and Icalures of Device Mobility.

Device Mobility Characteristics

• Device Mobility can be used in multisite environments with


centralized call processing,
• Device Mobility allows users to roam between sites with
their Cisco IP phones (typically, Cisco IP Communicator or
Cisco Unified Wireless phones).
• IP phones are assigned with a location-specific IPaddress
by DHCP.
• Cisco Unified Communications Manager determines the
physical location of theIPphone based on the IP address
used by the IP phone.
• Based on the physical location ofthe IP phone, the
appropriate device configuration is applied.

Dev ice Mobilitv can beused in multisite environments with centralized call processing. It
supports Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) Cisco IP
phones andCisco IP Communicator.
Dev ice Mobilitv allows users to roam between sites with their IP phones. Typically, these are
Cisco Unified Wireless IP phones or Cisco IP Communicator phones.
When the device is added to the network ofroaming sites, itis first assigned an IP address.
Because the IP networks are difTerent for each site. Cisco Unified Communications Manager
can detemiine the physical location of(he IP phone that is based on its IP address.
Based on the physical location ofthe IP phone. Cisco Unified Communications Manage:
reconfigures the IPphone with site-specific settings.

© 2Q10 Cisco Systems, Inc


Implementation ofFeatures and Applications for Multisite Deployments
Using Device Mobility to Solve Roaming Device Issues
Device Mobility offers functionality thatis designed to enhance themobility of devices within
an IP network.

Device Mobility Solves Issues of


Roaming Devices

Issue WithoutDevice Mobility Device Mobility Feature to Solve Hieissue


When mottle user moves to liferent location,
Cal Admission Control selings are not Location settiigs are dynamical? assigned.
adjusted.

PSTN gateways tone used are fixed. Dynamic phone CSS allows for site-Independent
local gateway access.
SRST reference is feed. SRST inference is flynamicaBy assigned.
When mobile user moves to efferent region,
codec settings are not adjusted. Region settings are dynamicallyassigned.

AAR does not work for mobile users. AAReating search space andAARflroup of
directorynumbers are dynamically assigned.
Media rescurces are assigned independent of
location. Meda resource listis dynamically assigned.
AAR causes Issues wih Cisco Extension Cisco Extension Mobtity also benefits from
Mobitty. dynamic assignment.

ITie device stil! registers with the same Cisco Unified Communications Manager cluster, but it
adapts some ofits behavior that is based on the actual site where itis located. Those changes
aretriggered by the IP subnet inwhich thephone is located. Thetable shows which issues are
solvedby Device Mobility.
Basically, all location-dependent parameters can be dynamically reconfigured by Device
Mobility. Thus, the phone keeps its user-specific configuration, such as directory number,
speed dials, and call-forwarding settings, but adapts location-specific settings like region,'
location, orSRST reference to the actual physical location. Device Mobility can also be
configured in such away that dial plan-related settings, such as the device calling search space
(CSS), AAR group, and AAR CSS, are modified.

4-6 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 »2010 Cisco Systems, Inc.
Issues with Roaming Devices
When phones move between different Cisco Unified Communications Manager sites, some
settings can become inaccurate.

Issues with Roaming Devices

Ifa user is moving between sites and is using a


phone:
• Location-dependent settings are set per phone (MAC).
• The physical device location is assumed to be constant.
• The constant settings become inaccurate:
Region
- Location
SRST reference
AAR group
- CSS
MRGs and MRGLs
Other settings

The configuration ofan IP phone includes personal settings and location-dependent settings
thai are all bound statically to the MAC address ofthe phone and hence to the device itself. The
phv sical dev ice location isassumed to be constant.
Ifa phone or. more likely, asoftphone is moved between sites, the location-dependent settings
become inaccurate. Some of these settings and theirerrors arcas follows:
•m
• Region: Might cause wrong codec settings
• Location: Might cause wrong Call Admission Control (CAC) and bandwidth settings
• Survivable Remote Site Telephony (SRST) reference: Might cause malfunction ofCisco
Linified SRS I
• Automated alternate routing (AAR) group: Might cause malfunction ofthe call
redirection on no bandwidth
• Calling search spaee (CSS): Might cause usage of remote gateways instead ofloeai
gateways
• Media Resource Groups (MRGs) and Media Resource Group Lists (MRGLs): Might
cause allocation ofwrong media resources, such as conference bridges oriranseoders
To maintain the correct settings. Cisco Unitied Communications Manager needs lo be aware of
the ph> sical location ofall phones, including moving devices.

© 2010 Cisco Systems. Inc


Implementation ofFeatures and Applications for Multisite Deployments
Issues with Devices Roaming Between Sites
This topic describes issues that occur when users roam between sites with their devices.

Roaming Devices

Device can be an IP phone or, more likely, a softphone (such as


Cisco IP Communicator) ofa roaming user.

Cisco
Unified
Com municatj oris
Remote
Manager
Gateway

•s. WAN

Roaming Device

When users roam between sites, they might take their phones with them. This situation
typically does not apply lo Cisco IP phones, but is very common with softphoncs such as Cist
IP Communicator orCisco Unified Wireless IP phones.

4-4
Implementing Cisco Unified Communications Manager. Part 2(CIPT2) V8.0 >2010 Cisco Systems, Inc.
Lesson 11

Implementing Device Mobility


Overview
St is common in multisite em ironments that some users roam between sites regularly. When
such users lake their Cisco Unified Communications endpoints, such as aCisco Lnified
Wireless IP Phone or Cisco IP Communicator (a softphone) phone, with them, the standard
configuration of their endpoints must be adapted to suit the needs ot the current physica
location. It is important that aprofessional unified communicalions system provides such a
solution.
This lesson describes Cisco Unified Communications Manager Device Mobility, afeature of
Cisco Unified Communications Manager that allows its endpoints lo be dynamically
reconfigured based on their actual location as determined by the IP address that is used bv the
device.

Objectives
Upon completing this lesson, you will be able to describe how Device Mobility works and how
it is implemented. This ability includes being able to meet these objectives:
Identify the issues with devices roaming between sites
Describe the Device Mobility feature
Describe the Device Mobility configuration elements and their interactions
Describe Device Mobility operation
Describe Device Mobility interaction with globalized call routing
Contigurc Device Mobility
ttfc

mm

4-2
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 >20f0 Cisco Systems, Inc.
Module 41

Implementation of Features
and Applications for Multisite
Deployments
Overview
Users in multisite environments often roam between sites. They cither take devices (such as a
Cisco Unified Wireless IP Phone or Cisco IP Communicator) with them or use guest phones at
the siles that they roam to.
This module describes Cisco Unified Communications Manager Device Mobility and Cisco
Extension Mobilitv and their implementation. The implementation provides users with the
freedom to roam and still be reachable bv their own extensions, no mailer where they are or
what dev ice thev use.

Module Objectives
Upon completing this module, you will be able to implement Device Mobility and Cisco
Fxtension Mobility. This ability includes being able to meet these objectives:
• Dcscnbc how Device Mobilitv works and how il is implemented
• Describe how Cisco Extension Mobility works and how il is implemented
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 )2010 Cisco Systems, Inc.
Monitoring Leamed Routes in Cisco Unified Communications Manager Express 5-57
CCD PSTN Backup—CSS jj-58
SRST Considerations J"^
CCD and Static Routing Integration Considerations £-bi
Cisco IOS SAF Client Considerations When Using Globalized Call Routing 5-b^
Solution for PSTN Backup Advertised in E.164 Format Without Leading + 5-63
TEHO Considerations ™
Trunk Considerations When Using Globalized Call Routing ^
Cisco Unified Communications Manager Clusters and CCD Configuration Modes 5-bb
Other SAF and CCD Considerations 5-67
„ d-oo
Summary _g8
References ,„
Module Summary 5]6g
References ,. -,.
Module Self-Check r~
Module Self-Check Answer Key

••c 2010 Cisco Systems. Inc


Implemenling Cisco Unified Communications Manager, Part 2(CIPT2) v8 0
Step 7b: Subscribe Phone to Cisco Extension Mobility Phone Service 4-67
Summary ~
References Tro
Module Summary 7™
References 71^
Module Self-Check Jy
Module Self-Check Answer Key 4"'4
Call Control Discovery . — 5~1
5-1
Overview
5-1
Module Objectives
Implementing SAF and CCD . $£
Objectives ^
SAF and CCD Overview 5-4
Dial Plan Scalability Issues in Large Networks 5-5
Scalable Dial Plan Solution for Large Networks 5"6
Call Control Discovery Overview 5-7
SAF Characteristics 5-8
SAF Client Types 5"9
SAF Message Components 5-10
SAF Routing Characteristics 5-11
SAF Neighbor Relationships 5"12
SAF Client and SAF Forwarder Functions 5-13
CCD Characteristics 5-14
CCD Characteristics 5-15
CCD Services in Cisco Unified Communications Manager 5-17
Processing Received Routes in Cisco Unified Communications Manager 5-19
CCD Operation 5_2|
CCD—Propagation of HQ Routes 5"22
CCD—Propagation of BR Routes 5-23
CCD—Call from HQ to BR 5-24
CCD—Link Failure at BR 5"25
CCD—Call from HQ to BR During Link Failure 5-26
SAF and CCD Implementation 5-28
External SAF Client Configuration Elements 5-3°
Relationship ofExternal SAF Client Configuration Elements 5-31
Internal SAF Client Configuration Elements 5-32
Relationships ofInternal SAF Client Configuration Elements 5-33
SAF Forwarder Configuration Procedure 5-34
Step1: Configure SAF Forwarder 5-35
Step2: Configure SAF Forwarder to Support External SAF Clients 5-36
External SAF Client Configuration Procedure 5-37
Step1: Configure SAF Security Profile 5-38
Step2: Configure SAF Forwarder 5-39
Step 3: Configure SAF Trunk 5-40
Step 4: Configure Hosted DN Group 5-41
Step 5: Configure Hosted DN Pattern 5-42
Step6: Configure CCD Advertising Service 5-43
Step 7: Configure CCD Requesting Service and Partition 5-44
Step 8: Configure CCD Blocked Leamed Patterns 5-45
Step 9: Configure CCD FeatureParameters 5-46
Internal SAFClient Configuration Procedure 5-48
Step 1: Configure Trunk Profile 5-49
Step 2: Configure Directory Number Blocks 5-50
Step 3: Configure Call Control Profile 5-51
Step 4: Configure Advertising Service 5-52
Step 5: Configure Requesting Service 5-53
Step 6: ConfigureVoIP Dial Peer 5-54
CCD Considerations 5-55
Monitoring Leamed Routes in Cisco Unified CommunicationsManager 5-56

ii ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)v8.0 © 2010 Cisco Systems, Inc.
Table of Contents
Volume 2

Implementation ofFeatures and Applications for Multisite Deployments ±1


mll Overview 4-1
Module Objectives 4-1
Implementing Device Mobilitv ___ 4.3
Objectives 4^
Issues with Devices Roaming Between Sites 4_4
m Issues with Roaming Devices 4_5
Using Device Mobility to Solve Roaming Device Issues 4_6
Device Mobility Overview 4_7
** Device Mobility—Dynamic PhoneConfiguration Parameters 4-8
Device Mobility—Dynamic Configuration by Location-Dependent Device Pools 4-10
^ Device Mobility Configuration Elements 4_11
Relationship of Device Mobility Configuration Elements 4-12
Device Mobility Operation 4_14
mm Device Mobility Operation: Flowchart 4_1g
Device Mobility Considerations 4^1 g
Device Mobility and Calling Search Spaces 4_20
**• Examples ofCall-Routing Paths Based on Device Mobility Groups and TEHO 4-22
Device Mobility Interaction with Globalized Call Routing 4_24
Advantages ofUsing Local Route Groups and Globalized Call Routing 4-26
mm Example: No Globalized Call Routing—Different Device Mobility Group 4-27
Example: No Globalized Call Routing—Same Device Mobility Group 4-28
mm Example: Globalized Call Routing 4_29
Device Mobility Configuration 4_30
Steps 1 and 2. Configure Physical Locations and Device Mobility Groups 4-31
ww Step 3: Configure Device Pools 4.32
Step 4. Configure Device Mobility Infos 4.33
Step 5a: Set the Device Mobility Mode Cisco CallManager Service Parameter 4-34
** Step 5b: Set the Device Mobility Mode for Individual Phones 4-35
Summary 4_3g
m
References 4.37
Implementing Cisco Extension Mobilitv 4.39
Objectives 4.39
Issues with Users Roaming Between Sites 4-40
Issues of Roaming Users 4-41
Cisco Extension Mobility Solves Issues of Roaming Users 4-42
Cisco Extension Mobility Overview 4-43
Cisco Extension Mobility: Dynamic Phone Configuration Parameters 4-45
Cisco Extension Mobility: Dynamic Phone Configuration by Device Profiles 4-46
Cisco Extension MobilityConfiguration Elements 4-47
Relationship of Cisco Extension Mobility Configuration Elements 4-49
Cisco Extension MobilityOperation 4-50
Issues in Environments with Different Phone Models 4-52
Default Device Profile and Feature Safe 4-53
How Cisco Extension Mobility Handles Phone Model Differences 4-54
Cisco Extension Mobility and CSSs 4-56
Alternatives for Mismatching Phone Models and CSS Implementations 4-57
Cisco Extension MobilityConfiguration 4-58
Step 1: Activate the Cisco Extension MobilityService 4-59
Step 2: Set Cisco Extension MobilityService Parameters 4-60
Step 3: Add the Cisco Extension MobilityPhone Service 4-61
Step 4: Create Default Device Profiles 4-62
Step 5a: Creale Device Profiles 4-63
Step 5b: Subscribe Device Profile to Cisco Extension Mobility Phone Service 4-64
Step 6: Associate Users with Device Profiles 4-65
Step 7a: Configure Phones for Cisco Extension Mobility 4-66
3-110 Implementing CiscoUnified Communications Manager. Part 2 (CiPT2) v8.0 ) 2010 Cisco Systems, Inc.
Module Self-Check Answer Key
QD D

Q2) A

Q-D B

Q4) C

05) D

06) B

Q-) Standard locations-based CAC docs nol allow tiic configuration of a dilTerenl limit per pair of locations.
Onh a tola! limit for all calls coming in to or going oul of a location can be configured.
Q8) B

Q9) B. [•

QIO) B

qui A

©2010 Cisco Systems, Inc. Bandwidth Management and CAC Implementation 3-109
Q7) What is alimitation ofstandard locations-based CAC? (Source: Implementing CAC)

Q8) Which statement is false about CAC when using RSVP-enabled locations? (Source:
Implementing CAC)
A) CAC adapts to the actual topology and considers network changes.
B) RSVP is used for CAC and toprovide QoS for each individual stream.
C) The RSVP agent to be used by aphone is determined by the Media Resource
Group Listof the phone.
D) The RSVP agent isconfigured as an MTP in Cisco Unified Communications
Manager.

09) AAR reroutes calls to the PSTN for which two types ofcalls? (Choose two.) (Source:
Implementing CAC)
A) calls rejected by an H.323 gatekeeper
B) calls rejected by standard location-based CAC
C) calls placed tounregistered phones
D) calls placed toa gateway that is busy
E) callsrejected by RSVP-enabled location-based CAC
F) calls rejected bySIPprecondition-based CAC
Q10) When using end-to-end RSVP with SIP preconditions, RSVP is used between the
originating and the terminating phone. (Source: Implementing CAC)
A) true
B) false

QII) How can calls that are rejected by an H.323 gatekeeper be rerouted by using adifferent
path? (Source: Implementing CAC)
A) by configuring route lists and route groups with backup devices
B) by putting the gatekeeper-controlled intercluster trunk or H.225 trunk into a
location that is set to unlimited
C) by configuring a second route pattern in the same partition that refers to a
backup device cannot be done, because AAR only supports internal calls

3-J08
implementing Cisco Unrfied Communications Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module Self-Check Answer Key.
Ql) Which feature does not conserve bandwidth in the IP WAN? (Source: Managing
Bandwidth)
A) RTP headercompression
B) low-bandwidth codecs
C) local media resources
D) quality of service
02) How can the bandwidth per call be limited in Cisco Unitied Communications
Manager? (Source: Managing Bandwidth)
A) b\ specifying the maximum permitted codec bandwidth between pairs of
regions
B) bv specifying the maximum permitted codec bandwidth between pairs ot
locations
C) by specifying the maximum bandwidth per stream with the bandwidth zone
local command
D) by specifying the maximum permitted codec bandwidth tor calls going out ot
or coming into a region
Q3) When dcploving local conference bridges at each site, what is the minimum number of
Media Resource Group Lists that arc required? (Source: Managing Bandwidth)
A) number ofsites *(number ofsites - l)/2
B) one per site
C) one per site and one per conference bridge
D) one
Q4> Which device requires access to Ihe transcoder from its Media Resource Group List
when transcoding is required for acall? (Source: Managing Bandwidth)
A) both endpoinls of the call
B) the callingdevice
C) ade% ice that supports only codecs that are not permitted tor the call
D) the called device
Q5) Which statement is true about multicasl MOI 1from branch router flash? (Source:
Managing Bandwidth)
A) Multicast MOH from branch router flash requires an SRST router to be in
fallback mode to work.
B) Multicast MOH from branch router flash can also be used tor unicast MOH.
C) The branch router supports G.711 and G.729 only for MOH.
D) Regions in Cisco Unified Communications Manager have to be configured in
such away that G.711 is allowed between the Cisco Unified Communications
Manager MOH server and the branch phones.
Q6) Which CAC-related feature applies to intercluster calls? (Source: Implementing CAC)
A) locations
B) H.323gatekeeper CAC
C) AAR
D) RSVP-enabled locations

Bandwidth Management and CAC Implementation 3-107


) 2010 Cisco Systems. Inc
3-106 implementing Cisco Unified Communicalions Manager, Par. 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Module Summary
This topic summarizes the key points that were discussed in this module.

Module Summary

• Cisco Unified Communications Manager supports several


features that reduce bandwidth requirements in multisite
environments.
* Cisco Unified Communications Manager CAC mechanisms
include locations, RSVP-enabled locations for calls within a
cluster, RSVP-enabled locations for calls through SIP trunks,
and H.323 gatekeeper-based CAC.

This module described the available design options and features that are recommended tor
deplovment in amultisite environment in order to reduce bandwidth requirements mthe II
WAN The module also described the different ways of implementing Call Admission Contro
(C \C) within acluster and beyond cluster boundaries. Finally, the module explained how calls
can be rerouted over the public switched telephone network (PSTN) ifthere is insufficient
bandwidth.

References
For additional infomiation. refer to these resources:
• Cisco Svstems. Inc. Cisco Unified Communications System 8.x SRMX April 2010.
http-,'Uuw.cisco.c<>iii'cii/"US/docs.'\oicejp_.co.nin/cucm/snid/8x/uc8x.htinl
• Cisco Systems. Inc. Cisco Unified Communications Manager Administration Guide
Release 8.0/1). February 2010. _
lmp:/^vNu.asco.coni/en.'l.S.'doc>.\oicc_ip_comin/cuem/ailn.m/8 O.J/ecmdg.bccm-801-
cm.html
• Cisco Svstems Inc. Cisco Unified SRSTSystem Administrator Guide, December 2007.
IUtp:.vw;w.cisco.coni/eivUS/partner/docs/voice ip^onitn/aisrst/adtnin/srst/configurtmc.,..
guide srr.lsa.hlml
. Cisco Svstems. Inc. Cisco IOS H.323 Configuration Guide Release 15.0- Configuring
H3"3 Gatekeepers and Proxies. February 2008. October 2009.
lu.p. x,uxv.cisco.co,n.cn/US/partner/docs/.os/voice/l,323/conngu,-at.on/gu,dc.vh.h32, gk
config psl05'Jt TSD Products Configuration Guide.Chupler.lilm!

Bandwidth Management and CAC Implementation 3-105


) 2010 Cisco Systems. Inc
Summary
This topic summarizes the key points that were discussedin this lesson.

Summary

• CAC limits the number ofcalls in order to avoid voice quality


issuescaused bybandwidth oversubscription due totoomany
voice calls.

• Cisco Unified Communications Managerlocations can be used


for CAC within a Cisco Unified Communications Manager
cluster that has a hub-and-spoke topology.
1Cisco Unified Communications Manager RSVP-enabled
locations provide topology-aware CAC between RSVP agents.
AAR allows calls that were denied by locations-based CAC to
be rerouted over the PSTN.
SIP Preconditions allows calls between clusters toflow through
dedicated routers.
H.323 gatekeepers can provideCAC on Cisco Unified
Communications Manager H.323 trunks.

References
For additional information, refer to these resources:
• Cisco Systems, Inc. Cisco Unified Communications System 8.x SRND, April 2010.
http:/Avuu.cisco.com/en/US/docs/voice_ip .coinm/cticm/srnd/8N/uc8\.himl
• Cisco Systems, Inc. Cisco Unified Communications Manager Administration Guide
Release 8.0(1), February 2010.
h!tp:/Av\u\.cisco.c(>m/enAJS/doLVvoicc_ip_comnVcucin/admin/8_0_l/ccmcfe/bccni-80I-
em.html

• Cisco Systems, Inc. Cisco IOS H.323 Configuration Guide Release 15.0 - Configuring
H323Gatekeepers and Proxies, February 2008, October 2009.
http://\\u^.cisco.com/en/L!S/partner/docs/ios/voicc/h323/coniiguration/guidc/vh_h323 gk
contIg_psl059i_TSD_Products_Connguration_Guide_Chapter.html

3-104 Implementing Cisco Unified Communications Manager. Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Note The command syntax and a sample configuration were shown earlier in this topic.

To provide backup paths for the gatekeeper-controlled trunk, perform this step:
Step 1 Add PSTN gateways lo route groups, and add these gateways to the route lists that
are using the gatekeeper-controlled trunks.

Note You configured PSTN backup in earlier lab activities ofthis course

Bandwidth Management andCAC Implementation 3-103


© 2010 Cisco Systems. Inc
Configuration Procedure for Implementing H.323 Gatekeeper-
Controlled Trunks with CAC
The figure shows the required steps for implementing gatekeeper-controlled trunks for call
routing only. It also shows you how to add gatekeeper CAC functionality and how to provide a
backup pathfor the gatekeeper-controlled trunk.

Configuration Procedure for


Implementing H.323 Gatekeeper-
Controlled Trunks with CAC
Implement gatekeeper-controlled trunks:
1 Configure gatekeeper (Cisco IOS router) for call routing.
2. Add gatekeeper to Cisco Unified Communications Manager.
3 Add and configure gatekeeper-controlled trunk (gatekeeper-
controlled intercluster trunk or H.225 trunk) inCisco Unified
Communications Manager.
4 Configure route patterns, routelist, and route group pointinq to
gatekeeper-controlled trunk.

Implement gatekeeper CAC:


• Configure gatekeeper (Cisco IOS router) for CAC.
Provide PSTN backup for gatekeeper-controlled trunk;
• Modify route list and route groups to provide a PSTN backup
path for the gatekeeper-controlled trunk.

To implement gatekeeper-controlled trunks, perform these steps:


Step 1 Enable gatekeeper functionality at aCisco IOS router and configure the gatekeeper
for call routing. This configuration typically includes zones, zone prefixes, and the
default technology prefix.

Note
More information about gatekeeper configuration is provided in the Implementing Cisco
Voice Communications and QoS (CVOICE) course.

Step 2 Add the gatekeeper to Cisco Unified Communications Manager.


Step 3 Add the gatekeeper-controlled trunk (either agatekeeper-controlled intercluster
trunk or an H.225 trunk) to Cisco Unified Communications Manager, and configure
the trunk. ' &

Step 4 Configure route groups, route lists, and route patterns in order to route calls that
match acertain route pattern (for example, 9.5[l2][l2].„ , for the examples that
were shown earlier in this topic) tothe gatekeeper-controlled trunk.
Note
You performed the last three steps of the preceding procedure in earlier lab activities of this
course.

To implement gatekeeper-controlled CAC, perform ihis step:


Step 1 Configure the Cisco IOS gatekeeper with bandwidth commands to enable bandwidth
imitations (typically required only for interzone calls).
limitations (tvniYallv rpni n r**H rmlw frt- :«<^ -~n .^

3-102 Implementing Cisco Unified Communicalions Manager, Part 2(CIPT2) v8.0 ©2010 Cisco Systems, Inc.
Note For a PSTN backup, you need to perform digit manipulation msuch away that the calling
number and (more importantly) the called number are transformed to always suit the needs
of the device that isactually used. This transformation can be done atthe route list, where
digit manipulation can be configured per route group. In the example, the called number 91
511 555-1234 has to bechanged to a 10-digit number for the H.225 trunk, because the
gatekeeper is configured with area code prefixes without the long distance 1 The called
number must also bechanged to an11 -digit number if rerouting the call to the PSTN
gateway is necessary. Abetter solution would be using global transformations atthe egress
devices (H 225 trunk and PSTN gateways). In a large multisite environment or in an
international deployment, the implementation of globalized call routing would be the best
solution

Bandwidth Management andCAC Implementation 3-101


© 2010 Cisco Systems, Inc.
Providing PSTN Backup for Calls Rejected by CAC
This subtopic describes how backup paths can beprovided for calls that are rejected by a
gatekeeper because of CAC.

Providing PSTN Backup for Calls


Rejected by CAC

Route lists and route groups provide backup paths if the


preferred path fails. In the example, ifthe calls cannot be
established over the H.225 trunk because of CAC, the calls use
the PSTN gateway (HQ-1) as backup.
Cisco Unified Ccmmmieaiors Ci sco Un ified C om mu n ica t ions
Manager Cluster Manager Cluster
PSTN Prefixes 511.521 PSTN Prefixes: 512, 522
HQ-1

Route Pattern:
9.15112J2XXXXXXX
Route Group. H.225 Trunk. Clusterl

Route Group PS I N Gateway HQ-1

A call that is placed to a gateway or a trunk can fail for many reasons:
• The appropriate device can be down. Timeouts occur when a call isplaced toan H.323
gateway, when an ARQ message issent toan H.323 gatekeeper, orwhen keepalive
messages are notexchanged with an MGCP gateway.
• Communication problems can occur with the gateway. H.323 messages can be sent tothe
IP address of thewrong interface. Gatekeeper registration can fail because of an invalid
zone name orbecause the call isrejected due toa lack ofresources. Acall might be
rejected when no channel is available on an EI or Tl trunk, when an administratively
configured limit ofcalls isreached atadial peer, orwhen a call isdenied by CAC.
Cisco Unified Communications Manager uses the same backup method—route lists and route
groups—for all ofthese types ofcall failures. Ifthe currently attempted device ofaroute group
cannot extend the call (for whatever reason), Cisco Unified Communications Manager will try
the next device according to the route group and route list configuration.
Therefore, providing abackup for calls that have been rejected due to H.323 gatekeeper CAC is
as simple as having aroute list and route groups that prefer the gatekeeper-controlled trunk
overoneor more PSTN gateways. If thecall cannot besetup overthe trunk, Cisco Unified
Communications Manager will reroute the call to the PSTN gateways. Instead ofreferring to a
dedicated PSTN gateway that should be used as abackup, the local route group feature can be
used.

3-100 Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 52010 Cisco Systems, Inc.
The maximum audio bandwidth is limited to 64 kb/s. Calls requiring more bandwidth {for
media such as wideband audio codecs or video calls with a video call bandwidth of more
than 64 kb/s) are not permitted in any zone.
Thetotal of all calls(interzone andintrazone calls) in zone ClusterB must notexceed 688
kb/s. As anexample, ibis configuration allows three G.729 calls to ClustcrA (three times
twice the codec bandwidth of 8 kb/s) and five G.711 calls within ClusterB (five times twice
the audiocodec bandwidth of 64 kb/s). Intrazone calls in zone ClusterA are unlimited.

Note Some ofthe bandwidth commands inthe example are forillustration only andare not useful
inthis scenario. Forexample, youcould change the bandwidth interzone default 64
command to bandwidth interzone ClusterA 64 because interzone default appliesonly to
zone ClusterA; zone ClusterB is explicitly configured, and no other zones exist. Furthermore,
intrazone limitations have been configured but would never apply inthis scenario. The
reason is that all calls are interzone calls.Thegatekeeper is used only forintercluster calls,
and the two clusters are in different zones.

mm

Bandwidth Management and CAC Implementation 3-99


©2C1Q Cisco Systems. Inc
Example: H.323 Gatekeeper Also Used for CAC
The figure shows an example ofaCisco IOS H.323 gatekeeper that has CAC enabled.

Example: H.323 Gatekeeper Also Used


for CAC

Cisco Unified Communications


Cisco Unified Communications
Manager Cluster
Manager Cluster
PSTN Prefixes 511.521
PSTN Prefixes 512,522

192.168.3.254
10.1 1.1
pow Trunk: Cluster^ ^mm^ Ji.225 Trunk: CL-^ 10.1.1.1

gatekeeper
ions local ClusterA lab.ccm 192.168.3.254 10.2.1 2
10.1.1 2
ions local ClusterB lab.cm 192.169.3.254
•one prefn ClusterA 511-
H 225 Trunk'Clusterl
lone prefix ClusterA 521" H.225 Trunk; Cluster2
DeviceType. Gateway
ions prefin ClusterB 513« DeviceType.Gatenvay
Zone ClusterA
rone prefix ClusterB 522* Zone1 ClusterB
Technology Prefix Mr
bandwidth interzone default a Technology Prefix: Mr
GK 192 158 3 254
bandwidth intertone sons CI ustsrB IS GK 192.168 3.254
bandwidth session default 128
bandw4.dth total zone ClusterB 688
9"-type-prefix lt« default- technology
no shutdown

The example is based on the previously illustrated example, but now the H.323 gatekeeper also
performs CAC.

The bandwidth interzone default 64 command specifies that 64 kb/s is permitted for calls
going out of and coming into azone. Because no specific zone is specified but the keyword
default is used, this setting applies to all zones that are not explicitly configured with a
different setting.

The bandwidth interzone zone ClusterB 48 command specifics that the previously configured
default interzone bandwidth limit should not apply to ClusterB but that ClusterB should instead
be limited to 48 kb/s.

The bandwidth session default 128 command limits the bandwidth to be used per call to a
codec that does not require more than 64 kb/s (for example, G.711 or G729) Because no
d.fferent session bandwidth is configured for any specific zone, this default applies to all zones.
The bandwidth total zone ClusterB 688 command limits all calls of ClusterB (that is calls
within the cluster and intercluster calls) to atotal of688 kb/s. Because there is neither a
bandwidth total default command nor aspecific bandwidth total command for ClusterA
ClusterA has nototal limit applied.
IfG.729 is used for inter/one calls and G.711 is used for intrazone calls, this configuration
effectively would permit these limitations:
> There can be amaximum of three G.729 calls between ClusterA and ClusterB because
CusterB is limited to 48 kb/s (that is, three times twice the codec bandwidth of8kb/s)
ClusterA could have four G.729 calls to other zones. However, because the example shows
only two zones and the other zone (ClusterB) is limited to three G.729 calls ClusterA will
never beable to use thepermitted interzone bandwidth.

3-98
Implemenling Cisco Unified Communications Manager, Part 2(CIPT2) v8.0
©2010 Cisco Systems, Inc.
Bandwidth limitations are configured differently on different Cisco products and for different
features. The table summarizes how to configure bandwidth limitations in Cisco Unified
Communications Manager.

Cisco Unified Cisco IOS H.323


Cisco Unitied
Communications Communications Gatekeeper

Manager Manager

Region Location

Audio codec bit rate + Twice the audio codec


Audio-Only Call Audio codec only
Configuration Layer3 overhead bit rate

80 kb/s 128 kb/s


Example: G 711 Call G.711

Video call speed Twice the video call


Video Call Audio codec and video
call speed speed
Configuration
384 kb/s 768 kb/s
Example 384-kb/s G.711 and 384 kb/s
Video Call

Note
Video calls have not been discussed in this course but are also shown for completeness.

Bandwidth Management and CAC Implementation 3-97


;010 Cisco Systems, Inc
Using an H.323 Gatekeeper for CAC
To use an H.323 gatekeeper for CAC, you have to configure bandwidth limitations, as shown
the figure.

Using an H.323 Gatekeeper for CAC


router(config-gk)#
bandwidth {interzone | total | session}
{default | zone zone-name} bandwidth-size
1Sets the maximum bandwidth (in kb/s) permitted per zone (or the
H
default for all zones not explicitly configured):
• interzone: Applies to all calls coming into and going out of the
specified zone (interzone calls)
- total: Applies toall calls in the specified zone (interzone and
intrazone calls)
• session: Applies toeach call in thespecified zone (specifies
the maximum bandwidth per call)
Bandwidth ofa call is twice the bandwidth ofthe audio codec:
- G.711:128 kb/s
• G.729: 16 kb/s

In Cisco IOS Software, you implement H.323 gatekeeper CAC by using the bandwidth
command.

bandwidth Command Parameters

Syntax Description

interzone Specifies the total amount of bandwidth for H.323 traffic from the zone to any
other zone. '

total
Specifies the total amount ofbandwidth for H.323 traffic that isallowed in the
zone.

session
Specifies the maximum bandwidth that isallowed for a session in the zone
default Specifies the default value for all zones.
zone
Specifies a particular zone.
zone-name Names the particular zone
bandwidth-size Maximum bandwidth. For interzone and total, the range isfrom 1to
10,000,000 kb/s. For session, therange isfrom 1to 5000 kb/s.

The bandwidth that is calculated per call is twice the bandwidth of the audio codec AG729
call consumes 16 kb/s of the configured bandwidth, and a G.711 call consumes 128 kb/s of
the configured bandwidth.

3-96
Implementing Cisco Unified Communicalions Manager, Part 2(CIPT2) vB.O >2010 Cisco Systems, Inc.
Thev all use different H.323 IDs because different trunk names have been contigured in the two
clusters and because Cisco Unified Communications Manager adds the _1 and _2 to the trunk
name to uniquely identify the call-processing servers per cluster.
Note If the same trunk name was configured in the two clusters, registrations would fail because
ofduplicate H.323 IDs.

The call-processing servers of ClusterA registered in /one ClusterA. and the call-processing
servers of ClusterB registered in zone ClusterB. You can verify this situation by using the
command show gatekeeper endpoints. All endpoints are registered with the prefix 1# which
is configured to be the default technology prefix. You can verify this situation by using the
command show gatekeeper gw-type prefix. The output of these two commands is shown m
one table in the figure.

Note For more information regarding gatekeeper configuration and operation, refer to the
Implementing Cisco Voice Communications and QoS (CVOICE) course. ____

Ifthe gatekeeper receives an Admission Request (ARQ) message from one ofthe H.323
aatewavs (a call-processing Cisco Unified Communications server, in this case), it looks up its
call-routing table (list of configured /one prefixes) to find out in which /.one the requested
prefix can be found.
You can verifv the list of configured prefixes and their /ones by using the command show-
gatekeeper zone prefix.
If an ARQ message was sent from 10.1.1.1 to the gatekeeper that requests acall to
512555P34 the gatekeeper will determine that the call has to be routed to zone ClusterB. Inc
onlv prefix that is reg.stered by gateways in this zone is 1#*. which is the default technology
prefix and is registered bv 10.2.1.1 and 10.2.1.2. Therefore, the gatekeeper chooses one of these
two eatcwa% s(in round-robin fashion) to be the terminating gateway. It will inform the
originating gatewav (the call-processing server ofClusterB that sent the ARQ message) to set
up an 11.323 call with the determined terminating gateway (10.2.1.1 or 10.2.1.2).
Note At this point, the gatekeeper is configured only to perform call-routing address resolution. It
resolves adialed number to the IP address where the call has to be routed. No CAC is
performed by the gatekeeper in this example

Bandwidth Management and CAC Implementation 3-95


j 2010 Cisco Systems, Inc.
Example: H.323 Gatekeeper Used for Call Routing (Address
Resolution) Only
The figure shows an example for gatekeeper-controlled trunks in adistributed Cisco Unified
Communications Manager deployment.

Example: H.323 Gatekeeper Used for


Call Routing (Address Resolution) Only
Cisco UnrfiedCommunications i-i,™ 11„-« .. r-
u„„,„ r-,
Manager .
Cluster Cisco Unified
,,, Communications
„, .
PSTN Pr*« 511.52, PSTN pXe"'512^22
192.168.3.254
101 11 -" H.225Trur^Clus^ ^ ^ J^Tn** C,uste/2 10.2.1.1

gatekeeper
zone local ClusterA lab.con
zone local ClusterB lab.com 10.2.1.2
10.1.1.2
zona prefix ClusterA 511*
H 225 Trunk Clusleri zone prefix ClusterA 521-
zone prefix ClusterB 512* H.225 Trunk: Cluster2
DeviceType Galeway DeviceType. Gateway
Zone CluslerA zone prefix CluaterB 522*
Zone: ClusterB
Technology Prefix If g»-type-prefix 1#« default-technology
no shutdown
Technology Prefix MT
GK. 192168.3254 GK. 192 16S.3.254
GATEKEEPER BKDPOINT HEGISTRATIOH
H323-ID IPAddr ZonaName Type Prefii
Clusterll 10.1.1.1 ClusterA VOIP-GW 1#*
Clusterl_2 10.1.1.2 ClusterA VOIP-GW 1#'
Cluster2_l 10.2.1.1 ClusterB VOIP-GW If
ClusterJ_2 10.2.1.2 ClusterB VOIP-GW 1#*

In the example, two Cisco Unified Communications Manager clusters arc shown Each cluster
hasan H.225 trunk configured.
The 11.225 trunks use different names per cluster in order to keep the H323 IDs unique
ClusterA uses Clusterl. and ClusterB uses Cluster2. In each cluster, there are two call-
processing nodes (10.1.1.1 and 10.1.1.2 in ClusterA, and 10.2.1.1 and 10.2.1.2 in ClusterB).
The trunk in ClusterA with the name Clusterl is configured with zone ClusterA and technology
prefix 1# . The trunk in ClusterB with the name Cluster2 is configured with zone ClusterB and"
mVITi6^!??010^ PrCfiX ('**}" B°th tnmks refer t0 **1P address oUhc sa™ gatekeeper:
I yl. 168.3.254.

The gatekeeper has two local zones: ClusterA and ClusterB. It is configured to route calls to
prefixes 511 and 521 to zone ClusterA, and calls to prefixes 512 and 522 to zone ClusterB In
addition, the gatekeeper is configured to use 1#* as the default technology prefix 'fhat is calls
to prefixes for which the gatekeeper does not know which gateway to use are routed to the
gateway orgateways that registered a technology prefix of I#*).
This gateway configuration means that the gatekeeper will have four gateways registered:
' Manager
MUSterL^*Group
WhiCuthatfS isconfigured
tHe ^ cal|-Processing server of the Cisco Unified Communications
in the device pool ofthe trunk
• Cluster ]_2. which is the second call-processing .server ofClusterA
• Thetwo call-processing servers of ClusterB

3-94
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) vB.O ©2010 Cisco Systems, inc.
Note The H.323 ID has to be unique. Cisco Unified Communications Manager keeps the H.323 ID
that is used by the members of acluster unique by adding the individual ending _x
Furthermore because Cisco Unified Communications Manager does not allow multiple
trunks to use the same name, no duplicate H.323 IDs can be presented to the gatekeeper
from a duster However, if the same trunk name is configured in multiple clusters, the call-
processing servers of two or more clusters will try to register with the same H.323 ID. The
gatekeeper will not allow these duplicate H.323 IDs to register, so the trunk will not be
operational Therefore, it is important to use unique trunk names across all Cisco Unified
Communications Manager clusters that register with a gatekeeper. _

II 323 zone: H323 zones are used to group devices. You perform call routing and CAC
based on these /ones. For instance, you could configure aso-called detault technology
prefix per zone that identifies the gateway (or gateways) to which calls should be routed
when the gatekeeper does not know which gateway to use. Also. CAC can be configured
differentlv for calls within a zone versus interzone calls.

Note The H323 zone name that is configured at the gatekeeper-controlled trunk is case-sensitive
and hastoexist atthe gatekeeper ^ __

• Technology prefix: H.323 gateways (including Cisco Unified Communications Manager)


can register prefixes (that is. number ranges that they can route calls to) at the gatekeeper.
The prefix can consist onlv ofnumbers (for example. 511). or it can include atechnology
prefix (such as IM. 2#. and so on). One way of using an H.323 technology prefix is tor a
»atewav to indicate the services that it provides by specifying an appropriate technology
prefix ('for instance. 1* for voice services, 2* for fax services, and so on). Calls that include
the technology prefix in their numbers (for example, acall that is placed to 1*5115551000)
can be muted'to the gateway in the zone that registered the appropriate technology prefix.
\s mentioned earlier, agatekeeper can be configured to route calls-for which it does not
know which gateway to use-to the gateway or gateways that register with aprefix that is
configured to be the default technology. For example, if there is only one Cisco Unified
Communications Manager cluster registering per zone, you can configure the trunk in each
cluster with atechnology prefix of 1*#. and configure the gatekeeper lo send all calls to the
gateway that registered with the configured default technology prefix (1*# in this case).
The eat'ekeeper needs onlv aconfiguration ofnumber prefixes (which number to find in
which /one). When the outgoing zone is determined, the gatekeeper just sends the call to
one of the gateuaj s(Cisco Unified Communications Manager systems) that registered in
the zone with the default technology prefix.

Note More information about how agatekeeper routes calls is provided in the Implementing Cisco
Voice Communications and QoS (CVOICE) course. _

Bandwidth Management and CAC Implementation 3-93


©;010 Cisco Systems. Inc
H.323 Gatekeeper CAC
This topic describes 11.323 gatekeeper CAC support in Cisco Unified Communications
Manager.

Cisco Unified Communications


Manager Support for H.323 Gatekeepers

Cisco Unified Communications Manager supports H.323


gatekeeper networks using:
• Gatekeeper-controlled intercluster trunk
- To be used with Cisco CallManager versions earlier than v3.2
• H.225 trunk
- To be used with Cisco CallManager v3.2 or later, Cisco Unified
Communications Manager, and all other H.323 devices
Trunks register with gatekeeper and provide the following
information:
• Type of device (Usually, Cisco Unified Communications Manager
registers as gateway.)
• H.323 IDof trunk is built from trunk name (plus _x, where x is a
number that identifies each call-processing server in cluster).
• H.323 zone.
• Technology prefix.

Cisco Unified Communications Manager can connect to other Cisco Unified Communications
Manager clusters or to any other H.323 devices via H.323 trunks. H.323 trunks can be
configured on their own—without the use of a gatekeeper for address resolution and CAC—or
as gatekeeper-controlled trunks. You can configure two gatekeeper-controlled trunks in Cisco
Unified Communications Manager:
• Gatekeeper-controlled intercluster trunk: This trunk is used to connect to Cisco
CallManager versions earlier than 3.2.
• H.225 trunk: This trunk can be used to connect to Cisco Unified Communications
Manager Version 3.2 or later and to all other H.323 devices. The H.225 trunk features a
peer discovery mechanism and hence can identify the device that is located at the other end
of the trunk and use the appropriate feature set.

A Cisco Unified Communications Manager gatekeeper-controlled trunk usually registers as an


H.323 gateway with the gatekeeper. Alternatively, it can beconfigured to register asa H.323
terminal. When a trunk isregistered. Cisco Unified Communications Manager provides this
information to the gatekeeper:
• H.323 device type: Thedevice typecan be eithergateway or terminal. Cisco Unified
Communications Manager isusually configured to register asa gateway.
• H.323 ID: The H.323 ID isbased on the name of the trunk that isconfigured inCisco
Unified Communications Manager with the string jr at theend. Thex is a number that
uniquely identifies each call-processing server of the cluster (that is,Cisco Unified
Communications Manager servers where Cisco CallManager service isactivated) that is
listed in the device pool that is assigned to the trunk.

3-92 Implementing Cisco Unitied Communications Manager. Part2 (CIPT2) vB.O 12010 Cisco Systems, Inc.
Step 2b: Apply SIP Profile to Trunk
The figure shows you how to applv the previously configured SIP profile to a trunk.

Step 2b: Apply SIP Profile to Trunk

trunk LonlquHlun ^^^^^B

;tr.-^i;- iOi'tis i-,g


Apply SIP Profile.
n 4 .L --_

fl--!lei!=;^'.:».C.Jc-.' ':iul«» j
jr "
:..,ln-(i,-:u5* ii*r3j (1 P tara g-cw: / r
;:=-Tj-kS«:u--. f-tfw' --'IMSele;tM •- /jr V

*-•«!... C*l 'j5M-f5|U ' '.cr- j ^^^ **

-_• 3' ? sl3j ;;'V 13ls-3'«•--* Ipi e . i,™ -. Jf .

5„ = sc=.t£ECa i-j5.»'=-!«:! - •,;-= - y' V

---; ;,-•„.' r~i'j.f"*:oi>dsio'-s , v

^^jr, K-.f-

At the SIP trunk, set the SIP profileto the profilethat you createdearlier.
When the RSVP OverSIPparameter of the SIPprofile is set to Local QoS, or fall back to local
RSVP is enabled at the SIP profile, the SIP trunk needs to have an MRGL assigned sothatit
can allocate an RSVP agent for intracluster RSVP-enabled CAC. You can setthe MRGL
directK at the SIP trunk configuration page. If it is notsetat the trunk, you must setthe MRGL
at the device pool that is applied to the SIP trunk.

Bandwidth Managementand CAC Implementation 3-91


© 2010 Cisco Systems. Inc.
Step 2a: Configure SIP Profile
The figure shows how to configure SIP Preconditions settings at a SIP profile.

Step 2a: Configure SIP Profile

Chocse E2E from


Check the checkbox
to allowfatlbackto
the drop-down
local RSVP list.

Tuinl Specific Confi»

Re'mjtt l-KcmiT Trjnkbasedon' jpkever


RSVP Over SIP"

W Fill back Lclocal B5VP


SIP P.e ll XX Onboii" Send PRACK f l . i Contains SDP

SetSIPRellXXOptbns
to Send PRACKif Ixx
Contains SDP

The necessary configuration for SIP Preconditions is applied to SIP trunks via SIP profiles. At
the SIP profile, you have to set the SIP RellXX Options parameter to Send PRACK if Ixx
Contains SDP.

Then you have to set RSVPOver SIP to E2E (end-to-end) whenyou want to enable SIP
Preconditions. If you want the trunk to use local QoS only, you wouldset the parameter to
Local QoS instead of to E2E.

WhenSIP Preconditions is configured (RSVPOver SIP is set to E2E),you can check the check
box fall back to local RSVP. This option allows a fallback to local QoS if the far end does not
support SIP Preconditions. If SIP Preconditions is supported by the far end and the RSVP
reservation fails, there is no fallback to local RSVP.

Note When the other side ofthe SIPtrunk is CiscoUnified Communications Manager, there will
never be a fallback to local RSVP. SIP Preconditions is never considered to be unsupported
between two Cisco Unified Communications Manager clusters, regardless whether it has
been enabled at the other side or not. As a consequence SIP Preconditions always fails and
never falls back to local RSVP in such a scenario.

When the other side of the SIP trunk is Cisco IOS device—for example, Cisco Unified
Communications Manager Express—and end-to-end RSVP is not enabled at that remote
router, then a fallback to local RSVP is performed, if configured at the local Cisco Unified
Communications Manager cluster. Ifend-to-end RSVP is not configured on a Cisco IOS
device, SIP Preconditions is considered to be unsupported and therefore local fallback is
possible.

3-90 Implementing CiscoUnified Communications Manager, Part 2 (CIPT2) v8.0 12010 Cisco Systems, Inc.
SIP Preconditions Configuration Procedure
This subtopic describes the SIP Preconditions configuration procedure.

SIP Preconditions Configuration


Procedure

! Follow standard procedure of RSVP-enabled locations.


a Configure RSVP service parameters.
b Configure RSVP agents in Cisco IOS Software.
o Add RSVP agents to Cisco Unified Communications
Manager.
d Enable RSVP between location pairs.
e Configure Media Resource Groups.
f Configure Media Resource Group Lists.
g Assign Media Resource Group Lists to devices.
2 Configure SIP profileand apply SIP profile to trunk.

The configuration for SIP Preconditions is identical to theconfiguration of RSVP-enabled


locations. In addition to thestepsrequired for RSVP-enabled locations, youhave to configure
the SIP trunks that should use SIP Preconditions for end-to-end QoS.

Note The RSVP agentthatis associated with the IPphone is usedfor the call leg to the far-end
SIP device. IfQoS fallback is not enabled, the SIP trunkwill never allocate an RSVPagent.

IfQoS fallback mode is enabled, two local RSVP agents are required in a fallback scenario:
one forthe IP phone and one forthe SIP trunk. Therefore, the MRGL at the SIP trunk is
required only for QoS fallback mode orfor when theSIP trunk is not configured for SIP
Preconditions at all but is configured to use local QoS.

Thefirst configuration step was described earlier inthe lesson and is notdescribed again.
Refer to the"Configuration Procedure for Implementing RSVP-Enabled Locations-Based
CAC" subtopic inthis lesson for a description of Step 1.

© 2010 Cisco Systems. Inc


Bandwidth Management and CAC Implementation
• When preconditions fail on the far end, QoS fallback has no effect. Consequently, the call
continues without RSVP when the RSVP policy is Optional (Video Desired), and the call
fails when the RSVP policy is either Mandatory or Mandatory (Video Desired).
• When receiving an INVITE with no preconditions and QoS fallback is off, the call fails
when the RSVP policy is Mandatory or Mandatory (Video Desired). When the RSVP
policy is Optional (Video Desired), the call continues without RSVP.
• When receiving an INVITE with no preconditions and QoS fallback is on, the configured
RSVP policy is applied to local RSVP.
• When receiving an INVITE with preconditions, and local QoS (instead of SIP
Preconditions) is configured at the receiving SIP trunk, the call fails when the received
RSVP policy is Mandatory. If the received RSVP policy is Optional and the local policy is
No Reservation, the call proceeds with no RSVP. If the received RSVP policy is Optional,
the locally configured policy is applied to local QoS.

If QoS fallback or local QoS configuration, the policies that are applied to local QoS are
managed the same way that they are managed for intracluster calls with RSVP-enabled
locations.

3-88 lrr.p)ementmg Cisco Unified Communications Manager, Part2 (CIPT2) v8.0 ©2010Cisco Systems, Inc.
Fallback from End-to-End RSVP to Local RSVP
This subtopic describes the fallback mechanism from end-lo-end RSVP to local RSVP when
the far end of the SIP trunk does not support SIP Preconditions,

Fallback from End-to-End RSVP to


Local RSVP

QoS fallback can be enabled to use local RSVP instead


of end-to-end RSVP when end-to-end RSVP is not
supported at the far end.
• Applicable only when SIP Preconditions is not supported by far
end (not on reservation failure).
* Call is reattempted without SIP Preconditions, in this case.
CAC reverts to local RSVP.
- RSVP policy configuredfor SIP Preconditions is used for local
RSVP

- Cluster-internal RSVP agents are used.


• Originating phone to its RSVP agent (no RSVP)
• RSVP agent oforiginating phoneto RSVP agent ofSIP
trunk (RSVP)
• RSVP agent tofarend (no RSVP)

You can configure QoS fallback to use local RSVP when end-to-end RSVP is notsupported by
the farend. fallback applies only in the casewhere the far enddoesnolsupport SIP
Preconditions. If il does supportSIP Preconditions and the RSVP reservation fails, there is no
fallback to local RSVP.

If there is QoS fallback, the call is reattempted without SIP Preconditions. CAC reverts to local
RSVP. uhich means that two cluster-internal RSVP agents arc used. The call is split into three
local call legs:
• One from the originating phone to its RSVP agent
• One from that RSVP agent to the RSVP agentthat is associated with the SIPtrunk
• One from the RSVP agent that is associated with the SIP trunk, toward the othercall-
mm
routing domain (where the same action con happen inthe ease ofa Cisco Unified
Communications Manager)

However, the call leg between the two clusters or between the local cluster and the SIP device
on the other end does not use RSVP-based CAC.
The configured RSVP policy determines how calls areprocessed in certain scenarios:
• When the far end does not support preconditions and QoS fallback is off, the call fails
when the RSVP policy is Mandatory, or Mandator,' (Video Desired). When the RSVP
policy is Optional (Video Desired), the call continues without RSVP.
• When the farend does notsupport preconditions and QoS fallback is on,the configured
RSVP policy is applied to local RSVP.

>2013 Cisco Systems, Inc Bandwidth Management and CAC Implementation 3-87
SIP Preconditions Call Flow Summary
(Cont.)

Cisco Unified Communications


Manager Media component
initiates renegotiation of media
capabilities.

Media Request. forFull Sat


ot Codec Capabilities

Answ3witti SlnflteCode
NegotiatedbyMedia

Session is established (RSVP Session is established (RSVP


bandwidth is adjusted if banOwidth Is adjusted if
necessary). necessary).

Whenthe call is answered, the terminating side sends an OK messagethat is confirmed from
the other side with an ACK message.
Now. where the call is formally set up. the terminating side triggersa renegotiation of media
capabilities with an INVITE message with no SDP attached.
Theoriginating sidesends an OK message, including the capabilities of the enddevice, in its
SDP.

The terminating side selects a codec and informs the originating side with an ACK message
with anattached SDP, including theselected capabilities (codec, packetization size, and soon).
Ifneeded. RSVP reservations areupdated between the two RSVP agents.

3-86 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) vS.O ©2010 Cisco Systems, Inc.
SIP Preconditions Call Flow Summary
This subtopic illustrates a summarized call flow forSIP Preconditions calls.

SIP Preconditions Call Ffow Summary

QoS "Preconditon"
m=amJio 20O0G RTPfAVP 0
0=!NlP4 192022
m=auara10000 rtf/wP 0 a=wjrE.flose2e '.vi'-t
e=MIP4 1920 21 > a=desqos mandatory e2a
a=currqose2ei
^H.II.J.I Ii>Kiaa*gaa^ai
<
sendrecu
a=des qos mandatory e2e a^conl qos e2e recv
flendrecv

SIPUA1 initiates
RSVP reservation in SIP UA2 initiates
the 1 -» 2 direction RSVP reservation in
the 2 ^ 1 direction.
nvauOio 10000 RTPNWP 0
c=!NIP4 192021
a^currqos s2e';e--.i m=audio 20000 RTP/AVP 0
allies qos mandatory e2e C=INIP4192 02 2
sendiecv 7 a=curr qtra e2f ser **•;•.•
aides' qos mandalory e2e
•^f—BJSIfriJt'Jii'lWI
<i sendrec*<

Precondition Complete Precondition Complete

"fhe figure shows the most important components ofthe first phase ofthe call setup over a SIP
trunk that iseonligured for SIP Preconditions. The phase starts with the initial INVITE
message with the IP address of the originating RSVP agent and the request for RSVP CAC in
the SDP.

Then it show s the 183 response message that confirms the received RSVP CAC request inits
SDP. The SDP furtherincludes the IP address of the terminating RSVP agent and the request
for RSVP CAC for the reverse direction.
This negotiation isthen completed by the PRACK message that issent from the originating
side toward the temiinating side.
RSVP reser\ ations arethen setup In each RSVP agent for thedirection to theother RSVP
agent, using RSVP PATH and RSVP Resv messages.
The originating side then informs the temiinating side about the successful RSVP reservation in
the SDP of an UPDATH message. The terminating side confirms this information in anOK
message with SDP that includes the same status information for the other direction.
The precondition phase is now completed, and the terminating device can now send a
RINGING message to the originating side.

BandwidthManagement and CAC Implementation 3-85


© 2010 Cisco Systems. Inc.
SIP Preconditions Operation (Cont.)

After call is answered, terminating Cisco Unified


Communications Manager requests renegotiationof media
capabilities (INVITE, no SDP).
Originating Cisco Unified Communications Manager sends full
set of supported media capabilities (OKwith SDP).
Receiving Cisco Unified Communications Manager sends ACK
with SDP, including selected codec.
Ifselected codec has different bandwidth requirements, RSVP is
updated accordingly.
Call is established with three call legs:
- Originating phone to originating RSVP agent (no RSVP)
- Orig inating RSVPagent to terminating RSVP agent (RSVP)
- Terminating RSVP agent to terminating phone (no RSVP)

6. When the call isanswered, the terminating Cisco Unified Communications Manager
requests a renegotiation of media capabilities by sending a SIP INVITE message without
SDP.

7. The originating Cisco Unified Communications Manager responds with aSIP OK message
with SDP. Thecomplete set of supported media capabilities is included in the SDP.
8. The receiving CiscoUnified Communications Manager sends a SIPOK withSDP
message, including the selected codec. This codec is nowactually usedfor the end-to-end
call.

9. Ifthe selected codec has bandwidth requirements that are different from the requirements
that were used during the SIP Preconditions phase, the RSVP reservation is updated
accordingly.

10. The call is now established with three call legs (like with RSVP-enabled locations for calls
within a cluster):

— The call leg between the originating IPphone and its RSVP agent, where no RSVP-
based CAC was performed
— The middle call legbetween thetwo RSVP agents, where RSVP-based CAC was
performed, as described earlier
— The call leg between the terminating IP phone and its associated RSVP agent, where
againno RSVP-based CAC was performed

Note Standard locations-based CAC is performed between the IP phones andtheir associated
RSVP agents As a result, thecall leg from theIPphone to itsRSVP agent iscounted
against themaximum bandwidth thatisconfigured at thelocations thatare applied to theIP
phone and to the RSVP agent.

3-84 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc.
SIP Preconditions Operation
This subtopic describes the operation ofSIP Preconditions inCisco Unified Communications
Manager.

SIP Preconditions Operation

Phone places call to destination reachable via SIP trunk.


Originating Cisco Unified Communications Manager sends INVITE
messagewith SDP:
-• IP address of originating RSVP agent is used.
• RSVP is requested.
Terminating CiscoUnified Communications Manager sends SESSION
PROGRESS message with SDP:
IP address of terminating RSVP agent is used.
RSVP request is confirmed for forward direction.
RSVP request is sent for reverse direction
After confirmation (PRACK and OK), each RSVP agent attempts
RSVP reservation for its forward direction.
Ifsuccessful, standard call setup is performed (RINGING, OK, ACK)

A call with SIP Preconditions follows the message sequence of RFC 3312 to establish a
precondition. Here isa summarv' ofthe session establishment phases:
1. The originating IP phone places a call to adestination that isreachable through a SIP trunk.
According to the location configuration at the originating IP phone location, RSVP has to
beused between the location ofthe originating IP phone and the SIP trunk where the call
mm
should be routed to.

2, The originating Cisco Unified Communications Manager sends a SIP INVITE message
with Session Description Protocol (SDP). The IP address for the media stream in the SDP
is setto the IP address of the originating RSVP agent. RSVP is requested in the SDP.
3 The tenninating device—for example aCisco Unified Communications Manager server of
another cluster—responds with a SIP SESSION PROGRESS message with SDP. Itwill
provide the IP address of the terminating RSVP agent, confirm the RSVP request for the
forward direction, andsend an RSVP request forthe reverse direction.
4. The negotiation of SIP Preconditions for RSVP CAC is completed by SIP PRACK and OK
messages. Then each of the two RSVP agents attempts an RSVP reservation tor i+s forward
direction (that is. toward the other RSVP agent) ofthe preconditioned bandwidth.
5. Ifthe RSVP reservation issuccessful, a standard call setup isperformed by SIP RINGING,
OK. and ACK messages.

mtw

Bandwidth Managementand CAC Implementation 3-83


j 2010 Cisco Systems, Inc.
CAC with SIP Preconditions
This subtopic describes how you can implement end-to-end RSVP-based CAC for SIP trunks
with SIP Preconditions.

CAC with SIP Preconditions

For SIP calls going out of the cluster, RSVP can be used end-to-end
between different domains.

With Cisco Unified CommunicationsManager, RSVPagent of the


phone is used (not the one of the trunk).
Cisco IOS gateways and Cisco Unified Communications Manager
Express also support SIP Preconditions.

SIP Trunk
SCCP
RTP
• RSVP
_ Anarogor
Digital Voice

When both endsof a SIPtrunk support SIP Preconditions and the IP phone and the SIPtrunk
are in different locations and RSVP is enabled between thesetwo locations, then end-to-end
RSVP is used. Asa result, only the RSVP agent thatis associated with the IP phone is invoked;
there is nosecond local RSVP involved. TheRSVP agent of thephone now uses RSVP-based
CAC toward the other end of the SIP trunk.

Iftheother endis another Cisco Unified Communications Manager cluster, then the same result
happens at that farend: only one RSVP agent is invoked. If the otherend is a CiscoIOS router,
then that router (either Cisco Unified Communications Manager Express or a Cisco IOS SIP
gateway) terminates RSVP at the far end.

With SIP Preconditions, RSVP is now virtually end-to-end. Itspans the two call- routing
domains and is not limited to the local cluster.

Note Due to proprietary extensions, SIP Preconditions for RSVP-enabled CAC iscurrently
supported only between Cisco Unified Communications Manager, Cisco Unified
Communications Manager Express, andCisco IOS SIP gateways. Third-party SIPdevices
are currently not supported.

3-82 Implementing Cisco Unified Communications Manager, Part2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc.
CAC Without SIP Preconditions
This subtopic describes how you can implement local RSVP-based CAC for SIP trunks when
SIP Preconditions is not used.

CAC Without SIP Preconditions

For SIP calls going out ofthe cluster, RSVP can be used only
between local RSVP agents associated with phone and SIP
trunk.

No end-to-end RSVP between separate domains.

When not using SIP Preconditions, you can use RSVP only within the local Cisco Unified
Communications Manager cluster. Such an implementation islike RSVP-enabled locations, as
discussed in an earlier topic ofthis lesson, except that the two devices that are involved in the
local Cisco Unified Communications Manager cluster arean IP phone and a SIP trunk (or two
SIP trunks).
The IP phone and the SIP trunk are in different locations, and RSVP is enabled between these
two locations. The IP phone refers to its RSVP agent by its MRGL, and the SIP trunk refers to
its RSVP agent b> its MRGL. RSVP CAC applies between these two RSVP agents. Because all
devices are local 'to the Cisco Unified Communications Manager cluster, this implementation
model is called local RSVP. Ifanother Cisco Unified Communications Manager cluster is atthe
other end of the SIP trunk, local RSVP can beused also at that end. However, the call leg
between the two RSVP agents that are associated with the SIP trunk ateach cluster isnol
subject to RSVP. Therefore, there isno end-to-end RSVP in this ease.
Ifthe other end ofthe SIP trunk isa third-party device, a Cisco IOS SIP gateway, orCisco
Unified Communicalions Manager Express, then local RSVP applies only tothe end ofthe SIP
trunk where Cisco Unitied Communications Manageris used.

BandwidthManagement and CAC Implementation


)2O'0 Cisco Systems. Inc
SIP Preconditions
This topic describes SIP Preconditions and how it is used in Cisco Unified Communications
Manager to implement RSVP-based CAC for calls through SIP trunks.

SIP Preconditions Overview

Based on RFC 3312: Integration of Resource Management and SIP


- RFC allows for several types of precondition signaling.
- Cisco Unified Communications Manager currently supports RSVP
only.
lntercluster(also known as end-to-end) RSVP
- Built on the capabilities of intracluster RSVP.
- Allows RSVP to be used with devices outside the Cisco Unified
Communications Manager cluster.
- Supports RSVP CAC for calls over SIP trunks to
• Cisco Unified Communications Manager
• Cisco Unified Communications Manager Express
* Cisco IOS SIP gateway
• Cisco Unified Border Element

The Cisco Unified Communications Manager implementation of SIP Preconditions is based on


RFC 3312. Integration of Resource Management and SIP. The RFC describes severaltypes of
precondition signaling. Cisco Unified Communications Manager is currently supporting
precondition signaling for RSVP only.
SIP Preconditions appliesto SIPtrunks and henceappliesto calls going out of the cluster. Like
RSVP-enabled locations, it allows RSVPagentsto be used for calls through SIP trunks. It is
therefore also referred to as intercluster RSVP.

Another term that is used to refer to SIP Preconditions is "end-to-end RSVP." This term does
not mean that RSVPis implemented in the actualendpoints (IP phones),but it refers to
intercluster calls. Before SIP Preconditions, intercluster callsusing SIPwereableto useonly
local RSVP within a cluster. In thiscase, an RSVP agent that is associated with the IP phone,
and another RSVPagent that is associated with the SIP trunk, are used. Sucha configuration
requires the phone and the trunk to be in separate locations, and RSVP needs to be enabled
between these two locations. Thesetwo RSVPagents,however, were both local to the Cisco
Unified Communications Managerclusterand hence were not spanningto the other end of the
cluster. With SIP Preconditions, RSVP can be used between both ends of the SIP trunk; hence
the name end-to-end RSVP.

SIP Preconditions is not limited to intercluster trunks (that is, calls between two Cisco Unified
Communications Manager clusters). It can be used also for SIP trunks to Cisco Unified
Communications ManagerExpress. Cisco IOS gateways, and Cisco Unified Border Elements.

3-80 Implementing CiscoUnified Communications Manager. Part 2 (CIPT2) v8.0 ) 2010 Cisco Systems. Inc.
Step 4: Configure Phones for AAR (Cont.

Forward calls to
voce mail if directory Set individual destination number
Set (verify) exiemal
number cannot be mask (CFNB) to be used instead of
phone number mask
reached due lo external phone number mask and
otdireclory numbef
locai ms-based AAR group prefix
CAC.

You need lo configure the IP phone directory numbers for AAR. The Directorv- Number
Configuration windowdisplays these relevantoptions:
• Voice Mail: If this check box is checked, calls to this phone are forwarded to voice mail if
this directory numbercannotbe reached due to locations-based CAC.
• AAR Destination Mask: If thisoption is set. the number where callsare rerouted to if this
directory number cannot be reached due to locations-based CAC iscomposed of this mask
and this director, number. Otherwise, the number would be composed of this directorv
number, the external phone number mask, and an AAR group prefix. Because 1his setting is
configured for each directory number, it allows any destination to be specified. (Ifthere arc
not n wildcard digits inthe mask, then calls arererouted to the specified number without
considering any digits ofthe directorv' number.) Therefore, this setting isoften referred lo
as CFNB.

• AARGroup: An AAR group at the directory number has to be set in orderto allow AAR
calls to thisdirector.' number. The AAR group that is configured at thedirectorv number is
the destination AAR group.
• External Phone Number Mask: This mask is the external phone number mask of the
directory number. Itshould always be set, because it is used by other features (such as digit
manipulation at route patternsor route lists).

© 2010 Cisco Systems. Inc BandwidthManagement and CAC Implementation 3-79


Step 4: Configure Phones for AAR
The figure shows how to configure phones for AAR.

Step 4: Configure Phones for AAR

Cisco Unified Communications Manager Administration:


Call Routing > Phone

When you enable AAR on a phone, there are two possible settings in the Phone Configuration
window:

• AAR CSS: This CSS is used ifa call that originated at this phone is rerouted using AAR.
• AAR Group; The AAR group of the phone is the source AAR group, while the AAR
group that was set at the directory numberis the destination AAR group. It is important to
understand this distinction for the configuration of AAR prefixes,becausethey are
configured separately foreachpairof AAR source anddestination group. If no AAR group
is set at the phone, then the AAR group of the directory number is used as the AAR source
group for this phone.

3-78 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 12010 Cisco Systems, Inc.
Step 3: Configure AAR Groups
As mentioned before. Step 2. "Configure partitions and CSSs." is not shown, because the
configuration of partitions and CSSs has been covered earlier. This figure illustrates Step 3. the
configuration of AAR groups.

Step 3: Configure AAR Groups

Cisco Unified Communications Manager Administration:


Call Routing > AAR Groups

Enler the name of me AAR group.

onfiguie the prefix that is added to the


external phone number mask of the callefl
phone for AAR calls within the same AAR
group

For each of the other AAR groups,


configure the dial prefix that is added to the
external phone number mask of the called
phone

Specify the dial prefix for bolh directions


(call from this AAR group to the other AAR
group and vice versa)

You configure AAR groups from Cisco Unified Communications Manager Administration
underCall Routing > AAR Groups. Each addedAAR group can be configured with a dial
prefix for itsown group and twodial prefixes foreachof the otherAARgroups (one forcalls
going to theother group andone forcallsbeingreceived from theothergroup).

Note Inthis example, there are onlytwoAAR groups. For AAR calls from HQto BR a prefix of
0001 is used. For calls tn the other direction, a prefix of 901149 is used. The AAR
configuration that is shown would fit to a scenario where the HQ site is in Germany and the
BR site is in the United States The external phone number mask at both sites would use
national format.

As a result, an AAR call from Germany to the United States would be placed to 0001
followed by the national number (10 digits). 0 is the PSTN access code in Germany, 00 is
the international access code, and 1 is the country code for the United States. An AAR call
from the United States to Germany would be placed to the national number of a Germany
phonethat is prefixed with 901149. 9 is the PSTN access code inthe United States, 011 is
the international access code, and 49 is the country code of Germany.

Tip The configuration thatisshown in thefigure does not useglobalized call routing. Globalized
call routing is recommended in larger multisite environments, especially ininternational
deployments. With globalized call routing, all sitesuse thesame AAR group and noprefixes
are required within thatgroup The external phone number mask is specified in globalized
format(E.164 number with + prefix).

) 2010 Cisco Systems. Inc. Bandwidth Management and CAC Implementation 3-77
Step 1: Configure AAR Service Parameters
The figure illustrates how to enable AAR and how to set AAR-related parameters.

Step 1: Configure AAR Service Parameters

Cisco Unified Communications Manager Administration:


System > Service Parameters > Cisco CallManager

You enable AAR by setting the Cisco CallManager service parameter Automated Alternate
Routing Enable to True (False is default).
Other AAR-related service parameters aretheOut-of-Bandwidth Text parameter, where you
can set the text that is displayed on an IP phone when a call fails due to no available bandwidth,
and the AAR Network Congestion Rerouting Text parameter, whereyou can set the text that is
displayed on an IP phone when AAR reroutes a call.

3-76 Implementing CiscoUnified Communications Manager, Part 2 (CIPT2) v8.0 >2010 Cisco Systems, Inc.
AAR Configuration Procedure
The implementation of AAR includes these steps.

AAR Configuration Procedure

1 Configure AAR service parameters (Cisco CallManager


service).
2 Configure partitions and CSSs.
3 Configure AAR groups.
A Configure phones for AAR:
a ApplyAARCSS and (source) AARgroup to IP phones.
& Configure IPphone directory numbers:
1) Apply (destination) AAR group.
2) Set individual AAR destination mask (CFNB),
s, Forward to voice mail if no bandwidth is available.

Step 2.-Configure partitions and CSSs." is notdiscussed in this topic, because the
configuration of partitions and CSSs was discussed in detail in the Implementing Cisco Unified
Communications Manager, Part 1 (CIP'1'1) course,and both of these itemshave already been
used se\eral limes in this course.

You need to precisely design partitions and AAR CSS. The AAR CSS of the calling device
must include the partition that is necessary to route the redirected call. Thecall is routed to the
number that iscomposed of the destination directory number, external phone number mask, and
AAR prefix (according tothe AAR group configuration). Ifyou configure an individual AAR
destination mask or forward to voice mail, the AAR CSS has to provide access to these
numbers (numbers that arccomposed of the called directory number and AAR destination mask
or voice-mail pilot number).
As mentioned earlier, in globalized call routing, AAR configuration is simpler when you use
the globalized format at theexternal phone number mask.

© 2010 Cisco Systems. Inc BandwidthManagement and CAC Implementation


AAR Considerations
Ihis subtopic discusses important considerations when you are implementing AAR.

AAR Considerations

AAR supports these call scenarios:


- Call originates from an IP phone within one location and
terminates at an IP phone within another location.
- Incoming call through a gateway device within one location
terminates at an IP phone within another location.
AAR does not work with SRST:
- AAR is not activated by WAN failure.
- AAR requires CAC failure.
Use of globalized call