Cipt 2 Vol 1&2

Table of Contents
Volume 1
POP-1
1
1
Course Introduction
Overview
Learner Skills and Knowledge Course Goal and Objectives

Course Flow
3
4
Additional References
5 5 6
Cisco Glossary of Terms Your Training Curriculum
Multisite Deployment Implementation

Overview
1-1
1-1 1-1
Module Objectives
Identifying Issues in a Multisite Deployment

Objectives
1-3
1-3 1-4
Multisite DeploymentIssues Overview

Quality Issues
1-6
1-7
Quality Issues Example: Jitterand Packet Drops

Bandwidth Issues
Example: Bandwidth Issues
1-8 1-8
1-9 1-10 1-11 1-12
Bandwidth Issues Example: Voice and DataTraffic Competing for Bandwidth Bandwidth Issues Example: Load Caused by Centralized Media Services
Availability Issues Example: IP WAN Failure
Availability Issues
Dial Plan Issues
1-13
1-16 1-17
Example: Variable-Length Numbering, E.164 Addressing, and DID

Fixed vs. Variable-Length Numbering Plans Detection of End of Dialing in Variable-Length Numbering Plans
Optimized Call Routing and PSTN Backup

Example: TEHO
1-18 1-20 1-21 1-22 1-23

1-25
Example: Overlapping and Nonconsecutive Numbers

Various PSTN Requirements
Issues Caused by Different PSTN Dialing

Dial Plan Scalability Issues NAT and Security Issues Example: NAT Security Issues Summary
References
1-26 1-28 1-29

1-30
1-30
identifying Multisite Deployment Solutions

Objectives
1-31
1-31
Multisite Deployment Solution Overview

QoS
1-32 1-33
1-34 1-35
QoS Advantages
Solutions to Bandwidth Limitations
Low-Bandwidth Codecs and RTP-Header Compression
1-37 1-38 1-39 1-40

1-41 1-42 1-44
Codec Configuration in Cisco Unified Communications Manager

Disabled Annunciator
Local vs. Remote Conference Bridges

Transcoders
Guidelines for Transcoder Configuration

Mixed Conference Bridge Multicast MOH from Branch Router Flash Multicast MOH from Branch Router Flash Example
1-45
1-47
Multicast MOHfrom Branch Router Flash: Cisco IOS Configuration Example

Alternatives to Multicast MOH from Branch Router Flash
1-49 1-50
1-51
Preventing Too Many Calls by CAC
Availability
PSTN Backup MGCP Fallback; Normal Operation

MGCP Fallback: Fallback Mode
1-52 1-53
1-54
Fallback for IP Phones; Normal Operation

Fallback for IP Phones: Fallback Mode
1-55
1-56 1-57
Using CFUR toReach Remote-Site IP Phones Over the PSTN During WAN Failure
Using CFUR to Reach Usersof Unregistered Software IP Phones on Their Cell Phones
Automated Alternate Routing
Mobility Solutions
Dial Plan Solutions
1-58 1-59 1-60 1-61

1-62 1-64 1-65 1-68 1-70 1-72 1-73 1-74
Dial Plan Components in Multisite Deployments

Globalized Call-Routing Overview Globalized Call RoutingThree Phases Globalized Call Routing Advantages
NAT and Secunty Solutions
Cisco Unified Border Element in Flow-Through Mode

Summary
References
1-75 1-77
1-77
Implementing Multisite Connections

Objectives Multisite Connection Options
Cisco Unified Communications ManagerConnection Options Overview

Cisco IOS Gateway Protocol Functions Review Cisco IOS Gateway Protocol Comparison Review
SIP Trunk Characteristics H.323 Trunk Overview
1-78 1-79 1-80

1-81 1-82 1-83 1-84
H 323 Trunk Comparison
MGCP Gateway Implementation Review Cisco IOS Gateway MGCP Configuration Methods Review
Configuring Cisco IOS Gatewayfor MGCPExample

H.323 Gateway Implementation Review
1-86 1-87
1-89 1-91
Cisco Unified Communications Manager H.323 Gateway Configuration

Cisco IOS H.323 Gateway Configuration
Trunk Implementation Overview
Gatekeeper-Controlled ICT and H.225 Trunk Configuration Overview

Trunk Types Used by Special Applications SIP Trunk Implementation Intercluster and H.225 Trunk Implementation Cisco Unified Communications Manager Gatekeeper-Controlled ICT and H.225 Trunk Configuration Summary
References
1-93 1-94 1-95

1-96 1-97
1-98 1-100
1-102 1-105 1-105
Implementing a Dial Plan for International Multisite Deployments

Objectives
Multisite Dial Plan Overview
1-107
1-107
1-108
Dial Plan Requirements for Multisite Deployments with Distributed Call Processing
Dial Plan Scalability Solutions Implementing Site Codes for On-Net Calls
1-109 1-110 1-112 1-113 1-114 1-115 1-116 1-117 1-118 1-119 1-120
1-121
Digit Manipulation Requirements for UsingAccess and Site Codes Centralized Call-Processing Deployments: Access and Site Codes Implementing PSTN Access in Cisco IOS Gateways PSTN Access Example
ISDN TON
Example: ISDN TONCalling NumberTransformation of Incoming Call

Implementing Selective PSTN Breakout
Configuring IP Phones to Use Local PSTN Gateway

Implementing PSTN Backup for On-Net Intersite Calls
DigitManipulation Requirements for PSTN Backup of On-Net Intersite Calls

ImplementingCisco Unified Communications Manager. Part 2 (CIPT2)v8.0
1-122
)2010 Cisco Systems, Inc.
Implementing TEHO
TEHO Example Without Local Route Groups TEHO Example with Local Route Groups Implementing Globalized Call Routing
Considerations for Using Remote PSTN Gateways
Globalized Call Routing: Number Formats Normalization ofLocalized Call Ingress onGateways
1"127 1"129 ]-] 31
l-i
]_J24
Considering Globalized Call-Routing Interdependences

Globalized Call RoutingTEHO Advantages Globalized Call RoutingTEHO Example
Localized Call Egress atGateways Localized Call Egress at Phones Globalized Call-Routing Example: Emergency Dialing
Normalization of Localized Call Ingress from Phones
1-133 1-136
1-138 1-140 1-142
1-137
1-146
1-147 1-148
Summary
Module Summary
References
I'ltn
I Icl*
,
Module Self-Check Module Self-Check Answer Key

Centralized Call-Processina Redundancy Implementation
Overview
References
1'153 1'158
2^
2-1
1-151
Module Objectives
Examining Remote Site Redundancy Options
2-1
2^
Objectives Remote Site Redundancy Overview
Remote Site Redundancy Technologies
2-5
2-6
2-7
2"3 2-4
When to Use MGCP Fallback When to Use Cisco Unified SRST
When to Use Cisco Unified Communications Manager Express inSRST Mode

Cisco Unified SRST Operation Cisco Unified SRST Function: Switchover Signaling
Cisco Unified SRST Function: Call Flow After Switchover
2-9
2-10 2-11
2-12
Cisco Unified SRST Function: Switchback Cisco Unified SRST Timing

MGCP Fallback Operation MGCP Gateway Fallback: Switchover MGCP Gateway Fallback: Switchback MGCP Gateway Fallback Process Cisco Unified SRST Versions and Feature Support Cisco Unified SRST 8.0 Platform Density Plus (+) Prefix and E.164 Supportin Cisco Unified SRST
2-13 2-14
2-15 2-16 2-17 2-18 2-19 2-20 2-21
Support for Multiple MOH Sources

Dial Plan Requirements for MGCP Fallbackand Cisco Unified SRST Scenarios Ensure Connectivity for Remote Sites Ensure Connectivity from Main Site UsingCFUR
CFUR Considerations CFUR Interaction with Globalized Call Routing CFUR Example WithoutGlobalized Call Routing CFUR Example with Globalized Call Routing
2-22
2-23 2-24 2-25
2-26 2-28 2-30 2-31
Keeping Calling Privileges Active in SRST Mode

Cisco Unified SRST Dial Plan Requirements Example Summary
References
2-32
2-33 2-34
2-34
2010 Cisco Systems, Inc.
Implementing Cisco Unified Communications Manager, Part2(CIPT2) v8.0
Implementing SRST and MGCP Fallback

Objectives MGCP Fallbackand Cisco Unified SRST Configuration Overview MGCP Fallback and Cisco Unified SRST Configuration Requirements Cisco Unified Communications ManagerSRST Configuration Step 1: SRST Reference Step 2: Device Pool Cisco IOS Gateway SRST Configuration Steps 1 and 2: Enabling Cisco Unified SRST and Setting Cisco Unified SRST IP Address Steps 3 and 4: Setting Maximum Directory Numbers and Telephones Steps 5 and 6: Setting Maximum Directory Numbers Per Phone and Keepalive Timer Cisco Unified SRST Configuration Example Cisco IOS GatewayMGCP GatewayFallback Configuration Steps 1 and 2: Enabling MGCP Fallback and Setting Fallback Service MGCP Fallback Configuration Example
2-35
2-35 2-36 2-37 2-38 2-39 2-40 2-41 2^2 2-43 2^J4 2-45 2-46 2-47 2-48
Cisco Unified Communications Manager Dial Plan Configuration for SRSTSupport

Step 1: Define a CSS for CFUR
2-49
2-49 2-50
2-51
Step 2: Setting Max Forward Unregistered Hops to DN

Step 3: Configuring CFUR
Cisco IOS GatewayMGCP Fallback and Cisco Unified SRST Dial Plan Configuration
Additional SRST Dial Plan Requirements Cisco Unified SRST Dial Plan Commands: Dial Peer
2-53
2-54 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 Summary

References
2-67 2-70
2-70
Implementing Cisco Unified Communications Manager Express in SRST Mode

Objectives
2-71
2-71
Cisco Unified Communications Manager Express Overview Cisco Unified Communications Manager Express in SRST Mode When to Use Cisco Unified Communications Manager Express in SRST Mode Cisco Unified Communications Manager Express Features Important Cisco Unified Communications Manager Express Features General Configuration of Cisco Unified CommunicationsManager Express Cisco Unified Communications Manager Express: Basic Configuration Example
Providing Phone Loads Cisco Unified Communications Manager Express: MOH
Additional MOH Sources
2-72 2-73 2-74 2-78 2-79 2-80 2-82

2-83 2-84
2-85
Additional Music on Hold SourcesConfiguration Example Configuration of Cisco Unified Communications Manager Express in SRST Mode Phone Provisioning Options Advantages of Cisco Unified Communications Manager Express in SRST Mode Phone Registration Process Configuring Cisco Unified Communications Manager Express in SRST Mode Cisco Unified Communications Manager Express in SRST Mode Configuration Example Summary
References
2-86 2-87 2-89 2-90 2-91 2-92 2-94 2-95

2-95
Module Summary
References Module Self-Check
2-97
2-97 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

Overview
3-1
3-1
Module Objectives
3-1
Managing Bandwidth Objectives Bandwidth Management Overview

Cisco Unified Communications Manager Codec Configuration Review of Cisco Unified Communications l\ anager Codecs
3-3
3-3
3-4
3-6 3-7 3-8 3-10 3-11

3-13 3-15
Example: Codec Configuration

Local Conference Bridge implementation
Example: Implementing Local Conference I ridges at Two Sites Transcoder Implementation Example: Implementing a Transcoder at the Main Site Configuration Procedure for Implementing ranscoders Step 1: Add Transcoder Resource in Cisco Jnified Communications Manager Step 2: Configure Transcoder Resource in isco IOS Software Multicast MOH from Branch Router Flash Implementation Multicast MOH from Branch Router Flash: I legion Considerations
Multicast MOH from Branch Router Flash: , .ddress and Port Considerations Multicast MOH: Address and Port Incremer t Example
3-17
3-18
3-19 3-21 3-23 3-24

3-25 3-27 3-30
Example: Implementing Multicast MOH froi i Branch Router Flash Configuration Procedure for Implementing lulticast MOH from Branch Router Flash Step 1; Enable Multicast Routing on Cisco OS Routers Step 2a: Configure MOH Audio Sources foi Multicast MOH Step 2b: Configure Multicast MOH in Cisco|Unified Communications Manager ia Resource Groups Step 2c: Enabling Multicast MOH at the Step 3: Enable Multicast MOH from Branch!Router Flash at the Branch Router Used for MOH RTP Packets Step 4a: Configure the Maximum Hops to Step 4b: Use IP ACL at IP WAN Router Ints rface Step 4c: Disable Multicast Routing on IP W VN Router Interface
Summary
References
3-31 3-32 3-33 3-34 3-35 3-36 3-37

3-38
3-39
3-39
Implementing CAC Objectives

CAC Overview
3-41
3-41
3-42 3-43
3-44 3-45 3-46
CAC in Cisco Unified Communications Manjager

Standard Locations
Configuration Procedure for Implementing Ijocations-Based CAC

Locations Configuration Example: Hub-and Spoke Topology
Step 1: Configure Locations Step 2: Assign Locations to Devices
RSVP-Enabled Locations
Locations: Hub-and-Spoke Topology Locations: Full-Mesh Topology
3^17 3-48
3-49
3-50
3-51 3-52 3-53 3-54 3-55 3-57 3-58 3-59 3-63 3-65
Three Call Legs with RSVP-Enabled Locations

Characteristics of Phone-to-RSVP Agent Ci II Legs Characteristics of RSVP Agent-to-RSVP Agent Call Leg
How RSVP Works
Configuration Procedure for Implementing RSVP-Enabled Locations-Based CAC Example: RSVP-Enabled Locations Configuration Step 1: Configure RSVP Service Parameters Step 2: Configure RSVP Agents in Cisco IOS Software Step 3: Add RSVP Agents to Cisco Unified Communications Manager Step 4: Enable RSVP Between Location Pairs Automated Alternate Routing
AAR Characteristics
3-66
3-68 3-69 3-70 3-72
AAR Example Without Local Route Groups and Globalized Numbers AAR Example with Local Route Groups and Globalized Numbers
2010 Cisco Systems. Inc.
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0
AAR Considerations
AAR Configuration Procedure Step 1: Configure AAR Service Parameters Step 3: Configure AAR Groups Step 4: Configure Phones for AAR SIP Preconditions CAC Without SIP Preconditions
CAC with SIP Preconditions SIP Preconditions Operation
3.74 3-75 3-76 3.77 3-78 3-80 3-81

3-82 3-83
SIP Preconditions Call Flow Summary

Fallback from End-to-End RSVP to Local RSVP SIP Preconditions Configuration Procedure Step 2a: Configure SIP Profile Step 2b: Apply SIP Profile to Trunk H.323 Gatekeeper CAC
3-85
3-87 3-89 3-90 3-91 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
References
Module Self-Check
3-105
3-105
3-107
3-109
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 solutions toreduce bandwidth i 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
Course Introduction
Course Flow
This topic presents the suggested flow of the course materials.
Course Flow
[Course Introduction [
s implementation
M j Deployment ,. implementation j Implementation , (Cot*.)
Aj
. J
MJtsite
Deployment
Multisite
Centra Iced
Bandwidth
; of Features and 1 AppBcatena far
CsS-P recessing Redundancy

Implements! on {Cont.)
Management
and CAC
;
s
Multisite
Deployments
(Cont)
Implementation (Cor*)
CCD
Lunch
Mufti sits
Bandwidth
Deployment
Impiemen tiiofi
. MuKsite
Management ana
8andwkJtn
'
Deployment
(Cont)
CentrafzerJ
CAC Implementation; (Cont) j

Impiementation
of Features and
CCD
M fmplenientaliort
Cal-Processing
Redun&ncy frnptementation
Management
and CAC
f
'
(Cont)
Implementation
Applications for
Multisite
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.
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 Urified Presence
Cisco Unified
Communications
Network Cloud
Manager Gatekeeper
Cisco Unrty
Connection
_^^ Cisco Unified t^H Border Element

Gateway
Cisco Unified
Messaging
Gas* a/
Personal
Communicator
Voice Router
Cisco Un ified
Coco Adapt ve Secirty Appliance
Cisco Unified
SRST Router
Communications
Manager Express
Cisco Unified
SAF Enabled
Router
Communications
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).
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
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

Appticatiom
___
'imgnâseoWllkKlCommunications
Voice Metw or king
www Cisco com/go/certificatons
i 2010 Cisco Systems, Inc.
Course Introduction
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
and TL1IO in an international environment
Implement adial plan to support inbound and outbound PSTN dialing, site-code dialing,
1-2
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0
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
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 networkfor 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.
The issue of vulnerability when IP addresses are translated to public IP addresses is not limited to multisite deployments.
Note
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

Voice quality is reduced.
Queuing delay causes jitter.
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.
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/ationencapsulating digitized voice into
RTP. User Datagram Protocol (UDP). IP. and a Layer 2 protocolis 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
for Bandwidth
Bandwidth Issues Example: VDice and Data Traffic Competing

The example illustrates the higher ovdVh ead ofvoice packets when comparing them with file
transfer packets.
Data Traffic Compdt:ing for Bandwidth

In multisite environments, media services such as
Bandwidth Issues Sample: Voice and
music on hold (MOH), conferences, annunciators,

and so on, can cause considerable bandwidth
consumption over the IP WAN.
Voice packets:
Small size
High packet rate Large overhead
-wwr
Vo-ceand data packets are

competing for IP WAN bandwdlh
Data packets:
Large size Lower packet rate
Small overhead
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.
can achieve this optimization by utilizing local media resources.
is caused by the overhead ofIP, UDP. and RTP headers that are added to small packets and
As shown mthe figure and as already mentioned, voice packets consume lots of bandwidth that
they do not have to cross the IP WAN all the time, thus conserving valuable bandwidth You
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
>2010 Cisco Systems, Inc.
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
when only remote phones areparticipating in the conference. The same problem applies to media termination points (MTPs),
annunciators, and MOH
phones that are located at the remote site to cross the IP WAN, even
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êtt.ngs each
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.
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
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
Signaling
several services;
- Remote IPphones registering with centralized Cisco Unified

Communications Manager
- Remote MGCP gateways controlled bycentralized Cisco Unified

- 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
Cisco Unified Communications Manager server thatacts asan MGCP call agent.
Communications Manager server. Remote MGCP gateways are controlled by acentralized
Signaling in Cisco Unified Communications Manager multisite deployments with distributed call processing: In such environments, sites are connected via H.323
(SIP) trunks.
(nongatekeeper-controlled. gatekeeper-controlled, or H.225) or Session Initiation Protocol
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.
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
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
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.
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 fixedlength 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
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 countriesand sometimes even various PSTN
providers withinthe same countrycan 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.
received from the PSTN can be represented in various ways: as a7-digit subscriber
The calling number (the Automatic Number Identification, or ANI) ofcalls that are being
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.
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 Aulo-Attendanl Used
Variable-Length E.164
Addressing with DID
Manager
"fhe example features a main site in the United Slates. The NANP PSTN number is408 5551234. 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.
1-16
Implementing Cisco Unmeet Communications Manager. Part 2 (CIPT2) v8.0
2010 Cisco Systems.
Fixed vs. Variable-Length Numbering Plans

The table compares characteristics of a fixed numbering plan with characteristics of a variablelength 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)
Components
|*ea Numbering Plan

MAW
1
_,
VsriSUle-Length Numbing
"
Example Country code

Area code
Subscriber numoer
Avetiia
43
3 digit
1-4 (Halt*
3-tfio.texchsng cads
^cfigistaawtcoas
9
1
3mor-<Igflt
PSTN access code National access code International access code
"~
0
0
011
00 or*
(+' 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
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 VariableLength Numbering Plans

There are three ways to detect end of dialing in variablelength 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
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
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
not used, the discard digit instruction is ignored and hence the PreDot component ofthe discard
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 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,
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.
1-19
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 possibleeither 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
Example: TEHO
The figure illustrates the use of TEHO in a multisite deployment.
Example: TEHO
San Jose
Chicago
.
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.
'2010 Cisco Systems, Inc.
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 *
Nonconsecutive
1001-1099 -+ 2158-2364
2000-2157 + 2365-2999
Numbers
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

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

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
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
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 administratorfor example, the target PSTN number for automated alternate routing (AAR) targets. Call-forwarding
destinations should also be in a universal formata 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
call to a number that was stored according to the NANP dial rules while incountries that
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
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.
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
Answer Key
appear here.
The correct answers and expected solutions for the activities that are described in this guide
Lab 1-1 Answer Key: Implementing Basic Multisite

Connections
fhe solution is part of the activity procedure and verification.
Multisite Deployments
Lab 1-2 Answer Key: Implementing a Dial Plan for International

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

Lab 4-1 Answer Key: Implementing Device Mobility

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

Implementing Cisco Unrfied Communications Manager, Part 2(CIPT2) v8.0
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
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
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 CCDlearned 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
) 2010 Cisco Systems. Inc
Lab Guide
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:

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.
Step 10
Repeat the test calls. Verify thatthe callsarererouted via the local PS'fN gatewa; b\ usingdebug isdn q931 command at bothgateways.
Be aware of the call flow in this scenario. After calling a phone of the other pod using site-
Note
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.
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

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 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).
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:
Dial peer8y2 to destination pattern 85ly2... Dial peer8v3 to destination pattern 852y3... 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:
router eigrp SAF service-family ipv4 autonomous-system 1 topology base
exit -sf -topologyLab 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 .. .
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

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
Step 32
Step 33
Move the SAFSlPTrunk to Selected SAF Trunks.

Check the Activated Feature check box and click Save.
You have completed this task when you attain these results: Verify registration of the external SAF client. 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.
Step 1
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
Step 4
In Cisco Unified RTMT navigate to CallManager > Report > [.earned Pattern.
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 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.
Cisco Unified Communications Manager will set up a call to the learned IP address using the
Note
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
Lab Guide
Configure the SAF SIP Trunk in Cisco Unified Communications Manager

Step 10 Navigate to Device > Trunk and click Add New.
Step 11
Step 12
Choose SIP Trunk, set the Trunk Service Type to Call Control Discovery, and
then click Next.
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
Step 14
Navigate to Call Routing >Call Control Discovery >Hosted DN Croup and click
Add New.
In the Name field, enterPod-*_DN. Click Save.
Step 15
Step 16
Na% igate to Call Routing >Call Control Discovery >Hosted DN Pattern and
click Add New.
In the Hosted Pattern field, enter 851jc2XXX.
Step 17
From the Hosted DN Group drop-down menu, choose Pod-Jt DN.
Step 18
Step 19
For PSTN Failover Strip Digits, enter 4, and for PS'fN Failover Prepend Digits
enter +5551jc555. Click Save.
Click Add New.
'
Step 20
In the Hosted Pattern field, enter 85Zx3XXX.
Step 21 Step 22
From the Hosted DN Group drop-down menu, choose Pod-:r_DN. For PSTN Failover Strip Digits, enter 4, and for PSTN Failover Prepend Digits
enter +6651r555. Click Save.
Configure the Advertising Service
Step 23
Step 24
Step 25
Navigate to Call Routing >Call Control Discovery >Advertising Service and

click Add New.
In the Name field, enter CCD Advertising Service I.
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
From the SAF SIP Trunk drop-down menu, select SAFSlPTrunk, and from the
Step 27
Step 28 Step 29
Na\ igate to Call Routing >Call Control Discovery >Partition.

In the Name field, enter CCD_pt. Click Save. Add partition CCD lo the CSS GIobal_css.
Step 30
Step 31
Navigate to Call Routing >Call Control Discovery >Requesting Service.

In me Name field, enter CCD Requester.
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
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
Step 7
Navigate to Advanced Features >SAF >SAF Forwarder and click Add New.
Configure the SAF forwarder with the following settings:
Name: HQ.v_SAF Client Label: HQr_SAF
Note
Step 8
The client label needs to match the external client configured at Task 1
SAF Security Profile: IIQjSAF_Profile
SAF Forwarder Address: 10jf.250.l01
Click Show Advanced Link and move the CM_CUCM-1 Server to the Selected
Cisco Unified Communications Manager field.
Click Save.
StepS
Lab Guide
87
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
Step 1
Open a Telnet session to your HQ-.r router(IOjc. 1.10I).
Step 2
Step 3
Enter theconfigure terminal command to access theglobal configuration mode.

Enter the following commands:
i
router eigrp SAF

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
Step 6
Enter the configure terminal command toaccess the global configuration mode.
Enter the following commands:
router eigrp SAF

topology base
exit-sf-topology
neighbor 10.x.250.101 LoopbackO remote 16 exit-service-family
You have completed this task when you attain these results:
The SAF forwarders have been configured as described in the activity procedure.
86
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
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
Step 15
From the Selecta Servicedrop-down menu, choose the EM service. Click Next.
Step 16
Step 17
Click Subscribe, "fhe Cisco F.xiension Mobility service isdisplayed under

Subscribed Services.
Click Save, then close the window.
Step 18 Step 19
Click Reset in the Phone Configuration window to reset the phone. 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
Step 3
Choose the Cisco Extension Mobility service.

Log in with username and PIN.
Step 4
Step 5
The phone will reset and should (hen be loaded with your device profile, fhe
director, numbershouldchangeto 2405.
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
Step 2
minutes) to expire. You should be automatically logged out when the timer expires. 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.
Log in at Phone3-.v and place acall. Then wait for the maximum login timer (3
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
Cisco Systems, Inc. 2010
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
Step 2
Go to Device >Device Settings >Phone Services and click Add New.

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 appearCisco Extension Mobility does not
need any additional parameters to be specified.
Subscribe Device Profiles to the Cisco Extension Mobility IP PhoneService
Step 3
Step4
Nav igate to Device >Device Settings >Device Profile and click the Find button.
Click the device profile andy_dp.
Step 5 Step 6 Step 7

Step 8
At the Related Links, choose Subscribc/linsubscribe Services: then click Go. From the Select aService drop-down menu, choose the EM service. Click Next. Click Subscribe. The Cisco Extension Mobility service is displayed under
Subscribed Services.
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
;;010 Cisco Systems, Inc
At the Related Links choose Subscribc/linsubscribe Services: then click Co.

Lab Guide
Task 3: Add and Associate an End User with the User Device
Profile
this user with the newly created device profile.

Activity Procedure
In this task, you will add an end user to Cisco Unified Communications Manager and associate
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.
Click Save.
Steps
Step 6
In User Management > End User, verify that the end user "andy" has been added to
Cisco Unified Communications Manager.
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
Cisco Systems, Inc 2010
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
Step 1
Step 2
Nav igate to Device >Device Settings >Device Profile.

Click Add New.
Step 3
Step 4
Note
Step 5
Tor ihe phone model, choose Cisco 7965. Click Next.

Keep the SCCP signaling option and click Next.
If your Phonel -x is a different model, usethe model of your phone
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
Step 6
The phone button template depends on the phone model that you chose earlier.
Soflkey Template: Standard User
Click Save.
Step 7
In the Association Info pane, click the Line 111 Add anew DN link.
lor the director) number, enter 2405. Choose the route partition Internal. Choose the CSS HQ_Phones_CSS.
Step 11
Step 12
For the Exiemal Phone Number Mask value, enter +5551.v5552X\X.

Click Save.
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
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
Step 2
Open Cisco Unified Serviceability.

Go to Tools > Service Activation.
Step 3
Note
Step 4
Check the check box for the Cisco Extension Mobility service and click Save to
activate it.
The Cisco Extension Mobility service can be activated on multiple servers
In Cisco Unified Communications Manager Administration, navigate to Systc

Service Parameters.
Step 5
From the Serverdrop-down menu, choose ltLv.1.1.
Step 6
Step 7
From the Service drop-down menu, choose Cisco Extension Mobility.

Configure the following parameters:

Note
Enforce Intra-Cluster Maximum Login Time: True

Intra-Cluster Maximum Login Time: 0:03
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.
Steps
Intra-Cluster Multiple Login Behavior: Auto Logout

Remember the Last User Logged In:True
Clear Call Log on Intra-Cluster EM: True
Click Save.
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
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

Mobility
Subscribe IP phones and device profiles to the IP phone service for Cisco Extension
Visual Objective
The figure illustrates what vou will accomplish in this activity.
Lab 4-2: !rn
Mobility
=hpne'-< PI>one2
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
The local route group ofaroaming phone should be updated. Perform the following steps
for verification: Stepl
Step 2 Step 3
Nav igate to Device > Phone and click Find.

Choose Phone2-.v.
Settings link next to the Device Mobility Mode parameter. Awindow will pop up,
show ing ihecurrent configuration of the phone.
Note
At the phone configuration window, click the View Current Device Mobility
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
Step 5 Step 6
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.
Shut down the ISDN interface at the branch router so that the gatcwav cannot be
used for TEHO calls to the BR PSTN.
From the Phonc3-.v (which is currently roaming to the HQ site) place acall to the
the one configured in the roaming device pool.
IIQ-.v gateway. This indicates that the local route group ofthe phone was updated by
BR PSTN by using the home dial rules (for example, 9 5554444). 'fhe call uses the
78
Implementing Cisco Unified Communicatiot ;Manager, Part 2(CIPT2) v8.0
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
Step 20
Mov ethe Branch device pool from the Available Device Pools list to the Selected
Dev ice Pools list.
Click Save.
Enable Device Mobility Mode for the Cluster Step 21 Navigate to System>Service Parameters.
Step 22
Step 23
from the Server drop-down list, choose Cisco Unilied Communications Manager
10-v.l.l.
From die Service drop-down list, choose Cisco CallManager
Step 24
In Clusierwide Parameters (Device- Phone), set the Device Mobility Mode to On.
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
Step 2 Step 3
Disconnect Phonc2-.r and Phone3-.v from the switch port.

Reconnect Phone2-.r to the port of Phone3--v. Reconnect Phone3-.v lothe port of Phone2-v.
Step 4
Step 5
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.
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
Step 2
Nav igate to Device >Phone and click Find.

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
Step 5
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).
In order to sec that these updated settings are active, place acall from I'hone2-* lo
should be G.729.
Phonel -.v. Press the ?button twice at both phones. The codec that is used tor the cal
When it is in the home location, Phone2-x uses G.722 for calls to Phone1-x.
Lab Guide
Note
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
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
Step 3 Step 4
Description: Headquarters
Click Save.
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
Step 7
Navigate to System > Device Pool andclickthe Find button.

Choosethe device pool Default.
Step 8
Step 9
From the Physical Location drop-down menu, choose IIQ_pl.

Click Save and then reset the dev ice pool.
Step 10
Step 11
In the Related finks pane, select Back To Find/List and then click Ihe Go button.
Choosethe device pool Branch.
Step 12
Step 13
From the Physical Location drop-down menu, choose BR__pl.

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
76
Move the Default device pool from the Available Device Pools list lo ihe Selected
Device Pools list.
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v*02010 Cisco Systems. Inc.
Lab 4-1: Implementing Device Mobility

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
Lab 4-1; Implementing Device
Required Resources
These are the resources and equipment that arc required to complete this activitv

Student PC Cisco IP Phones
Cisco IOS MGCP gateway H.323 gateway
Lab Guide
75
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 Step 5
Step 6
Step 7
Configuration section.
Nav igate to Device >Device Settings >SIP Profile and click the Add button. In the Name field, enter SIPPrecondition, and scroll down lo the Trunk Specific
From the Reroute Incoming Request toNew Trunk Based On drop-down menu, select Never. '
From the RSVP Over SIP drop-down menu, select E2E and at theSIPRel IXX Options, choose Send PRACK if Ixx Contains SDP.
Step 8
Go to the configuration page ofthe existing trunk called SIPJI'runk.

Apply.
Step 9
From the SIP Profile drop down menu, select SIP_Precondition and click Save and
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
the bandwidth thatcan bereserved by RSVP as follows:
interface Serial...
ip rsvp bandwidth 4 0
Test RSVP SIP Preconditions CAC
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.
You configured SIP Preconditions between the two pods as described in the activity
procedure.
used for that call as described inthe activity procedure.

procedure.
You can place one call between the two pods over the SIP trunk and end-to-end RSVP is
When placing an additional call, the PSTN is used as abackup as described in the activity
Note Make sure lo turn off all of the debug commands at all of the routers (use no debug alt
command).
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) V8.0
Cisco Systems, Inc. 2010
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 Step 22
Step 23
Try calls between the headquarters and branch. The calls should be rerouted through
ihe PSTN.
Configure One Phone for an Alternate CFNB Destination
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.
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
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
Verify that one call between the headquarters and branch uses the IP WAN. Keep
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 endto-end CAC for calls between pod 1 and pod 2.
Activity Procedure
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.

and from the RSVP Setting drop down menu, choose Mandatory (V ideo Desired).
Click Save.
Lab Guide 73
Step 2
Step 3
Prom fhe Modifv Settings) to Other Locations pane, select the Iliib_None location,
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
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
Step 3
From the Service drop-down menu, choose Cisco CallManager.

Locate the Clusterwide Parameters(SystemCCM Automated Alternate
Routing) pane.
Step 4
Step 5
Set the Automated Alternate Routing Enable parameters toTrue.

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

Click Save.
Configuring Phones for AAR

Step 9
Step 10
Navigate to Device > Phone and click Find.

Choose Phonel-x.
Step 11
Click Line 1toget tothe Director) Number Configuration window.
Step 12
Step 13
Step 14
In the AAR Settings pane, choose System_AAR for the AAR Group.
Verify that the external phone number mask isin globalized format.
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
usedthe local route group.
Step 17
Step 18
Click Save and then OK in the pop-up window.

Reset the phone.
72
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
Test RSVP CAC
Add the BR-RSYP RSVP agent tothe BR-SW-CFB_mrg MRG.
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
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.
I stablish one call between a headquarters phone and the branch phone and keep the
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
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
Step 9
Use the main interface that is connected to the Frame Relay network (PSTN router).
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
Step 13
In Cisco Unified Communications Manager Administration, navigate to Media

Resources >Media Termination Point and click Add New.
Verify that the Media Termination Point Type value isCisco IOS Enhanced
Software Media Termination Point.
Step 14
Note
Enter HQ-RSVP for the Media Termination Point Name value.

Tne name ofthe media resource iscase-sensitive.
Step 15
Step 16
Note
Hnter HQ-* RSVP Agent for the description.

Choosethe device pool Default.
The location Hob^None and region HQ are applied to the HQ-RSVP media resource
through the device pool Default.
Click Save.
Step 17
Step 18
Note
Agent, and device pool to BR.
Click Copy and change the name to BR-RSVP, the description to HR-a RSVP 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
'
Step 12 Step 13
Step 14
Step 15
Repeat the previous steps lo apply the llub_Nonc location to the MOH.Only
device pool.
Repeat the previous steps to apply the Branch location to the BR device pool.
Nav igate lo Device >Trunk and click the Find button.
Choose the SIP_Trunk.
Step 16
Step 17
From the location drop-down menu, choose Trunk.

Click Save and reset the trunk.
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
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
Step 2
Nav igaie to System >Locations and click the Find button.

Click Branch.
Step 3
Step 4
Step 5
In the Modifv Sctting(s) to Other Locations pane, from the RSVP Setting drop-down
menu, choose the Hub_Nonc location and choose Mndatory(Vidco Desired).
Click Save. You should see the changes in the Location RSVP Settings pane. 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
H.323 gateway
Job Aids
This job aid is available to help you complete the lab activity.
Location Configuration
Name
Allowed Bandwidth
Applied To Device
Pool
Applied To Device
Hub_None
Branch Trunk
Unlimited
Default
MOH_0nly
24 kb/s 24 kb/s Branch
SIPJTrunk
Task 1: Configure Locations In this task you will configure locations-based CAC for calls between the headquarters, branch
and SIP trunk.
Add Locations to Cisco Unified Communications Manager Create new locations as described in the "Location Configuration" table in the .lob Aids section.
Step 1
Step 2
Navigate to System > Location and click the Find button.
Click the location name Hub_None to enter the Location Configuration window.
Make sure that the Hub^None location has unlimited audio bandwidth.
Click the Add New button.
Step 3 Step 4
Step 5
Configure anew location with the following parameters:

Name: Branch
Step 6
Step 7
Audio bandwidth should be limited to 24 kb/s
Click Save.
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
inthe Location Configuration" table in the Job Aids section.

Steps
Apply the newly created locations to devices, through the device pool or directly, as described
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 Step 11
From the Location drop-down menu, choose HubJSonc.

Click Save and reset the device pool.
68
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
Configure standard locations
completing this activity, you will be able lo meet these objectives:

Configure RSVP-enabled locations
methods
i Configure AAR to route calls over the PSTN ifthey arc not admitted by the deployed CAC
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:


Lab Guide
Enable Multicast MOH from Branch Router Flash at the BR-x SRST Router
Step 51 Configure the branch router as follows:
telephony-service
multicast moh 239.1.1.1 port 16384 route 10.x.4.102
Note
Step 52
The moh moh-file-name command that is used to enable unicast MOH in SRST mode already configured in an earlier lab exercise.
Saveyour configuration to NVRAM.
Verify That Multicast MOH from Branch Router Flash Works
Step 53
Step 54
Place acall from Phonel-* to Phone3-*, and at Phonel-*, put the call on hold
Phone3-* should play MOH. Keep the call in this state.
Pressthe Settings button at Phone3-x
Step 55 Step 56
Choose option 2 Network Configuration. Press 6orscroll down toget tooption 6 IPAddress.
Step 57
Step 58
Write down the IP address ofPhone3-*: 10.
.4.
Using a web browser, browse tothe IP address of Phone3-.v.
Step 59
Step 60
Click the Stream 1link to see details about the current RTP stream.
to the multicast MOH stream.
The local address should be 239.1.1.1/16384, which indicates thai the phone listens
The phone now plays the locally generated multicast MOH stream.
' ' . ___
Note
Branch phones can play MOH created by the local SRST router as described in the activity
procedure.
Note
More detailed verification was pan of the Activity Procedure.
66
Step 42 Step 43
Press the Settings button atPhone3-.v. Choose option 2 Network Configuration.
Press 6or scroll down to get to option 6. IP Address. Write down the IP address ofPhone3-.v: 10. .4. Using aweb browser, browse to the IP address of Phone3-.r.
Note Step 47
Step 48
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.
Click the Stream 1link to see details about the current RTP stream.
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...
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
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
branch phones, the MOH server needs to be placed into aseparate, dedicated region In
limit calls to these other devices to G.729 but allow G.7I Ibetween the MOH server and the
At this point, the MOH server shares the same region with all other headquarters devices To
Step 29
Step 30
In Cisco Unified Communications Manager Administration, navigate to System >

Region and click Add New.
Enter MOH for the name and click Save.
Step 31
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.
Using the Modify Relationship to other Regions pane, allow the G.722 and G711
Step 32
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.
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.
Using the same technique, also allow the G.722 and G.711 audio codecs for calls
Note
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

DateATime Group: CMLocal
Region: MOH SRST Reference: Disable
Cisco Unified Communications Manager Group: Default
Step 35
Click Save.
Step 36
Step 37
Navigate to Media Resources >Music On Hold Server and click lind.

Choose HQ-SVV-MOH.
Step 38
Step 39
Change the device pool from Default to MOH_Only.

Click Save.
Step 40
Reset the MOII server.
Verify That Multicast MOH Now Works to Branch Phones
Step 41
64
Phone3-.v should play MOH. Keep the call inthis state.
Place acall from Phone I,r to Phone3-x, and at Phone I-x put (lie call on hold
Implementing Cisco Unified Communications Manager. Par. 2(CIPT2) v8.0
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 Step 22
Press the Settings button at Phonc2-.v. Choose option 2 Network Configuration.
Step 23 Step24 Step 25

Note
Press 6or scroll down to get to option 6, IP Address. Writedown the IP address of Phonc2-.x: 10. .2. _ Using aweb browser, browse to the IP address ofPhone2-v.
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
Step 28
Note
The Local Address should be 239.1.1.1 /16384. which indicates that the phone listens
lo the multicast MOH stream.
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.
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
work well with music.
quality for music is poor; G.729 is designed and optimized for human speech, and does not
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
Update MRGs to Use Multicast
Step 14
Step 15
Navigate to Media Resources >Media Resource Group and click the Find button.
Choose the Generalmrg MRG.
Step 16
Step 17
Configuration window.
Click Save.
Multicast for HQ-SW-MOH Audio check box in the Media Resource Group
Ifat least one multicast HQ-SW-MOI Iresource is available, cheek the Use
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...
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;

interface Serial...
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
Stepl Step 2
Initiate an ad hoc conference from Phone3-jr (adding Phonel-* and Phone2,v>.
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
butnotbetween branch and headquarters. Keep the call open.
conference bridge is at the branch and G.7I I is only allowed locally at the branch
Step 3
Step 4 Step 5
At BR-.r. enter the show dspfarm cisp all command. You should see three used
connections representing the three conference participants.
r.nd the conference. Verifv thai all DSP resources arc freed by entering the sho
dspfarm dsp all command again.
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.
Repeat the previous steps but initiate the conference from Phone I-x or Phonc2-.v.
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
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
Step 3
Step 4
Choose the onlv available audio source and verify that the Play Continuously check
box is checked.
Check the Allow Multicasting check box.

Click Save.
Step 5
Step G
Nav igate to Media Resources >Music On Hold Server and click ihe Find button.
Click the only available MOI Iserver (HO-SW-MOH).
Step 7
Steps
Under Multicast Audio Source Information, check the Enable Multicast Audio
Sources on This MOH Server check box.
Click Save.
Step 9
Step 10
Verify the following parameters under Multicast Audio Source Information:

Base Multicast IP Address: 239.1.1.1 Base Multicast Port Number: 16384
Change the Increment Multicast value from Port Number to IP Address.

enabled audio source to 3.
Step 11 Under Selected Multicast Audio Sources, set the Max Hops value for the multicastStep 12 Click Save.
Step 13
Reset the MOII server.
Lab Guide
Step 17
Enter HQ_mrg for the name of the MRG.
Step 18
Step 19
Enter HQ SW Conference Bridge for the description. From the Available Media Resources pane, add HQ-SW-CFB to the Selected Media
Resources list. Click Save.
Step 20
Step 21
Create MRGLs
Repeat the previous steps to add the other two MRGs, as described in the "Media
Resource Group Configuration" table in theJobAids section.
conference bridge.
In these steps, you will configure dilTerenl MRGLs that allow IP phones to use their local
Navigate to Media Resources> Media Resource Group List.
Click the Add Newbutton. Enter HQ_mrgl for the name of the MRGL.
Step 22
Step 23 Step 24
Step 25
Step 26
General_mrg MRGs to the Selected Media Resource Groups list.

Click Save.
From the Available Media Resource Groups pane, add the HQ-SW-CFB and
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.
Assign MRGLs to Devices
gateways) by configuring the appropriate MRGL in the available device pools.

Step 28 Step 29 Navigate to System > Device Pooland click Find. Choosethe device pool Default.
In these steps, you will assign the newly created MRGLs to devices (phones, trunks and
'
Step 30
Step 31 Step 32
From the Media Resource Group List drop-down menu, choose IIQ_mrgl.
Click Save. Reset the device pool.
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.
BR-.v provides aconference hardware media resource (BR-HW-CFB) lhat is registered with Cisco Unified Communications Manager. Perform the following steps at router BR-v
to verity the hardware media resource configuration and statusand that the TCP Link Status is CONNECTED.
resources, and the listof supported codecs.
Step 1 Step 2
Enter the show seep command. Verify that the Conferencing Oper Stale is ACTIVE
Enter the show dspfarm profile 1command. Verify the stains, number ofavailable
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
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
for the Branch
Add the Cisco IOS Hardware Conference Bridge to Cisco Unified Communications Manager
Step 5
Step 6
Nav igate to Media Resources >Conference Bridge.

Click Add New
Step 7
Step 8
Note
From the Conference Bridge Type drop-down menu, choose Cisco IOS Fnhanced
Conference Bridge.
Inter BR-HW-CFB for ihe name ofthe media resource.

Themedia resource name is case-sensitive.
Step 9
Lnter Hardware Conference Bridge at BR-a" for the description.

region BR.
Step 10 Apply device pool BR to the transcoder. This device pool is configured with the
Step 11
Step 12
Set the device security mode to Non Secure Conference Bridge.

Click Save.
Step 13
Reset the newly created conference bridge.

Communications Manager 10..V.L1.
Step 14 Verily the registration status. It should say Registered with Cisco Unified
Create MRGs
Step 15
Step 16
Nav igate to Media Resources >Media Resource Group.

Lab Guide 59
Step 6
Step 7
Step 8
Note
From the Transcoder Type drop-down menu, choose Cisco IOS Knhanced Media
Termination Point.
Enter Hardware Transcoder at HQ-x for the description.

Enter HQ-HVV-XCD forthename of themedia resource.
The media resource name is case-sensitive.
Step 9
Step 10
Step 11
the region HQ.
Apply the device pool Default to the transcoder. This device pool is configured with
Click Save.
Reset the newly created transcoder.
Step 12
Verify the registration status. Itshould say Registered with Cisco Unified
Communications Manager 10jr. I. I.
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-*
toverify the hardware media resource configuration and status:
and that the TCP Link Status is CONNECTED.
Step 1 Step 2
Enter the show seep command. Verify that the Transcoding Oper State is ACTIVE 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
performing the following steps:
even though they are not allowed to use the G.711 codec over the IP WAN. Verify this by
Set up an ad hoc conference with Phonel-*, Phone2-*, and Phone3-.v as members.
G.711 codec being used for the call, while Phone3-* shows G.729.
Step 1
Step 2 At each IP phone press the ?button twice. Phonel-* and Phone2-.r should show the
Step 3 At HQ-.v. enter the show dspfarm dsp all command. You should see two used
conference bndge and G.729 to Phone3-*).
connections representing the two call legs ofthe transcoder (G.711 tothe software
Task 4: Implement a Hardware Conference Bridge

implement MRGs and MRGLs to ensure that IP phones use the local conference media
resource.
In this task, you will configure alocal hardware conference bridge at the branch You will
Activity Procedure
Configure aCisco IOS Router as aHardware Conference Media Resource for the Branch
Step 1 Connect to your BR-*.
Step 2
Enter configuration mode.
58
Task 3: Implement Transcoders

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.
to join confe'renccs on aG.711-only software conference bridge, even though branch phones
In this task vou will implement atranscoder at the headquarters in order lo allow branch users
Activity Procedure
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.

commands:
voice-card 0
Step 2 To configure router DSP resources to be used as atranscoder. enter this sequence of
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

no shutdown
Step 3
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
Steps
Navigate to Media Resources >Transcoder.

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

Click Save.
Step 37
process at the BR gateway by entering the no mgcp command, followed by the

morn rnmmnniH mgcp command.
Reset the gateway in Cisco Unified Communications Manager and reset the MGCP
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
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
Step 17
Verify that the region issetto HQ.
Step 18
Step 19
Step 20
Step 21
At the relaled links, choose Back To Find/List and click Go.

Choose the Branch device pool.
Change the region lo BR.
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
routegroup HQ_rg configured. ^^_
group). Until now, the trunk had the device pool Detault applied, which also has the local
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.

Default and Phone3-.v is listed with device pool Branch.
Step 26 At the list of phones, verify that Phonel* and Phonc2-x are listed with device pool
Note
Step 27
Step 28
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.
Navigate to Device >Trunk and click Find.

Choose the SIP-Trunk.
Step 29
Step 30
Change the dev ice pool from Default to Trunks.

Click Save.
Step 31
Step 32 Nav igate to Device >Gateway, choose the option to Show endpoints. and click 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
Reset the trunk.

Find.
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.
You can establish ad hoc conferences using the HQ-SW-CFB conference resource Verily
Task 2: Configure Regions

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.
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
Create and Configure Regions

Step 1
Step 2 Step 3
Step 4
Navigate to System > Regionandclick Find.

Choose the region Default. Change the name to HQ.
Verify that G.722/G.7I Iaudio codecs are allowed for calls within region
headquarters.
Click Save.
Step 5
Step 6
Step 7
Step 8
Enter Trunks for the name ofthe new region and click Save.
for calls within region Trunks by highlighting Trunks in the Regions list and
TJ-." /Villi- llJltliin Hr^x^-^^.^- T 1.1 I II . , -
Using the Modify Relationship to other Regions pane, allow the G.729 audio codec
choosing G.729 from the Audio Codec drop-down menu. Click Save.
Step 9
Using the same technique, allow the G.729 audio codec for calls between region
Trunks and region HQ.
Note
The changes will then appear in the Region Relationships pane.

Step 10 Click Add New.
You must click Save after each change in the Modify Relationship to Other Regions pane
Step 11 Step 12
Step 13
Enter BR for the name ofthe new region and click Save. Allow G.722/G.711 for calls within region BR.
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
with the new regions, as described in the "Device Pool Configuration" table in .he Job Aids
otciions.
In these steps, you add anew device pool for the trunks and update the existing device pools
Navigate to System >Device Pool and click the Find button.
Choose the Default device pool.
Step 15
Step 16
54
>2010 Cisco Systems. Inc.
Task 1: Enable Software Media Resources on Cisco Unified

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 w change the default names and descriptions of these media resources. ill
Activity Procedure
Verify That the Cisco IP Voice Media Streaming Application Service Is Activated
Step 1
Feature Services.
Log in to Cisco Unified Serviceability and navigate to Tools >Control Center-
Step 2
Note
Verify that the Cisco IP Voice Media Streaming App service is activated and
running at CUCMl-.v.
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
Step 5
Verify the status of the media resource. It should be registered with your Cisco
Unitied Communications Manager CUCMI-x (IO.r. I.I).
Click the shown Annunciator media resource (ANN_2).
Step 6
Step 7
Step8
Change the Name to HQ-SW-ANN and the description lo Software Annunciator

atCICMl-.Y.
Verifv that the Device Pool is Default.

Click Save.
Step9
Reset the media resource.

values:
Media Resource
Name
Step 10 Repeal the previous steps for the following media resources using the specified
Description Software Conference Bridge at
CUCMI-x
Conference Bridge
HQ-SW-CFB
Media Termination
Point
HQ-SW-MTP
Software Media Termination

Point at CUCMI-x
MOH Server
HQ-SW-MOH
Software MOH Server at

CUCMI-x
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
Job Aids
These job aids are available to help you complete the lab activity.
Region Configuration
HQ HQ Trunks
BR
Trunks
G.729
BR
G.711 G.729
G.729
G.729 G.729
G.711
G.729
G729
Note
Region Default, which exists by default, will be renamed to HQ.
Media Resource Group Configuration

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

Name
HQ_mrgl BR_mrgl
Contains I ContainsMedia Resource Groups

HQ_mrg General_mrg
BR_mrg
Generaljnrg
Device Pool Configuration

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

BR-HW-CFB
52
Lab 3-1: Implementing Bandwidth Management

Activity Objective
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:
In this activitv. vou will configure multicast MOH from branch router flash, regions, local
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
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.
npiement multicast MOH from branch

router flash
Implementlocalconference bndge;
Required Resources
These arc the resources and equipment that are required to complete this activity:

Lab Guide
Step 4
down in Step 2.
Step 5
When prompted for the IP address of the FTP server, enter the IP address you wrote
For the source filename, enter moh.au.
Steps
Step 7
Confirm the destination filename (moh.au) and wait for the file to be copied.
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.
Branch phones can listen to MOH when put on hold. This can be verified by performing
the following steps:
Step 1
Step 2
Place a call between aheadquarters phone and the branch phone.

At the branch phone (Phone3-^). putthecall on hold.
Step 3
Note
The headquarters phone should play MOH coming from the branch router.
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
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 telephonyservicetftp-bindings command.
To verify that SRST isworking, follow these steps:
Step 1 Step 2
Step 3
list 100 in the incoming direction atthe interface ofthe HQ-.r router that connects to
the BR-.v router.
Break connective lo Cisco Unified Communications Manager by reapplying access 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.
2002). The call should work: the calling party number should be the I0-digit PS IN
number of the branch phone.
Place acall from Phone3-.r to aheadquarters phone (use internal dialing: 2001 or
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
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
Step 2
At PC-v. navigate to Start >Run and enter the cmtl command.

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.
Step 3
-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. C this opy tile to the Hash of vour BR-.v router by entering the copy ftp flash command:
Lab Guide
H.323 gateway
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 Step 2
Log in tothe BR-j router and enter configuration mode. 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
the following commands:

telephony-service
Enable Cisco Unified Communications Manager Express in SRSI mode by entering

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.02010 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
Communications Manager. In addition, you will enable MOII. After completing this activity,
you will be able to meet these objectives;
mode to provide basic telephony services lo phones that lost the connection to Cisco Unified
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 Manager Express in SRST Mode
Communications
Required Resources These are the resources and equipment that arc required to complete this activity:

Student PC
Cisco IP Phones
Cisco IOS MGCP gatewa;
Lab Guide
& 2010 Cisco Systems, Inc.
Step 16
Step 17
300I).
Place atest call to the branch phones of the other pod using site-code dialing (852v
Save your configuration changes.
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.
the other pod asdescribed in the activity procedure.
From Phone3,v. you can use the internal numbering plan to reach sites within the pod .
Detailed verification was part of the activity procedure.
Note
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
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.

number of Phone3-.v (52r 555 3001).
Step 10 Verily that the calling number ofthe outgoing calls is now placed with the PSTN
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
Configure the Branch SRST Router toAllow Outgoing Calls

allowoutgoing PSTN calls.
In these steps, you will add adestination pattern to the existing POTS dial peer Iin order to
At BR-.t. enter the following commands in configuration mode:
Step 5
destination-pattern 9011T
prefix Oil
port 0/0/0:23
destination-pattern 911
prefix 911 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]

prefix 1
port 0/0/0:23
destination-pattern 9 [2-9]
port 0/0/0:23
interface serial 0/0/0:23 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
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
Verify that outgoing calls are working by calling 9011 55 Six 5552001 from
cisco Sys(emSi ,nc 2D10
Step 2
The call arrives at BR-.v. but DID is not enabled and the called party number is a 10digit number and not a4-digit director) number.
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
Verifv using the debug isdn q931 command whether the call hits the HR-* gateway.
Note
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
Configure the Branch SRST Router toAllow Incoming Calls In these steps. > will configure an inbound dial peer to allow incoming calls to be routed ou
correcllv.
Step 1
l.nable DID for the voice port that connects to the PSTN by entering the following
commands:
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
bv entering the following commands:
PSTN (the complete PSTN number 52.x 55530(11) to the four-digit directorv number,
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.
of the calling phone.
Lab Guide
Note 'that the calling parly number that is displayed at Phone3,v is the PS IN number
Task 3: Implement a Dial Plan in Cisco Unified
SRST Mode
Communications Manager Supporting Outbound Calls Durina

main siteto call remote phones viathe PS'fN in SRST mode.
In this task, you will configure CFUR for remote phones to allow phones that are located at the
Activity Procedure
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 Step 3
Step 4
From the Service drop-down menu, choose the Cisco CalfManager service. In the Clusterwide Parameters (FeatureForward) pane, change Ihe Max Forward
UnRegistered Hops toDN parameter to2 (default is0).
Click Save.
Configure CFUR for the Branch Phone
Step 5
Navigate toCall Routing >Directory Number and click the Find button.
Step 6
Step 7
From the result list, click directorv number3001, which is in the Internal partition. 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
Step 8
CSS: GlobaI_css
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
usedthe local route group.
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
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.
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
Step 2
i; nter the debug ephone register command to start debugging.

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 ...
Note
Step 4
Use the interface that connects the HQ-x route with the BR-x router
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 "ephonel|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
HJ23 gateway
Task 1: Configure SRST Gateways in Cisco Unified Communications Manager

and apply the device pool toremote phones.
Activity Procedure
In this task, you will add an SRST reference, configure adevice pool with the SRST reference
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)
Step 2
Step 3
IP Address: 10jt.250.102 (loopbackO)
Configure the BR Device Pool withthe New SRST Reference

At the BR device pool, set the SRST reference to BR-x.
Reset the device pool.
Anew SRST reference is configured in System >SRST as described in the activity

procedure.
The SRST reference is assigned to the branch IP phone. This can be verified at Ihe phone
by performing the following steps:
Step 1
Step 2 Step 3
Press the Settings button.

Choose option 3 Device Configuration. Choose option I CallManager Configuration.
Step 4
The second entry should read "CallManager 2SRST," and when you choose Select the IP address of the loopback interface ofBR-* (10jc.250.I02) should be shown.
SRST
Task 2: Configure a Cisco IOS Gateway for MGCP Fallback and

In this task, you will configure SRST and MGCP Fallback support at aCisco IOS gateway.
Activity Procedure
Configure the Gateway for SRST
Step 1
Log in to your BR-x router and enter configuration mode.
40
Lab 2-1: Implementing SRST and MGCP Fallback

Complete this lab activity to practice what you learned in the related module. Activity Objective IP phones, and MGCP fallback for gateway survivability. After completing this activity, you
will be able lo meet these objectives:
In this activ itv vou will configure Cisco Linified SRST to provide call survivability for Cisco
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
Lab 2-1; implementing SRST and MGCP

Fallback
Required Resources These are the resources and equipment that are required to complete this activity:

Lab Guide
39
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
Step 3
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.
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
isdn q93I command at the gateways ofthe other pod to verify that the TEHO
Place test calls to TEHO PSTN destinations located at the other pod. Use the debug
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
Step 5
Shut down the serial interface that connects your pod with the other pod.
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
Cisco Systems. Inc. 2010
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
Partition; System
V+5551yf2-9]XXXXXX
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
\+55.51y5552XXX Configuration 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
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
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
theLocalization 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
verify that the TEHO gateway is used. Make sure that for IEl 10 calls through the HQ gateway, the calling number is the number ofthe BR phone (in international
Place test calls toTEHO PSTN destinations. Use the debug isdn q931 command to
format) while the calling number for TEHO calls through the BR gateway isnot the IIQ number but the number ofthe BR attendant (52x5553001).
Verify PSTN Backup for TEHO Within the Pod Step 6 Shut down the ISDN interface at the IIQ gateway and try placing aTEI10 call from
the BR phone. Because the primary path (through the TEHO gateway) does not
work, the local gateway (BR) should beused asa backup.
Step 7
Step 8
Step 9
Use the no shutdown command on the ISDN interface.

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 work, the local gateway (HQ) should be used as a backup.
Use the no shutdown command on the ISDN interface.
You have completed this task when youattain this result:
You can place TEHO calls within your pod as described in the activity procedure.
When IP connectivity between the two siles is broken, the local gateway is used as a
backup as described in the activity procedure.
36
Cisco Systems, lire 2010
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 Partition. System
\+5551x[2-9]XXXXXX
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
Pattern
Configuration
\+.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)
numbers without number types ^
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
Activity Procedure
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. focal Route Group item to the route list. Make sure that the BR_rg is listed first.
Lab Guide
Step 2
Create aroute list that is called TUIO-BR.rl and add the BR_rg and the Standard
35
Step 11
Make sure that the callingnumberis shown with the internally used directorynumber 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.
Use the no shutdown command on the serial interface.
Step 14
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 sitecode dial prefix as described in the activity procedure.
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 Step 7 Apply the CSS Ininkjjss to the SIP trunk. 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.
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
Note
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
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.
Lab Guide
Changing the Called Number of Calls Received Through the SIP Trunk
Translation Pattern \+5551x555 2XXX
Configuration
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
\+5551y555 2XXX Configuration 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)

Prefix: 852/555
\+6652y555.3XXX
Partition: xform-cg_BR-phones Description: BR-Phones (other pod BR)

Prefix: 852y555
Activity Procedure
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.
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.
Configure Translation Patterns to Globalize Intersite Calls Step 3
32
Implemenling Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0
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
Partition: Global
851/2XXX
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
Partition: System
\+5551y
5552XXX
Description HQ of other pod Urgent Priority: deactivated Gateway/Route List: lntersite_rl
H6652/
5553XXX
Partition System Description: BR of other pod
Urgent Priority: deactivated Gateway/Route List. Intersite_rl
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

Note
Description: Calls to Globalized Numbers CSS: System_css Urgent Priority: activated

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.
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
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.
You can call the HQ phones by any valid PSTN number, regardless of the line of the PSTN
Note
phone that you use Valid numbers are: 555-2001 and 555-2002, 0-51x-555-2001 and 051x-555-2002, 00-55-51X-555-2001 and 00-55-51X-555-2002.
Step 16
Step 17
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. 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.
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-5553001
Note
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. 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.
Step 20
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.
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
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
\+5551xXXXXXXX
Configuration
Partition: xform-cg_HQ-phones Description HQ-Phones (Local)
\+55 XXXXXXXXXX
Partition: xform-cgJHQ-phones
Description. HQ-Phones (National)

Prefix: 0
\+66 XXXXXXXXXX
Partition: xform-cg_BR-phones Description: BR-Phones (Local, National)

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
Configure the H.323 Gateway to Support Inbound PSTN Calls Reconfigure the existing POTS dial peerto support inbound PSTN calls: Step 1
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

2010 Cisco Systems Inc
Lab Guide
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
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.
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
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 Step 12 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. 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
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.
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
\+5551x5552XXX
Configuration
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
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
\+5551xXXXXXXX
Configuration Partition: xform-cd_HQ-out Description HQ (Local)

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)

Prefix: 0
Called Party Number Type: International

\+.112
Partition xform-cd_HQ-out
Description: HQ (Emergency)

Prefix: 0
Called Party Number Type: Unknown

\+S652x XXXXXXX
Partition xform-cd_BR-out
Description: BR (Local)

\+66 XXXXXXXXXX
Partition xform-cd_BR-out Description: BR (National)

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
Globalization of Called and Calling Parties During Call Ingress for Outbound
PSTN Calls Placed from BR Phones
Translation Pattern 9011.!
Configuration 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 [2-9]XX
XXXX
Partition BR_PSTN Description: BR (National)
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
XXXX
Partition. BR_PSTN Description: BR (Local) CSS: System_css

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

Calling Party. Use external phone number mask: activated

9.911
Partition BR_PSTN Description: BR (Emergency) CSS: System_css Urgent Priority: activated (default setting)
Called Party: Discard Digits Instructions: PreDot Called Party Prefix Digits. +
22
2010CiscoSystems, Inc.
Translation Pattern
0.112
Configuration
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
000.!
Configuration
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

000 !#
Partition: HQ_PSTN Description: HQ (Intl, #)
CSS. System_css Urgent Priority: deactivated

Called Party: Discard Digits Instructions: PreDot Trailing-* Called Party Prefix Digits: +
00.[2-9]XX [2-9]XX
XXXX
Partition: HQ_PSTN Description: HQ (National)
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
XXXX
Partition: HQ_PSTN 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
Step 5
Enter the following parameters in the Calling Search Space Configuration window:
Name: HQ-Phones_css
Step 6
Description: HQ Phones
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
Step 7
IIQ_PSTN
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
Note
Click the IP phone with the directory number 2001 (Phonel-.v) to open the Phone Configuration window.
From the left column, click Line |l]2001 (no partition) to access the Directory Number Configuration window. Choose Internal for the Route Partition. Assign CSS HQ_Phoncs_css to the line.
Make sure that you assign this CSS to the line level of the phone.
Step 14
Step 15
Note
from Related Links, chooseConfigure Deviceand click Go to get back lo the

Phone Configuration window.
Assign CSS Global_css lo the phone.

Make sure that you assign this CSS to the device level of the phone
Step 16 Step 17
Click Save and then, in the pop-up window, click OK. Repeat these steps to for Phone2-.v.
Step 18
Step 19
Repeat the above steps for Phone3-.v. butapply CSS RR Phones_css to the fine level
instead of CSS H()_Phoncs_css. 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.
) 2010 Cisco Systems. !nc
Lab Guide
CSSs
CSS Name
Description HQ phones
Contains Partitions
Internal
Assigned to Devices
HQ Phone lines
HQ_Phones_css
HQ_PSTN BR_Phones_css BR phones

Internal
BR Phone lines
BR_PSTN Global_css
Trunk_css
General external
access
Global
All Phones (device level)
Calls received over SIP trunk
Internal
SIP trunk
System System xform-cd_HQ-out xform-cg_HQ-out xform-cd_BR-out

xform-cg_BR-out
System^css
xform-cd-HQ-
Route patterns
(globalized) XF called, HQ out
Translation patterns HQ gateway HQ gateway

BR gateway
out_css
xform-cg-HQout_css xform-cd-BR-out_css xform-cg-BR-out_css
XF calling, HQ out
XF called, BR out
XF calling, BR out XF calling, HQ phones XF calling, BR

phones
BR gateway HQ phones BR phones
xform-cgJHQphones_css xform-cg_BRphones_css
xform-cg_HQ-phones xform-cg_BR-phones
Activity Procedure
Configure Partitions In these steps, you will configure the partitions lhat are listed in the "Partitions" table of the Job
Aids section.
Step 1 Step 2
In Cisco Unified Communications Manager Administration, navigate to ("all

Routing > Class of Control > Partition, and click Add New.
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.
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 Internal Global
Description Internal IP phones General patterns
Assigned to Phones or Patterns Directory numbers of phones

Translation patterns that are used for sile-code dialing and natively dialed globalized numbers Translation patterns that are used
HQ_PSTN
PSTN as dialed by HQ users PSTN as dialed by BR users

System patterns
for HQ PSTN dialing
BR_PSTN
System
Translation patterns that are used
for BR PSTN dialing

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_HQphones
xform-cg_BR- phones
XF calling, HQ phones
Calling party transformation patterns that are applied to HQ phones for

inbound calls
XF calling, BR phones
Calling party transformation patterns that are applied to BR phones for

inbound calls
20' 0 Cisco Systems. Inc
Lab Guide
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 Phonel-x Phone2-x
BR-x
E.164 Number with + Prefix

+55 51x555 2001
HQ-x
+55 51x555 2002 +66 52x 555 3001
Phone3-x
HQ-y
Phonel -y Phone2-y
+55 51/555 2001 +55 51/ 555 2002 +66 52/555 3001
BR-y
Phone3-y
Intersite Dialing
Site
IP Phone
Intersite Dialing
8 51/2001
HQ-y
Phonel-y Phone2-y
8 51/2002
8 52/ 3001
BR-y
Phone3-y
PSTN Access Codes and Emergency Numbers

Location HQ BR
PSTN Access Code

0 9
National Access
0
1
International Access
00 011
Emergency
112,0112 911,9 911
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
Lab 1-2: Implementing a Dial Plan for International Multisite Deployments

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
Configure site codes tor intercluster calls
Configure PSTN backup for intercluster calls

Configure TEHO with local backup
Visual Objective
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:

Student PC
Cisco IP phones
Lab Guide
) 2010 Cisco Systems. Inc.
Note
Further verification will be done in the next lab exercise.
Task 5: Configure a SIP Trunk in Cisco Unified

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
Step 2
In Cisco Unified Communications Manager Administration, choose Device >

Trunk.
Step 3
From the Trunk Type drop-down menu, choose SIP Trunk.
Step4
Step 5
FortheTrunk Service Typedropdownmenu, leave None(Defaull). Click Next.

In the Trunk Configuration window, enter the following parameters:
Device Name: SIP_Trunk
Description: SIP Trunk to POD/

Device Pool: Default

Step 9 Step 10
Step 11
In the SIP Information pane, enter the IP address of the other pod's Cisco Unilied
Communications Manager server: \0.y.\A.
Make sure that the Destination Address is an SRV box is not checked. From the SIP Trunk Security Profile drop-down menu, choose Non Secure SIP
Trunk Profile.
From the SIP Profile drop-down menu, choose Standard SIP Profile. Click Save, and then, in the pop-up window, click OK.
Reset the newly added SIP trunk.
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
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
shutdown
0/0/0
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.
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: Navigate lo Device > Gateway.
Step 1
Step 2
Choose the option lo Shaw endpoinls and click Find. The status of the endpoint should be registered with IO.v.I.I.
LabGuide 13
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.
Further verification will be done in the next task.
Note
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
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 Step 4
Display the network interfaces and their IP configurations by entering Ihe show ip
interface brief command.
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
Step 7
Enter the debug ccm-manager con fig-down load events command to debug the
configuration server feature events.
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.
Save your configuration changes using ihe copy running-config startup-config
command.
Step 10
12
Implementing Cisco UnrfiedCommunications Manager, Part 2 (CIPT2) v8.0
Note
Task 3: Add an MGCP Gateway to Cisco Unified Communications Manager

Inthistask. >ou will addan MGCP gateway to Cisco Unified Communications Manager.
Activity Procedure
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 Step 2
In Cisco Unified Communications Manager Administration, choose Device >

Gateway and click the Add \cw button.
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. From the Protocol drop-down menu, choose the protocol type MGCP and click
Next
Step 3 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 Step 7
Click the port icon on the right of the displayed endpoint 0/0/0. 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
Step 9
Click Save and. when the pop-up window appears, click OK.
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.
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
Add an H.323 Gateway to Cisco Unified Communications Manager

Step 2
Step 3
Navigate to Device > Gateway to display the find and List Gateways window.
Step 4
Step 5
from the Gateway '1 ype drop-down menu, choose 11.323 Gateway.
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.
You ha\e added a new H.323 gateway in Device > Gateway.
Note
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
Step4 Step5
Display the status of your ISDN PRI by entering theshowisdnstatuscommand.

Display the network interfaces andtheir IP configurations by entering the show ip
interface brief command.
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
Communications
IP Addr (as
Function
Login Administration User and

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
Name HQ-x
IP Addrpss
Function
Login Password and Enable Secret
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
Number
Location
Phonel-x Phone2-x
Phone3-x
DHCP subnet 10.X.2.0/24

2001
Headquarters Headquarters
Branch office
2002
3001
Task 1: Add an H.323 Gatew
iy to Cisco Unified
In this task, you will add the HQ-.v -1.323 gateway to Cisco Unified Communications Manager
Activity Procedure
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

s.
Aids section of this guic
Lab 1-1: Implementing Basic Multisite

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

Student PC
Lab Guide
The figure pros idesa summary of (hedial plan.
Dial Plan Summs ry

intiyCode: 55
HQ-I 2 XXX 5552XXX
51*S552XXX
55 5U555 2XXX
PSTN Access Code 0

Mati
5552XXX
al Access Code: 0
Access Coda I
51y5552XXX 55 51/5552XXX
HQ-y zxxx
:; ;xx x
b [2^:X< [i."';>* xtxx

G 'nTf' [2 u'XX *Xi* 'i :.ffi p.-j;xx <xx<
;;-?jxx \:
iiS5..XXX U.^.-J55-3XXX 00-55-51 <-55S-XX>; 55S-3XXX

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 80C [J 1 i'OO [25SXXXX <X*XXX
1 51iE5!)?XXX (HIMMlBSSiXXX 5553XXX 1 52* 555 3XXX 011 SB 521 555 3XXX
5553XXX
52I5553XXX
y Code: 66
j Access Code: 9
555 3XXX
66 521 555 3XXX
Ial Access Code: 1

nal Access Code: 011
52/555 3X XX 66 52y 555 3XXX
Note
The blue text boxes
towards PSTN-Phone-x indicate how thenumber isdialed by HQ-x and
;s) BR-x users (leftblue boxs) 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
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
Local
Calling Number Presentation

556 4444, TON - subscriber 606 555 4444, TON = national
77 606 555 4444, TON = international
"PSTN"
National Intemtl
800
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
Controller type
Framing
Line code E1 crc4 hdb3 line
BR-x Gateways
T1
esf
b8zs
Clock source
line
Timeslot range
ISDN switch type
1-8, 16
1-8.24
net5
primary
pnmary-ni
Lab Guide
Calls Sent to PSTN-Phone-x

Received from HQ-x Sites
Received from BR-x Sites
Local calls
Sent to PSTNPhone-x Line Local
[2-9JXX XXXX
TON = subscriber
[2-9]XXXXXX
1 [2-9]XX 2-9]XX
XXXX
National calls
[2-9JXX [2-9JXX XXXX,

TON = national
National
international calls
(E.164 number of any length),

TON = international
011 {E.164 number of any length)

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

TON = national
800
Premium calls
900 [2-9JXX XXXX,

TON = national
Premium
Emergency calls
112,
TON = Unknown
911
Emergency
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 PSTNNumber Dialed at PSTN-
Phone-x, Sent to HQ-x Site

Local calls National calls
International calls 555 2XXX
Phone-x, Sent to BR-x Site

555 3XXX 1 52x 555 3XXX
011 66 52x555 3XXX
0 51X555 2XXX
00 55 51x 555 2XXX
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.
) 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
3XXX
Internal directory number range PSTN range in local (subscriber) format PSTN range in national format
PSTN range in international format
PSTN access code
National access code
International access code
2XXX
555 2XXX 51x555 2XXX 55 51* 555 2XXX

0 0
00
555 3XXX 52x 555 3XXX

66 52x 555 3XXX 9
1
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
Local calls
Received from BR-x Sites
[2-9]XX XXXX,
TON = subscriber
[2-9]XX XXXX 1 52x [2-9]XX XXXX

011 (E.164 number of any length)
National calls
51x[2-9]XXXXXX.
TON - national
International calls
(E 164 number of any length),

TON = international
Toll-free calls
800 [2-9JXX XXXX,

TON = national
1 800 [2-9]XX XXXX 1 900 [2-9]XX XXXX
Premium calls
900 [2-9]XX [2-9]XXX,

TON - national
Emergency calls
112, TON = Unknown
911
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:
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
Note _ - x,
DHCPf*^
10 y 2 0/24 followed by y (in
DHCPP*^
ascending order)
DHCP t
10. 1 0/24 10yHQ1-J
, 101 10700/16 ^101
101 10y30J2J
DHCP
HQ1-y\ "
10y10C4
10 >_50 101/32 10
10 y 250 101/32
BR_y
Ptione3-y
10 y.250.102/3
1011 0/24
4_ffiL_
DHCP
*-_*
Pody
iA~-*
(PSI^? 10jj4 0/24 T*'

M02
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
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
lab 2-1 Lab 2-2
Lab 3-1
Implementinga Dial Plan for Internalional Multisite Deployments

Implementing SRST and MGCP fallback
Implementing Cisco Unified Communications Manager Kxpress in SRSI" Mode

Implementing Bandwidth Management Implementing CAC Implemenling Device Mobility Implemenling Cisco Fxtension Mobility Implementing Cisco SAP and CCD
Lab 3-2 Lab 4-1

Lab 4-2
Lab 5-1
Answer Ke\
Lab 3-2: Implementing CAC ActivityObjective Visual Objective

Required Resources
Job Aids
67 67 67
67 68
Task 1: Configure Locations
68 69
Task 2: Configure RSVP-Enabled Locations

Task4 (Optional): Configure SIP Pre[x>nditions
Lab 4-1: Implementing Device Mobility Activity Objective Visual Objective Required Resources Task 1: Configure Device Mobility
Task 3: Configure AAR and CFNB to Route Calls over the PSTN If They Are Not Admitted by the 72 Deployed CAC Methods
73
75 75
75 75 76
Lab 4-2: Implementing CiscoExtension lability

Activity Objective Visual Objective Required Resources
Task 1: Activate the Cisco Extension
Parameters
79 79
79 79
Mobility Service and Configure the Corresponding Service

80 81 82
Task 2: Create a Device Profile for a User
Task 3: Add and Associate an End U ser with the User Device Profile
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 ActivityObjective
85 85
Visual Objective Required Resources
85 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 91 Leam Routes Using CCD Answer Key 96
Lab 1-1 Answer Key: Implementing Basic Multisite Connections

Lab 1-2 Answer Key: Implementing a Dial Plan for International Multisite Deployments Lab 2-1 Answer Key: Implementing RST and MGCP Fallback
Mode
96
96 96 96
96 96 96 96
Lab 2-2Answer Key: Implementing (Jisco Unified Communications Manager Express in SRST
Lab 3-1 Answer Key: Implementing Ejandwidth Management

Lab 3-2 Lab 4-1 Lab 4-2 Lab 5-1 Answer Answer Answer Answer Key: Implementing Key: Implementing Key: Implementing Key: Implementing CAC Cevice Mobility Cisco Extension Mobility . AF and CCD
96
Table of Contents
Lab Guide Overview Outline Lab Topology Dial Plan Information Lab 1-1: Implementing Basic Multisite Connections Activity Objective Visual Objective Required Resources
Job Aids
1 1 2 2 7 7 7 7
8
Task 1: Add an H.323 Gateway to Cisco Unified Communications Manager Task 2: Configure an H.323 Gateway Task 3: Add an MGCP Gateway to Cisco Unified Communications Manager Task 4: Configure an MGCP Gateway Task 5: Configure a SIP Trunk in Cisco Unified Communications Manager Lab 1-2: Implementing a Dial Plan for International Multisite Deployments Activity Objective Visual Objective Required Resources
Job Aids
8 9 11 12 14 15 15 15 15
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 ActivityObjective Visual Objective
47 47 47
Required Resources Task 1: Configure Cisco Unified Communications Manager Express in SRST Fallback Mode Task 2: Configure MOHon Cisco Unified Communications Manager Express Lab 3-1: Implementing Bandwidth Management Activity Objective Visual Objective Required Resources
Job Aids Task 1: Enable Software Media Resources on Cisco Unified Communications Manager
47 48 49 51 51 51 51
52 53
Task Task Task Task
2: Configure Regions
3: Implement Transcoders
4: Implement a Hardware Conference Bridge 5: Implement Multicast MOHfrom Branch Router Flash
54 57 58 61
5-74
Impiementing Cisco Unified Communications Manaj :f, Part 2(CIPT2) v8.0

OD y_) D.G 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)
Call Control Discovery
06)
Which CSS isused for CCD PSTN backup calls? (Source: Implementing SAF and
CCD)
A) B)
C)
line CSS of the originating phone device CSS of the originating phone
CSS of the SAF trunk
D) K)
AAR CSS of the originating phone CSS of the PSTN gateway
5-72
Implementing Cisco Unitied Communications Managt -, Part 2 (CIPT2) vB.O
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) B) Cisco Unified SRST Cisco IOS gateway
C) I)) F.)
Cisco Unified Border Element Cisco IOS gatekeeper Cisco Unified Communications Manager
F)
G)
Cisco Unified Communications Manager Express

Cisco IOS Catalyst switches
Q2)
Which two statements are true about SAF? (Choose two.) (Source: Implementing SAF
and CCD)
A) B) C)
D|
SAF forwarders interpret the SAF header and SAF service data. An internal SAF client is allocated with a SAF forwarder. An internal SAF client resides in Cisco Unified Communications Manager.
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) B) C)
Call routing information is learned by the CCD requesting service. Call routing infonnation is advertised by the CCD advertising service. Load balancing occurs among trunk protocols and learned remote IP addresses.
D) F)
Learned call routing information can be placed into different partitions that are
based on the remote call control identity.
based on the remote IP address.
Learned call routing information can be placed into different partitions that are
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) B) Configure SAF forwarder. Configure SAF trunk.
C) D)
F) F)
Configure CCD advertising and requesting service. Configure hosted DN group and hosted DN pattern.
Configure DN blockprofile. Configure blocked learned patterns.
5-71
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
5-69
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/configuraion/guide/saf_cg _ps 105')2_TSD_Prod uctsC'onfiguration GuidcC haft' :er.html.
Cisco Systems. Inc. Cisco Unifiid Communications System 8.x SRND, April Uniji
htlp:'V\\w\\.cisco.(jom/en/US.'''do s/voicejp eomm/cuem/sntd/8xAic8\.himl
2010.
CiscoSystems. Inc. Cisco Unifi Communications Manager Administration Guide ifiei Release 8.0(1). February 2010.
http://w ww.cisco.com/en.T ;S/doc s/voice_ip_comin/eucm/admin/8_0
cm.html
l/ccmcig/hccin-801-
Implementing Cisco Unified Communications Manage -. Part 2(CIPT2) v8.0
Other SAF and CCD Considerations This subtopic describes additional issues that you need to consider when implementing CCD in
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.
Cisco Unified Communications Manager Clusters and CCD

Configuration Modes This subtopic describes considerations regarding Cisco Unified Communications Manager
CCD configuration modes.

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
Manager Cluster
SRF Forwarder SAF Forwarder
Primary
Secondary
SAF Forwarder SAFForwarder
Primary
Secondary
to the SAF-enabled trunk or trunks Via the device pool will register with the configured SAF
forwarder.
SAF forwarders, by default, all Cisao Unified Communications Manager nodes that are applied
When you are configuring aCisco Unified Communications Manager cluster with one ormore
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
cluster.
command, or you have to manually ônfigure all names that are used by the nodes in your
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
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 twiceonce 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
call can be routed back out to the PSTN at the TEHO gateway when the called number is in
globalized format.
received with a- prefix. The reason is that they are advertised that way and the incoming VoIP 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.
5-65
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.

(default: 48 hours).
ToDID).
Learned route is removed only after expiration ofCCD PSTN Failover Duration
Cisco IOS Software can advertise +only in global patterns (which do not support
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
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.
used as a backup. This situation reduires having aToDID rule of0:. With this rule, the CCD
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.
CC DPSTN Failover Duration timer, which is 48 hours by default.

Software ifthe + is required and local backup is desired.
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
Based on these issues, it is recommended that you not advertise TEHO patterns from Cisco IOS
5-64
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 Called DN External Phone Number Mask 2G01. -MC8S5Sv.XaX
Destination Phone DN and hxlirriUl
Si..
52001
Route Pattern Pattern \+' Partition AAR
AAR CSS Partitions AAR
Urgent Pnority
Route List
PSTN
CCD PSTN Backup

Call
Called Number
~J The +isprefixed for

\ callsplaced with ^ AAR CSS ifthe
called number does
not include +
Composed from
Learned DN Pall em and 1c _'[} F<"re
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
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 (\+!).
pattern ' to apartition that is accessible only from the AAR CSS. At that pattern, you can prefix 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
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
the external phone number mask of the destination phone is in E. 164 format with a+prefix,
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. do not match the Vi-! translation pattern and are therefore routes, as explained earlier.
Note
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
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. .
5-63
i_010 Cisco Systems,
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
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
p-atlla da-tlock 1 i l l u -
DN Pattern
and ToDID
P-.-~_ 197.555
4XXX
pe-B l tj- uiuuios
0:1972555
The+ not supported In-lias-prefix or extension.

PSTN backup canrroi be advertised with +.
profil. da-block 2 P_ttrn 1 type global

H0470712-S
14087071222
The + is added lo patternsconfigured with type

global,
(noToDID)
Global patternsalways have ToDID unset. There is no PSTN backupforglobal patterns
unset, regardless ofthe configured alias prefix at the directory number block profile.
instead the pattern tag type extension command. In this case, however, Ihe ToDID is always
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
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
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
that time, and calls to learned patterns fail.
time by using the CCD learned Pattern 11' Reachable Duration CCD feature parameter. During
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
lower value than the default {twodays).
PSTN backup b> setting the CCD PSTN Failover Duration timer to 0. or set the timer to a
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.
5-60
Implementing Cisco Unified Communications Manager, Pari 2(CIPT2) vB.O
SRST Considerations This subtopic describes how CCD can be implemented at Cisco Unified SRST gateways.
SRST Considerations
SRST subscribes to the CCD service but does not publish
any patterns.
New Yort( SRST Routing Table DN Pattern TaDiDRule . Protocol
BlP
SIP
SIP
During WAN failures, SRST

uses learned patterns to
840BXXXX **14S855&' ;10V B416XXXX 4:14lB777- fC'1
transparently reroute calls over

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
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
place calls to other sites b\ dialing the internal directory number ofthe other site. Cisco linified
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 callrouting 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.
of4:+l8415. and 8949XXXX with a ToDID rule of4:+l949222.
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
5-59
CCD PSTN BackupCSS

This subtopic describes which CSS is used for PSTN backup calls.
CCD PSTN BackupCSS

When PSTN backup is invoked,
the number that is built based on the DN and the ToDID rule is called. HQ Learned Routes
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
!> 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

........
Pattern
.010:03:12 16:03:27:838
private Dialplan Partition ********
- 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
Pattern - *4420>
(E164) Dialplan Partition **'
Trunk-Route!-} ID
Pattern - .16505051234
- 271 272
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).
5-57
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 -,
'3HMJ1118563)
!408707131;
JraSBf
Reich**
Rotfuc*
a* H323
.Eatm
_-j<*
nitMi(fflio)
?3f3n!iS3] 2matw2W()j:7 M(lW)ni1SSS3J ;jioiriisij 331*0*1185(3;
RtmaM HM!hj rium Rsjuuw
tnunci?:oi
SlttidWnKMlr
SUnrnkiwCluslH
0151t(SM(i 015 IH3J143f oiuiiaowj
t>-umm tSWKW
01132 tci?.ai
Stan-UcneriLisiBi
HSM
_H1OTJM1J1 35
Reichit*
SWkWWwCIusIb.
01511(5060) ai.tici.t43t
Administration web page. The only way to view SAF-leamed routes is by using the Cisco
Unified Real-Time Monitoring Tool (RTMT).
SAF-leamed routes are not visible by any tool of the Cisco Unified Communications Manager
The figure shows an example ofSAF-leamed routes that are displayed by Cisco Unified
path forthe respective learned patterns.
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
RTMT. The ToDID rule 0: means that the '-internal" pattern and the pattern that is used for
5-56
Implemenling Cisco Unified Communications Manager, Part 2<CIPT2) v8.0
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
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
. f - i n t . r f . c . F.tl[
u tonohoua-ayc
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 icollli
1 typa tnioQ 4111

c.llt
da-jarvlca trunk.tout*
da-block cbumal 1 ubacrib*

I
1 vrc ci
Sir yjtan
roj 1
ntrol wildc*rdad
publish c.ll
VoIP dial peer for outbound calls using SAF.
dial-paar ,OK
!IH5 voip
The configuration ofthis dial peer is like the configuration ofadial peer that refers to asession
dial peer that is irsed on outbound SAF calls, and for the incoming dial peer that is used on
inbound SAF calls.
all learned routes. The rest ofthe dial peer configuration is used as atemplate for the outgoing
target ras command when an H.323 gatekeeper isused. The destination pattern .Tstands for
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
Bession protocol sip interface loopbackl transport tcp port 5060

pattern 1 type extension 4XXX
profile dn-block 1 alias-prefix 1972555

I
profile callcontrol 1
trunk-route 1
dn-block 1
SAF client is enabled for

channel 1 vrouter SAF asysten 1 subscribe callcontrol wildcards publish callcontrol 1
learning (subscribe).
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
at the channel configuration level.
are advertised by the SAF process that matches the autonomous system number that is specified
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 exit-
of-topology
ervice-family
ervice saf
pro fi e
trunk-route
ip interface loopbackl transport tcp port 5060

rofila dn-block 1 olias-prnfin 1972555
pattern 1 type extension 4XXX rofile callcontrol 1
dn-service trunk-route 1 dn-block 1
Actual SAF client, which you can enable
foradvertising (shown here)and learning (shownin nextfigure). Advertising service (publish) refers to call control profile.
Refers to EIGRP process and
autonomous system number.
channel 1 vrouter SAF asyste

publish callcontrol 1
You configure the advertising and requesting services under channel tag vrouter E/GRP-ID
wasassigned to the EIGRP service family.
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
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.
To enable the advertising service itself, you use the command publish callcontrol tag The tag
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

sf-interface FastEthernet0/0
topology base
exit-sf-topology
exit-service-family voice service saf
1
session protocol sip interface loopbackl transport top port 5060


profile callcontrol 1
dn-service
The profile refers to directory number blocks

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 profile The extension-length argument sets the number ofdigits (starting with the least
added.
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
significant digit) that should be preserved from the configured extension before the site code is
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

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

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

1
sf-interface FastEthernetO/O
topology base
exit-sf-topology exit-service-family
voice service saf
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.
5-49
Internal SAF Client Configuration Procedure

This subtopicshowsthe configuration procedure of an internal SAF client.
Internal SAF Client Configuration

Procedure
1 2 3 4 5 Configure trunk profile. Configure directory number blocks to be advertised. Configure call control profile. Configure advertising service. Configure requesting service.
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
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.
21)10Cisco Systems, Inc
5-47
Step 9: Configure CCD Feature Parameters

The figure shows the configuration ofCCD feature parameters in Cisco Unified
Step 9; Configure CCD Feature Parameters

fli" ^s*a
** ****!
n-ajva.
lH.*S '.!< If.LfcUc ,m^ tsffitra"
|FW>
~3 ~3
F"k* T,"
Here are the configurable CCD feature parameters:
CCD Maximum Numbers ofLearned Patterns: This parameter specifies the number of
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.
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
patterns that this Cisco Unified Communications Manager cluster can learn from the SAF
CCD Learned Pattern IP Reachable Duration: This parameter specifies the number of
seconds that learned patterns stay active (IP reachable) before Cisco Unified
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 marks those patterns as unreachable. PSTN failover occurs when Cisco Unified Communications Manager cannot communicate with the SAF
reached through PSTN failover. The default value is60seconds

5-46
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
to the IP path of routes as soon as the routes have been received with the appropriate
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
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
Implementing Cisco Unified Communications Manager, Part 2{CIPT2) v8.0
Step 8: Configure CCD Blocked Learned Patterns

The figure shows the configuration of the CCD blocked learned patterns in Cisco Unified
Step 8; Configure CCD Blocked Learned

Patterns
Blocked wanted Pattern configuration
-Purge""> ttock S*FCCD Learned Route* Intormat

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

5-45
Step 7: Configure CCD Requesting Service and Partition

The figure shows the configuration ofthe CCD requesting service in Cisco Unified
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,
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
and to all learned ToDID rules, respectively.
You can configure only one CCD requesting service. You have to enter the partition that all
learned pattern prefix and aPSTN prefix. These prefixes are applied to all learned DN patterns
Finally, the CCD that isrequesting service isreferred tothe SAF-enabled SIP or to the SAFenabled 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
;>2010 Cisco Systems, Inc.
Step 6: Configure CCD Advertising Service

The figure shows the configuration of the CCV> advertising service in Cisco Unified
Step 6: Configure CCD Advertising Service
^Sr X1" O0 <}* 'V"""*"

The advertising service
> uri.fe-l.i)*) <.ii Inf. -
refers to trunks and one hosted DN group
SVHIH*-..
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.
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 Hofl *tre '

DeiciDbon
Hosted im Group"
If no ToDID rules are
configured, ToDID rules of
hosted DN group are

If set here or at hosted DN group, configured hosted partem is also ToDID
number.
applied.
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
DN group.
figure does not generate aToDID rule of 0:, but it applies the settings of the configured hosted
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
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. Ifallor at least mostof
patterns if the hosted DN pattern parameters areunset.
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 The Use Hosted DN as PS'fN Failover check box instructs Cisco Unified Communications
backup is identical to the internally used number. Usually, this result occurs only when tail-end
hop-off (TF. HO) patterns are advertised.
Manager to create aToDID rule of 0:. As aresult, the number that is to be used for PSTN
5-41
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*
[* tow'
H.323 trunk. With aSAF-enabled H.323 trunk, you have to first add astandard nongatekeepercontrolled ICT and then check the Fnable SAF check box. Once the check box ischecked, the
call isplaced. The destination IPaddress isthen taken from the learned SAF service data.
You can configure one SAF-enabled SIP trunk (as shown in the figure) and one SAF-enabled
destination IP address but instead acts as a template for adynamically created trunk once a SAF The same concept applies to the SAF-enabled SIP trunk. The only difference is that the SAFenabled 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
IP address field is disabled. The reason is that the configured trunk does not refer to aparticular
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
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.
The destination IP address has to match the one ofthe interface that is specified with the sfinterfaee 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.
5-39
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
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. Configure SAF forwarder. Configure SAF trunk. Configure hosted DN group. Configure hosted DN pattern. ConfigureCCD advertising service.
:>
4 5
6 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.

5-37
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
eit-Bf-topology
external-oliont HQSAP
1
IID configured at theexternal

SAF client.
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

he figure shows the SAF forwarder configuration.

EIGRP process \0 has only
local significance.
router eigrp SAF
service-family ipv4 autonomous-systew^^

sf-interface FastEthernetO/0
topology base
exit-sf-topology exit-service-family
Autonomous system must be

the same on all SAF forwarders that should exchange data
"~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.

5-35
SAF Forwarder Configuration Procedure

This subtopic shows the configuration procedure of the SAF forwarder.
SAF Forwarder Configuration Procedure

1 Configure SAF forwarder,
used).
2 Configure SAF forwarder tosupport external SAF client (if
The configuration ofthe SAF forwarder consists oftwo steps: the SAF forwarder configuration
(mandatory) and the support ofan external SAF client (if used).
5-34
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
Profile
SAF CH "Charmer
CCD Recjueslmg
Service
Profile
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.
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 Call control profile
(internal number and number used for PSTN backup).

profile.
profile dn-block: Configured withpatterns to be advertised
profilecallcontrol: Refersto DN block profiles and trunk

channel: Configuredwith SAF client IDand autonomous
SAF client -channel'
system. Advertising and requesting services areenabled; the

advertising service refersto the callcontrol profile.
0(81 f>e&
session target saf. This isthe incoming and outgoing dial peer
for a caHsent to or received from SAF trunks.
dial-peer voice:Configured with destination-pattern .Tand
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
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 Itiple blocked learned patterns, SAF forwarders, and SAF security profiles. You a n nfigure one CCD SIP trunk and one CCD H.323 trunk. Only one trunk is required
mu
co
5-31
External SAF Client Configuration Elements

This subtopic describes the confiiuralion elements ofan external SAF client.
External SAF Client Configuration Elements

SAF security profile
SAF forwarder
Catena *musernameBiWpasBVn).ReienmcJ(tomSAFtOnWidar.
Points to a to SAF sec
AFforwarder Configured with IP addressof SAF forwarder Refers

nty profile
One SAF
SAFtrur*s
configure Hti a destination IPaddress.Therest ofthe confaurafjon isstrraiar configured' ti

to normals 3andH323r/uni.
trunk andone SAF H323 twr* canbeconfigured. Ttiey arenot

PSTN failover prepend diaits
Nested DN group
Configured nth PSTN laitover stripdigrtsand i 1 DN patterns
Directory Hosted DN pattern

PSTN hosted DN
pdiojaj andPSTN faliover prepaid aigHs; ifnotonofigwad

i wipeonriguratlonriiH).Appli8dtDhosted DNB'OUO
ot directory number raneetoBeadvetttned. Configured wth
CCD advertising service CCD requesting service
Refersto hoptedDNgroup, SAFSIPtrunk, and SAFH.323trunk
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.
Step 2
Map the external SAF client to the SAF autonomous system.
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.
patterns.
Configure the CCD requesting service and the partition to be used for learned
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
as Cisco Unified Communicatior s Manager Express.
implement CCD in Cisco Unifiel Communications Manager and
in Cisco IOS call agents such
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,
and trunk to be used.
Configure call control profile referring to directorynumber blocks
Configureactual CCDr cess (channel) referring to SAF forwarder pn

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
forwarder.
:an specify the interface thatshould beused bytheSAF
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
Step 2 Step 3
that is used by theSAF forwarder.
The IP address (interfaci) that is used for call signaling can be different from the IP address
Configure the directoryjnumber blocks to be advertised. 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 requesting service.
Fnable the CCD advertising service by referring to the call control profile.
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
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.
5-27
2010 Cisco Syslems. Inc
CCDCall 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.
CCDCall 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.
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
Manager does not strip any digits {because ofthe 0 in front of
backup call istheAAR CSSofthecalling phone. The 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
route pattern, route list,
is reachable from the AAR
The CSS that is used fo the PSTN
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
CCDLink Failure at BR
This subtopic describes how CCD manages a link failure between the SAF client and its SAF
forwarder at the BR site.
CCDLink Failure at
HQ Learned Routes
M 01WI559
BR learned Routes
B0
Marked Unreachable
r);M0R6il!1
' WI.S.10
SIP
- 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.
CCDCall from HQ to BR
This subtopic describes the call flow for a call from the HQ site tothe BR site.
CCDCall from HQ to BR
BR Learned Routes
WWt *48WS31 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
CCDPropagation of BR Routes
This subtopic describes how BR routes are propagated to the IIQ site.
CCDPropagation of BR Routes
HQ Learned Routes
0-*!B7M65 10.1 T.10 SIP
BR Learned Routes
W&nmmmWmMmW mmnV^&mmmmmn^R Mf
ao
0Miai,
10.iS.1tt
BIP
Learn hosled DN range and ToDID

rule and store in memory
PSTN
Advertise hosted DN range
(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 callrouting 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.
5-23
CCDPropagation of HQ Routes
This subtopic describes how HQ routes are propagated tothe BR site.
CCDPropagation 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 callrouting table ofthe BR cluster ispopulated with the directory number pattern 2XXX and a
ToDID rule of 0:+498953121.
Therefore, the BR cluster learns the route only for SIP.
At the advertising site, only aSIP trunk has been associated with the CCD advertising service.
5-22
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.
CCDBase 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 rane 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.
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
All learned routes are put into one configurable partition. All devices that should have access to
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
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

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,
site code.
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 digitslor example, by their
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! loadshare the outbound calls to the corresponding destination among all possible paths (that is. t>>
protocol and remote IP addresses).
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.
5-18
CCD Services in Cisco Unified Communications Manager

This subtopic describes the two CCD services that exist in acall agent such as Cisco Unified
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.
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
digits should bestripped).
range 2XXX. In this case, your ToDID rule would start with 4: (because the four leading
want to strip the leading 8408 before prefixing the necessary digits to directory number
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.
be stripped and the prefix are separated by a column.
In the given example, the complete ToDID rule would be 4:+1408555, because the numbers to
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
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 callrouting 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
consists of two components:
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.
5-15
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

service data to their SAF forwarders.
Co mmunica lions
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
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.
CCD is a function ofcall agents. Itallows call agents to advertise locally known internal
ACCD-enabled call agent is configured to send its locally configured directory number range
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).
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
the SAF service data).
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.
5-u
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.
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
adjacent, there are two configuration options:
SAF forwarders can be. but do not have to be, directly neighboring devices. If they are Layer 2
like a LAN using Fthernet, they can communicate toeach other via multicasts. This
Multicast: When multiple SAF forwarders are connected via abroadcast-capable medium
configure the Layer 2 adjacent neighbors.
communication allows adynamic neighbor discovery because there is no need to statically
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
fashion. Instead, they should communicate only in ahub-and-spoke fashion (one router
directly with each other).
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
communicates with both ofthe others, and the other two routers do not communicate
between themthese nonadjacent neighbors have to be statically configured. No discoverv is possible. See the H lustration in the lower-right comer of the figure for an example of non-L aver
2 adjacent SAF forwarders.
When SAF forwarders are not Layer 2adjacentthat is, when there are one or more IP hops
5-12
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8 0
H 2010 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
FIGRP-derived features include bandwidth percent, hello interval, holdtime. split horizon,
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
maximum hops, andmetric weights.
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).
Although SAF routing is verv like EIGRP, it is independent of the used IP routing protocol,
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
information
unique instance
Used by forwarders to
Transparent to forwarders
Client data depends on service type
propagate advertisements
Metrics used to avoid loops
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
SAF Client Types

This subtopic describes the two available CCD SAF client types.
SAF Client Types

SAF forwarder is always Cisco IOS router. Two types of SAF clients:
External SAF clients * SAF client and SAF forwarder are
different devices.
Manager
SAF client is Cisco Unified
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
Internal SAF client: The SAF client and the SAF forwarder arc two different functions
within the same devicea 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.
SAF Characteristics
This topic describes the characteristics of SAF.
SAF Components
SAF supports any service
lo be advertised
Cisco Unified
Communications
Cisco Unified
Communications
CCD is the first Cisco application
Manager
Manager
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
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 theSAFenabled 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 informationinternal
director, numbers and their corresponding PSTN numbers.
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 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
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 callrouting 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 fullmesh 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.
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 Agem
Call Agent
Call Agent
Call Agent
Call Agent Call Agent
CaHAgent Call Agent
In large networks with several call agentssuch as Cisco Unified Communications Manager Express. Cisco Unified Communications Manager, Cisco Unified Border Element, Cisco Unified SRST. and Cisco IOS gatewaysthe 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^
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
Module 5

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

QU
Q2) 03)
B
C. D.G
A.C
C
B B
Q4)
Q5)
06)
Q7) Q8) 09) Q10) Oil)
CD
A. D. E
A, D 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) B) C) D)
E)
If the multiple login behaviorserviceparameter is set to disallowed, the login

fails.
If the multiple login behaviorservice parameter is set lo auto-logout, the user is

automatically logged out of the other device.
If the multiple login behaviorenterprise parameter is set to allowed, the login

succeeds and the user also remains logged in at the other device.
If the multiple login behaviorenterprise parameter is set lo prompt, the user is

given the option to log out of the other device first. 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) B) C) D)
Q8)
The phones that they use have the wrong location and region settings. Users get the wrong extensions on their phones. Users get the wrong calling privileges. Users do not have speed dials available.
Which two settings cannot be updated when Cisco Extension Mobility is used? (Choose two.) (Source: Implementing Cisco Extension Mobility) A) B) C)
D) E) F)
phone button template

softkey template device CSS network locale phone service subscriptions 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) C) D) F) F) Ci)
phone
end user
device security profile device pool device profile 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) C) D) E)
Do not configure a device CSS.

Do not configure a line CSS.
Configure the device with a CSS that includes all PSTN route patterns pointing
to die local gateway. 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
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)
B)
region
directorv number
O D)
location SRST reference
021
Which three of the following are device mobility-related settings in Device Mobility? (Choose three.) (Source: Implementing Device Mobility)
A)
B)
Region
SRST Reference
C) D) F.)
F)
AAR Calling Search Space Device Mobility Calling Search Space Media Resource Group List
Location
Ci)
03)
AAR Group
Which two statements are correct about (he relationship between Device Mobility
configuration elements? (Choose two.) (Source: Implementing Device Mobility'.

A) B) C) D) E|
Q4)
Device Mobility Infos refer to one or more device pools. Device pools refer to one or more physical locations. Device pools can refer to one device mobility group, Device pools can refer to one Device Mobility Info. Physical locations refer to device mobility groups.
Which statement is not correct about Device Mobility operation? (Source:
Implementing Device Mobility)
A) B) C)
A dev ice pool is selected basedon the IP address of the device. If the selected device pool is the home device pool, no changes are made. 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) B)

C)
D)
The user of a roaming phone can use the home dial rules. Fhe user of a roamingphone can use the homedial rules, but then the home gateway is used all of the time. The user of a roaming phone can use the roaming gateway. 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
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
! j
Unified Communications Manager users to log into an IP phone and have their personal profile 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-SOlem.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^-801cm.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
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
rScnrtte lnfonnaMon
Enter the service
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
-| rvcxl I
Close
Exlension Mobility
phone service by
using the name
assigned in Step 3
Then, click Next
3. Click Subscribe.
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.
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 partenabling 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.
4-66
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

l" 1
1
Usei ID and PINaie
~<
=====
] used for Cisco J Extension Mobility login
-fr.--.o-* j-t*f
Associate user
-
/
VA
A
device profiles, optionally, set

default profile
(if moielhan
one controlled
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.
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
Sew* a erv-c*'
5ei-Lic Des^ripfic
2. EnlerBie service name as it should
appear at the phone.

EH Loôn ; Lagotf
Not Selected
0* mo5e<v
Sen.-*
otion: EM Logon / Logoff
EM Logon .' Logoff
1. Choose the Cisco
EM Logon / Logoff
- Subscribed Services
Extension Mobility phone service by using the name
assigned in Step 3.
Then, cick Next.
3. Click Subscribe.
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 profilesthat 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.
4-64
ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)vfl.O
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
PKor n.*- TrPijtn.E*
Setter Tcmcla-rB
modeiand
protoccrf.
IK^
Enter device
profile name and description.
Configure phone
lines and buttons.
[g-.=rr
1 (Default) Profile llfOrM*lkirl-
Configure userspecific 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.
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 J
"
Select phone 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.
4-62
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
SrviP Name'
A5CTI Service f*a'n
EH Logon ,' LogcC

EH Logon ,J LOQOt*
Extension Mcbilil. ..ckju Uicif 5trv.c
service description;
enter Cisco Extension
S=rv>cc Descfipt.oi
Semce UHL
htrp ''101 i.i.eoeoien OPC'EWAnpSt vlet'devic c-tDI
<l
Mobility service URL.
^?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.
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
by choosing System > Service Parameters.
4-60
Implemenling Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0
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
Select Serve*
Se C'CCl 10 Snr,ltC5 do
CMSenhw : Tiimn Umii Cisco CalWanswer CISCO Tttp Cisco Messaging IrtprTicp
CKfo unrfifd Mobile Vane fides? Ser.-c
MK<HBMil**W
Ace rated Activated Oe actuated Attested Ac! vsted
ActivateCisco Extension
Mobility service.
Cisco ]P Vo<e. Media Streamy Aoo
LZ
Cisco Entensran MeMitY

Cisco Eflenri^d Finlftiorrf
*t (^
'dilated Deadly ate d
I>e actuated
Cisco Dialed PfljmDei Analyser

Cisco CHCP Menrto- Swv.
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
4-59
Cisco Extension Mobility Configuration

This topic describes how to configure Cisco Extension Mobility.

Steps
1
2
Activate the Cisco Extension Mobility service.

Set Cisco Extension Mobility service parameters.
3 A 5. 6
Add the Cisco Extension Mobility phone service. Create default device profiles for all phone models used (optional). Create device profiles and subscribe them to the Cisco Extension Mobility phone service. 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
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.
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
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.
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
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
Mobiity profile. Series 797x models are equivalent

User Device Prose tor CISCO
is similar
User dewce
profile is
used
Mobiity profile No administration tasks are required to activate a Cisco Extension Mobility feature
safe
Unified fP Prone 7940
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).
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.
Different conigu ration parameters are available, depending on the phone model lhal is selected
Cisco unified IP Phone 7945
What ifa user logs into a different phone model

than Ihe model tiat s conlgured in the device profile of the user' Default device profiles can be configured
Default device profiles contain default Log In
phone-con figuration parameters for the

large! phone:
Phone model series is different
Phone button template Softkey template

0etaiilt values for parameters that might not be available at the device profile of the user (if fhe phone model specified
User Dovfcs PmBftfor Cisco

Unified IP Phone 7965
Default device
profile for Cisco

Unified IP Phone 7945 is used.
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
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).
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 updated configuration.
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.
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 meansthatthe useris provided a separate device profile per site. This approach is common when thetraditional approach is used toimplement CSSs. Cisco Extension Mobility updates
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
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
Stilt N
\
\
Oevice Profile: B
Device Profile: C
Cisco Unified IP
Phone 7940 SCCPDef&ft Device Profile
Cisco Unified IP Phone 7940 SIP

OefeuS Device
Cisco Unified !P
SCCP Default Device Proffle
Cisco Unified IP
Phone 7065 SIP
Default Device
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
device profile must be subscribed to the Cisco Extension Mobility phone service; this
subscription isrequired to allow a user to logoutof a phone.
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
Cisco Extension Mobility Configuration Elements

Thistopic describes the configuration elements thatCisco Extension Mobility uses.

Elements
Configuration
Element Name
Configuration Element Function

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
Device profile
Stores user-specific phoneeoniguraflon in logical proSles. ContDuration parametersinclude user-specific phone and button {lines, speed dials,etc.) 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
and deuce prof les need to be subscribed to the serwce
Phone service
Stores tie default device-configuration parameters thai should be appliedwhen
Default device profile
[he phone ^ wMW) fte usw |(jgs |(| ^ ^^ ^^ ^ ^ jsÂv!f,ai ,s;ty

ciîred lorvetvphone mwlBlihaS hasCiKoExiensie'R MosilMy activated
the phonemode* offie deviceprofileofa user isUrfferert than the phonemodelof
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.
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
Manager
Remote
Gateway
Logout
Device Profile of Roaming User Andy
Login
Device Profile of
Login User
and PIN
User Andy:
UMTUKda Iter yOHAufe Sara
User Andy:
UwrMOH AMID South
Ftcru tUscr, Timvlm
H[
ftm* fcltwt'riwl* 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
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 parametersUser 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. 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.
Configuration of phone buttons(including lines):
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
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.
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

Mobiiily
Extensions are bound to physical devices.
Cisco Extension Mobility Feaiure thatSolves the Issue

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.

MWI status Extension îs updated during Cisco ^
MWIslaluss defined ror physical devrces.

.,.= .,. _ ,j -
casng privileges are delned for phytic*!

devices andlocations oevicej analocaons.
tttttoa.* Wevfce-based) Bfldptiyscal device umg.s(locatiCKKef*d).
*'*'**>* " mar9a *lln9
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
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.
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.
Manager
Remote
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
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
4-38
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

hup: 'www.cisco.com en US/docs/\oice ipcoin nv'cu em/admin/8 0 l/ccmcfg/beem-XOI

cm.html
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
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

phone
EH^=^
Dev :e pr
" " =" - s"'" s"
SL
n(j .|.|>
-
There are overlapping settings at the
device pool and at the phone; they have higher prioritythan settings at
the home device pool but are
replaced by settings from the roamng

device pool
r-
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
device pool.
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
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* "
,|
û^^,
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
(DevicePhone) section, set Device Mobility Modeto On or Off (OtTis the default).
4-34
Implementing Cisco Unified Communications Manager. Part2 (CIPT2) v8.D
Step 4: Configure Device Mobility Infos

The figure shows how to configure device mobility infos.
Step 4; Configure Device

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
Io configure device mobility infos, choose System > Device Mobility >Device MobilityInfo. 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.
4-33
Step 3: Configure Device Pools

The figure shows how to configure adevice pool when using Device Mobility.
Step 3: Configure Device Pools

Manager Ad ministration:
System > Device Pool

ConGguteroamingsensitive 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>et ier tc apply t
roa m mg-sens ilive s etlings

and Device Mobility-related
settings
Configure Dev.ce Mobilityrelated 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 roamingsensitive 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
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

System > Physical Location
Entername arid description. L^_ "'""' "'>-"'
Cisco Unified Communications Manager Administration: System > Device Mobility > Device Mobility Group
I1IIU 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
Device Mobility Configuration

This topic describes how to configure Device Mobility.
Device Mobility Configuration Steps

1
2 3
4
Configure physical locations. Configure device mobility group. Configure device pools.
Configure device mobility infos (IP subnets).

Set the Device Mobility mode by using: a. A Cisco CallManager service parameter to set the default for all phones
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
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
HQ
(Partition HQ, CSS. System:

000 ' -> DDI PreDot, Prefix +
00 i -> DDI PreDot. Prefix +49
Physical
Location HQ
DDI PreDot, Prefix +4940

Route Pattern \+'
Local Route
Group >~'j
Partition System
Single Route List. Default Local Roule Group

Device Pool. E
Physical
BR Translation Patterns Location BR
(Partition BR. CSS. System|
CSS BR]
Local Route
91 [2-9)XX[2-9JXXXXXX -> DDI

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
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.
Implementation of Featuresand Applications for Multisite Deployments
4-29
Group
Example: No Globalized Call RoutingSame Device Mobility

environment where globalized call routing is not implemented. Also, gateway selection is
performed by the device CSS ofthe IP phone.
The figure shows an example of Device Mobility with identical device mobilitv groups in an
Example: No Globalized Call RoutingSame 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 [
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
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
HQ.
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
4-28
Implemenling Cisco Unified Communications Manager, Part 2(CIPT2) v8.0
^2010 Cisco Systems, Inc.
Example: No Globalized Call RoutingDifferent 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 RoutingDifferent Device Mobility Group

Route Pattern 49 40 552XXX
01
Device Pool HQ
Physical
Location i C
Device Mobility
Group HQ
Route List
(Device Mobility
CSS. HQ)
Route Group HQ-GW
Device Pool BR Route Pattern
Physical
Location1 Lit*
9
Partition Branch
Device Mobility Group. BR
(Device Mobility
Route List
CSS. BR)
HQ: EU Numbering
Plan
Roule Group. BR-GW
UR. NANP
| BR user roaming lo HQ uses NANP dial rules and uses BR gateway |
site ("BR"' in the figure) is in the United States. Separate route patterns (representing the
In the example, there are two sites. The main site ("I IQ" in the figure) is in Europe, the branch
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.
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.
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.
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
The AAR CSS and AAR group that are configured at the device level can be the same for all
in global format by configuring either the external phone number mask orthe AAR
phones as long as the AAR number is always in global format. (You can ensure that it is always
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
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)
Further, there is no need for different AAR CSS, because the gateway selection is not based on
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
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.
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).
In summarv. unless TEHO is used, the implementation ofDevice Mobility without globalized
implementation otFeatures and Applications for Multisite Deployments
4-25
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 groupsand globalized call routing, which utilizes local route groupsis 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 Mobilityrelated 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 Mobilityrelated 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
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.
In these three examples, the user has to dial PSTN destinations by following the dial rules of
the home location (Great Britain).
Note
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.
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

destination close id dome location, no TEHO.
Cal use* local PSTN gateway at roaming

location for a long-distance PSTN cal. Cal uses IP WAN to gateway at home location
for a local PSTN call.
Same device mobility group, call lo PSTN

destination close D home location, TEHO.
Same device mobity group, call to PSTN

destinalIon close b roamhg location. Different device motility group, call to PSTN
destination close lo home location.
Cal uses local PSTN gateway at roaming

location for a local PSTN call.
Cal uses IP WAN to gateway at dome local on

for a local PSTN call.
Different device mobility group, call lo PSTN destination close Id roaming location, no TEHO. Different 0evice mobility group, call lo PSTN
destination close to roammg location, TEHO.
Cal uses IP WAN to gateway at home location
tor a king-a stance PSTN caK.

CaB uses local PSTN gateway at roaming
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 hopoff (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.
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]).
Note
4-22
Implementing Cisco Unified Communicalions Manager, Part 2 (CIPT2) v8.0
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.
> Cisco Systems. Inc 2010
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.
This partition is included in the device CSS ofthe phones, and therefore itenables the use ofa
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
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.
assigned to separate partitions. The line CSS ofaphone now will include Ihe partitions of those
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
local gateway for PSTN calls. To implement class ofservice (CoS), PSTN route patterns that
Device Mobility and CSSs
the same device mobility group.
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
4-20
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) u8.0
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
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
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
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 local site to which the phone was moved.
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
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.
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:
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.
- WhatgatewaytouseforPSTNaccessandAAR PSTN calls(device CSS andAAR CSS),and how to composethe AAR number(AAR group)? - Changes may result indifferent dialing behavior (forexample, different
- 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
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
CSS (which is called simply CSS at the phone). AAR CSS, and AAR Group. Ifthese
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
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.
^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
hi ^m
I
Apply roamtngssnsttiua sellings
from selected device
pool.
Slop- Apply DeviceMobiifty-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 loadsharing 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.
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 highestlev el geographic entities in your network. Depending upon ihe network size and scops,
or other entities. Because Device Mobility-related settings (which areapplied only v hen
your device mobilitv groups could represent countries, regions, states or provinces, c.ties, 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 Mobilityrelated 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

pool are also applied.
the Device Mobility-related settings of the roaming device
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).
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.
> Cisco Systems, Inc. 201D
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
i
!
SJ1 dmi
SJ_A_ dp
(Building A) SJ_B1_ dp
(10 1.1 0/24) SJ2_dmi

(10.1.2.0/24)
c--.^
^ ^
/
i
i
(Buiding B) SJ_B2_ dp (Building B)
_.*!
\
SJ_pl
"
i (SJ-campus) I
Jr
~i s,,\
,4\ US dmg !
1
SJ3 dmi
i
i
(10 1.3.0/24)
sU
* **
*
NY dmi
i
(10.3 1.0/24)
NY_dp
mv
'
j (NY-campus) j
W.
.>
LON dmi
(10.10.1.0/24)
LON_ dp
.
LON_pl
i GB_dmg , i
(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 mobilityinfo 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
Device Mobility Configuration Elements

This topic describes the configuration elements that arc used by Device Mobility.
Configuration Element Functions
Configuration
Element Name
Configuration Element Functon

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.
Deuce MoNiy Info
Specifies an IP subnet and associates it withone or more device pools. Multiple device mobility inlos can be associated with one
device pool
Physical Location
Tliephysical location Is a teg assignedto one or moredevice 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
Devi :e MobilityDynamic Configuration by LocationDependent 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 MobilityDynamic Configuration by Location-Dependent Device Pools

Main Site Remote Site
Device Pool Remote Local'on
Region
Location
SRST Reference
SRST Reference
Device Motility CSS

AAR CSS
Deuice Mobility 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
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
Note
Calling Party Iransformation CSS

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 onlyor bolh roaming-sensitive settings and Device
Mobilitv -related settingscan 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
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
setting, although shown as such in the GUI.
physical locations ofthe home device pool and the roaming device pool are different. The
Implementation otFeatures and Applications for Multisite Deployments
Device MobilityDynamic Phone Configuration Parameters

This subtopic shows the two types ofphone configuration parameters that can be dynamically
assigned by Device Mobility.
Device MobilityDynamic Phone

Configuration Parameters
Two types of phone settings can be applied by Device Mobility.
Local Roule Group Region
SRST Reference
- Date/Time Group
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îr.
- L?.-ii':n,) Party Ti30fi.imsai!O!i CSS
the physical location ofthe phone. Device Mobility does not modify any user-specific phone
parameters or any IPphone button settings such as directory numbers.
Device Mobilitv can reconfigure site-specific phone configuration parameters that are based on
The phone configuration parameters that can be dynamically applied todie device
configuration are grouped into two categories:
Date/Time Group
Region
Location
Note
The Date/Time Group, Region, and Location are configured at device pools only.
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.
supports Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) Cisco IP
phones andCisco IP Communicator.
Dev ice Mobilitv can beused in multisite environments with centralized call processing. It
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
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

When mottle user moves to liferent location, Cal Admission Control selings are not
adjusted.
Device Mobility Feature to Solve Hieissue Location settiigs are dynamical? assigned.
Dynamic phone CSS allows for site-Independent
local gateway access.
PSTN gateways tone used are fixed.

SRST reference is feed.
SRST inference is flynamicaBy assigned.
When mobile user moves to efferent region,

codec settings are not adjusted.
AAR does not work for mobile users.
Region settings are dynamicallyassigned. AAReating search space andAARflroup of directorynumbers are dynamically assigned. Meda resource listis dynamically assigned.
Cisco Extension Mobtity also benefits from
dynamic assignment.
Media rescurces are assigned independent of

location.
AAR causes Issues wih Cisco Extension
Mobitty.
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.
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
(CSS), AAR group, and AAR CSS, are modified.
Basically, all location-dependent parameters can be dynamically reconfigured by Device Mobility. Thus, the phone keeps its user-specific configuration, such as directory number,
configured in such away that dial plan-related settings, such as the device calling search space
4-6
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:
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.
Issues with Devices Roaming Between Sites

This topic describes issues that occur when users roam between sites with their devices.
Roaming Devices
Cisco IP Communicator) ofa roaming user.
Cisco
Device can be an IP phone or, more likely, a softphone (such as
Unified
Com municatj oris
Manager
Remote
Gateway
s.
WAN
Roaming Device
IP Communicator orCisco Unified Wireless IP phones.
typically does not apply lo Cisco IP phones, but is very common with softphoncs such as Cist
When users roam between sites, they might take their phones with them. This situation
4-4
Implementing Cisco Unified Communications Manager. Part 2(CIPT2) V8.0
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
solution.
location. It is important that aprofessional unified communicalions system provides such a
This lesson describes Cisco Unified Communications Manager Device Mobility, afeature of
Cisco Unified Communications Manager that allows its endpoints lo be dynamically
device.
reconfigured based on their actual location as determined by the IP address that is used bv the Upon completing this lesson, you will be able to describe how Device Mobility works and how
Identify the issues with devices roaming between sites
Describe the Device Mobility feature
Objectives
it is implemented. This ability includes being able to meet these objectives:
Describe the Device Mobility configuration elements and their interactions

Describe Device Mobility operation
Describe Device Mobility interaction with globalized call routing

Contigurc Device Mobility
4-2
>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
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
Upon completing this module, you will be able to implement Device Mobility and Cisco
CCD PSTN BackupCSS SRST Considerations

TEHO Considerations
Monitoring Leamed Routes in Cisco Unified Communications Manager Express
5-57
-bi
^
Cisco IOS SAF Client Considerations When Using Globalized Call Routing Solution for PSTN Backup Advertised in E.164 Format Without Leading + Cisco Unified Communications Manager Clusters and CCD Configuration Modes Other SAF and CCD Considerations Summary
References
CCD and Static Routing Integration Considerations
jj-58 J"^
5-b^ 5-63 5-bb 5-67 d-oo _g8
,
Trunk Considerations When Using Globalized Call Routing
Module Summary
References
5]6g
,. -,.
Module Self-Check Module Self-Check Answer Key
r~
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

Summary
4-67
~
References
Module Summary
Tro
Module Self-Check
References
71^
4"'4
Jy

Overview
.
.
5~1
5-1 5-1
Module Objectives
Implementing SAF and CCD

SAF and CCD Overview
$
5-4
Objectives
Dial Plan Scalability Issues in Large Networks Scalable Dial Plan Solution for Large Networks Call Control Discovery Overview SAF Characteristics SAF Client Types SAF Message Components
SAF Client and SAF Forwarder Functions CCD Characteristics CCD Characteristics CCD Services in Cisco Unified Communications Manager
SAF Routing Characteristics SAF Neighbor Relationships
5-5 5"6 5-7 5-8 5"9 5-10
5-11 5"12
5-13 5-14
CCD Operation
Processing Received Routes in Cisco Unified Communications Manager
5-15 5-17
5-19
5"22 5-23
CCDPropagation of HQ Routes CCDPropagation of BR Routes

CCDCall from HQ to BR CCDLink Failure at BR
5_2|
5-24 5"25
CCDCall from HQ to BR During Link Failure SAF and CCD Implementation External SAF Client Configuration Elements Relationship ofExternal SAF Client Configuration Elements Internal SAF Client Configuration Elements Relationships ofInternal SAF Client Configuration Elements SAF Forwarder Configuration Procedure Step1: Configure SAF Forwarder Step2: Configure SAF Forwarder to Support External SAF Clients External SAF Client Configuration Procedure Step1: Configure SAF Security Profile Step2: Configure SAF Forwarder Step 3: Configure SAF Trunk Step 4: Configure Hosted DN Group Step 5: Configure Hosted DN Pattern Step6: Configure CCD Advertising Service Step 7: Configure CCD Requesting Service and Partition Step 8: Configure CCD Blocked Leamed Patterns Step 9: Configure CCD FeatureParameters
Internal SAFClient Configuration Procedure Step 1: Configure Trunk Profile Step 2: Configure Directory Number Blocks Step 3: Configure Call Control Profile Step 4: Configure Advertising Service Step 5: Configure Requesting Service Step 6: ConfigureVoIP Dial Peer
CCD Considerations
5-26 5-28 5-3 5-31 5-32 5-33 5-34 5-35 5-36 5-37 5-38 5-39 5-40 5-41 5-42 5-43 5-44 5-45 5-46
5-48 5-49 5-50 5-51 5-52 5-53 5-54
5-55
Monitoring Leamed Routes in Cisco Unified CommunicationsManager

ii ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)v8.0
5-56
Table of Contents
Volume 2

Overview
Module Objectives
1
4-1 4-1
Implementing Device Mobilitv
___
4.3
4^ 4_4 4_5 4_6 4_7 4-8 4-10
Device Mobility Configuration Elements
Objectives Issues with Devices Roaming Between Sites Issues with Roaming Devices Using Device Mobility to Solve Roaming Device Issues Device Mobility Overview Device MobilityDynamic PhoneConfiguration Parameters Device MobilityDynamic Configuration by Location-Dependent Device Pools
4_11
Relationship of Device Mobility Configuration Elements Device Mobility Operation Device Mobility Operation: Flowchart Device Mobility Considerations Device Mobility and Calling Search Spaces Examples ofCall-Routing Paths Based on Device Mobility Groups and TEHO Device Mobility Interaction with Globalized Call Routing Advantages ofUsing Local Route Groups and Globalized Call Routing
Example: No Globalized Call RoutingDifferent Device Mobility Group
4-12 4_14 4_1g 4^1 g 4_20 4-22 4_24 4-26
4-27
Example: No Globalized Call RoutingSame Device Mobility Group Example: Globalized Call Routing Device Mobility Configuration Steps 1 and 2. Configure Physical Locations and Device Mobility Groups Step 3: Configure Device Pools
Step 4. Configure Device Mobility Infos
4-28 4_29 4_30 4-31 4.32

4.33
Step 5a: Set the Device Mobility Mode Cisco CallManager Service Parameter Step 5b: Set the Device Mobility Mode for Individual Phones
Summary References
4-34 4-35
4_3g 4.37
Implementing Cisco Extension Mobilitv

Objectives Issues with Users Roaming Between Sites Issues of Roaming Users Cisco Extension Mobility Solves Issues of Roaming Users Cisco Extension Mobility Overview Cisco Extension Mobility: Dynamic Phone Configuration Parameters Cisco Extension Mobility: Dynamic Phone Configuration by Device Profiles Cisco Extension MobilityConfiguration Elements Relationship of Cisco Extension Mobility Configuration Elements Cisco Extension MobilityOperation
Issues in Environments with Different Phone Models Default Device Profile and Feature Safe How Cisco Extension Mobility Handles Phone Model Differences Cisco Extension Mobility and CSSs Alternatives for Mismatching Phone Models and CSS Implementations Cisco Extension MobilityConfiguration Step 1: Activate the Cisco Extension MobilityService Step 2: Set Cisco Extension MobilityService Parameters Step 3: Add the Cisco Extension MobilityPhone Service Step 4: Create Default Device Profiles Step 5a: Creale Device Profiles
4.39
4.39
4-40 4-41
4-42 4-43 4-45 4-46 4-47 4-49 4-50

4-52 4-53 4-54 4-56 4-57 4-58 4-59 4-60 4-61 4-62 4-63
Step 5b: Subscribe Device Profile to Cisco Extension Mobility Phone Service
Step 6: Associate Users with Device Profiles Step 7a: Configure Phones for Cisco Extension Mobility
4-64
4-65 4-66
3-110
Implementing CiscoUnified Communications Manager. Part 2 (CiPT2) v8.0

QD
D A
Q2) Q-D
Q4)
05)
B C
D B
06)
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)
Q9) QIO)
B. [
B A
qui
3-109
Q7) Q8)
What is alimitation ofstandard locations-based CAC? (Source: Implementing CAC) Which statement is false about CAC when using RSVP-enabled locations? (Source:
Implementing CAC)
A)
B)
CAC adapts to the actual topology and considers network changes.

RSVP is used for CAC and toprovide QoS for each individual stream.
C)
D)
The RSVP agent to be used by aphone is determined by the Media Resource

Group Listof the phone.
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)
B)
calls rejected by an H.323 gatekeeper

calls rejected by standard location-based CAC
C) D)
E) F)
calls placed tounregistered phones calls placed toa gateway that is busy
callsrejected by RSVP-enabled location-based CAC 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) B) true false
QII) How can calls that are rejected by an H.323 gatekeeper be rerouted by using adifferent
path? (Source: Implementing CAC)
A) B) C)
by configuring route lists and route groups with backup devices by putting the gatekeeper-controlled intercluster trunk or H.225 trunk into a
location that is set to unlimited
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
Module Self-Check
Use the questions here to review what you learned in this module. The correct answers and
Ql)
Which feature does not conserve bandwidth in the IP WAN? (Source: Managing
Bandwidth)
A) B)
C)
RTP headercompression low-bandwidth codecs

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)
b\ specifying the maximum permitted codec bandwidth between pairs of

regions
bv specifying the maximum permitted codec bandwidth between pairs ot

locations
C) D)
by specifying the maximum bandwidth per stream with the bandwidth zone by specifying the maximum permitted codec bandwidth tor calls going out ot
or coming into a region
local command
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) C)
D)
number ofsites *(number ofsites - l)/2

one per site
one
B)
one per site and one per conference bridge
Q4>
Which device requires access to Ihe transcoder from its Media Resource Group List
when transcoding is required for acall? (Source: Managing Bandwidth)
A) B)
C)
both endpoinls of the call the callingdevice

the called device
ade% ice that supports only codecs that are not permitted tor the call
D)
Q5)
Which statement is true about multicasl MOI 1from branch router flash? (Source:
Managing Bandwidth)
A)
C) D)
Multicast MOH from branch router flash requires an SRST router to be in

fallback mode to work.
B)
The branch router supports G.711 and G.729 only for MOH. 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.
Multicast MOH from branch router flash can also be used tor unicast MOH.
Q6)
Which CAC-related feature applies to intercluster calls? (Source: Implementing CAC)

A) locations
B) C) D)
H.323gatekeeper CAC
AAR
RSVP-enabled locations
3-107
3-106 implementing Cisco Unified Communicalions Manager, Par. 2(CIPT2) v8.0
Module Summary
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.
deplovment in amultisite environment in order to reduce bandwidth requirements mthe II

can be rerouted over the public switched telephone network (PSTN) ifthere is insufficient
bandwidth.
This module described the available design options and features that are recommended tor
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
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-801cm.html
Cisco Svstems Inc. Cisco Unified SRSTSystem Administrator Guide, December 2007.
guide srr.lsa.hlml
IUtp:.vw;w.cisco.coni/eivUS/partner/docs/voice ipônitn/aisrst/adtnin/srst/configurtmc.,..
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
. Cisco Svstems. Inc. Cisco IOS H.323 Configuration Guide Release 15.0- Configuring
config psl05'Jt TSD Products Configuration Guide.Chupler.lilm!

3-105
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
Cisco Systems, Inc. Cisco Unified Communications System 8.x SRND, April 2010.
Release 8.0(1), February 2010.

em.html
http:/Avuu.cisco.com/en/US/docs/voice_ip .coinm/cticm/srnd/8N/uc8\.himl Cisco Systems, Inc. Cisco Unified Communications Manager Administration Guide
h!tp:/Av\u\.cisco.c(>m/enAJS/doLVvoicc_ip_comnVcucin/admin/8_0_l/ccmcfe/bccni-80I-
Cisco Systems, Inc. Cisco IOS H.323 Configuration Guide Release 15.0 - Configuring
H323Gatekeepers and Proxies, February 2008, October 2009.
contIg_psl059i_TSD_Products_Connguration_Guide_Chapter.html
http://\\u^.cisco.com/en/L!S/partner/docs/ios/voicc/h323/coniiguration/guidc/vh_h323 gk
3-104
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
Note
Add PSTN gateways lo route groups, and add these gateways to the route lists that
are using the gatekeeper-controlled trunks.
You configured PSTN backup in earlier lab activities ofthis course
Bandwidth Management andCAC Implementation

3-103
Configuration Procedure for Implementing H.323 GatekeeperControlled 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 GatekeeperControlled 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 (gatekeeper4
controlled intercluster trunk or H.225 trunk) inCisco Unified Communications Manager. 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;
path for the gatekeeper-controlled trunk.
Modify route list and route groups to provide a PSTN backup
To implement gatekeeper-controlled trunks, perform these steps:
Step 1
default technology prefix.

Note
Enable gatekeeper functionality at aCisco IOS router and configure the gatekeeper for call routing. This configuration typically includes zones, zone prefixes, and the
More information about gatekeeper configuration is provided in the Implementing Cisco
Voice Communications and QoS (CVOICE) course.
Step 2 Step 3
Step 4
Add the gatekeeper to Cisco Unified Communications Manager. Add the gatekeeper-controlled trunk (either agatekeeper-controlled intercluster trunk or an H.225 trunk) to Cisco Unified Communications Manager, and configure
the trunk. ' &
match acertain route pattern (for example, 9.5[l2][l2]. , for the examples that
were shown earlier in this topic) tothe gatekeeper-controlled trunk.
Configure route groups, route lists, and route patterns in order to route calls that
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
limitations (tvniYallv rpni n r**H rmlw frt- :<^ -~n .^ imitations (typically required only for interzone calls).
3-102
Implementing Cisco Unified Communicalions Manager, Part 2(CIPT2) v8.0
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
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
PSTN Prefixes 511.521
Manager Cluster
PSTN Prefixes: 512, 522 HQ-1
Route Pattern:
9.15112J2XXXXXXX
Route Group. H.225 Route Group PS I N
Trunk. Clusterl
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 methodroute lists and route
groupsfor 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
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.
overoneor more PSTN gateways. If thecall cannot besetup overthe trunk, Cisco Unified
3-100
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.
2C1Q Cisco Systems. Inc
3-99
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 Manager Cluster PSTN Prefixes 511.521 192.168.3.254
Cisco Unified Communications Manager Cluster
PSTN Prefixes 512,522
10.1 1.1
pow Trunk: Cluster^ ^mm^ Ji.225 Trunk: CL-^

gatekeeper
ions local ClusterA lab.ccm 192.168.3.254
10.1.1.1
10.1.1 2 H 225 Trunk'Clusterl
10.2.1 2
ions local ClusterB lab.cm 192.169.3.254

one prefn ClusterA 511-
DeviceType. Gateway
Zone ClusterA
lone prefix ClusterA 521"

ions prefin ClusterB 513
H.225 Trunk; Cluster2
DeviceType.Gatenvay
Zone1 ClusterB
Technology Prefix Mr
GK 192 158 3 254
rone prefix ClusterB 522*
bandwidth interzone default a bandwidth intertone sons CI ustsrB bandwidth session default 128
Technology Prefix: Mr
IS
GK 192.168 3.254
bandw4.dth total zone ClusterB 688

9"-type-prefix lt default- technology
no shutdown
performs CAC.
The example is based on the previously illustrated example, but now the H.323 gatekeeper also
different setting.
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
default interzone bandwidth limit should not apply to ClusterB but that ClusterB should instead
be limited to 48 kb/s.
The bandwidth interzone zone ClusterB 48 command specifics that the previously configured
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
ClusterA has nototal limit applied.
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
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
effectively would permit these limitations:
IfG.729 is used for inter/one calls and G.711 is used for intrazone calls, this configuration CusterB is limited to 48 kb/s (that is, three times twice the codec bandwidth of8kb/s)
> There can be amaximum of three G.729 calls between ClusterA and ClusterB because
never beable to use thepermitted interzone bandwidth.
only two zones and the other zone (ClusterB) is limited to three G.729 calls ClusterA will
ClusterA could have four G.729 calls to other zones. However, because the example shows
3-98
Implemenling Cisco Unified Communications Manager, Part 2(CIPT2) v8.0
Bandwidth limitations are configured differently on different Cisco products and for different features. The table summarizes how to configure bandwidth limitations in Cisco Unified
Cisco Unitied Communications Cisco Unified Communications Cisco IOS H.323
Gatekeeper
Manager Region Audio-Only Call Configuration

Audio codec only
Manager
Location
Audio codec bit rate +
Twice the audio codec

bit rate
128 kb/s
Layer3 overhead
80 kb/s
Example: G 711 Call

Video Call
G.711
Audio codec and video
Video call speed
Twice the video call
Configuration
call speed
G.711 and 384 kb/s
384 kb/s
speed
768 kb/s
Example 384-kb/s
Video Call
Note
Video calls have not been discussed in this course but are also shown for completeness.

;010 Cisco Systems, Inc
3-97
Using an H.323 Gatekeeper for CAC

the figure.
To use an H.323 gatekeeper for CAC, you have to configure bandwidth limitations, as shown
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
default for all zones not explicitly configured):
specified zone (interzone calls)
interzone: Applies to all calls coming into and going out of the
- 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
interzone
Description
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 default
zone
Specifies the maximum bandwidth that isallowed for a session in the zone
Specifies the default value for all zones.
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
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. ____
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.
Ifthe gatekeeper receives an Admission Request (ARQ) message from one ofthe H.323
You can verifv the list of configured prefixes and their /ones by using the command showgatekeeper 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
two eatcwa% s(in round-robin fashion) to be the terminating gateway. It will inform the
prefix and is registered bv 10.2.1.1 and 10.2.1.2. Therefore, the gatekeeper chooses one of these
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

j 2010 Cisco Systems, Inc.
3-95
Resolution) Only
Example: H.323 Gatekeeper Used for Call Routing (Address

Communications Manager deployment.
The figure shows an example for gatekeeper-controlled trunks in adistributed Cisco Unified
Call Routing (Address Resolution) Only

Cisco UnrfiedCommunications u, Cluster Manager r-, .
Example: H.323 Gatekeeper Used for
Cisco Unified Communications ,,, , .
i-i, 11- .. r-
PSTN Pr* 511.52,
PSTN pXe"'512^22
192.168.3.254
10.2.1.1
101 11 -"
10.1.1.2
H.225Trur^Clus^ ^ ^ J^Tn** C,uste/2

gatekeeper
zone local ClusterA lab.con zone local ClusterB lab.com

zona prefix ClusterA 511* zone prefix ClusterA 521-
10.2.1.2 H.225 Trunk: Cluster2
H 225 Trunk Clusleri
DeviceType Galeway
Zone CluslerA
zone prefix ClusterB 512*

zone prefix CluaterB 522*
DeviceType. Gateway
Zone: ClusterB
Technology Prefix If
GK. 192168.3254
g-type-prefix 1# default-technology
no shutdown
Technology Prefix MT
GK. 192 16S.3.254
GATEKEEPER BKDPOINT HEGISTRATIOH
H323-ID
Clusterll Clusterl_2 Cluster2_l ClusterJ_2
IPAddr
10.1.1.1 10.1.1.2 10.2.1.1 10.2.1.2
ZonaName Type
ClusterA VOIP-GW ClusterA VOIP-GW ClusterB VOIP-GW ClusterB VOIP-GW
Prefii
1#* 1#' If 1#*
hasan H.225 trunk configured.
In the example, two Cisco Unified Communications Manager clusters arc shown Each cluster
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 ('**}" Bth tnmks refer t0 **1P address oUhc sa gatekeeper: I yl. 168.3.254.
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
ClusterA uses Clusterl. and ClusterB uses Cluster2. In each cluster, there are two call-
The 11.225 trunks use different names per cluster in order to keep the H323 IDs unique
The gatekeeper has two local zones: ClusterA and ClusterB. It is configured to route calls to
gateway orgateways that registered a technology prefix of I#*).
This gateway configuration means that the gatekeeper will have four gateways registered: ' Manager Group that isconfigured in the device poolof the Cisco Unified Communications MUSterL^* WhiCu fS tHe ^ cal|-Processing server 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-
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. _
processing servers of two or more clusters will try to register with the same H.323 ID. The
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
differentlv for calls within a zone versus interzone calls.
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
The H323 zone name that is configured at the gatekeeper-controlled trunk is case-sensitive
and hastoexist atthe gatekeeper ^ __
Note
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
prefix ('for instance. 1* for voice services, 2* for fax services, and so on). Calls that include
\s mentioned earlier, agatekeeper can be configured to route calls-for which it does not
atewav to indicate the services that it provides by specifying an appropriate technology
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.
configured to be the default technology. For example, if there is only one Cisco Unified
know which gateway to use-to the gateway or gateways that register with aprefix that is
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. _

;010 Cisco Systems. Inc
3-93
H.323 Gatekeeper CAC

This topic describes 11.323 gatekeeper CAC support in Cisco Unified Communications Manager.
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 ownwithout the use of a gatekeeper for address resolution and CACor 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
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.-î;- iOi'tis i-,g
Apply SIP Profile.
.L
--_
fl--!lei!=;^'.:.C.Jc-.'
:..,ln-(i,-:u5* ;:=-Tj-kS:u--. f-tfw'
*-!... C*l 'j5M-f5|U
':iul
ii*r3j (1 P tara g-cw:
jr
r
"
V
--'IMSele;tM -
' '.cr- j
- ,;-= -
^^^
Jf
y'
/jr
** . V
-_ 3' ? sl3j ;;'V 13ls-3'--* Ipi

5 = sc=.tECa i-j5.'=-!:!
---; ;,-.'
e . i, -.
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
Step 2a: Configure SIP Profile

The figure shows how to configure SIP Preconditions settings at a SIP profile.
Step 2a: Configure SIP Profile
Check the checkbox

to allowfatlbackto
Chocse E2E from
the drop-down
list.
local RSVP
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 devicefor example, Cisco Unified Communications Manager Expressand 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
SIP Preconditions Configuration Procedure

This subtopic describes the SIP Preconditions configuration procedure.
SIP Preconditions Configuration

Procedure
! a Follow standard procedure of RSVP-enabled locations. Configure RSVP service parameters.
b o
d
Configure RSVP agents in Cisco IOS Software. Add RSVP agents to Cisco Unified Communications
Manager.
Enable RSVP between location pairs.
e f
Configure Media Resource Groups. Configure Media Resource Group Lists.
g 2
Assign Media Resource Group Lists to devices. 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.
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
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-
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.
3-87

(Cont.)
Manager Media component
initiates renegotiation of media capabilities.

Media Request. forFull Sat ot Codec Capabilities
Answ3witti SlnflteCode
NegotiatedbyMedia
Session is established (RSVP bandwidth is adjusted if
necessary).
Session is established (RSVP
banOwidth Is adjusted if
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

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
e=MIP4 1920 21
a=currqose2ei
>
a=wjrE.flose2e '.vi'-t a=desqos mandatory e2a
a=des qos mandatory e2e

flendrecv
^H.II.J.I Ii>Kiaa*gaaâi
<
sendrecu
a^conl qos e2e recv
SIPUA1 initiates
RSVP reservation in the 1 - 2 direction

nvauOio 10000 RTPNWP 0 c=!NIP4 192021
SIP UA2 initiates

RSVP reservation in the 2 ^ 1 direction.
a^currqos s2e';e--.i
allies qos mandatory e2e
sendiecv
m=audio 20000 RTP/AVP 0 C=INIP4192 02 2
^fBJSIfriJt'Jii'lWI
a=curr qtra e2f ser **;. aides' qos mandalory e2e
<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
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 RSVPbased CAC was performed
The middle call legbetween thetwo RSVP agents, where RSVP-based CAC was
performed, as described earlier
Note
The call leg between the terminating IP phone and its associated RSVP agent, where
againno RSVP-based CAC was performed 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
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
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 devicefor example aCisco Unified Communications Manager server of

another clusterresponds with a SIP SESSION PROGRESS message with SDP. Itwill
forward direction, andsend an RSVP request forthe reverse direction.
provide the IP address of the terminating RSVP agent, confirm the RSVP request for the
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.
j 2010 Cisco Systems, Inc.
3-83
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
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.
)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
Step 4: Configure Phones for AAR (Cont.
Forward calls to
Set (verify) exiemal

phone number mask
voce mail if directory

number cannot be
reached due lo locai ms-based CAC.
Set individual destination number
mask (CFNB) to be used instead of

external phone number mask and
AAR group prefix
otdireclory numbef
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).
3-79
Step 4: Configure Phones for AAR

The figure shows how to configure phones for AAR.
Step 4: Configure Phones for AAR

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
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).
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
AAR Configuration Procedure

The implementation of AAR includes these steps.
AAR Configuration Procedure

1
2
3 A
Configure AAR service parameters (Cisco CallManager

service).
Configure partitions and CSSs.

Configure AAR groups. Configure phones for AAR:
ApplyAARCSS and (source) AARgroup to IP phones.
& Configure IPphone directory numbers: 1) Apply (destination) AAR group.

2)
s,
Set individual AAR destination mask (CFNB),

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.
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 routing simplifies AAR implementation in international deployments.
AARdoes not support CTI route points as the origin or destination

of calls.
AAR does not workto Cisco Extension Mobility users roaming to

different sites.
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 Survivable Remote Site Telephony (SRST). AAR is activated only
after a call is denied by CAC, not by WAN failures.
Using globalized call routing simplifies the implementation of AAR substantiallyespecially

in international deployments.
AAR does not support CTI route points as the origin or destination of calls, and AAR is not compatible with Cisco Extension Mobility for users who roam to different sites.
Note
When tail-end hop-off (TEHO) is used, itisimportant toconfigure AAR in such a way that the local gateway is always used for callsbeing rerouted by using AAR. This automatically
occurs when you use local routegroups. When youare not using local routegroups, you have to configure AAR CSS so that the focal gateway is used forAAR calls. Ifthe AAR CSS refersto the TEHO gateway, AAR callswill fail, because the callleg to the (remote) PSTN gateway again has the same issue that the initial call had: Itneeds to go overthe IP WAN (which typically meansthat itgoes outofthe location ofthe originating phone), butdoing thatis not possible becauseno bandwidth is left for the location (which was the reason why
the initial called ended up in a CACfailure).
3-74
implementing CiscoUnified Communications Manager, Part2 (CIPT2) v8.0
In the example, all phones are in the same AAR group (System). Noprefix is configured for callswithin thissingle AAR group. There is a single route pattern in Ii.164 format: (\+!). The route pattern refers to the only configured route list, which is configured to usethe local route group. Each gateway is referenced from a site-specific route group. U.S. phones use a U.S.specific device pool with the local route group setto U.S., and German phones use a device pool specific to theircountry. where the local route group refers to the DE route group. The external phone number mask in globalized format is +15115222xxx at U.S. phones and +4969125xxxx at Gemian phones. The AAR CSS is the same for both phones and provides
access to the '*+.! route pattern.
When a call from a U.S. phone to a German phone is notadmitted because of no available bandwidth, theexternal phone number mask of the German phone is merged withthe directory number ofthe phone (in thiscase, the result is +49691253001). No AAR prefix is added, so a
call isplaced to that number. It matches the \+.! route pattern, and the local route group isto be
used, fherefore. the call is sent to the U.S. gateway, where the called numbercan be localized,
using called-party transformation (that is. the number ischanged lo49691253001 with a
number type of international) settings thatare configured at the gateway.
The same thing happens for calls in the other direction. As a result,+15115552001 is called,
and after the called numberis localized at call egressagain provided by global Iransformations at the gatewaya call with a number type of international is placed to
15115552001. this time through the Gennan gateway.
3-73
AAR Example with Local Route Groups and Globalized

Numbers
The figure shows an AAR examplewhere globalized call routing and local routegroups are
used.
AAR Example with Local Route Groups

and Globalized Numbers
,. Sitel Site 2
IP WAN
PSTN
Route PaBem;**!
1
Single Roule List Default Local Route Group
DN" 2001
Ext Phone Number Mask + 15115552XXX
DN": 3001
Single Route Pattern in One

Partition, Single AAR CSS, Single AAR Group, No Prefixes Within AAR Group
Ext. Phone Number Mask
+4969125XXXX
' Unified CM = Cisco Unitied Communications Manager, " DN = directory number
If the AAR destination mask is entered in the globalized form, and if every AAR CSS is able to
route calls to destinations in the globalized form, then system administrators can forego the
configuration of AAR groups, because their sole function is to determine which digits to prefix based on the local requirements of the PSTN access of the calling phone to reach the specific destination. With globalized call routing, Cisco Unified Communications Manager can route calls to the PSTN in E. 164 format with a + prefix. When you configure the external phone number mask, in this format, no prefixes are required for AAR. To localize the called- and calling-party numbers, implement global transformations for each egress PSTN gateway (like
for normal PSTN calls).
Without local route groups, the AAR CSS is used to route the call through the colocated gateway of the calling phone by matching a site-specific route pattern that refers to a sitespecific route list, route group, and gateway. When local route groups and globalized call routing are implemented, the egress gateway does not need to be selected by site-specific AAR CSS. because the egress gateway is determined by the local route group feature. In summary. \\ hen you are using globalized call routing with local route groups, AAR implementation is extremely simple: Only a single AAR CSS and AAR group are required and applied to all phones, regardless of their location.
3-72
In the other direction, an AAR call from a German phone to a U.S. phone composes a dial string of 00015115552001. which is the format that is used for inlemalional calls to the United States. It matches the 0.! route pattern and is sent out using the German gateway. In summary, this two-site example requires two route patterns in different partitions, two AAR CSSs. and two AAR groups. In a large, worldwide deployment with lots of different numbering plans, the configuration of AAR groups can be relatively complex.
)2010 Cisco Systems, Inc
AAR Example Without Local Route Groups and Globalized

Numbers
The figure shows an example of AAR when globalized call routing and local route groups are not being used.
AAR Example Without Local Route Groups and Globalized Numbers

Second call fails locations-based CAC
UnifiedCW
Site 1 (+1):
international
and should use PSTN.
Site 2 (+49):
International
Dialing: 9.011
Location Configuration
Hu6_None. Unlimited
BR-LOC 24 kb/s
Dialing: 0.00
AAR Group Configuration.

ON" 2001 Prefix U.S. lo DE. 901149 Prefix DE to U S.. 0001 DN": 3001 Ext Phone Number Mask: 69125XXXX
E<t Phone
Number Mask: 511S552XXX
Two Roule Paltems in Different
Partitions, Two AAR CSSs,
Two AAR Groups

' Urafied CM - Cisco Unified Communications Manager, " DN = directory number
There are two sites, one in the United States and the other one in Germany (country codes 1 and 49). At site 1 (country code 1) the access code is 9, at site 2 (country code 49) the access code
is 0. Both countries use 10-digit numbers. There are two route patterns(9.@ for site 1 and 0.! for site 2). Each route pattern is in a site-specific partition, and the phones use site-specific
CSSs.
Fromthe perspective of AAR, U.S. phones are configured with a 10-digitexternal phone number mask, and phones at Germany also use national format for the external phone number mask. U.S. phones are in AAR group U.S., and German phones are in AAR group DE. AAR prefixes are configured in this way:
Prefix from AAR group U.S. to AAR group DE: 901149

Prefix from AAR group DE to AAR group U.S.: 0001
The AAR CSS of U.S. phones has accessto the 9.@ roule pattern; the AAR CSS of German
phones has access to the 0.! route pattern.
When a call from a U.S. phone to a Gennan phone is not admitted because of no available bandwidth, the extemal phone numbermask of the German phone is merged with the DN of the phone (in this case, the result is 691253001). Then the prefix 901149configured from AAR group U.S. to DE is appended, resulting in a call to 901149691253001, which is processed by the 9.(S) route patternthat refersto the U.S. gateway.
3-70
AAR Characteristics
This subtopic describes the characteristics of AAR.
AAR Characteristics
Provides a fallback mechanism for calls denied by CAC:
- Reroutes calls over PSTN.
- Works only for locations-based CAC (standard locations

and RSVP-enabled locations).
Works only for cads placed to internal directory numbers. Alternate number is composed of dialed directory number, a
prefix configured per AAR source and destination group, and the external phone number mask of the called device: - AAR destination mask can be configured per device (a.k.a. Call Forward No Bandwidth [CFNB]) to reroute calls to other phone numbers, such as cell phones. - Forward to voice mail can be configured per device to
reroute calls to voice mail.
AAR pro\idesa fallback mechanism for callsthat are denied by locations-based CAC or
RSVP-cnablcd locations-based CAC bv rerouting calls over the PSTN in the event of CAC
failure.
AAR works only for calls that arc placed to internal directory numbers. It docs not apply to calls that are placed to route patterns or feature patterns such as Meet-Me or Call Park. Ho\\e\ er. it does work for hunt pilots and computertelephony integration (CTI)ports.These entities can be configured with an AAR group andan AAR calling search space (CSS).
The alternate number that is used for the PSTN call is composed of the dialed directory
number, a prefix that is configured perAAR source and destination group, and theexternal
phone number mask of the called device.
Alternatively, calls can berouted tovoice mail, oryou can configure an AAR destination mask
for each device that allows an> numberto be used for the rerouted call. The numberthat is
specified at the AAR destination mask isalso known as the Call Forward No Bandwidth
(CFNB) destination. Note AAR is a fallback mechanism for calls that are denied by locations-based CAC or RSVPenabled locations-based CAC. It does not apply to calls that are denied by gateways d le to
exceeding the available or administratively permitted number ofchannels, or to calls tut have been rejected on trunks (for example, ongatekeeper-controlled H.225 or intercluster trunks) If suchcalls fail (for whatever reason), fallback mechanisms are provided by route
lists and route groups.

This topic describes how to implement AAR in Cisco Unified Communications Manager.
AAR Overview
Headquarters
Branch B
ys Cisco Unrfied CommunicationsManager CACblocks a call over the IP WAN.
9 The call isautomatically rerouted over thePSTN.
AAR allows calls to be rerouted through the PSTN by using an alternate number when Cisco Unified Communications Manager blocks a call due to insufficient location bandwidth. With AAR. the caller does not need to hang up and redial the called party. Without AAR, the user wouldget a reordertone and the IP phone woulddisplay "Not enoughbandwidth."
AAR applies to centralized call-processing deployments. For instance, ifa telephone in a

company headquarters calls a telephone in branch B and the available bandwidth for the WAN
linkbetween the branches is insufficient (as computed by the locations mechanism), AAR can
reroute the call through the PSTN. The audio path of the call would be IP-based from the
calling phone to its local (headquarters) PSTN gateway, time-division multiplexing (TDM)based from thatgateway through the PSTN to the branch B gateway, and IP-based from the
branch B gateway to the destination IP phone.
AAR is transparent to users. Itcan beconfigured so that users dial only theon-net (for example, four-digit) directory number of the called phone. (Noadditional userinput is required
to reach the destination through an alternate network such as the PSTN.) In the examplethat is shown here, a call is placed from PhoneA to Phone B, but the locationsbased CAC denies the call due to insufficient bandwidth. Cisco Unified Communications Managernow automatically composes the required route patternto reach Phone B via the
PSTN and sends the call off-net.
3-68
Implementing Cisco Unified Communications Manager, Part2 (CIPT2) vfl.O
Afteryou click Save,the changes are displayed in the Location RSVP Settings section of the window. Only the locations thatarcnotconfigured to use the system default arelisted.
Note You can also enable RSVP within a location. For the currently configured location, Use
System Default is not an option. Youcan choose only No Reservation, Optional (Video Desired), Mandatory, or Mandatory (VideoDesired)within a location. The defaultfor calls to
own location is No Reservation, and to all other locations, the default is Use System Default.
Note
When RSVP-enabled locations are used, it is extremely important that the phones use the
appropriate RSVP agent. Note thattherewill be threecall legs, phone to its RSVP agent; that RSVP agent to another, remote RSVP agent; and finally, that remoteRSVP agent to its
phone.
How does Cisco Unified Communications Manager determine which RSVP agent is the
RSVP agent to be used by a given phone?The selection of the RSVP agent is based solely on the MRGLs that are assigned to the phones that attempt to establish a call. Errors in the MRGL configuration can resultinsuboptimal traffic flows. Therefore, whenyouimplement RSVP-enabled locations, you must properly assign phones to RSVPagents by using MRGLs and MRGs. The sample scenarioat the beginning ofthis configuration subtopic provided all the information that is needed for assigning the RSVP agentstothe phones Theappropriate configuration is notshown here becausethe configuration ofMRGLs and MRGswas covered in detail in the Implementing Cisco Unified Communications Manager. Part 1 (CIPT1) courseand becauseMRGLs and MRGs havealready beendiscussed inthis
course.
3-67
Step 4: Enable RSVP Between Location Pairs

The figure illustrates how to enable RSVP between pairs of locations.
Step 4; Enable RSVP Between Location

Pairs
After configuring the RSVPagentsin Cisco IOS routersand adding them to Cisco Unified Communications Manager, you need to enable RSVP between one or morepairsof locations. You performthis task in the Location Configuration window, whichyou access from Cisco Unified Communications Manager Administration by choosing System > Location. Choose
the location for which RSVP should be enabled for calls to one or more other locations. In the
Location Configuration window underModify Setting(s) to OtherLocations, the currently

configured location is listed. All other locations are also listed.
Choose the location to which RSVP should be used, and then choose the RSVP setting. You will find the same options thatyou found at the Default interlocation RSVP Policy service
parameter:
\o Reservation: No RSVP reservations are made between any two locations.
Optional (Video Desired): A callcanproceed as a best-effort, audio-only callif failure to obtain reservations forboth audio and video streams occurs. The RSVP agentcontinues to
attempt an RSVP reservation for audio and informs Cisco Unified Communications Manager if the reservation succeeds.
Mandatory: Cisco Unified Communications Manager does notringtheterminating device until RSVP reservation succeeds for the audiostream and, if the call is a video call, for the
video stream as well.
Mandatory (Video Desired): A video call can proceed as anaudio-only call ifa
reservation for the audio stream succeeds but a reservation for the video stream does not
succeed.
Inaddition, there is theoption Use System Default, which applies thevalue of the Default
interlocation RSVP Policy service parameter for calls to the chosen location.
3-66
Step 3: Add RSVP Agents to Cisco Unified Communications

Manager
The figure shows how to add an RSVP agent in Cisco Unitied Communications Manager.
Step 3: Add RSVP Agents to Cisco

Administration:
Media Resources > Media Termination Point
tAilt-n.-iaoifcrtTrB"
;,SCO105 Fnh.nr.H 5ft PWd.aT.rni.njtion 1 .
ttuioaon
H 1 HSiF lot 1
^\
Choose media termination point type and device
pool. Enter media termination point name and

description. Note The configured media termination point name has to matctittie name assignefl lothe
media resource at the Cisco IOS router
After configuring the RSVP agent function at theCisco IOS gateway, youneed to add the
corresponding media resource toCisco Unified Communications Manager. In Cisco Unitied

Communications Manager, choose Media Resources > Media Termination Point and click
Add New.
Inthe Media Termination Point Configuration window, choose the type of the MTP (currently there is only oneoption. Cisco IOS Enhanced Software Media Termination Point), enter a name anddescription, and then choose the device pool that should be used.
Note The name of the MTP has to match the name that was configured at the Cisco IOS router
with the associate profile idregister command entered inseep ccm groupidconfiguration
mode. The name is case-sensitive.
Note
Because RSVP-enabled locationsallow RSVPto be used between two RSVPagents lat are betweenthe twoendpoints ofa call, at least two RSVP agents have to be configured in a cluster to make itwork. Inthe example, these agents are HQ-1 and BR-1 The figure that
is shown with this step is an example that uses the HQ-1 router.
3-65
Note
The bandwidth that is reserved for a call depends on the codec that is used. As with standard (non-RSVP-enabled) locations, it is 80 kb/s for G.711 and 24 kb/s for G.729. During the call setup, however, the RSVP agent will always request an additional 16 kb/s, which is released immediately after the RSVP reservation is successful. Therefore, the
interface bandwidth has to be configured in such a way that it can accommodate the desired
number of calls (considering the codec that will be used) plus the extra 16 kb/s. If, for example, two G.729 calls are permitted on the interface, 64 kb/s must be configured; for two 2 G.711 calls, 176 kb/s is required.
In the example, only one G.729 call is permitted.
Note
Because RSVP-enabled locations allow RSVP to be used between two RSVP agents that are between the two endpoints of a call, you need to configure at least two RSVP agents in a cluster to make it work. In the example, these agents would be HQ-1 and BR-1, The figure that is shown with this step is an example that uses the HQ-1 router.
3-64
Step 2: Configure RSVP Agents in Cisco IOS Software

The figure shows how to configure a Cisco IOS router to enable RSVP-agent functionality.
Step 2: Configure RSVP Agents

in Cisco IOS Software
:p local FastBtheraetO/C
;p ccp 10.1.1.1 identifier 1
;p ccm group 1
SBOciate ecu 1 priority 1
Pass-through codec is
used, which allows a CiscolOS Software
MTP to be used.
Buociatf profile
1 register hq-1_mtf
MTP is used as RSVP
agent. Software MTP is used;

interface SerialO/1
description
IP-WAN
no hardware DSPs are
ip address 10.1.4.101 255.255.255.

duplex sutc
speed auto ip rsvp bandwidth 4C
required.
RSVPis enabled on
interface; permitted bandwidth is specified.
As with other mediaresources that arc provided by Cisco IOS Software (conference bridges and transcoders). the configuration starts with global Skinny Client Control Protocol (SCCP)
settings, followed by the Cisco Unified Communications Manager group configuration. In configuring the media resource itself (which you perform indspfarm profile configuration
mode). \ou use three commands that arc specificto the implementation of a software MI P
RSVP agent:
codec pass-through: This command specifies that the actual content ofthe RTP stream is
not modified. Mediaresources usually have to interpret and modify the audio stream:
examples are transcoders that change the codec ofthe audio stream, orhardware MTPs that
are used to convertout-of-band signaling to in-hand dual tone multifrequency (DTMF).
The RSVP agent repackages RTP only at Layer 3 and Layer 4. Itterminates the incoming call leg by dc-encapsulating RTP and then re-encapsulating the identical RTP into a new-
call leg. Because this simple repackaging does not require interpreting and modifying the audio payload (which isrequired with transcoders or hardware MTPs that are used for
DTMF). the router can perfonn this function in software.
* rsvp: This command specifics that this MTP isused as an RSVP agent that will be used to
set up a call leg to another RSVP agent where RSVP with IntServ over DiffScrv has to be
used.
maximum sessions software sessions: This command specifies the maximum numberof sessionsfor the mediaresource. Note that the keyword software has been used. This
keyword indicates that this RSVP agent should nol use digital signal processors (DSPs) but that itshould perform its function in software. You can use software MTP only when codec
pass-through has been configured.
After setting up the Ml"P RSVP agent, you need toenable RSVP on the WAN interface or interfaces b\ using the ip rsvp bandwidth bandwidth command. The specified bandwidth
determines how much bandwidth can be reserved by RSVP.
3-63
Step 1: Configure RSVP Service Parameters (Cont.)

Cisco Unified Communications Manager Administration: System > Service Parameters > Cisco CallManager
t "* *.r
- r- *
-l^.. j_f-i^...Kurj
.
Set default interlocation RSVP

. >*, -t .- . . rr, c*n B* T,Qt b*tt *HM
^Jtfrj
:-?
n-;-j. r.-r^ "i'^sjrti?
^
v d6T*ultDS
enor-handling option.
_St
or**,* DSCP<OO00O0l
0c**uK DSCP10CQ00D)
* d<Jult 05
Set DSCP values for calls where
RSVP failed (either immediately at

Ihe cal setup or m id-call).
The figureshows the configuration of the previously mentioned serviceparameters, as well as the service parameters that are used to set the differentiated servicescode point (DSCP) values thatshould be used forthe RTP packets of callsfor which RSVP failed. These parameters can be audiochannel (for which RSVPfailed at the call setup if the policywas set to Optional) or a videoor audiochannel(if the RSVPfailure occurred mid-call and the Mandatory RSVPmidcall error handle option is set to Call becomes best effort).
Youcan configure all these service parameters from Cisco Unified Communications Manager Administration by choosing System > Service Parameters under the Cisco CallManager service. All these parameters are clusterwide parameters; that is, they apply to all serversof the
cluster that is running the Cisco CallManager service.
3-62
The table shows the interactions of these policy settings.

RSVP Policy
When Reservation
Mandatory
RSVP
Mandatory
RSVP
Behavior or Call
Result
Failure (Non-Multilevel
Precedence and
Mid-Call Error
Handle
Mid-Cail
Preemption [MLPP])
Occurs
Retry
Counter
Option
Mandatory
Audio or video RSVP
Call rejected.
failure in initial call setup
Mandatory
Audio or video RSVP failure in mid-call
Call fails
following retry
counter
Call released if reservation does not
succeed after n retries.
exceeded
Mandatory
Call becomes best effort
Call proceeds as best

effort, and reservation is retried infinitely.
Mandatory (Video Desired) Mandatory
Audio RSVP failure in
Call rejected. Call proceeds as audioonly call.
initial call setup

Video RSVP failure in
~ -
(Video Desired)
Mandatory (Video Desired)
initial call setup

Audio RSVP failure in
mid-call Call fails
n
following retry
counter exceeded
Call released if reservation does not succeed after n retries.
Mandatory (Video Desired) Mandatory
initial call setup

Audio RSVP failure in mid-call Call becomes best effort
n
Call proceeds as audioonly call.

Call proceeds, audio
stream in call becomes best effort if reservation does not succeed after
n retries.
(Video Desired)
Mandatory
Call fails
Call proceeds as audioonly call.
(Video Desired)
mid-call
following retry
counter exceeded
Mandatory

mid-call
(Video Desired)
Call becomes best effort
Call proceeds; video

stream in call becomes
best effort if reservation does not succeed after

n retries.
Optional (Video Desired)
Audio or video RSVP
Call proceeds as audioonly call with best

effort; RSVP is trie.,
until reservation
succeeds or call is torn

down
Optional (Video
Desired)
Call proceeds as audioonly call; if audio

stream had reservation
failure, it becomes best

effort.
Mandatory
Audio or video RSVP
Call rejected.
~
3-61
RSVP Retry Timer: This parameter defines the interval (in seconds) after which the RSVP agent will retry the reservation if there is a failure. If you set this parameter to 0, you disable RSVP retry on the system. If the RSVP policy is optional, the call can still proceed even if there is RSVP failure during call setup time. An RSVP failure indicates insufficient bandwidth at the time of setup, so the call is likely to begin with poor voice quality. However, this condition may be transient, and the automatic reservation retry capability may succeed during the course of the call, at which point adequate bandwidth will be ensured for the remainder of the call. The icon or message that is displayed to the user initially should convey something like, "Your call is proceeding despite network congestion: you may experience impaired audio quality; if this condition persists, you may want to try your call again later." If reservation retry succeeds, the icon or message should be removed or should be replaced by one that conveys a return to normal network conditions and ensured audio quality. Mandatory RSVP Mid-Call Retry Counter: This parameter specifies the RSVP mid-call retry counter when the RSVP policy specifies Mandatory and when the mid-call error handle option "call fails following retry counter exceeded" is set. The default value specifies one time. If you set the service parameter to-1, retry continues indefinitely until either the reservation succeeds or the call gets torn down.
Mandatory RSVP Mid-Call Error Handle Option: This parameter specifies how a call should be processed if the RSVP reservation fails during a call. You can set this service parameter to these values: Call Becomes Best Effort: If RSVP fails during a call, the call becomes a besteffort call, if retry is enabled, RSVP retry attempts begin simultaneously. Call Fails Following Retry Counter Exceeded: If RSVP fails during a call, the call fails after n retries of RSVP if the Mandatory RSVP Mtd-Call Retry Counter service
parameter specifies n.
3-60
Step 1: Configure RSVP Service Parameters

Ihis step describes RSVP service parameters and how to configure them.
Step 1: Configure RSVP Service

Parameters
Default Interlocation RSVP Policy:
No Reservation: No RSVP resen/ations are made between locations.
Optional (Video Desired): Iffailure to obtain reservations for both audio and video
streams occurs, an audio-only call will be placed with best-effort service. Mandatory: Both audio and video (if wdeo call) reservations must succeed for
Cisco Unified Communications Manager to ring terminating device.
Mandatory (Video Desired): A video call can proceed as an audio-only call if a

reservation (or the audio stream succeeds but a reservation for the video stream
does not succeed
RVSP Retry Timer: Defines how often (in seconds) the RSVP agent will retry the reservation if there is a failure. Mandatory RSVP Mid-Call Error Handle Option: Ifa mid-call failure
occurs, defines whether call becomes best effort or fails (after n retries).
Mandatory RSVP Mid-Call RetryCounter: Defines the n tries for midcall error processing.
You can configure these important RSVP service parameters:
Default Interlocation RSVP Policy: This parameter sets the clusterwide default RSVP polic\. You can set thisservice parameter to oneof these values:
No Reservation: No RSVP reservations arc made between any two locations.
Optional (Video Desired): Acall can proceed asa best-effort, audio-only call if
failure to obtain reservations for both audio and video streams occurs. The RSVP
agent continues toattempt an RSVP reservation Tor audio and informs Cisco Unified
Communications Manager if the reservation succeeds.
Mandatory: Cisco Unified Communications Manager docs notring the terminating

device until RSVP reservation succeeds for the audio stream and, if the call is a
video call, for the video stream as well.
Mandatory (Video Desired): Avideo call can proceed as an audio-only call ifa
reservation for the audio stream succeeds but a reservation for the video stream does
not succeed.
3-59
Example: RSVP-Enabled Locations Configuration

The figure shows an example of RSVP-enabled locations-based CAC implementation.
Example: RSVP-Enabled Locations Configuration

Location HQ
HQ
10.1.1.1
Location BR
BRMRGL
1
BR RSVP
Cisco Unified
MRG
l^VtfWt
BR
In the example, there are two sites: headquarters (HQ) and branch (BR). Phones that are located in the headquarters are in location HQ, and phones that are located at the branch are in location
BR. RSVPagentsexist at each site (HQ-1_MTP is provided by router HQ-1, and BR-1_MTP is provided by router BR-1). The RSVPagentsare assigned to their respective locations.
Headquarters phones have the MRGL HQ MRGL applied; this MRGL includes the MRG
HQ RSVP_MRG, which includes the HQ-1MTP RSVP agent media resource. Branch phones have the MRGL BR MRGL applied; this MRGL includes MRG BR RSVP_MRG, which
includes the BR-1_MTP RSVP agent media resource.
Regions (not shown in the figure) are configured in such a way that G.729 has to be used for calls between headquarters phones and branch phones.
3-58
Configuration Procedure for Implementing RSVP-Enabled

Locations-Based CAC
To implement Cisco Unified Communications ManagerRSVP-enabled locations, you will need
to follow these steps.
Configuration Procedure for implementing

RSVP-Enabled Locations-Based CAC
1 2 3
4
Configure RSVP service parameters. Configure RSVP agents in Cisco IOS Software. Add RSVP agents to Cisco Unified Communications
Manager, Enable RSVP between location pairs.
5 6 r
Configure Media Resource Groups. Configure Media Resource Group Lists. Assign Media Resource Group Lists to devices.
Because the implementation of Media Resource Groups (MRGs) and MRGLs has been discussed in detail in the Implementing Cisco Unified Communications Manager, Part I (CIPT1) course and has been used in earlier lessons of this course, only Steps 1 lo 4 are
discussed in this topic.
Here are other RSVP messages:
Krror and confirmation messages: Reservation-request acknowledgment messages are sent as the result of the appearance of a reservation-confirmation object in a reservationrequest message. This acknowledgment messagecontains a copy of the reservation confirmation. An acknowledgment message is sent to the unicast address of a receiver host,
and the address is obtained from the reservation-confirmation object. A reservation-request
acknowledgment messageis forwarded to the receiverhop by hop to accommodate the

hop-by-hop integrity-check mechanism. Path-error messages result from Path messages, and they travel toward senders. Path-error messages are routed hop by hop using the path state. At each hop, the IP destination address is the unicast address of the previous hop.
Reservation-request errormessages result from reservation-request messages and tra\ cl toward the receiver. Reservation-request error messages are routed hop by hop using the reservation state. At each hop, the IP destination address is the unicast address of the next-hop node. Here is some of the information that can be carried in
error messages:
Admission failure Bandwidth unavailable
Service not supported
Bad flow specification

Ambiguous path
Teardown messages: RSVP teardownmessages remove the path and reservation state
without waiting for the cleanup timeout period. Teardown messages can be initiated by an
application in an end system (sender or receiver) or a router as the result of state timeout. RSVP supports two types of teardown messages: Path-teardown: Path-teardown messages delete the path state (which deletes the reservation state), travel toward all receivers downstream from the point of initiation, and are routed like Path messages.
Reservation-request teardown: Reservation-request teardown messages delete the reservation state, travel toward all matching senders upstream from the point of
teardown initiation, and are routed like corresponding reservation-request messages.
3-56
2010CiscoSystems, Inc.
How RSVP Works

The figure reviews the basic operation of RSVP.
How RSVP Works
Resv
Res
; ( Dest 10505050 !!
. Desl 10 30 30 30 .
/
!
Res.
Res*
.. 10 30 30 30 Dest ,
\NHop 10 SO 60 8'
; Dea '.320 20 20
NHop 10 50 50 5o]!\NHop 10 SOSOSrJ
3est 10 10 10 10
\MHap '330 33 30
In Hot. 1020 202\
= RSVP processing occurs
= BanAwitltti is reserved on interface
As shown in the figure, the RSVP-enabled sender (in this case, an RSVPagent)sends a Path message towardthe RSVP-enabled receiver(again,an RSVPagent in this case) along the path that requests bandwidth for the call to be set up. The receiver responds with a Resv message that is routed back along the path. Each RSVP-enabled device cheeks to see if the requested bandwidth is available and sends the appropriate information in the downstream path toward
the sender.
If no RSVP-enabled device on the path had lo deny the reservation because of insufficient
bandwidth, the reservation was successful: the call was admitted by RSVP CAC.
Here is a more detailed description of the key RSVP messages:
Path messages (Path): An RSVP Path message is sent by each sender along the unicast or multicast routesthat are provided by the routing protocol. A Path messageis used to store the pathstate in each node. The pathstateis used to route Resv messages in thereverse
direction.
Reservation-request messages(Resv): A reservation-request message is sent by each receiver host toward the senders. This message follows in reverse the routes that the data
packets use. all the way to the sender hosts. A reservation-request message must be
delivered to the sender hosts so that the hosts can setup appropriate traffic-control
parameters forthe first hop. RSVP does notsend any positive acknowledgment messages.
3-55
Characteristics of RSVP Agent-to-RSVP Agent Call Leg

This subtopic describes the characteristics of the call leg between two RSVP agents.
Characteristics of RSVP Agent-to-RSVP Agent Call Leg

Based on standard Cisco IOS RSVP.
IP network between RSVP agents is RSVP-enabled. Each interface is configured with maximum bandwidth to be reserved by RSVP. - If RSVP is not enabled on any hop in the path, the appropriate link is ignored by CAC algorithm.
IntServ and DiffServ models are used:
- RSVP only for CAC (control plane)

- LLQ for QoS (data plane) Call is set up only after successful RSVP CAC.
The call leg between two RSVP agenLs uses standard RSVP, as implemented in Cisco IOS routers. The IP network between the RSVP agents is RSVP-enabled. In other words, each interface is configured with a maximum amount of bandwidth that can be used for RSVP calls. When not enough bandwidth is available end-to-end (between the two RSVP agents, in this case). RSVP CAC denies the call, If RSVP is not enabled on any hop in the path, the appropriate link is ignored by the CAC algorithm {that is. it is always admitted on this link).
Cisco Unified Communications Manager RSVP agent CAC uses the Integrated Services (IntServ) and Differentiated Services (DiffServ) models for the RSVP call leg. In other words. RSVP is used only for CAC (the "control" plane), and not with RSVP-reservable queues for providing QoS to the streams. Instead, standard low-latency queuing (LLQ) configuration is required to provision QoS for the voice stream (the "data" plane). The end-to-end callthat is, the incorporation of all three call legsis established only after the RSVP call leg has been admitted. If the RSVP call leg is not admitted, the call fails due to CAC denial (not enough bandwidth).
3-54
ImplementingCisco Unrfied Communications Manager, Part 2 (CIPT2)v8.0
Characteristics of Phone-to-RSVP Agent Call Legs

This subtopic describes the characteristics of the call legs between phones and RSVP agents. Characteristics of Phone-to-RSVP
Agent Call Legs

* Based on Cisco Unified Communications Manager locations: - Usually phones and their RSVP agents are in the same
location.
If phone and its RSVP agent are in separate locations, standard location-based CAC is performed for this call leg. Phones have to use their RSVP agent: - RSVP agent that is used by a certain phone should be as close as possible to the phone, - RSVP agent to be used by a certain phone is determined by the Media Resource Group List of the phone. RSVP agent is an MTP: - Pass-through codec is supported: No changes to RTP payload
Allows secure RTP to be used
Standard locations algorithms apply lo the call leg between an IP phone and its RSVP agent, which are usually in the same location. If they are in separate locations, standard locationsbased CAC is performed for this call leg (phone to RSVP agent) first. The two RSVP agents will tr> to set up their call leg by using RSVP only if enough bandwidth is available for the IP phones to reach their RSVP agents.
An RSVP agent registers with Cisco Unified Communications Manager as a special MTP device. Cisco Unified Communications Manager uses the Media Resource Group List (MRGL) of the IP phone to determine which RSVP agent is to be used by which IP phone. The association of a phone to its RSVP agent does not occur as the result of a search for an RSVP agent in the same location of the phone. As mentioned earlier, the IP phone and its RSVP agent can be in separate locations. Only MRGLs arc used to identify the RSVP agent to be used by an IP phone.
From a design perspective, the RSVPagent that is used by a certain IP phone or group of phones should be as close as possible to the IP phone or phones. Such a design ensures that there are optimal pathswhere the phones ideallydo not use the IP WANto accesstheir RSVP agents. This design also ensuresthat RSVPis used at the IP WAN and that the call legs that do
not use RSVP utilize only LAN infrastructure.
1he RSVP agent supports pass-through codec configuration, which allows any codec to be used (the codecdocs not have to be known or supported by the RSVP agent). Pass-through codec configuration includes Secure Real-Time Transport Protocol (SRTP), where the RTP payload is
encrypted.
3-53
Three Call Legs with RSVP-Enabled Locations

When RSVP-enabled locations are used, the end-to-end call is split into three separate call legs.
Three Call Legs with RSVP-Enabled

Locations
Location A
Location B
SCCP SCCP or ..''*..-*' Communications ''''..''-._ SCCP or
.'
..-'
Cisco Unified''-.. ""..
'--'"..-SCCP
Mana9er
SCCP-C'V
RSVPAgentl to RSVPAgent2: RSVP-RTP

SCCP or SIP *
**
RSVP
RTP
In the figure, Phonel. which is in Location A, places a call to Phone2, which is in Location B. The Cisco Unified Communications Manager location configuration specifies that RSVP has to
be used for calls between these two locations.
Cisco Unified Communications Manager instructs the two involved RSVP agents (one in Location A. and one in Location B) to use RSVP to try to set up the call between each other. If the call is admitted (that is, if enough bandwidth is available in the network path between these two devices), the RSVP agents inform Cisco Unified Communications Manager that the RSVP call leg was successfully set up.
Cisco UnifiedCommunications Managernow tells the phonesto set up their call legs,each to its respective RSVP agent. If the RSVP call setup between the two RSVP agents is denied,
Cisco Unified Communications Manager considers the call to have failed CAC.
It is important to realize that there are three separate RTP streams: Phonel talks to RSVP Agentl. RSVP Agentl talks to RSVP Agent2, and RSVP Agent2 talks to Phone2.
RSVP CAC is used between the RSVP agents only.
3-52
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.D
"Ihis topic describes RSVP-enabled locations in Cisco Unified Communications Manager.
Characteristics
Based on Cisco Unified Communications Manager locations
Allows RSVP to be enabled selectively between pairs of locations Uses RSVP agents: Devices (MTPs) through which call has to flow
RSVP used between RSVP agents Topology-aware:
- Works well with all topologies (full mesh, partial mesh, hub
and spoke)
- Adapts to network changes; considers actual topology:

Link failures?
Backup links?
Load-share paths?
RSVP-enabled locations are based on Cisco Unified Communications Manager (standard) locations. RSVP-cnahled locations differ from standard locations in two ways. First. RSVP can
be enabled selectively between pairs of locations. Because endpoints such as Cisco IP phones do not supportRSVP. the solution uses so-called RSVP agents.
An RSVP agent is a Media Temiination Point (MTP) through which the call hasto flow. RSVP is then used only betueen the two RSVP agents, while the Real-Time Transport Protocol (RTP)
stream from IP phone to RSVP agent does not use RSVP.
Thesecond andmostimportant difference between RSVP-enabled locations andstandard

locations is that the use of RSVP makes the location-based CAC mechanism topology-aware. It
workswell with all topologies (full mesh, partial mesh, and hub and spoke)and adapts to network changes by considering the actual topology. Theadvantages include these
considerations:
Link failures: If one link in the IP network goes down and packets are routed on different
paths. RSVP is aware of the change and considers the bandwidth thatis now available at
the path that is actually routed.
Backup links: Ifbackup links are added after link failures, orif bandwidth ondemand is
used to add dial-on-demand circuits. RSVP again is fully awareof the routing path that is currently used and thebandwidth that is available on each link along thatpath.
Load-share paths: If load sharing is used. RSVP is aware of the overall bandwidth thatis
provided by multiple load-sharing links.
Using RSVP for CAC allows admitting ordenying calls that are based onactual oversubscriptions. The result is always based onthe currently available bandwidth and
interfaces, not on a logical configuration that ignores the physical topology.
Step 2: Assign Locations to Devices

The figure shows how you can assign locations to devices.
Step 2: Assic
n Locat ons to Device s
Product Tr: OtvHe Proton 1
tltt* SCCP
Manager
Administration: Device > Phone
Location is
indirectly applied
BBQi[tr*(*n ur-tnown
via device pool (each device pool Is = T location).
H"*"'1
Itisr-f &L*ron Tarrtpl&U*
cm*
j If location is J
1
N*m0wom.u*.s
1 selectedhere.
location of
ignored
device pool is
w**^
' """ -
..}
"
Locations are a mandatory setting in a device pool, and you must assign a device pool to each device. Therefore, a device always has a location that is assigned indirectly through its device pool. If a device uses a different location from the one specified in its device pool, that location can be chosen at the device itself. A location that is assigned at the device levelhas higher priority than the location of the device pool.
3-50
Step 1: Configure Locations

The figure shows the configuration of the locations in Cisco Unified Communications
Manager.
Step 1: Configure Locations

Cisco Unified Communications Manager Administration: System > Location
Enter location name.
Set bandwidth permitted for
cals coming into and going

out of location
You configure locations b\ choosing System> Location in Cisco Unified Communications Manager Administration. One location exists bydefault: the HubNone location. This location
is the default location for all devices. To add a new location, click Add New.
In the Location Coniiguration window, entera name forthe location andset the bandwidth for
audio calls (the default is Unlimited).
Calculations of call bandwidth include Layer 3 overhead: A G.729 call is calculated with 24 kb/s. and a G.711 call consumes 80 kb/s. Be aware that unless RSVP-enabled locations (which are discussedlater in this lesson)are used, the bandwidth limit that is configured at a location
applies only to calls coming into and going out ofthe location. Calls within a location are
ignored b\ standard location-based CAC.
201C Cisco Systems, Inc
3-49
Locations Configuration Example: Hub-and-Spoke Topology

The figure shows an exampleof a hub-and-spoke locations-based CAC implementation.
Locations Configuration Example: Hub-and-Spoke Topology
Location HQ 96 kb/s
Location BR1: 24 kb/s
Location BR2:72 kb/s
There are three sites: the headquarters and two branches. Each site has its own location (IIQ, BR I. and BR2). The physical topology is a hub-and-spoke topology (headquarters is the hub). The link between branch I and the headquarters should not carry more than one G.729 call, and
the link between branch 2 and the headquarters should not carry more than three G.729 calls. The next two subtopics describe how to implement locations-based CAC for this scenario.
3-48
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8,D
Configuration Procedure for Implementing Locations-Based

CAC
To implement Cisco Unified Communications Manager locations-based CAC. you need to follow two steps.
Configuration Procedure for Implementing Locations-Based CAC

Add locations and configure CAC bandwidth limit. 2 Assign locations to devices.
Note
To know how much bandwidth you need to calculate per call, you should design and
configure regions before implementing locations
2010 Cisco Systems, inc
3-47
Locations: Full-Mesh Topology

The figure shows a full mesh topology with locations-based CAC.
Locations: Full-Mesh Topology

Bandwidth is not
What if there are no
limited between pairs

of locations, which can
Location HQ:
Urt mited
calls to or from BR1
are attempted, but four
causeprobtems in
non-hub-and-spoke
calls are attempted

from 8R2 toHQ?
topologies.
Location BRl: 48 kb/s
Location BR2:96kb/s
This example is based on the previous example, but a direct IP WAN link has been added
between BRl and BR2. The idea is that one G.729 call is allowed on the WAN link from BRl
toward the headquarters, one G.729 call is allowed on the WAN link between BRl and BR2,
and three G.729 calls are allowed on the WAN link from BR2 toward the headquarters. Such a scenario reveals issues that arise when locations-based CAC is used in topologies other than hub-and-spoke topologies. To allow the additional G.729 call that is permitted on the
WAN link between BRl and BR2, the bandwidth limit of these two locations has been
increased by 24 kb/s. Increasing the bandwidth, however, can lead to these undesirable
situations:
Two G.729 calls from BRl to HQ: Because the BRl location now has a limit of 48 kb/s.
it allows two G.729 calls. Location bandwidth limits are not configured per destination; any call coming into or going out of a location is considered, regardless of the other location that is involved in the call. Therefore, there is no way to divide the available 48 kb/s into
one call toward the HQ and one call to BR2.
Kour G.729 calls from BR2 to HQ: The same problem occurs with the BR2 location: The
additional bandwidth that was added to accommodate the desired call toward BRl can be
used toward I IQ. occupying that link with one more call than intended.
Note The problems that are described here are caused by the fact that the bandwidth limit is configured per location, regardless of the other location (where the call goes or comes from)
3-46
Implementing Cisco Unitied Communications Manager, Part 2 (CIPT2) v8.0
Locations: Hub-and-Spoke Topology

"fhe figure shows a hub-and-spoke Cisco Unified Communications Manager topology with
locations-based CAC.
Locations: Hub-and-Spoke Topolo*

Locations-based CAC works relatively well in hub-and-spoke topologies.
i tjkt Location HQ.
Unlimited
idlBaB
lxG.729
\
IPWANV
3xG729
Location BRl: 24 kb/s
Location BR2: 72 kb/s
As shown in the figure, there are three sites: the headquarters (HQ) and two branches (BRl and BR2). There is no direct connection between the branches; all traffic goes by way of the
headquarters.
Ihis scenario is ideal for locations-based CAC If the intention is lo allow only one G.729 call on the link between BRl and HQ and three G.729 calls on the link between BR2 and HQ. this location configuration would suit these needs:
Location HQ: Unlimited

Location BRl: 24 kb/s location BR2: 72 kb/s
This coniiguration ensures that no more than oneG.729 call will be sentoverthe IP WAN
toward location BRl and that no more than three G.729 calls will be sent over the IP WAN
toward location BR2.
Note
The configuration also allows one G.729 call betweenBR1 and BR2. Because the configured bandwidth limit does notconsider the destination location, the 24-kb/s limit of BR1 allows any call to go out (orcome in) regardlessof where itgoes (orwhere itcomes from) The headquarters limit is not affected at all bysucha call. Only locations BR1 and
BR2 will subtract 24 kb/s from their limits. Because locations-based CAC does not provide
topology awareness, Cisco Unified Communications Manager is not even aware that thecall
physically flows through the headquarters. ^^
3-45
Standard Locations
This topic describes how to implement CAC in Cisco Unified Communications Manager by using standard locations.
Locations Characteristics
Each device has one location assigned.
You limit calls by permitting a certain bandwidth for calls coming in and going out of a location:
- Audio bandwidth is calculated by actual codec plus IP overhead (assuming 20 ms packetization period). Examples: 80 kb/s for G.711, 24 kb/s for G.729.
- Calls within a location are unlimited.
- Bandwidth limit of source and of destination location are
checked individually. Works within a Cisco Unified Communications Manager cluster (including exit points):
- Trunks and gateways can be put into a location, allowing some control for calls leaving the cluster. Locations-based CAC is unaware of topology
Each device has one location assigned. The assignment can be direct or via a device pool. If both types of assignment are used, the device configuration has higher priority. You limit calls by permitting a certain bandwidth for all calls coming into and going out of a location. Cisco Unified Communications Manager calculates the actual audio codec bandwidth plus IP overhead (assuming a packetization period of 20 ms). This means that each G.711 call reduces the bandwidth that is configured for a location by 80 kb/s, while a G.729 call reduces the available bandwidth by 24 kb/s.
Note Calls withina location do not decrease the bandwidth limit; they are unlimited. Only calls that go out of a location or that are received from outside the location are considered by the locations-based CAC algorithm.
The bandwidth limitsthat are configured at the location of the originating device (the source location) as well as at the location of the terminating device (the destination location) are checked individually. Unlike with regionconfiguration, where the maximum permittedcodec is configured perpairofregions, the bandwidth limitof a location applies to all (both placed and
received) interlocation calls. If the bandwidth limit of the source or of the destination location
(or of both) is exceeded, the call is not admitted. Locations provideCAC for calls within clusters; however, because locations can alsobe configured for gateways and trunks, locations do allow some control for calls leaving the cluster.
Locations-based CAC in Cisco Unified Communications Manager is completely unaware of the

topology of the network. It is a purely logical assignment and does not reflect the actual
topology or the actual bandwidth available.
3-44
CAC in Cisco Unified Communications Manager

Cisco Unified Communications Manager supports various CAC methods.
CAC in Cisco Unified Communications
Manager
Manager supports the following

CAC features:
CAC within a cluster:
H.323 Gatekeeper or SIP

_CAC-K
If CAC denies call, automated
alternate routing (AAR) can be

used lo reroute call over PSTN
CAC for calls leaving a cluster. H.323 gatekeeper or SIP

Preconditions If CAC denies call and no other entnes in route list are left to
Locations
i Locations
CAC
CAC ,
try. call fails.
In centralized call-processing deployments, you can use standard locations and Resource Reservation Protocol (RSVP)-enabled locations lo provide CAC within a Cisco Unified Communications Manager cluster. If a call is not admitted by one of these two CAC methods due to bandwidth limitations, you can use AARto reroutethe call over the PSTN (off-net)
instead of denying the call. AAR provides a service like PSTN backup, except thatthe reason for call backup is not that the call failedon the on-ncl path, but that there is no available
bandwidth from a CAC point of view.
In distributed call-processing environments, you canuse H.323 gatekeeper CAC with H.323 trunks (gatekeeper-controlled intercluster trunks and H.225 trunks). If Session Initiation
Protocol (SIP)trunks, you can use SIP Preconditions, which allows RSVP-based CAC. If calls are not admitted by the H.323 gatekeeper, standardbackup functionalitv of route lists
and route groups is applied, for example, to route calls thathave not been admitted by the gatekeeper to be sent over the trunk, you can configure one or more PSI'N gateways inanother (lower-priority) route group of the same route list. In this way, the gatekeeper-controlled trunk ispreferred over the PSTN aslong ascalls are admitted; after admission isrejected, calls are sentoverthe PSTN. Thesame principle applies to callsthat arc placed through SIP trunks that
are configured for SIP Preconditions.
CAC Overview
This topic describes the CAC optionsthat are available in Cisco Unified Communications
Manager.
Call Admission Control
CAC limits the number of calls between certain parts of the network in order to avoid bandwidth oversubscription:
QoS can be used to give priority to Voice over Data.
QoS cannot solve the problem of too much prioritized traffic (caused by too many voice calls). Oversubscription results in delayed packets and packet drops: - Any packets of any voice stream are affected (not just packets of the call that exceeds bandwidth limit).
- Results in quality degradation of all voice calls.
CAC avoids such problems by limiting the number of voice calls.
CAC limits the number of calls between certain parts of the network in order to avoid bandwidth oversubscription with too many voice calls. QoS is not able to achieve this result because QoS provides only the means to prioritize Voice over Data traffic. QoS does not avoid the situation in which too many (prioritized) voice streams are sent over the network. If oversubscription occurs, any packets of any voice stream can be affected, not just packets of the particular call or calls that exceed the bandwidth limit. The result in this case is packet delays and packet drops of all voice calls, and hence oversubscription degrades the quality of
all voice calls.
Therefore, in order to ensure good voice quality, you need to use CAC to limit the number of
voice calls.
3-42
Lesson 2
Implementing CAC
Overview
Implementing multisite IP telephony deployments over an IP WAN requires additional planning to ensure the quality and availability of voice calls.
When an IP WAN connects multiple sites in a Cisco Unified Communications deployment.
quality of sen. ice (QoS) hasto be implemented in orderto prioritise voice packets overdata packets. Ilow ever, to avoid an oversubscription that is caused by too many voice calls, a mechanism is necessary to limit the numberof calls that are allowed at the sametime between
certain locations. Call Admission Control (CAC) is the mechanism that ensures that voice calls do not oversubscribe the IP WAN bandwidth and thus impact voice quality.
This lesson describes how to implement CAC mechanisms that are provided by Cisco Unified Communications Manager, andexplains how automated alternate routing (AAR) can be used in
some scenarios lo reroute calls that were denied by CAC over the public switched telephone
network (PSTN).
Objectives
Upon completing this lesson, you will be able to describe and configure CAC mechanisms and
AAR in Cisco Unified Communications Manager and in gatekeepers. Ihis ability includes being able to meet these objectives:
u Describe the CAC options that are provided by Cisco Unified Communications Manager
Implement locations-based CAC in Cisco Unified Communications Manager
Implement RSVP-enabled locations-based CAC in Cisco Unified Communications

Manager
Implement AAR inorder to reroute intracluster calls over the PSI'N if notenough
bandwidth is available for an on-net call
Implement SIP Preconditions onSIP trunks inCisco Unified Communications Manager Implement 11.323 gatckceper-based CAC in Cisco Unified Communications Manager
3-40
Summary
Summary
Bandwidth management methods include techniques that reduce required bandwidth of voice streams, techniques that keep voice streams off the IP WAN, and other techniques such as deploying
transcoders.
The highest bandwidth-consuming codec for a call between

two devices is determined by the Cisco Unified Communications
Manager region configuration of the two involved devices.
When you are deploying local conference bridges at multiple

sites, use Media Resource Groups and Media Resource Group Lists to control which conference bridge is used by which device.
Transcoders allow low-bandwidth codecs to be used over the
IP WAN when low-bandwidth codecs are not supported by both

endpoints.
Multicast MOH from branch router flash is a feature that allows
MOH streams to be generated locallyat the remote site instead of being sent across the IP WAN from the main site.
References
for additional infonnation. refer to these resources:
Cisco Svstems. Inc. Cisco Unified Communications System 8.x SRND. April 2010. litip:.,',www.ci,bCo.com/en.llS'/docs/\oicc ip eomm/cucm/srnd/8\/ue8\.htm)
Cisco S\ stems. Inc. Cisco Unified Communications Manager Administration Guide
iilip:';www.cisc(XC<)m;cn;US^docs^(iiec_ip_coniin/cucni/admin/8_0_l/ecnicfg''1iccm-801cm.him]
Release 8.0(1). February' 2010.
Cisco Systems. Inc. Cisco Unified SRST System Administrator Guide. December 2007. hup:.' www,cisco.eoni/en'US/pji'lner'docs/voice ip conim/cusrst/admiii/srst/coiifiguratioii.'
sjuide.-'srstsa.html
>2O10Cisco Systems, Inc
3-39
Step 4c: Disable Multicast Routing on IP WAN Router Interface

The figure shows how to configure a Cisco IOS router to disable multicast routing at the IP
WAN interface.
Step 4c: Disable Multicast Routing on

IP WAN Router Interface
interface FastEthernetO/0
description HO-Voice-Servers
ip address 10.1.1.101 355.255.255.0 ip pim sparse-dense-mode
interface FastEthsrnatO/0
description HQ-Phones ip address 10.1.2.101 255.255.255.0 ip pim sparse-dense-mode

interface SerialO/l
description ip wan
ip address 10.1.4.101 255.255.255.0
1Disable multicast
,
.^___
" .
_J routing on WAN D
..
,.,.,
-! interface.
If no other multicast applications are used over the IP WAN, the simplest way of preventing the multicast MOH packets from being sent to the WAN is to disable multicast routing at the WAN
interface.
3-38
Step 4b: Use IP ACL at IP WAN Router Interface

The figure shows how you can use an IP ACL to configure a Cisco IOS router to drop multicast
MOI I packets.
Step 4b: Use IP ACL at IP WAN Router

Interface
ip multicast-routing ip access-list extended drop-moh
deny ip any host 239.1.1.1 range 16384 163B5 permit ip any any
interface PastEtoernetO/0
description HQ-Volce-Servers ip address 10,1.1.101 255.255.255.0
^^"IPACL Filtering MOH

Multicast Packets
interface FastEthernetO/1 description HO-Phones
ip address 10,1.2.101 255.255.255.0 ip pim sparse-dense-mode

interface SeriolO/1
description IP MAN
ip address 10.1.4.101 255.255.255.0

ip access-group drop-moti out
["
1
i
^___
PACLAppliedtoWAN
nterface
The ACL matches the MOH group address and port numbers that are used by the MOII server for the MOH RTP and RTCT packets. The ACL is applied to the IP WAN interface in the
outgoing direction and therefore doesnot allow multicast MOH packets to be sentout on the IP
WAN.
Note
As stated earlier in this lesson, the multicast address and port range that must be filtered
depend on several parameters, such as the audiosource number, the enabledcodecs, and
the increment method.
)2O10 Cisco Systems, Inc
Step 4a: Configure the Maximum Hops to Be Used for MOH

RTP Packets
Continue the multicast MOH server configuration by setting the maximum hop value, as shown in the figure.
Step 4a: Configure the Maximum Hops

to Be Used for MOH RTP Packets
Media Resources > Music on Hold Server
* tr.*hl* >**UI* L.M &*urcol 6" P% ri (Utdroi* &*uU&t4UBrt 16SW
NOtiSVW
*""*"
numbn null)
if Mai it
ta.tau ^ hnHfan*,. '

Selected *utocr Avdvsaortct-
Set maximum hops (time to

live) value for each audio
source for multicast packets.
All MOH audio sources that have been configured for multicasting are listed in the Selected Multicast Audio Sources section of the MOH Server Configuration screen. You can set the Max Hops value for each audio source; the default is 2. This parameter sets the TTL value in
the IP header of themulticast MOH RTP packets to the specified value. TTLin an IP packet indicates the maximum numberof routersthat an audio source is allowedto cross. If Max Hops
is set to 1. the multicast MOH RTP packets remain in the subnet of the multicast MOH server.
Whenyou use multicast MOH from branch router flash, you can set Max Hopsto a value that
is lower than the actual hop count from the MOI 1server toward the WAN interface of the main site router. This value, however, might conflict with the needs within the main site when IP
phonenetworkshave the same or a higher distancethat is, a higherhop countto the MOH serverthan the WAN network. In such a case, one of the other possible methodsof preventing the multicast MOH packets that aregenerated by the MOH server have to be used. Theyare
shown on the following pages.
3-36
Implementing CiscoUnified Communications Manager, Part 2 (C1PT2) v8.0
Step 3: Enable Multicast MOH from Branch Router Flash at the

Branch Router
The figure shows how to configure a Cisco IOS routerfor multicast MOI I from branch roi ter
flash.
Step 3: Enable Multicast MOH from Branch

Router Flash at the Branch Router
mai-epbones 1
nax-dn 1
ip source-address 10.1.5.102
nob mob-file.au
multicast mob 239.1.1.1 port 16364

interface FastEtharnatO/0
description BF-Phones ip address 10.1.5.102 255.255.255.0

interface SerlalO/1
description IP WXN
ip address 10.1.4.102 255.255.255.0
Multicast MOH from branch router flash is part of the SRST feature. Therefore, SRST must
already beconfigured before youcan enable multicast MOII from branch router flash.
Note SRSTconfiguration options are discussed inthe module "Centralized Call -Processing
Redundancy Implementation."
Rased on anexisting SRST configuration, you need only two commands to enable multicast
MOH from branch router Hash:
moh file-name: fhis command specifies the MOH audio source file. The specified file has
to be stored in flash memor> of the SRST gateway.
multicast moh multicast-group-address portport: This command specifies themulticast
address and port that are used for the multicast MOH packets. The specified address and port have toexactly match the values that have been configured at the MOH server in
Step 2b.
Note
TheSRST gateway will permanently streamMOH, regardless ofan IPWAN failure or IP phones being registered with the SRSTgateway. ^^
You can configure an additional five MOH streams using MOH group configuration. Refer to
the module "Centralized Call-Processing Redundancy Implementation" for more information
about MOII group configuration.
i 2010 Cisco Systems. Inc.
3-36
Step 2c: Enabling Multicast MOH at the Media Resource

Groups
This figure shows that the configuration of a Multicast is enabled at the Media Resource Group
(MRG).
Step 2c; Enabling Multicast MOH at the Media Resource Group(s)

Cisco Unified Communications Manager Administration: Media Resources > Media Resource Group
Multicast MOH only works if the multicast enabled MOH server is assigned to a multicast enabled MRG. This MRG will be configured to be a member of an MRGL. The MRGL will
then be associated with devices such as phones.
3-34
ImplemenlingCisco Unified Communications Manager, Part 2 (CIPT2)v8.0
Step 2b: Configure Multicast MOH in Cisco Unified

After allowing multicast MOH on audio sources, you must enable the MOH server for
multicast MOH. as shown in the figure.
Step 2b: Configure Multicast Cisco Unified Communications Manager

Media Resources > Music on Hold Server
r^ttmtlkijvltvtr InlwnilMn-
iaMtMHfcWiiliwi.in rmm itniif
Enable multicast MOH on the

MOH server.
'.ferine**'
Lttte4 HuKKuf AvrfiD 4
Configure multicast parameters.
fhe figure shows how to enable multicastMOH on a MOH server: In the Multicast Audio Source Infonnation section of the MOH server configuration screen, check the finable
Multicast Audio Sources on this MOH Server check box. 'fhe Base Multicast IP Address, Jase
Multicast Port Number, and Increment Multicast On parameters are automatically populated
when you enable multicast MOH on the server. You can modify these values as desired.
Note To avoid network saturation in firewall situations, it is recommended that you choose to
increment multicast MOH on the IP address instead of on the port number. Choosing this
option means that each multicastaudio source will have a unique IP address, and helps to avoid network saturation If multiplecodecs are enabled for the MOH server, additional IP
addresses will be in use (one per codec and per audio source).
3-33
Step 2a: Configure MOH Audio Sources for Multicast MOH

To enable multicast MOH. you first have to allow multicast MOH on MOH audio sources, as shown in the figure.
Step 2a: Configure MOH Audio Sources

for Multicast MOH
ManagerAdministration: Media
Resources > Music On Hold
Audio Source
ManagerAdministration: Media
Resources > Fixed MOH Audio
Source
-Nuikh W d l r m r h A t b V f l l**W1**Oan-
-*OH *j*e 5ff*n*fc*r**r' E
O-.-X-*
$.,..*
Flu * HOH * I l>f> >b
Mm'
|l 'uMci| |
("0-T*.( Tr#ftjl4tfift Coft*l*
Btf
11 )IH J 1 i
HemMi (M^jksJ.Ni ntouhrd j
DilfcSjKI-6
LO-Ctf T.-i*
\
MOH audio sources do not allow multicast
tan pi* Audi iSotii ca Lul*- t*a y
MOH by default.
MOH audio sources and fixed MOH audio
"
irra^'udiî^t* (?28.iv
sources (if used) must be enabled for

multicast MOH.
Check the Allow Multicasting check box for each MOH audio that is allowed to be sent as a multicast stream. This instruction applies to MOH audio sources and to fixed MOH audio
sources.
Note
More information about configuring the MOH server and MOH audio sources is provided in the ImplementingCisco Unified Communications Manager, Part 1 (CIPT1) course.
3-32
Step 1: Enable Multicast Routing on Cisco IOS Routers

The figure shows how to enable multicast routing on Cisco IOS routers at the main site an<: at
the remote site.
Step 1: Enable Multicast Routing in

Cisco IOS Routers
ip multicast-routing ~
Enable multicast
interface FaatEthernetQ/O
routing on router.
description HQ-Voice-Servers ip address 10.1.1.101 255.255.255.0 ip pin sparse-dense-mode

interface FaatEtnernetO/1
description HQ-Phonea
ip address 10.1.3.101 255.255.255.0

ip pim sparse-dense-mode interface SerialO/l
Enable multicast
routing on interfaces.
description IP WAN ip address 10.1.5.101 255.255.255.0 ip pim sparse-dense-mode
You use two commands to enable multicast routing in the network so that multicast MOH
streams can he sent:
anip multicast-routing: Configure thiscommand in global configuration mode. This

command enables multicast routing on the Cisco IOS router in general.
ip pim sparse-dense-mode: Configure thiscommand on eachinterface where multicast

routing should he enabled.
Note
The configuration that is shown in the example enables multicast routing in the whole
network. When multicast MOH from branch router flash is used, multicast streams will not be
sent to the IP WAN They can be blocked based on the maximum hops parameter (TTL field in the IP header) or by IP ACLs. You can also block multicast streams by disabling multicast
routing on the interface, butonlyifno other multicast routing applications are required inthe
network.
In the example, the maximum hops parametercannot be used because the HQ-Phones
network and the IP WAN network have the same distance to the HQ-Voice-Servers network To allow multicast MOH to be sent to the HQ phones, a maximum hop value of 2 is required.
This value, however, will allowthe multicast MOH packets to be sent out on the WAN interface. Therefore, IP ACLs have to be used, or multicast routing has to be disabled at the
WAN interface (if multicast routing is not required by otherapplications).
3-31
Configuration Procedure for Implementing Multicast MOH from

Branch Router Flash
Implementing multicast MOH from branch router Hash includes the following steps.
Configuration Procedure for implementing

Multicast MOH from Branch Router Flash
1 2 Enable multicast routing in the network. Configure multicast MOH in Cisco Unified Communications
Manager:
a. b c
3.
Configure MOH audio sources for multicast MOH. Configure MOH audio server for multicast MOH. Enable multicast MOH at the media resource group(s)
Enable multicast MOH from branch router flash at the

branch router.
Implement a method to prevent multicast MOH streams from being sent over the IP WAN: a
b
Configure maximum hop value to prevent multicast MOH streams from being sent over the IP WAN.
Use IP ACL at IP WAN router interface.
c.
Disable multicast routing on IP WAN router interface.
The configuration procedure describes the implementation of multicast MOH from branch router flash by first enabling multicast MOH (steps 1 and 2). Once this works as desired, the
configuration is modified so that the multicastMOH streamis generated locallyat the branch router (Step 3) and the multicast MOH stream that is generated by the MOH server is prevented
from being sent to the IP WAN.
WhenenablingmulticastMOH at the MOHserver,make sure that you set the maximum hop value of the multicast-enabled MOH audiosource(s)to a high enough value to allow the multicast MOH packets to be sent all the way to the remote phones.
When choosing option 4a to preventing the multicast MOH stream of the MOH server from
being sent to the IP WAN.you have to use a low enough value to ensure that the multicast
MOH packets generated by the MOH server do not reach the IP WAN.
Note All IP phones must be able to access to the main site Cisco Unified Communications
Manager MOH server from their MRGL. This access is required as soon as multicast MOH
is configured, whether multicast MOH from branch router flash is used. If the remote site IP
phones do not have access to the Cisco Unified Communications Manager MOH server from theirMRGL, CiscoUnified Communications Manager cannot instruct the IP phones to
join the multicast group and will make the phone use tone on hold instead of MOH. Furthermore, you need to check the Use Multicast for MOH Audio check box at the MRG that includes the multicast-enabled MOH server (see Step 2c). Finally, make sure that the G.711 codec is used between the MOH server and the branch phones, because SRST multicast MOH supports only G.711.
3-30
Disable multicast routine at the IP WAN interface: By disabling multicast routing at the IP WAN interface, multicast packets are not routed out on that interface.
At the branch router, the multicast MOH stream is sent out on the interface that is specified in
the ip source address command in call-manager-fallback coniiguration mode(or in telephonyserver configuration mode, when Cisco Unified Communications Manager Express in SRST
mode is used). Therefore, the multicast MOII stream that is generated at the branch router does
not have to be blocked at the branch router WAN interface.
3-29
Example: Implementing Multicast (VIOH from Branch Router Flash (Cont.)

Manager MOH Configuration

DA 239 1 1 1
DP. 16384
(a) Max Hops

(TTLV1 Main Site
ill-manager-fallback i-epbones 1
(b)
ip
accaaa
-liat
sirtended 3t 239.1
drop
1.1
mob
i ange
majt-dn
deny udp any ho

16384
ip aouroa-address 10.1.5.102
moh moh-fila.an
16385 any any
perBit
ip
multicast moh 239.1.1.1

inte rface serial -group
0/0
port 16394
ip
access
drop-moh out
The figure shows the configuration of the previously discussed scenario.
It is assumedthat the baseline configuration provides multicast routing in the wholenetwork and that the Cisco Unified Communications ManagerMOHserver is alreadyconfigured for
multicast MOH.
Now the multicast MOI1stream that is sent toward the remote site needs to be blocked, and multicast MOH from branch router flash needs to be implemented at the remote site.
Therefore, the SRST configuration of the remote site router is extended to include multicast
MOH. The SRST configuration uses the same multicast IP address and portthat are configured
at the Cisco Unified Communications Manager MOH server that is located at the main site.
To stopmulticast MOH generated by themain siteCisco Unified Communications Manager MOH server from beingsentoverthe IP WAN, you canchoose oneof three options:
Set Time to Live (TTL) to a low enough value at the Cisco Unified Communications Manager MOH server: If the TTL value in the IP headerof the generated multicastMOH packets is set to a low enough value, the packets will not be routed out to the IP WAN. However, if the IP WAN link is one hop away from the Cisco Unified Communications
Manager MOII server, andif the main site phones are alsoone hop away from the server. this method cannot beused, because themain site IPphones would also be affected by the
dropped packets. In the current example, TTL is set to 1, and it is assumed that the IP
phones are inthe same VLAN, like the Cisco Unified Communications Manager MOI I
server.
Filter the packets by an IP access control list (ACL): At the main site router, an ACL can be configured that drops the multicast MOH packets at the IP WAN interface.
Make sure thatyou verify the actually used multicast IPaddresses and ports. Asdescribed
earlier, itdepends on the base address and port configuration, the method that is used to
Note
increment the base number {on IP address or port), the codecs that are enabledfor MOH,
and the audio sources that are multicast-enabled.
3-28
Example: Implementing Multicast MOH from Branch Router

Flash
The figure shows a sample scenario for implementing multicast MOH from branch router flash.
Example: Implementing Multicast MOH

from Branch Router Flash
Multicast MOH packets generated by the Cisco Unified Communications Manager MOH server should not be sent over the IP WAN. Branch router should generate multicast MOH packets.
Cisco Unified
Communicalions
Manager MOH
Wain Site WAN
SRST MOH
Remote Site
In the example, a MOH server is located at themain site. It is configured for multicast MOH. Multicast routing has been enabled in the whole networkincluding inthe IP WAN link to the
remote site.
The main siterouter, however, should no longer route multicast MOH to the remote site. The remote site SRSI gateway should instead generate multicast MOII streams to the phones that
are located at the remote site.
Cisco Unified Communications Manager is not aware that the multicast packets that are
generated by the MOH server atthe main site are filtered onthe IP WAN interface and then are locally generated by the remote site SRST gateway. Therefore, Cisco Unified Communications Manager will instruct the IP phones that are located at the remote site lojoin the multicast group IP address that isconfigured at the Cisco Unified Communications Manager MOH server. To allow the phones to receive MOH for the multicast group IP address that they join, you must configure the SRST gateway touse the same multicast address and port that isused
bv the Cisco Unified Communications Manager MOH server that is located at the main site.
3-27
As you can see from the table, audio sources are incremented in ascending order, starting with
audio source 1 (live audio at source 0 is not multicast-capable and hence is excluded in the calculation). Codecs are enumerated in the order shown (G.711 mu-law, G.711 a-law, G.729,
wideband). For each audio stream, two ports are used: the first one (the even-numbered port) for the actual RTP transmission and the subsequent one (the odd-numbered port) for the
corresponding RTCP.
If you are not sure about the used multicast addresses and ports, you can configure traces for the Cisco IP Voice Media Streaming Application service. Make sure that you check the Service
Initialization check box in the trace configuration. Then restart the Cisco IP Voice Media Streaming Application service.
When analyzing the trace output, you will find this kind of information:
CMOHHgr: :KickStartMultiCastStreaiii {1} Starting Multicast
stream, asID = 1, conferencelD = 1, cocleeType = iKtSw,

Multicast ip:port - 239.1.1.it 163841
<CLID::Cluster><NID::10.1,i,l>
CMOHMgr::KickStartMultiCastStream <1) Starting Multicast stream, asID = 1, conferencelD = 1001, GQdecType = !#"$,
Multicast ip:port - 239.1,1.2il6384|

<CLID: :ClusterxHID: :1Q.1.1.1>
Note
The output that is shown does not match the example in the figure. It is used only to illustrate which information you will find in the trace output. The number after the KickStartMultiCastStream identifies the audio source. For each enabled codec, you will find information about the used multicast IP address and port. The NID (node ID) shows the IP address of the MOH server. In this example, only G.711 mu-law and G.711 a-law codecs are enabled. Onlyone audio source (audio source 1) is multicast-enabled. There is a single
MOH server at 10.1.1 1
Tip
It is importantto know the used multicastIP addresses and ports when you choose the
option to prevent multicast traffic from entering the IP WAN by access lists.
3-26
Multicast MOH: Address and Port Increment Example

The table shows an example of IP address and port increments for multicast MOH.
Multicast MOH: Address and Port
Increment Example
You can verify used IP addresses and ports by using traces: - Configure trace for the Cisco IP Voice Media Streaming Applicationservice, and check the Service initialization
check box
Restart Cisco IP Voice Media Streaming Application service.

- Analyze trace output.
Base IP 239.1 1.1 Base Port 16384
Enabled Codecs
increment on IP Address
Increment on Port
G711a-law, G729
Audio Source 1
239.1.1.2
No
239113
16386
Audio Source 2
Audio Source 3 Audio Source 4 Audio Source 5 Audio Source 6
"Ybs"
No No
Yes
239 1*1 11
1S402
16404
239.1.1.23
239 1 1 23
16428
The base multicast group iseonligured for IPaddress 239.1.1.1 and port 16384. G.711 a-law
and G.729 codecs are enabled: audio sources 1. 3. and 6 are multicast-enabled.
The figure slums the IP addresses orports that are used for the actual multicast MOII streams.
The next table shows how these numbers were derived.
Note
The yellow highlighted numbers mthetable present thevalues thatare used in thefigure. The gray highlighted and bold numbers present theIP address and port number that are
actually used in this example.
Audio
Source
Increment on IP Address
Increment on Ports
{239.1.1.xOnly Last Octet Shown)

G.711 mu-law
(163xxxOnly Last Octet Shown)

G.711 mu-law
G.711
a-law
2
6
G.729
Wideband
G.711 a-law
386/387
394/395
G.729
Wideband
1 2 3
1
5 9 13 17 21
3 7 11 15 19 23
364/3B5
392/393
400/401
388/389
396/397
390/391
398/399 406/407 414/415 422/423
10 14 18 22
12
16
402/403 410/411
418/419
404/405
412/413 420/421
4 5 6
408/409
416/417 424/425
20
24
426/427
428/429
430/431
3-25
Multicast MOH from Branch Router Flash: Address and Port

Considerations
This subtopic describes what you need to consider regarding the multicast group coniiguration
of MOH streams.
Multicast MOH from Branch Router Flash; Address and Port Considerations
You can configure MOH streams to be incremented on IP addresses or ports.
Increment on IP address is recommended.
For each audio source, four streams are considered (one per codec: G.711 mu-law, G.711 a-law, G.729, and wideband) for the
increment.
- independent of codecs that are actually enabled.
Numbers are incremented differentlyon IP address versus port.

- IP addresses are incremented by one per stream.
- Ports are incremented by two per stream (RTP and RTCP). When you increment IP address or port, consider audio sources
that are not enabled for multicast.
- Appropriate range is reserved for future multicast enablement.
Because a single MOH server can stream multiple multicast MOH files, you have to specify an initial multicast address and portthat is used forthe firststream. In addition, you have to
choose whether to increment the IP address or port on additional streams. It is recommended
thatyou increment on IP addresses instead of on ports. If there aremultiple MOH servers within a network, you have to make sure that they do not use overlapping multicastIP
addresses and ports for their streams.
Foreach audio source, fourstreams are considered for the incrementone per codec: G.711
mu-law, G.711 a-law, G.729, and wideband. Thisprinciple always applies, regardless of which MOH codecs have been enabled in the CiscoIP Voice Media Streaming Application service.
When you are incrementing on IP addresses, each stream consumes one IP address. In other
words, eachaudio source requires fourIP addresses. When incrementing on ports, you have to considerthe Real-Time Transport Control Protocol (RTCP). For each audio stream,two separate RTP ports are reserved: one forthe actual audiotransmission andone for (the optional) RTCP. Therefore, when you areincrementing multicast MOH on ports, each stream consumes two ports. You have to calculate eight port numbers peraudio source (two ports per
codec).
Audio sources that are not enabled for multicast MOH should nevertheless be considered for
the increment ofaddresses orports. Audio source 1,which starts with the configured base address and port, requires four IPaddresses oreight ports. The same principle applies toeach consecutive audio source (audio source 2, audio source 3, and so on), regardless of whether
these audio sources are multicast-enabled.
3-24
Implementing CiscoUnified Communications Manager, Part2 (CIPT2) v8.0
Multicast MOH from Branch Router Flash: Region

Considerations Ihis subtopic discusses how to configure codecs when you are using multicast MOH from
branch router flash.
Multicast MOH from Branch Router
Flash: Region Considerations

* Locally generated MOH streams have to be identical to the streams that are generated by Cisco Unified Communications
Manager MOH servers:
Same destination IP address (multicast address).

- Same destination port number.
- Same codec.
- Same packetization period. * Multicast MOH from branch router flash supports only G.711. G.711 must also be used for the stream generated by Cisco Unified Communications Manager MOH servers: Put Cisco Unified Communications Manager MOH server into a dedicated region. Allow G.711 between the region of the MOH server and
the region used by branch phones.

- Limit all other intersite calls to G.729.
When multicast MOH is used. IP phones andCisco Unified Communications Manager are not
aware that the IP phones listen to locally generated MOH streams. From a signaling
perspective, the IP phone isinstructed to listen to acertain multicast stream, and the local SRSI gateway has to generate amulticast MOH stream by using identical settings, such as
destination address (multicast group), destination port, codec, and packetization period.
Multicast MOH in SRST gateways and Cisco Unified Communications Manager support only
the G.711 codec, 'fherefore. G.711 must also be configured between the Cisco Unified
Communications Manager MOH server and the branch IPphones. IfCisco Unified
Communications Manager signals a codec other than G.711 tothe IP phone, the IP phone could not play the locally generated MOH stream because ofa codec mismatch (the signaling would
be G.729. but the received RTP stream would be G.711).
Toensure that Cisco Unified Communications Manager sends signaling messages to the phone
and instructs it to listen to a G.711 stream,configure regions in this way:
Put the Cisco Unified Communications Manager MOH server or servers into a dedicated
region (for example. MOH).
Putall branch devices intoa site-specific region (forexample. Branch-1).

Allow G.711 between regions MOH and Branch-1.
Make sure that region Branch-1 islimited to G.729 for calls loand from all other regions.
20i0 Cisco Systems. Inc.
Bandwidlh Managementand CAC Implementation
3-23
Each SRST or Cisco Unified Communications Manager Express router can stream up to six different MOH files. You can configure each of them for multicast MOH or unicast MOH. Therefore, the maximum number of multicast MOH audio sources diat can be used per remote site is limited to six. By providing different MOH files for each site, site-specific MOH files can be played for each site. Only G.711 codec is supported by SRST and Cisco Unified Communications Manager Express. When using multicast MOH also within the main site, you must enable multicast routing in
order to allow the multicast stream to be routed from the Cisco Unified Communications
Manager server network to the phone network or networks. If the MOH server is on the same network that the IP phones are on, multicast routing is not required, but such a scenario is not recommended, for security reasons (servers should be separated from endpoints).
3-22
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) w8.0
Implementation
1his topic describes how to implement the multicast MOH from branch router flash feature. Multicast MOH from Branch Router Flash Characteristics
Works only with multicast MOH.
Based on MOH capabilities of SRST (Cisco IOS router requires feature

set that supports SRST) Cisco Unified Communications Manager must be configured to use
multicast MOH
IP phone is not aware that it listens to locallygenerated MOH. Stream generated by MOH server is prevented from reaching the IP WAN.
Identical stream is generated locally at the branch sites.
Branch router can stream up to six MOH files. Only G.711 is supported. - Each stream can be selectively enabled for multicast.
Up to six different MOH sources supported per branch router.
Multicast MOH from branch router flash is a feature that allows multicast MOI I streams to be
generated b\ gateways that are located at remote sites instead ofbeing streamed from the main
site to the remote site over the IP WAN.
Cisco Unified Communications Manager is configured for standard multicastMOH. Neither Cisco IInilied Communications Manager northe phones that are located at theremote siteare
aware that the stream generated at the centra! site is replaced by a locally generated stream. The multicast MOH stream that is generated by the centrally located MOH server is prevented from traversing over IPWAN. and the remote site router generates a stream that has the same
attributes (codec, multicast address, and port).
As mentioned earlier, multicast MOII from branch router flash is based on multicast MOH. so
\ou must configure Cisco Unified Communications Manager to use multicast MOH instead of unicast MOH. This configuration is recommended anyway in order to reduce load at the MOH server by multicasting one stream that can be received by all devices, instead ofstreaming
MOH indi\idually for each endpoint in separate RIP sessions.
To generate a multicast MOI Istream at the remote site, you use features ofSurvivable Remote Site Telephom (SRST) orCisco Unified Communications Manager Express, fherefore. the
remote site router thatwill generate the multicast MOI I stream forthedevices that are located at the remote site has to beconfigured for SRST or Cisco Unified Communications Manager
Express. SRSI" does not have to be active (there is no need for a fallback scenario), because an SRST gatewaj that is configured for multicast MOH streams MOH all the time, regardless of
its state (standby mode or SRST mode). The same principle applies toCisco Unified Communications Manager Express: Only multicast MOH has tobe enabled, no further features
have to be enabled,and no phones have to be registered.
; 2010 Cisco Systems. Inc.
3-21
associate profile: To associate a DSP farm profile with a Cisco Unified Communications Managergroup, use the associate profile command in SCCPCisco Unified Communications Manager configuration mode.
The name that is specified in the Cisco IOS device must match the name in the Cisco Unified Communications Manager exactly; the names are case-sensitive.
Tip
Note
When a Cisco IOS Enhanced Media Termination Point is being configured, any name can be configured with the associate profile command. When a Cisco IOS conference bridge is
being configured, the name cannot be configured; it is MTP(AMC), where (MAC) is the MAC
address of the interface that was specified at the seep local command.
dspfarm profile: To enter DSP farm profile configuration mode and define a profile for DSP farm services, use the dspfarm profile command in global configuration mode. codec (dsp): To specify call density and codec complexity that is based on a particular codec standard, use the codec command in DSP interface DSP farm configuration mode.
maximum sessions (DSP farm profile): To specify the maximum number of sessions that are supported by the profile, use the maximum sessions command in DSP farm profile configuration mode. associate application seep: To associate SCCP to the DSP farm profile, use the associate application seep command in DSP farm profile configuration mode.
no shutdown: If you fail to use the no shut command for the DSP farm profile, it will be displayed in the gateway but will fail to operate.
To verify the Cisco IOS media resource configuration, use fhese show commands:
show seep: To check whether the Cisco IOS router successfully established a TCP connection with the configured Cisco UnifiedCommunications Managersystem or systems in order to exchange SCCP signaling messages, use the show seep command. show seep ecm group [group-number]: To see which media resources are registered with the Cisco Unified Communications Managersystem or systemsthat are configured in the specified group, use the show seep ccm group / command.
show dspfarm profile [group-number]: To see the status of the media resource of the specified profile at the Cisco IOS router, use the show dspfarm profile / command.
3-20
Step 2: Configure Transcoder Resource in Cisco IOS Software

The figure shows how to configure Cisco IOS Software to provide transcoding resources to
Step 2: Configure Transcoder

Resource in Cisco IOS Software
cp ccm group 1 îate ccm 1 priority 1
Name lo Register Wilti at Cisco

Unitied Communications
:iata profile 1 register HQ-1 XCODEB-*^-! Manager

dspfarm profile 1 transcode
codec g711ulaw
codec gTllalaw For verification use:
~| The profile IDhas to match
codec g729ar8 codec g729abrfl

maximum sessions 2
show seep
show seep ccm group 1 show dspfarm profile 1

no shutdown
In theexample that is shown in the figure, a Cisco IOS Enhanced Media Termination Point
type transcoder is configured:
dspfarm (DSP farm): To enable DSP farm service, use the dspfarm command in global
configuration mode. The DSP farm service is disabled by default.
dsp sen ices dspfarm: To enable DSP farm services for a particular voice network module, usethe dsp servicesdspfarm command in interface configuration mode. seep local: To use Skinny Client Control Protocol (SCCP) to select the local interface that is used to register the media resources with Cisco Unified Communications Manager, enter
the seep local command in globalconfiguration mode.
seep ccm: To use SCCP to add a Cisco Unified Communications Manager server tothe list
of available serversand set variousparametersincluding IP addressor Domain Name
System (DNS) name, port number, and version numberuse the seep ccm command in
global configuration mode.
seep: To enable the SCCP protocol and its related applications (for example, transcoding and conferencing), use theseepcommand inglobal configuration mode. seep ccm group: To create a Cisco Unified Communicalions Manager group and enter
SCCPCisco Unified Communications Managerconfiguration mode, use the seep ccm group command in global configuration mode.
associate ccm: To associate a Cisco UnifiedCommunications Manager with a Cisco
Unified Communications Manager group and establish itspnority within the group, use the
associate ccm command in SCCPCisco Unified Communications Managerconfiguration
mode.
Step 1: Add Transcoder Resource in Cisco Unified

The figure shows how to add a transcoderresourcein Cisco Unified Communications Manager.
Step 1: Add Transcoder Resource in Cisco Unified Communications Manager

You can freely choose the device name when using Cisco
IOS Enhanced Media Termination Point hardware.
In all other cases, it must be MTP followed by MAC

address.
Select transcoder type.
TrtMWdBi
Tip,"
C'tai (OS Mivad Hnba Ttrmnuliui Punf
^*\
|_
DttcVJon *>.. Pwl*

ttdqrm*ht)ti
HQ-ilEhrtcfbdiisf Dttouro* DbUJI

< tont >
Enter device name and
description.
i tf 1
V".
Select device pool.
Navigate to Media Resources > Conference Bridge and click Add New. The Transcoder Configuration window opens. Choose the type of Cisco transcoder media resource from these options:
Cisco IOS Enhanced Media Termination Point Cisco IOS Media Termination Point Cisco Media Termination Point Hardware Cisco Media Termination Point
Note
The type depends on the hardware that is used. For example, NM-HDV would require Cisco
IOS Media Termination Point to be selected while newer DSP hardware such as NM-HDV2
is configured as Cisco IOS Enhanced Media Termination Point.
Choosethe type of the Ciscotranscoder mediaresource, enter a device name and a description for the transcoding resource, and then choose a device pool. The device name has to match the name that is entered at the Cisco IOS router thai provides the mediaresource. The name is case-sensitive. If the transcoding resource is provided by Cisco IOS Enhanced Media Termination Point hardware, you can freely choose the name. In all other cases,the name is MTPfollowed by ihe MAC addressof the interface that is configured to be used for registering the media resource with Cisco Unified Communications Manager.
3-18
Implementing Cisco Unrfied Communications Manager, Part 2 (CIPT2)v8.0
Configuration Procedure for Implementing Transcoders

"fhis subtopic presents the procedure for implementing transcoders.
Configuration Procedure for Impiementing Transcoders

Add transcoder resource in Cisco Unified Communications
Manager.
2 3 4 G
Configure transcoder resource in Cisco IOS Software. Configure media resource groups (MRGs). Configure media resource group lists (MRGLs). Assign MRGLs to devices.
To implement transcoders. perfonn these steps:
Step 1 Step 2
Step 3
Step 4
Add transcoder resource in Cisco Unified Communications Manager. Configure transcoder resource in Cisco IOS Software.
Configure MRGs.
Configure MRGI.s.
Step 5
Note
Assign MRGLs to devices.

Only the first two steps of the procedure are presented on the following pages, because the last three stepsthe configuration of MRGs, the configuration of MRGLs, and the
assignmentof MRGLs to devicesare discussed inthe Implementing Cisco Unified

Communications Manager, Part 1 (CIPT1) course.
3-17
Example: Implementing a Transcoder at the Main Site (Cont.)

Region: HQ Region: BR
Region: HQ Region Configuration:

Within HQ: G.711
HQ to BR: G.729
Transcoder
Within BR: G.711
The figure illustrates how the solution described earlier in this topic is implemented in Cisco Unified Communications Manager. All headquarters devices (phones, voice-mail system, software conference bridge, and the transcoder) are in region HQ. Remote site phones are in region BR.
Cisco Unified Communications Manager region configuration allows G.711 to be used within region HO and within region BR. Calls between regions HQ and BR are limited to G.729. When a call is placed from a remote site phone to the voice-mail system, Cisco Unified Communications Manager identifies the need for a transcoder that is based on the capabilities of the devices(G.711 only at the voice-mail system)and the maximum permittedcodec (G.729). A device may support only a codec with higher bandwidth requirements than permitted by the region configuration, for example. If such a device can access a transcoder. the
call is set up and invokes the transcoder resource. The call would otherwise fail.
3-16
Example: Implementing a Transcoder at the Main Site

The figure illustrates an example of implementing a transcoder at the main site.
Example: Implementing a Transcoder at

the Main Site
G.729 audio streams are transcoded at the main site before
being passed on to endpoints supporting only G.711.
Manager
At the main site, there are two devicesthat supportCi.711 only. One device is a Cisco Unified
Communications Manager software conference bridge; theother device is a third-party voicemail application.
Regions are configured in such a way that all voice traffic between the remote site and the main
site has to use the G.729 codec.
When a user at a remote site needs to be added to a conference via the software conference
bridge, the user cannot be added, because G.729 must be used over the IP WAN but only G.711
is supported by the conference bridge.
By adding a transcoder resource at the main site gateway, you enable the remote site user to
send a G.729 voice stream, which is transcoded to G.711 and passed on to the conference
bridge b\ the transcoder that is located at the main site.
The same approach can beused for calls to the voice-mail system from the remote site.
Number of phones at remote site and number of calls that are placed toG.711-only phones over the IP WAN: How many phones are located at the remote site? How often do the phones need to communicate to phones located at the headquarters that support G.711 only and hence require a transcoder when G.729 must be used over the IP WAN? How many of these calls occur at the same time?
Available bandwidth and cost of additional bandwidth: Is there enough bandwidth (or can additional bandwidth be provisioned) to allow G.711 for calls to devices that do not
support G.729? How does the cost of adding bandwidth compare to the cost of deploying
local DSPs?
3-14
Transcoder Implementation
This topic describes how to implement transcoders in order to allow low-bandwidth codecs to
be used when they are not supported by both endpoints.
Considerations When Deploying

Transcoders
Allows low-bandwidth codecs to be used in the IP WAN when
one or both endpoints do not support low-bandwidth codecs: Affected endpoint uses high-bandwidth codec toward the
transcoder.
Transcoder changes voice stream from high-bandwidth

codec to low-bandwidth codec.
Low-bandwidth codec stream is sent to other device
(or transcoder) over the IP WAN. Efficiency depends on several factors:

Number of devices at remote site and likelihood of requiring
a transcoder
- Ease of adding required hardware resources (DSPs).

Available bandwidth toward central site.
As mentioned earlier in this lesson, transcoders arc devices that transcode voice streams, fhat
is. they changethe way that the audio payload is encoded(for instance, G.711 audio streams are changed to G.729 audiostreams). Transcoders arc deployedin order to allow the use of
low-bandwidth codecs over the IP WAN even if one of the endpoints supports only highbandwidth codecs such as G.711.
The transcoder hasto be deployed close to the device thatsupports only G.711. Thatdevice
will send a G.711 stream to the transcoder. which transcodes the audio to a low-bandwidth codec such as G.729. The G.729 voice stream is then sent from the transcoder to the other
device a phone that is located at a remotesiteoverthe IP WAN.

Note Itis important forthe MRGL to know that the devicethat is limited to the higher bandwidth
codec is the one that will request the transcoder media resource. If, for example, onlyG 729
is permitted between two IPphones, butone IP phone supports only G.711, the phone that cannotcomply with the permitted codec (G.729, inthiscase) is the one that will requesta transcoder. Therefore,the MRGL of this phone has to have access to a transcoder, which should be physically located close to the requesting device. Regions have to be set up in such a waythat the requesting phone is allowed to use G.711 to the transcoder(notethat this call leg is also subject to region configuration).
Refore deploying transcoders. you must consider some factors that are like the factors that must be considered when you deploy local conference bridges. Here arethe factors: Cost of adding DSPs: Is it necessary lo add DSPs to anexisting router only, or docs t le
whole platform have to be replaced?
3-13
Example: Implementing Local Conference Bridges at Two Sites (Cont.)
HQ_SWMRG
Main Site Cisco Unified
Communications
Manager
The figure illustrates how Media Resource Groups (MRGs) and Media Resource Group Lists (MRGLs) are used to ensure that headquarters phones use the conference resources at the
headquarters and that remote site phones use the remote site conference resource when
establishing a conference.
These three MRGs are created:
HQ_HW-MRG: Includes the hardware conference bridge that is provided by the voice gateway that is located at the headquarters IIQ_SW-MRG: Includes the software conference bridge that is provided by a Cisco Unified Communications Manager server that is located at the headquarters
BR_H\V-MRG: Includes the hardware conference bridge that is provided by the voice
gateway that is located at the remote site
The HQ HW-MRG is the first entry of the MRGL, which is called HQ_MRGL; (he HQ SWMRG is the next entry. Headquartersphones are configured with the HQ_MRGL. Because MRGs arc used in a prioritized way, headquarters phones that invoke a conference will first use the available hardware conference resources; when all of them are in use, the software
conference resources are accessed.
At the remote site, all phones refer to the BRMRGL, which includes only the BRJIW-MRG. This configuration allows remotephonesto use their local conference bridge when they invoke conferences instead of accessing conference resources that are located across the IP WAN.
3-12
Example: Implementing Local Conference Bridges at Two Sites

The figure shows a sample scenario for deploying local conference bridge resources at a remote
site.
Example: Implementing Local Conference Bridges at Two Sites

Phones at the remote site should use a local
conference bridge when creating a conference.
Main Site Cisco Unified Communications
Manager
WAN
Remote Site
The figure shows a main site with software and hardware conference resources. At the remote
site, hardware conference resources are added lo the remote site gateway. As a result, the
remotesite phones can set up conferences by using local resources insteadof by always accessing the conference resources that are located at the main site. For conferencing remote
site members onlv. no traffic has to be sent across the IP WAN. Note When an ad hoc conference includes members of separate sites, a separate voice stream
for each remote member has to be sent across the IP WAN. However, if a Meet-Me
conference is set up, the users that are located at the remote site could first establish an ad hoc conference (by using a media resource that is localto the remote users) and then add a
call to the remote Meet-Me conference to their local ad hoc conference. In this case, there is
onlya single voice stream that is sent across the IP WAN connecting the twoconferences.
2010 Cisco Systems.
3-11
Local Conference Bridge Implementation

"fhis topic describes howyou can implement local conference bridges at remote sites in orderto keep voice streams local when all members of the conference are located at thesame site.
Considerations When Deploying Local

Media Resources at Remote Sites
Trafficstays offthe IP WAN when remote site devices require a
media resourcefor example, conference bridges. - Local media resources require appropriate hardware at remote site (DSPs in gateway).
Efficiency depends on several factors:

- Number ofdevices at remote site and likelihood of using a feature or application requiring the media resource
- Ease of adding required hardware resources (DSPs)

- Available bandwidth toward central site
When local conference bridges or Media Termination Points (MTPs) are deployed at each site, traffic does not have to cross the IP WAN if all endpoints are located at the same site. You can implement local media resources such as conference bridges and MTPs by providing appropriate hardware (digital signal processors [DSPs]) at the routers that are located at the
remote sites.
Whether the extra cost for providing the DSP resources will be worthwhile depends on several
factors:
Cost of adding DSPs: Is it necessary to add DSPs to an existing router only, or does the whole platform have to be replaced?
Number of devices at remote site and likelihood of using applications or features that
require access to the media resource that is considered to be locally deployed: How
many phones are located at the remote site? How often do the phones use features that require a media resource that is currently available only over the IP WAN? What is the maximum number ofdevices that require access to the media resource at the same time?
Available bandwidth and cost of additional bandwidth: Is (here enough bandwidth (or can additional bandwidth be provisioned) to accommodate the requirements that are determined by the preceding factors? How does the cost of adding bandwidth compare to the cost of deploying local DSPs?
3-10
Example: Codec Configu ration (Cont)

Ipffcw OvftfluraJk*
ftevw JnfonmHIon Pwk-ti ctrfifteBfaifon
flimt
E4L_0|.2ftai
teuton RalBilQn4jiw* - - *mli*0 5=_JHm,*mm+****t* - .bpif^ -si.
a_)>
s *!>> i s ' :
M5,si>ii-tt
wq_i-<,-
e "til (S :;
Sites ts'Jf,
HQ_phones uses G.711 within its own region and to region HQ_gw; to all other regions,
G.729 is used
BR_phones uses G.711 within

its own region and to region BR_gw, to all other regions,
G.729 is used.
/\
"fhe figure illustrates region configuration in Cisco Unified Communications Manager for the discussed scenario. The configuration of the HQ_phones and the BR_phones regions is illustrated. Both regions are configured in such a way that calls within the region and calls to
the local gateway (regions HQ_gw and RR_gw) arc allowed to use (i.7l I. while calls to all
other regions are limited to G.729.
Note The preceding example is a partial configuration only. It does not show the configuration of
the other regions.

The figure shows a sample scenario for codec configuration in Cisco Unitied Communications
Manager.

Region Configuration
Within MQ_phorie9 G 711 WitntnHQ_gw G711

HQ_ptionestoHQ_gw G.711
Within BR_pnonee G 711 Within BRjuf G 711 BR_phones to BR_gv/ G.711

All others G 729
Remote Site
Region: HQ_phones
Region BR_phones
In the figure, phones that are located in the headquarters are configured with region HQ_phones. An intercluster trunk that connects to another Cisco Unified Communications Manager cluster and a Session Initiation Protocol (SIP) trunk connecting to an Internet telephony service provider (ITSP) are in region HQ_trunks. The public switched telephone network (PSTN) gateway that is located in the headquarters is configured with region HQ_gw. At the remote site, phones are in region BR_phones and the PSTN gateway is in region
BR_gw.
Cisco Unified Communications Manager regions are configured in the following way: Within HQ_phones: G.711 Within IIQ_gw: G.711
HQ_phones to HQ_w: G.711
Within BR_phones: G.711 Within BR_gw: G.711

BR_phones to BR_gw: G.711
All others: G.729
As a result, of this configuration, all calls that use the IP WAN between the remote site and the
headquarters use G.729. Calls that are sent through the intercluster or SIP trunk use G.729 as well. These calls use G.711: calls between phones within the headquarters, calls between phones within the remote site, calls from headquarters phones to the headquarters PS'fN gateway, and calls from remote site phones to the remote site PSTN gateway.
Review of Cisco Unified Communications Manager Codecs

This subtopic reviews how to control the codec that is used for a call in Cisco Unified Communications Manager.
Review of Cisco Unified
Communications Manager Codecs

The codec that will be used depends on Cisco Unified Communications Manager region configuration:
Each region is configured with the highest permitted codec bandwidth
- Within the configured region.
Toward specific other regions (manually added).

Toward all other regions (that have not been manually added)
Region is assigned to a device pool.

Device pool is assigned to a device.
Codec that is actually used depends on capabilities of the two devices:

Best codec that is supported by both devices and does not exceed
codec bandwidth permitted in region configuration.

If devices cannot agree on a codec, a transcoding device is invoked.
Loss type (configured in region) is also considered.
The codec that will be used for a call depends on the Cisco Unified Communications Manager
region configuration. Eachdevice is assigned with a regionvia the device pool configuration. For each region, the administrator can configure the highestpermitted codec bandwidth within a region, to other specifically listed regions, and to all other (not listed) regions. Whena call is placed between two devices, the codec is determined based on the regionsof the two devices and on the capabilities of the devices: The devices will use the bestcodec that is supported by both devices and that doesnotexceed the configured codec bandwidth forthe region or regions that are involved in the call. If the two devicescannotagree on a codec (for instance, if region configuration allowsonly 8 kb/s as the maximum codec bandwidth but one device supports only G.711). a transcoder is invoked, if available. The losstypeof a linkcan alsobe configured. On links that are configured to be lossy, codecs that are lesssensitive to packet lossarepreferred overcodecs thatresult in higher-quality degradation. Formore details about codec selection, refer to the Implementing Cisco Unified Communications Manager,
Part / (CIPTI) course.
Cisco Unified Communications Manager Codec Configuration

This topic describes how to configure Cisco Unified Communications Manager in order to limit
the codec that is used for a call.
Codec Configuration Considerations

Use high-bandwidth codecs in LAN environments,
Use low-bandwidth codecs for IP WAN.
* Low-bandwidth codecs are designed for human speech:

- Do not work well for other audio streams, such as music.
Use alternative methods for MOH:
Disable MOH for remote sites. Use multicast MOH from branch router flash.
To conserve IP WAN bandwidth, you should use low-bandwidth codecs in the IP WAN. For calls within a LAN environment, you should use high-bandwidth codecs for optimal audio quality. Whenyou are designing where to use which type of codec, it is important to consider that low-bandwidth codecs such as G.729are designed for human speech. They do not work
well for other audio streams, such as music.
As stated in the previous topic, other methods exist for limiting the bandwidth that is required
for MOH streams. If you cannot use multicast MOH from branch router flash but MOH streams
are not desiredon the IP WAN. you can disable MOHfor remotesite phones.
3-6
Implemenling CiscoUnified Communications Manager, Part 2 (CIPT2) v8,0
Other bandwidth management solutions includethe use of transcoders or the implementation of special features such as multicast MOH from branch router flash. Transcoders are devicesthat can transcode voice streams. That is. they change the way that the audio payload is encoded (for instance, a G.711 audio stream is changed to a G.729 audio stream). Transcoders allow the
use of low-bandwidth codecs over the IP WAN even if one of the endpoinls is limited to a
high-bandwidth codec such as G.711. Multicast MOII from branch router Hash allows a multicast MOH stream lo be generated by a Cisco IOS router that is located at the remote site,
instead of being sent over the IP WAN from a centralized MOH server.
Bandwidth Management and CAC Imptementation
Bandwidth Management Overview

fhis topic describes bandwidth management options in a Cisco Unified Communications Manager deployment.
Examples of Bandwidth Management Options

Bandwidth in the IP WAN can be conserved by:
Techniques that reduce required bandwidth of voice streams:
- RTP header compression (as part of QoS link efficiency

mechanisms)
Low-bandwidth codecs
Techniques that influence the flow of voice streams:
- Local media resources such as conference bridges

Other solutions: - Transcoders - Multicast MOH from branch router flash
You can use varioustechniques to conserve valuable IP WANbandwidth. One technique is to reducethe requiredbandwidth of voice streamsby using Real-Time Transport Protocol (RTP) header compression (which is a qualityof service [QoS]link efficiency mechanism), Another
technique is to use low-bandwidth audio codecs. You can also use a combination of these two
solutions.
Note
Refer to the "Quality of Service" moduleof the Implementing Cisco Voice Communications
and QoS (CVOICE) course for more detailed discussion about QoS.
Otheroptions for managing IP WANbandwidth are techniques that influence where voice streams are sent. If three phones, all located at a remotesite, establishan ad hoc conference, there is a greatdifference in bandwidth usage if the conference bridge is located at that remote
sitelocal to the phones that are members of the conferenceor if the conference is located at
the main site and has to be accessed over the IP WAN. Inthe latter case, all three phones are sending their voice stream tothe conference bridge over the IP WAN. The conference bridge is mixing thereceived audio and is then streaming it back to all conference members (in three
separate streams). Although the call appears to be local to the remote sitebecause all
conference members are located atthat sitedue tothe remotely located conference bridge, the
IP WAN is occupied by three calls.
3-4
Lesson 1
Managing Bandwidth
Overview
When an IP WAN connects various sites in a Cisco Unified Communications network,
bandwidth consumption at the IP WAN should beminimized. Several techniques can help
conserve bandwidth on the IP WAN in a multisite deployment;
Reducing the required bandwidth of voice streams
Keeping some \oice streams (such as local media resources) away from the IP WAN Employing special features like multicast music on hold (MOH) from branch router flash
(or the use of transcoders).
"fhis lessondescribes all these techniques and features and their implementation.
Objectives
Upon completing this lesson, you will be able to describe techniques to reduce bandwidth requirements on IP WAN links in Cisco Unified Communications Manager multisite deployments. This ability includes being able tomeet these objectives:
Describe methods to minimize bandwidth requirements for Cisco Unilied Communications
used for a call
Configure Cisco Unified Communications Manager in order tocontrol the codec that is
Implement local conference bridges in order to avoid accessing conference bridges over the
IP WAN even if all participants are local
Implemeni transcoders in order to allow low-bandwidth codecs to be used iflow-bandwidth

codecsare not supported by both endpoints
Implement multicast MOH from branch router flash to avoid MOH streams over the IP
WAN
3-2
2010 Cisco Systems, inc.
Module 3

Overview
Individual sites of a multisite deployment are usually interconnected by an IP WAN in situations in which bandwidth is relatively costly and bandwidth consumption should be minimized. Call Admission Control (CAC) is alsoimportant in a multisite environment in order
to avoid bandwidth oversubscription by too many voice calls.
This module describes methods of reducing bandwidth requirements and explainshow to
design and implement those methods so that the IP WAN bandwidth can be used as efficiently as possible. It also describes CAC options for intrasile calls and intersite calls and how to implemeni them in amultisite Cisco Unified Communications Manager deployment. The
module also describes automated alternate routing (AAR), which allows the public switched
telephone network (PSTN) to be used as a backup for calls that CAC denies due to insufficient
bandwidth.
Module Objectives
Upon completing this module, you will be able to implement bandwidth management and CAC to prevent oversubscription ofthe IP WAN. This ability includes being able to meet these
objectives:
Describe techniques to reduce bandwidth requirements on IP WAN links in Cisco Unified

Communications Manager multisite deployments
Describe and configure CAC mechanisms and AAR in Cisco Unified Communications
Manager and in gatekeepers

QD
02) 03)
C
B. C
voice service voip

h323
no h225 timeout keepalive

Q4) 05) 06) Q7) Q8) 09) 010) Qll) Q12) Q13) Q14) Q15) A,D
D
B B D
D A
B.C A,D B.C

A
2-102
Impiementing Cisco Unified Communications Manager, Part 2 (CIPT2) vB.O
Q12)
Which two statements about Cisco Unified Communications Manager Express are true? (Choose two.) (Source: Implementing Cisco Unified Communications Manager Express in SRST Mode) A) IP phonesregisterwith Cisco Unified Communications Manager Express in
standalone mode when Cisco Unified Communications Manager Express is
partof the Cisco Unified Communications Manager group (hat is specified in

the device pool of the phone.
B)
C) D)
During SRST fallback. IP phonesregisterwith Cisco Unified Communications ManagerExpress in SRSTmode when Cisco Unified Communications ManagerExpress is configured as the SRST reference for the IP phone. Cisco Unified Communications Manager Express in SRST modeprovides
more features than standard SRST.
The same platform can serve more phones when running Cisco Unified Communications Manager Express in SRST mode versus running standard
SRST,
E) 013)
Standalone Cisco Unified Communications Manager Express routerscan be

clustered for redundancy.
Which two features have been added in Cisco Unified Communications Manager
Express Release 8.0? (Choose two.) (Source: implementing Cisco Unitied

Communications Manager Express in SRST Mode)
A) fi\ e additional MOI 1sources
B) C) D)
E)
presence with BLE status \ideo support demote argument of the dialplan pattern command
local MOII
014)
Whichtwo commands are notconfigured in telephony-service configuration mode? (Choose two.) (Source: Implementing Cisco Unified Communications Manager Express in SRST Mode)
A) create cnf-files
B) C) D)
E)
ephone ephonc-dn max-ephoncs

max-dn
F)
ip source-address
Q15)
Which statement about Cisco Unified Communications Manager Express in SRST mode is not true? (Source: Implementing CiscoUnified Communications Manager
Express in SRST Mode)
A) B) C) D)
If only the ephone is preconfigured, only the ephone-dn is learned by SNAP. If only the ephone-dn is preconfigured, only theephone is learned bySNAP. If ephone and ephone-dn arepreconfigured, SNAP is notused. If neither ephone norephone-dn areprcconfigured, ephone and ephone-dn are
learned bv SNAP.
> Cisco Systems, Inc 2010
Centralized Call-Processing Redundancy Implementalion
2-101
Q6)
When implementing MGCP Fallback and SRSf, which configuration is not performed at Cisco Unified Communications Manager? (Source: Implementing SRST and MGCP
Fallback)
A) B)
adding SRST references enabling MGCP fallback at the MGCP gateway configuration page
C) D) Q7)
configuring CFUR to reach remote-site phones during SRST mode

applying SRST reference to phones
The SRST reference is configured under System > Enterprise Phone Parameters. (Source: Implementing SRST and MGCP Fallback)
A) B) true false
Q8)
Which command is used for SRST configuration at the Cisco IOS router? (Source:
Implementing SRST and MGCP Fallback)
A) B) C) D)
telephony-server ccm-manager fallback service alternate default call-manager-fallback
Q9)
Which command is not used for MGCP Fallback configuration? (Source: Implementing SRST and MGCP Fallback)
A) B) C) D)
E)
ccm-manager fallback-mgcp application global telephony-server

service alternate default
QIO)
Wheredo you configure the maximumnumberofhops that can be used by CFUR?

(Source: Implementing SRST and MGCP Fallback) A) B) C) D) service parameter enterprise parameter SRST gateway configuration phone configuration
Q1I)
How cancalling privileges be implemented for SRST individual phones? (Source:

Implementing SRST and MGCP Fallback)
A) B) C) D)
only when using Cisco Unified Communications ManagerExpress in SRST

mode
by preconfiguring the phonesthat need callingprivileges assigned by configuring an ephone-dn template by configuring COR lists for directory numbers
2-100
Module Self-Check
Use the questions hereto review whatyou learned in this module. Thecorrect answers and
Q1)
Which of these provides redundancy for MGCT-controlledgateways? (Source: Examining Remote Site Redundancy Options)
A) B) C) D) MGCP SRST SRST fallback MGCP fallback MGCP in SRST mode
Q2)
Which two types of calls arc notpreserved during switchover of an SRSf gateway? (Choose two.) (Source: Examining Remote Site Redundancy Options)
A) B) calls between IP phones that are located at the remote site conference calls of remote-site phones using a conference bridge that is located
at the main site
C) D) E)
calls between IP phones that arc located at the remotesite and at the main site calls between IP phones that are located at the main site calls from main-site phonesthat wereplaced to a remote-site phone and then transferred from the remote-site phone to another main-site phone
Q3)
Which configuration is required lo allow calls lo bepreserved during switchback from

H.323 to MGCP? (Source: Examining Remote Site Redundancy Options)
Q4)
What are the two correct statements of supported phones in SRST for the given platform? (Choose two.) (Source; Examining Remote Site Redundancy Options)
A) 800: 4
B) C) D) E)
2801:500 2851:350 3825:350 3845:1024
Q5)
What can you use toconfigure the dial plan ata remote-site gateway insuch a way that
branch users can stillreach the headquarters when dialing internal directory numbers during fallback? (Source: Examining Remote Site Redundancy Options) A) Ihis is not possible. Users have to dial headquarters users by their PSTN
numbers while in fallback mode.
B) C) D)
Use translation profiles modifying the callingnumber. Issue the dialplan-pattern command. Use translation profiles modifying the called number.
i2010 Cisco Systems. Inc.
Centralized Call-Processing Redundancy Implementation
Cisco Systems. Inc. Number Translation Using Voice Translation Profiles, February 2006,
http://w\\w.cisco.coni,'eii/US/tech/tk652/lky()/technoloies configuration__exantpld)9IS6a0
0803f818a.shtml
Cisco Systems. Inc. Voice Translation Rules, November 2006.
http:/.''www,eisco,com/en/IJS/lcch/tk652/lk90/lechnologies_tech_note09l86a0080325e8e.s
html
Cisco Systems. Inc. Cisco Unified Communications Manager Express System
Administrator Guide, November 2007 with updates 2010. hup://ww w,cisco.com/en/US/docs/voice ip comm/cucme/admiii/coiifiguration/guide/cmea
dm.html
2-9S
Module Summary
Module Summary
Cisco Unified Communications Manager supports features
that provide remote phones with redundancy in case of an IP

WAN failure.
Cisco Unified SRST allows remote site phones to register at a local router that performs call processing. MGCP gateways that lose the connection to their call agents can fall back to
H.323 or SIP.
Cisco Unified Communications Manager Express can be used in SRST mode to provide more features than standard
Cisco Unified SRST in the event of an IP WAN failure.
Ihis module described the available features for providing remote phones with backup in the
event of an IP WAN outage. It explained call survivability. Media Gateway Control Protocol
(MGCP) fallback, and Cisco Unified Survivable Remote Site Telephony (SRS'f). fhe module also contrasted the differences between standard SRST and Cisco Unified Communications
Manager Express in SRST mode. In addition, itdescribed how to implement standard SRST and a dial plan to support intersite connectivity through the public switched telephone network (PSTN), as well as PSTN access during IP WAN failure. Finally, the module showed how to implement a backup solution using Cisco Unified Communications Manager Express in SRST
mode instead of using standard Cisco Unified SRST.
References
Cisco Systems. Inc. Cisco Unified Communications System 8.x SRND, April 20IC. hup://\\\\w,cisco.com 'en.TJS/d()cs/voicejp_comni/ciiein/snid/8x/uc8x.hlinl Cisco Systems. Inc. Cisco Unified Communications Manager Administration Guide
Release 8.011). February 2010.
http://www.cisco.coni/cn/t'S/docs/v()icejp_coinm/cLicni/admin/8J) l/ecmcfg/bccm-KOIcm.html
Cisco Systems. Inc. Cisco Unified Survivable Remote Site Telephony Version 8.0.
lntp://w\\w.cisco.eoni/en/US/prod/collateral/voicesxv/ps6788/vcallcon/ps2l69/daUi .sheet_>
78-570481.html
November 2009,
Centralized CalI-Processing Redundancy Implementation
2-97
2-96
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8,0
Summary
Summary
Cisco Unified Communications Manager Express cannot be a member of a Cisco Unified Communications Manager cluster.
Cisco Unified Communications Manager Express supports
Cisco Extension Mobility, phone and media security, busy lamp field (BLF), and video. Basic configuration of Cisco Unified Communications Manager Express includes telephony-service configuration, ephone configuration, and ephone-dn configuration. The srst mode command in telephony-service configuration mode is required to allow Cisco Unified Communications Manager Express to learn ephones and ephone-dns via
SNAP
References
For additional information, refer to this resource:
Cisco Systems. Inc. Cisco Unified Communications Manager Express System

Administrator Guide. November 2007 with updates 2010.
http:''www.cisco.coiTt/en.-rS/docs.'Voice ip coiiim-'ciiciiie/adniin/cunliguration/guide/cnica
dm.html
Centralized Call-Processing RedundancyImplementation
2-95
Cisco Unified Communications Manager Express in SRST Mode Configuration Example

The figure shows a configuration example of Cisco Unified Communications Manager Express
in SRST mode.
Cisco Unified CME* in SRST Mode
Configuration Example
Cisco
Unity
Manager
telephony-service erst mode Auto-provision none

srst dn line-mode dual
srst aphone templata 1

srst dn template 3
srst ephone description CUCME-SRST ephone-template 1 keep-conference local-o Qly ephone-dn-template 3

hold-alert 25 idle
In the example. Cisco Unified Communications Manager Express uses ephone template 1 for newly added phones. This template configures conferences to drop if no internal members are
left in the conference.
Ephone-dns, which are learned using SNAP, are configured to alert the user if a call is on hold
for 25 seconds and the phone is idle.
For easier distinction, the description of learned phones should include an SRS'f string. The
ephone-dns should be dual-mode lines.
2-94
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) w8.0
Note
Ifsingle-line ephone-dns is used with multiline features likecall waiting, Call Transfer, and conferencing, there must be more than one single-line directory number on a phone.
Configuring Cisco Unified Communications Manager Express in SRST Mode (Cont)

CHERouter(confia-telephonv)#
srst dn template template-tag
Specifies an ephone-dn template to be used in SRST on a Cisco

Unified Communications Manager Express router. Range is 1 to 15.
CHERouter(config-telephony)#
srst ephone template template-tag
Specifies an ephone template to be used in SRST mode on a Cisco Unified Communications Manager Express router. Range is 1 to 20.
CHERouter (conf id-telephonv) tt
srst ephone description string
Specifies a description to be associated with an ephone learned in

SRST mode on a Cisco Unified Communications Manager Express
router Maximum is 100 characters
To specify an ephone-dn template to be used in SRST mode on a Cisco Unified Communications Manager Express router, use the srst dn template command in telephonyservice configuration mode:
Theparameter template-tag is the identifying number of an existing ephone-dn template.

The range is from I to 15.
To specifv anephone template to beused in SRS'f mode on a Cisco Unified Communications Manager Express router, use the srst ephone template command intelephony-service
configuration mode:
The parameter template-tag is the identifying number of anexisting ephone template. The
range is from 1 to 20.
To specifv a description to be associated with anephone in SRST mode on a Cisco Unified Communications Manager Express router, use the SRST ephone description comma.id in
telephony-service configuration mode:
Maximum length of the parameter string is 100characters.
Configuring Cisco Unified Communications Manager Express

in SRST Mode
The configuration of Cisco Unified Communications Manager Express in SRST mode is performed in telephony-service configuration mode. When the telephony-service command is active, the call-manager-fallback command is not accepted by the CI,I, and vice versa.
Configuring Cisco Unified Communications Manager Express in SRST Mode

CHERouter(config-telephony)#
srst mode auto-provision {all | dn | none}

Enables SRST mode for a Cisco Unified Communications Manager Express router - all writes information for leamed ephones and ephone-dns into the running configuration. - dn writes information for learned ephone-dn into the running
configuration.
- none does not include information for learned ephones or ephone-dns in the running configuration.
CHERouter(confiq-telephony)#
srst dn line-mode {dual | single}

Specifies the line mode for ephone-dns in SRST mode on a Cisco
Unified Communications Manager Express router. Default is single

line
To enable SRS'f mode for Cisco Unified Communications Manager Express, use the srst mode auto-provision command in telephony-service configuration mode:
The keywordall includes information for leamed ephonesand ephone-dns in the running
configuration.
The keyword dn includes information for learnedephone-dns in the runningconfiguration. The keyword none does not include information for learnedephonesor ephone-dns in the running configuration. Use this keyword when Cisco UnifiedCommunications Manager Express is providing SRSTfallback services for Cisco Unified Communications Manager,
Ifthe administrator saves the running configuration after learning ephones and ephone-dns, the fallback IP phones will be treated as locally configured IP phones on the Cisco Unified
Note
Communications Manager Express SRST router,whichcould adversely impact the fallback

behavior of those IP phones.
To specify the line mode for the ephone-dns that are automatically created in SRST mode on a Cisco Unified Communications ManagerExpress router,use the srst dn line-mode command in telephony-service configuration mode. The keywords provide these specifications: The keyword dual specifies dual-line ephone-dns.
The keywordsingle specifies single-line ephone-dns (the default).
2-92
Implementing Cisco Unified Communications Manager,Part 2 (CIPT2) vB.O
Phone Registration Process

This section describes the phone registration process.
Phone Registration Process

When an IP phone registers to Cisco Unified Communications Manager Express in SRST mode during
fallback:
The router searches for an existing ephone with the MAC address of
the phone.
tf found, tho ephone must be configured with a directory number
(button command), or automatjcassignmentmust be enabled.

If not found, the router searches for an existing ephone-dn that
matches the IP phone directory number (learned by SNAP). Iffound, an ephone is added that refers to the matched
ephone-dn
If not found, an ephone is added that refers to a newly created ephone-dn autoconfigured by SNAP.
Whenever an ephone is added by Cisco Unified SRST, the srst ephone template is applied. Whenever an ephone-dn is added by Cisco Unified SRST, the srst
ephone-dn template is applied.
When a phone loses connectivity to the Cisco Unified Communications Manager, itregisters to
its configured SRST reference.
If that SRST reference is Cisco Unified Communications Manager Express in SRS'f mode, the
Cisco Unified Communications Manager Express router firstsearches for anexisting
(preconfigured) ephone with the MAC address ofthe registering phone. Ifthe router finds an ephone. the stored ephone configuration isused. No phone configuration settings that arc pro\ ided b> SNAP are applied, and no ephone template is applied. Ifthe configured ephone is configured with one ormore ephone-dns. the stored configuration isused for the ephone-dn or ephone-dns ofthe phone. Neither the information that is provided by SNAP nor the ephone template thai isconfigured under telephony-service isapplied. Ifthe configured ephone isnot configured with an ephone-dn. automatic assignment has tobe enabled for the phone tobecome
associated with an ephone-dn. SNAPis no option in this case.
Ifno ephone is found for the MAC address ofthe registering phone. Cisco Unified Communications Manager Express adds the ephone (and applies the ephone template, if configured), using SNAP. Ifthe directory number exists, it is bound tothe added phone: otherwise, the directory number islearned using SNAP. Ifconfigured, the ephone-dn template
is applied.
2-91
Advantages of Cisco Unified Communications Manager Express in SRST Mode

UsingCisco Unified Communications ManagerExpress in SRST modehas several advantages, when compared with using standard SRST.
Advantages of Cisco Unified Communications Manager Express in

SRST Mode Provides many more features than standard SRST
- Allfeatures of Cisco Unified Communications Manager Express can be used.
* Allows a mix of preconfigured phones and directory numbers, and phones and directory numbers learned by SNAP - Only those phones and directory numbers that require individual configuration have to be preconfigured. - Pre configuration can be based on MAC address or on directory number.
- Phones that do not require individual settings do not have to be preconfigured. - Additional settings can be applied to phone and directory number configuration leamed by SNAP, using ephone and ephone-dn templates.
These are the main advantages:

Cisco Unified Communications Manager Express provides more features than standard SRST (in general). Cisco Unified Communications Manager Express in SRST mode allows a mix of preconfigured phones and directory numbers for those phones, and directory numbers that require individual settings and phones that are not configured but are leamed by SNAP.
You can combine the advantages of Cisco Unified Communications Manager Express (more features) and standard SRST (dynamic provisioning of phone configuration during fallback, using SNAP) by preconfiguring the required individual settings in Cisco Unified Communications Manager Express.
Ephone configuration is based on MAC addresses; ephone-dn configuration is based on the directory number.
All phones or directory numbers that collectively require identical configuration that is not provided by SNAP do not have to be preconfigured, but the additional configuration can be applied by templates.
These advantages allow flexible configuration of any Cisco Unified Communications Manager Express features in a scalable way, since only those phones and directory numbers that require additional features (or individual settings) have to be manually preconfigured.
2-90
Phone Provisioning Options

The table summarizes the phone provisioning options and shows the relevant configuration
parts.
Phone Provisioning Options

gpftone and
Ephone-dri ephone 1
mac-address. Cisco IOS
Ephoneand *f
ephone 1
mac-address...
Ephone.dr, and Complete5RST SRST Provisioning Provisioning

ephone-dn 6
number 3001
type 7960
button 1:6
telephory-sarmce
srst mode auto-
Configuration
type 7960 (no button...)

telephony- service
lelephony-seryice
srst mode auto-
ephone-dn 6
number 3001
provision. Phone directory

number
auto assign..
United CME"
provieion...
United CME*
Resulting
Directory Number
Existing
United CME'
ephone-dn
configuration
referenced by
automatic
Configuration
con fig u rat ion
assignment
ephone-dn configuration of matching phone directory number

united CME'
configuration
plus Unified CME'

SRST ephone-dn template (If used)
United CME*
Resulting Phone Configuration
Existing
United CME*
Existing
united CME'
configuration
ccrifiguration
ephone template (ft ephone template (if used) used)
-Urified CME = Cisco Unified Communications Manager Express
As shown in the table, if an ephone and ephone-dn are configured in Cisco Unified Communications Manager Express, a phone that registers with the configured MAC address will get the complete configuration (phone and director;' number) appliedas configured in Cisco Unified Communications Manager Express. Cisco Unilied Communications Manager Express does not use SNAP at all to configure the phone.
If an ephone is configured butis notassociated with an ephone-dn, automatic assignment hasto be enabled. Otherwise, the phone will not have a line and cannotplace or receive calls. The
ephone-dn configuration is determined based on the arguments of theauto-assign command.

SNAP is not used (for learning phone settings or director,' number configuration parameters).
If only ephone-dns are configured, the ephone configuration is learned by SNAP, while the ephone-dn configuration that is configured in Cisco Unified Communications Manager Express is used instead of the phone directory number configuration that is provided by SNAP. Ephone templates (if configured) areapplied to the learned ephone configuration.
If neitheran ephone (MAC address) nor a directory numberexists for the registering phone. Cisco Unified Communications Manager Express will learneverything(ephone and ephonc-dn configuration) from SNAP. Ephone and ephone-dn templates are applied, if configured.
i 2010 Cisco Syslems. Inc
Note
This combination is not very common because it combines the need for specific phone configuration parameters with the dynamic assignment of directory numbers.
Manually configured ephone-dn: An ephone-dn is not associated with an ephone. The reason to configure the ephone-dn but not the ephone is that only individual ephone-dn configuration is required, but default settings or a single template can be used for the ephone (uhich is added once the phone is registered).
No manual configuration: In this case, the ephone-dn and the ephone are learned by SNAP. You can apply configuration settings that are not supported by SNAP to such newly added phones and directory numbers by configuring the appropriate templates.
2-88
Configuration of Cisco Unified Communications Manager Express in SRST Mode

This topic describes how to configure Cisco Unified Communications Manager Express in
SRST mode.
Cisco Unified Communications Manager Express SRST Configuration Overview

An SRST reference configured in Cisco Unified Communications Manager can be a Cisco Unified Communications Manager Express router.
Phone configuration is not required for Cisco Unified Communications Manager Express in SRST mode. * Any combination of the following can be used: - Manually configured ephone with associated ephone-dn Manually configured ephone with no associated ephonedn. and automatic assignment enabled
- Manually configured ephone-dn (not associated with an

ephone)
- No manual configuration
If configured,ephone and ephone-dn templates are applied

to leamed ephones and ephone-dns
An SRST reference in Cisco Unified Communications Manager can be a standard Cisco
Unified SRSTgateway or a Cisco Unified Communications Manager Express router. Unlike the standalone Cisco Unified Communications Manager Express, when you are configuring Cisco Unified Communications ManagerExpress in SRST mode, no phones have to be
configured, since they can be learned by Simple Network-Enabled Auto Provision (SNAP).
Houc\ cr. Cisco Unified Communications Manager Express in SRST mode allows an>
combination of these configurations:
Manually configured ephone with associated cphone-dn: In thiscase, thephone is completely configured: both the ephone and anephone-dn, which is associated with the ephone. exist, fhis configuration isused for phones that require additional configuration settings that cannot be learned from the phone via SNAP. These settings should be applied only tothis phone (or to few phones); an ephone template orephone-dn template cann.il be
used, because these templates apply to all learned phonesor directory numbers.
Manually configured ephone with no associated ephone-dn: This configuration is useful ifspecific phone configuration parameters are required (parameters that cannot be assigned from a template) but no specific directory number isrequired. Ifan ephone ispreconfigured
in Cisco UnifiedCommunications Manager Express and it is not associated with a
directory number, thedirectory number is notlearned viaSNAP. Therefore, the phone will not have a directory number unless automatic assignment (which is equivalent to
autoresistralion in Cisco Unified Communications Manager) is enabled.
)2010Cisco Systems, Inc.
2-87
Additional Music on Hold SourcesConfiguration Example

The figure shows an example of a router that is configured with a default MOH audio source and two additional MOH audio sources for different departments.
Additional Music on Hold Sources-
Configuration Example
voice moh-group 1
moh Elashimohl.au
description HOH: customer services multicast moh 239.1.1.1 port 16381 extension-range 1000 Co 1099
extension-range 1300 to 1399
I
voice moh-group 2
moh flashimoh2.au
description HOB: marketing multicast moh 239.1.1.2 port 16384 extension-range 3000 to 3099
I
telephony - service
moh-file-buffer 5000 moh flashidefault.wav
multicast moh 239.1.1.3 port 163 64
For each department, an MOH group is configured. Within each group, the location of the MOH audio file and the extensions that should utilize the group have to be configured. In addition, an optional description can be configured and multicast MOH can be enabled for each MOH group. You configure RAM caching under call-manager-fallback (in the case of Cisco Unified SRST) or under telephony-service (in the case of Cisco Unified Communications Manager Express). You use the moh-file-buffer size-in-kb command for this configuration, and it specifies the maximum size of the MOH RAM cache, 'fhe configured limit applies to each audio source file. You cannot enable or disable audio source caching on a per-file basis. The total amount that is used for audio source caching, therefore, dependson the numberof configured MOI 1groups. If all five possible MOH groups and a default audio source are configured, the file buffer size that is allocated will be six times the specifiedamount. Ifa configured audiosource file is larger
than the configured moh-file-buffer, it will not be cached but will be read from flash instead.
Note
You can use the show flash command to see the size of the MOH files.
2-86
>201u Cisco Systems, Inc.
Additional MOH Sources

Cisco Unified Communications Manager Express Version 8 introduces the capability of configuring up to five MOH sources in addition to the default MOH source.
Additional Music on Hold Sources

Up to five additional MOH sources can be configured.
- Used oniy by SCCP phones that put call on hold.

- RAM caching of MOH file can be enabled.
Less CPU utilization because of reduced flash reads
Higher memory consumption
Supported by Cisco Unified Communications Manager Express,

Cisco Unified Communications Manager Express in SRST mode,
and Cisco Unrfied SRST.
Supported on Cisco Unified Communications 500 series and Cisco

1800, 2800. 2900. 3800, and 3900 Series Routers,
Only au or .wavfiles in G 711 8-bit mono format are supported.

Minimum size 100 Kb.
Default flash dnve should be used to store MOH files.
Configuration is based on MOH groups.
Phones not configured to use one of these groups use the default
MOH source.
These additional MOH sources can be utilized by SCCP phones that put calls on hold. Any
other entities thai putcallson hold (such as basicautomatic calldistribution [B-ACD] or SIP phones) will use the default MOH source. If live audio feed is used, it can beconfigured only
as the default MOH source.
Cisco Unified Communications Manager Express can be configured to cache files in RAM.
This configuration reduces CPU utilization because flash reads areessentially eliminated after
the audio fileshave been loadedto RAM. However, cachingaudio files in RAM can drastically
increase memory consumption. Memory requirements depend onthenumber of MOI I files and
their size (there is no limitation on the maximum size of an audio file).
Multiple MOH sources arc supported by Cisco Unified Communications Manager Express.
Cisco Unified Communications Manager Express in SRSTmode, and Cisco Unified SRST.
Multiple MOH sources arc supported onthese platforms: Cisco Unified Communications 500
Series and Cisco 1800. 2800. 2900, 3800. and 3900 Series Integrated Services Routers.
The audio files have to be .au or .wav files in G.711 8-bit mono format, and their minimum size
is 100 kb. Ifmultiple flash devices are present inthe router, the default flash drive should be
utilized.
The configuration of multiple MOH sources isbased on MOH groups. Endpoints that do not
source.
support MOH groups orthat are not configured to use an MOH group will use the default MOH
Note The MOH source is selected based on the configuration of the holder (thatis, the phonethat puts the call on hold).
2-85
Cisco Unified Communications Manager Express: MOH

MOH is an audio stream that isplayed to PSTN and VoIP callers who are placed on hold by
phones in aCisco Unified Communications Manager Express system. This audio stream is
intended to reassure callers that they are stillconnected to theircalls.
Default Music on Hold Source

The default MOH source is
enabled by the moh command under telephony service.

For multicast MOH, add the
multicast moh command. Cisco Unified Communications
Manager Express supports only

G.711 for MOH.
Transcoders are required to allow

G.729 to be used for MOH.
telephony-service
moh moh-file.au
multicast moh
239.1.1.1 port 16384
When thephone thatis receiving MOH is part of a system thatuses a G.729 codec, transcoding is required between G.711 and G.729. TheG.711 MOH must betranslated to G.729. Note that, because of compression. MOH that is using G.729 is of significantly lower fidelity than MOII
that is using G.711.
If the MOH audio stream is also identified as a multicast source, the Cisco Unified
Communications ManagerExpress router additionally transmits the streamon the physical IP

interfaces of the Cisco Unified Communications Manager Express router that you specify
during configuration. This transmission permitsexternal devices lo have accessto the router.
Certain IP phones do notsupport IP multicast and, therefore, do notsupport multicast MOI I.

You can disable multicast MOII to individual phones that do not support multicast. Callers hear a repeating tone when they are placed on hold.
In Cisco Unified Communicalions Manager Express, the MOH feature is supported when a call
is put on hold from a SIP phone and when the user of a SIP phone is put on hold by a SIP, SCCP. or plain old telephone service (POTS) endpoint. The holder (the party who pressed the Hold key) or holdee (the party who is put on hold) can be on the same Cisco Unified
Communications Manager Express group or on a different Cisco Unified Communications Manager Express group that is connected through a SIP trunk. MOH is also supported for Call Transfer and conferencing, with or without a transcoding device.
Configuring MOH for SIP phones is the same as configuring MOH for SCCP phones.
2-84
Implemenling Cisco Unified Communications Manager, Pan 2 (CIPT2) v8.0
Providing Phone Loads

You can configure Cisco Unified Communications Manager Express to provide specific phone
loads to IP phones for each type of phone.
Providing Phone Loads

Cisco Unified IP Phones 7945 and 7S65witti SCCP
Copy phone load

files to flash.
Make them
Firmware v9.0(2)SR1
accessible by TFTP.
Specify the phone load to be used per phone type under telephony service.
If no phone load is specified, the current phone load of the phone is used.
tftp-aerver flash; apps4S.9-Q-2ES2.sbn
tftp-server flash; cnu 4 5.9 - 0 - 2 ES2.sbn tftp-server flash; cmv45sccp.9-0-2ES2.sbn tftp-server flash: dsp45.9-0-2ES2.sbn tftp-server flash: jar45sccp.9-0-2BS2.sbn tftp-server flash: SCCP4 5.9-0-2SR1S.loads tftp-server flash: term45.default.loads tftp-aerver flash: termS5.default.loads
I
telephony-service
load 7965 load 7945 SCCP45. 9-0-2SR1S SCCP45. 9-0-2SR1S
Cisco Unified Communications Manager Express must be configured so that IP phone firmware files are available through the TFTP server. The command tftp-server flash: filename allows the specified tile that resides in fiash memory to be downloaded via TFTP.
The figure shows an example with finnuare files that support Cisco Unified IP Phone 7945 and
7965 with SCCP finnuare version 9.0(2)SR1).
Note You can view a list of IP phone models that are supported by the Cisco Unified
Communications Manager Express router by entering the load ? command in telephonyservice configuration mode
Tip
Firmware filenames are case-sensitive.
Cisco Unified Communications Manager Express: Basic Configuration Example

The figure shows an example of a basic Cisco Unified Communications Manager Express configuration.
Cisco Unified Communications Manager Express: Basic Configuration Example

telephony-service max-e phone s 5
max-dn 10
lp source-address 10.1.250.102 port 2000

create cnf-files
I
Manager Express
6
7
number 3001
ephone-dn
ephone-dn
1
number 3002
ephone
3
0012.0154.5D98
mac-address
type 7 96 0
button 1:6
ephone
4
0007.0E5 7.6F43
mac-address
type 7961
button
1
1:7
dlalplan-pattern 3 5215553... extension-length 4
The exampleshows a Cisco Unified Communications ManagerExpress configuration of two ephonesone ephone withdirectory number3001 and one ephone withdirectorynumber 3002. The four-digit extensions are expanded to a 10-digit E.164 PSTN address (521 5553xxx).
2-82
Implementing CiscoUnrfied Communicalions Manager, Part 2 (CIPT2) v8.0
number: Use this command lo define a directory number for an ephone-dn (extension),
which then can be assigned to an IP phone.
ephone: Use thiscommand in global configuration mode to create a phone in Cisco

Unified Communications Manager Express.
mac-address: Use this command in ephone configuration mode to specify the device ID of an ephone. When a phone registers with Cisco Unified Communications ManagerExpress, it has to providea device ID (which is based on the MAC addressof the phone) that is configured in Cisco Unified Communications ManagerExpress.
type: Use this command in ephone configuration mode lo specify the phone type of this
ephone.
button: Use this command in ephone configuration mode to assign one or moreephor>
dnsto an ephone.
dialpian-pattem: Use thiscommand in telephony-serv ice configuration mode to map

E. 164 PSTN numbers to internal extension numbers.
2-81
General Configuration of Cisco Unified Communications Manager Express

This topic describes general Cisco Unified Communications Manager Express coniiguration
parameters and their functions.
Basic Cisco Unified Communications
Manager Express Commands

telephony-service: Enters Cisco Unified Communications Manager
Express configuration mode
- max-ephones: Defines maximum number of IP phones - max-dn: Defines maximum number of directory numbers - ip source-address: IP address used by Cisco Unified
Communications Manager Express
- create cnf-files: Generates XML configuration files for phones ephone-dn: Enters ephone-dn configuration mode
- number: Sets the extension of the ephone-dn ephone: Entersephoneconfiguration mode - mac-address: Specifies the MAC address of the IP phone
- type: Sets the IP phone model type

- button: Applies an ephone-dn to an IP phone line
dialplan-pattern: Maps E.164 numbers to extensions
To deploj a Cisco Unified Communications Manager Express system, youmust configure

these commands:'
telephony-service: Usethis command to enter the telephony-service configuration mode, where you can configure the global settings of Cisco Unified Communications Manager
Express
max-ephones: Usethis command in telephony-service configuration mode to configure Cisco Unified Communications Manager Express with the maximum number of ephones.
max-dn: Usethis command in telephony-service configuration mode to configure the maximum numberof extension numbers (ephone-dns) in Cisco Unified Communications
Manager Express.
Note
The default values of max-ephones and max-dn are 0. These defaults have to be modified
inorder foryouto configure ephones and ephone-dns. The maximum numberof supported ephones and ephone-dns is version-specific and platform-specific. The number that is
displayed in Cisco IPS Software Help files does not always reflect the actual limit.
ip source-address: Usethis command in telephony-service configuration mode to define the IP address to which Cisco Unified Communications Manager Express is bound.
create cnf-files: Use this command intelephony-service configuration mode to generate

XML configuration files for phones.
2-80
ephone-dn: Use this command, a global configuration command, to create a directory number. After you enter this command, the router is inephone-dn subconfiguration mode.
Important Cisco Unified Communications Manager Express

Features
Cisco Unilied Communications Manager Express also includes features that are like legacy low-end PBXand key system features, creatinga cost-effective, highly reliable, feature-rich
communications solution for the small office.
Important Cisco Unified Communications Manager Express Features

Call Transfer, call transfer blocking, paging, intercom, call
coverage
Call Park, park call recall, dedicated park slot per extension,
MOH, multicast MOH
Hunt groups, basic automatic call distribution (B-ACD) Ad-hoc conferencing, retain conference call when conference
initiator drops
Night bell, night service call forwarding

Extension mobility, presence
New in Cisco Unified Communications Manager Express 8.0:

Five additional MOH sources
Support for E. 164 numbers and + prefixes - Enhancement of dialplan pattern command (new demote
argument)
- Voice translation profiles enhancement (new callback

number)
Ihe figure lists important features of Cisco Unified Communications Manager Express.
fhese new features are introduced with Cisco Unified Communications Manager Express
Version 8.0:
Kive additional music on hold (MOH) sources: SkinnyClient Control Protocol (SCCP)
phones can beconfigured to use oneof five additional MOII source files thatarc
configured by MOH groups.
Support for fc.164 numbers and + prefixes: IP phones can use E.164 format with a +
prefix for their directory numbers. Enhancement of the dialplan pattern command: You can use the dialplan pattern command to allow internal devices to call each other by an internally used shorter number
that is derived from a longer directory number of the phone {typically in E.164 format with
+ prefix).
Enhancement of voice translation profiles: Whena cal! is sent to an IP phone,an
additional number (that is. a callback number) is sent to thephone. The phone shows the
calling-party number on its display but uses the callback number for callbacks from call
lists.
2-79

Features
This topic describes Cisco Unified Communications Manager Express versions, their protocol support and features, and the required Cisco IOS Software releases.
Manager Express Features

Delivers capabilities to the small office that were previously available only to larger enterprises
Reduces the total cost of ownership by delivering voice, video, and

data over a consolidated infrastructure
Runs on Cisco IOS Software; protects customer investment Supports converged applications
Administered by GUI or CLI
Manager Express
Cisco Unified Communications Manager Express delivers to the small or medium-sized
business the capabilities that were previously available only to largerenterprises. Cisco Unified Communications ManagerExpressintegrates with voice-mail systemssuch as Cisco Unity, Cisco Unity Connection, Cisco Unity Express, and third-party voice-mail systems. GUI and command-line interface (CLI) are available for administering Cisco Unified
Communications Manager Express.
2-78
In summary, use Cisco Unified Communications Managerwhen Cisco Unified Communications Manager Express does not scale to the number of endpoints or does not
provide all therequired features. If youuse Cisco Unified Communications Manager and the
standard Cisco Unified SRST features do not meet the requirements for backup scenarios, you should use Cisco Unified Communications Manager Express in SRST mode.
2010 Cisco Systems Inc.
2-77
Standalone Unified CME* vs. Unified CM*
and Unified CME in SRST Mode (Cont)

Standalone Cisco Unified Communications Manager Express:
Small and medium sites (up to 450phones per Cisco Unified Communications Manager Express). Trunks used to interconnect multiple systems provide fewer features.
Cisco Unified Communications Manager with Cisco Unified
Communications Manager Express in SRST mode for backup:

Medium and large deployments (up to 30,000 phones per Cisco Unified Communications Managerclusler).
* No limits of features withn a cluster; larger number of phones have access

to all features.
Cisco Unitied Communications Manager Express in SRST mode used only

as backup for remote sites with centralized cal processing.
More features in SRST mode than standard Cisco Unified SRST.
"Unified CME = Cisco Unified Co mmuneat ions Manager Express '"Unified CM = Cisco Unified Communications Manager
The Cisco Unified Communications Manager call-processing solution offers feature-rich telephony services to medium or largeenterprises. Cisco Unified Communications Manager Express can serve small deployments on its own or is used as a backup for a centralized callprocessing Cisco Unified Communications Manager deployment (Cisco Unified Communications Manager Express in SRST mode). The Cisco Unified Communications Manager Express solution is based on the Cisco access router and Cisco IOS Software. Cisco Unified Communications Manager Express is simple to deploy and manage, especially for customers who already use Cisco IOSSoftware products. This simplicity allows customers to take advantage of the benefits of IP communication without the higher costs and complexity of deploying a server-based solution. However, the number of supported phones is relatively lowand depends heavilyon the routerplatform. It ranges from 15 phones at the Cisco 1861 routermodelto as many as 450 on the Cisco 3945E Integrated
Services Router model. Refer to http://www.cisco.com/en/US/prod/collatcral/voicesw/ps6788/ vca!lcon/ps4625/dataj>heet_c78-567246.html for detailedcapacity information per router
platform.
Although multiple Cisco Unified Communications Manager Express systems canbe

interconnected using trunks, the features that are supported across trunks arc limited.
Cisco Unified Communications Manager Express cannot beused if certain features arerequired
to operate across multiple sites. These features include Cisco Unified Communications
Manager Fxtension Mobility and Device Mobility, locations-based Call Admission Control
{CAC) (including Resource Reservation Protocol [RSVPJ-enabled locations), call hunting, Call
Pickup, presence, and many others. In this case, or simplybecauseof the size of the deployment Cisco Unified Communications Manageris the better choice.
Cisco Unified Communications Manager iscommonly used ascentralized call processing for
somesites. In such an environment, IP phonesregister to a Cisco UnifiedCommunications
Manager across the IP WAN. Inthis case. Cisco Unified Communications Manager Express in SRST mode is a better choice than standard Cisco Unified SRST functionality, because Cisco
Unified Communications Manager Express in SRST mode offers more features than standard
Cisco Unified SRST.
2-76
Because of the centralized architecture of Cisco Unified Communications Manager, remote site
survivability isextremely important. As discussed earlier. Cisco Unified SRST can be used to
provide survivability. However, it is quite limited in terms of telephony features.
To provide a richer feature that issetto IPphones that are in fallback mode, you can use Cisco
Unified Communications Manager Express in SRST mode. Such a deployment combines the
advantages ofCisco Unified Communications Managercentralized configuration and the availability offeatures to all phones, with the better feature support dial isprovided by Cisco
Unified Communications Manager Express versus standard Cisco Unified SRST in casethe site
is disconnected from the centralized Cisco Unilied Communications Manager cluster.
2-75
When to Use Cisco Unified Communications Manager Express

in SRST Mode
To choose between the standalone Cisco Unified Communications Manager Express and Cisco Unified Communications Manager Express in SRST mode, means to choose between the features of Cisco Unified Communications Manager Express and the features of Cisco Unified Communications Manager.
Standalone Unified CME* vs. Unified CM* and Unified CME in SRST Mode
Unilied CM with Unified CME for SRST
Feature
Standalone Cisco'
Unified
Normal Operation SRST Mode (United
Communications
(Unified CM)
Medium to large
Yes
Yes
CME foi SRST)

Multiple smal lo
medium sites
No No
Manager Express
Smal No
Enterprise size
Clustering
Centralized call processfig
Only within local site
All features
Features
AI features
supported by Unite
CM*
supported fay Unified si

CME*
Features are
CME'
Features are
Feature limitations
None
available only within available only within

local site local site
Unified CME = Cisco Unified Communications Manager Express "Unrfied CM = Cisco Unified Communications Manager
The server-based Cisco Unified Communications Manager telephony solutionprovides scalability for largeenterprises. Cisco Unified Communications Manager servers can be groupedin a cluster to provide fault-tolerant telephony for up to 30,000IP phones. Customers can make use of extensive server-based application programming interfaces (APIs) with Cisco
Unified Communications Manager.
Cisco Unified Communications Manageris a centralized architecture, which allowsendpoint call controlonly from serverswithin a cluster.Cisco Unified Communicalions Manager Express is a distributed architecture where eachCiscoUnified Communications Manager Express router provides call processing to an individual small site or a group of small sites.
Cisco Unified Communications Manager offers a greater choice of voice codecs and video
product selection. Cisco Unified Communications Manager Express doesnot support all Cisco
Unified Communications Manager features.
2-74
Cisco Unified Communications Manager Express in SRST

Mode
SRSTfallback supportusing Cisco Unified Communications ManagerExpress is a leaturethat enablesrouters to providecall-processing support for Cisco Unified IP phones if they lose connection to remote primary, secondary-, or tertiary Cisco Unified Communications Manager
installations or if the WAN connection is down.
Manager Express in SRST Mode

Cisco Unified Communications Manager Express in SRST mode
is used only as a backup for Cisco Unified Communications Manager. In case of WAN failure;
Cisco Unified Communications Manager Express provides Cisco CallManager service to IP phones at the remote site,
Cisco Unified Communications Manager Express controls voice gateway
functions of trie Cisco IOS router at the remote site.
Cisco
Unity
When Cisco Unified SRST functionality is provided by Cisco Unilied Communications
Manager Express, provisioning of phones isautomatic and most Cisco Unified Communications Manager Express features arcavailable to the phones during periodr of
fallback. The benefit is that Cisco Unified Communications Manager users will gain access to
more features during fallback withoutany additional licensing costs.
2-73

Overview
This topic describes Cisco Unified Communications Manager Express and the modes in which
it can be used.
Standalone Cisco Unified
Communications Manager Express

Standalone Cisco Unified Communications Manager Express
operates independently:
Remote site IP phones register with Cisco Unified Communications Manager
Express.
Remote site IP phones send signaling messages to Cisco Unified Communications Manager Express,
Calls between main site cluster and remote site use standard PSTN
connections or VoIP trunks.
H 323 or SIP Trunk Connection
Regislrafoon
and Signaling,' J
Manager
The figure shows a deployment of a Cisco Unified Communications Manager Express router
with several phones and devices that are connected to it. The Cisco Unified Communications
Manager Express router is connected to thepublic switched telephone network (PSTN) and
WAN.
Cisco Unified Communications Manager Express is a feature-rich, entry-level IPtelephonysolution that is integrated directly into Cisco IOS Software. Cisco Unified Communications
Manager Express allows small-business customers and autonomous small-enterprise branch offices to deploy voice, data, andIP telephony on a single platform for smalloffices, which
streamlines operations and reduces network costs.
Cisco UnifiedCommunications ManagerExpress is ideal for customers who have data connectivity requirements and need a telephony solution in the same office. Whether offered
through a managed serv ices offering of a service provider or purchased directly by a corporation. Cisco Unified Communications Manager Express provides mostof the core telephony features thatarerequired in a small office. It also provides many advanced features
that are not available with traditional telephony solutions. Being able todeliver IP telephony
and data routing using a single, converged solution allows customers to optimize their
operations and maintenance costs, resultingin a very cost-effective solution that meetsoffice
needs.
ACisco Unified Communications Manager Express system isextremely flexible because it is modular. It comprises a router thatserves asa PSTN gateway and supports oneor more
VLANs that connectIP phones and phone devices,as well as PCs,to the router.
2-72
>2010Cisco Systems, Inc
Lesson 3
Implementing Cisco Unified

Express in SRST Mode

Overview
This lesson begins with a description of key Cisco Unified Communications Manager Express
features, benefits, and limitations. It also explains the processof registering IP phoneswith Cisco Unified Communications Manager Express, fhis lesson discusses the basic telephonv sen.ice commands for configuring ephones and ephone-dns.
Objectives
Upon completing this lesson, you will be able to configure Cisco Unified Communications Manager Express to provide telephony services lo IP phones ifthe connection to the centralized
call agent islost. This ability includes being able tomeet these objectives:
Describe Cisco Unified Communications Manager Express and the modes in which it can
be used
Describe Cisco Unified Communications Manager Express versions, their protocol support, their features, and the required Cisco IOS Software releases
Describe general Cisco Unified Communications Manager Express configuration

parameters and their functions Describe how to configure Cisco Unified Communications Manager Express to support
SRSI fallback
Summary
Summary
A simplified Cisco Unified SRST dial plan has to be
implemented on the remote site gateways to ensure

connectivity for remote sites in SRST mode.
SRST reference is assigned via device pool membership. Basic Cisco IOS gateway SRST configuration requires only
six configuration steps.
Cisco IOS gateway MGCPfallback configuration requires

only two configuration steps. CFUR forwards calls made to unregistered directory numbers
to the defined destination.
ISDN overlap dialing has to be enabled in countries with open numbering plans.
References
Cisco Systems. Inc. Cisco Unified Communications Manager Administration Guide

Release 8.0(1), February 2010.
hftp://vvA\w.CMscii.coni/cn/lJS/does/voiee_ip_comm/cucin/admin/8_0_i/ecmefg,'lKem-80Icm.html
Cisco Systems. Inc. Number Translation Using Voice Translation Profiles, February 2006. http://\vw u.cisco.com,'en/US/teclL/tk652/lk90/teehnoloaies configuration e\ample()9186a0
0803f818a.shtmi
Cisco Systems. Inc. Voice Translation Rules, November 2006.
http://ww\v.cisco.com/cn/[i.S/tcch/tk652/tk90/techiK)logies_tech_note09186a008()325e8e.s
html
2-70
Cisco Unified SRST Dial Plan Example (Cont)
dial-peer voice
1 pots

corlist outgoing intl destination-pattern 9011T port 1/0:23
prefix Oil
I
incoming called-number
direct-inard-dial
]

port 1/3:33
1
dial-peer voice 2000 pots translation-profile outgoing to-HQ

9 pots
[
dial-peer voice
destination-pattern 2...
corlist outgoing local-ntl destination-pattern 9 port 1/0:23 prefix Oil

1
port 1/0:23
rule 1 /*2/ /151155S2/

1
dial-peer voice 91 pota corlist outgoing local-ntl destination-pattern 91 port 1/0:23
voice translation-profile to-HQ

translate called 1
Outgoing COR lists are applied to the outbound dial peers. Note that all dial peers that should
be available to all phones (that is. dial peer 911 for emergency and dial peer 2000 for intersite
calls) are nol configured with an outgoingCOR list.
Local and national PSI'N destinations areprotected by outgoing COR listlocal-ntl. This COR
has one member, pstn-local-ntl. and this member islisted only in the incoming COR list of
Phonc2. not in the incoming COR listof Phone3. Dial peer 9011, which is used for
international calls, is configured with an outgoing COR list intl, and the only member ofthai list, pstn-intl. is not included in the incoming COR lists ofPhone2 and Phone3.
One dial peer is configured with ihe incoming ealled-numbcr . command, "fhis dial peer is used as an incoming POTS dial peer, fhe dial peer isconfigured tosupport direct inward
dialing.
The called numbers of inbound PSTN calls (521 555-3xxx) are mapped to four-digit extensions because ofthe dialplan-pattern command that is configured in call-manager-fallback
configuration mode (see earlier in this subtopic). As aresult, incoming PSTN calls are sent to
the four-digit extensions.
Outgoing calls to phones that are located at the main site (calls to 2...) match the destination pattern in dial peer 2000. That dial peer sends calls to port 1/0:23 after performing digit manipulation using the to-HQ voice translation profile, 'fhis profile translates the four-digit calling number to an Il-digit E.164 PSTN number, which means that during SRST fallback,
users can still dial 4-digit extensions to reach the headquarters.
)20:0 Cisco Systems.
2-69
Cisco Unified SRST Dial Plan Example

(Cont.)
application
global
service a l t e r n a t e defa u l t
dial-pe
mentoet
sr
cor
list
local-ntl
pstn- local n t l
dial-pe
call-nanager- fallback
ip source-address 10.1 .250.101 port 2000 man-ephonss 3
mai-dn 3 member
cor
list intl
pstn- i n t l
dial-peer cor
member
list
phone 2
pfltn- local n t l
cor incoming phone! 2

cor incoming phone3 3 dialplan-pattern 1 extension-length \ disl-peer cor custom
name no-pstn
3002
3003
dial-peer cor l i s t phone 3

member
no-pstn
5215553.,.
name pstn-local-ntl name pstn-intl
Thefigure shows the first part of the SRST configuration. Itincludes a dialplan-pattern command (configured in call-manager-fallback configuration mode) thatmaps the internal
four-digit directory numbers to the E.164 PSTN number.
Based on the scenario, one phone (Phonel) should have unlimited access. No incoming COR
list is required at that phone because, in the absence of an incoming CORlist, all outbound dial peers are available regardless of a configured outgoing COR listat theoutbound dial peer.
The other two phpnes should have difTerent classes; therefore, anincoming COR listis
configured for each of them (COR lists Phone2 and Phone3). Phone3 should not be allowed to dial the PSTN at all (exceptfor emergency calls to 911), while Phone2 should not be allowedto
dial international PSTN destinations.
The dial peer that will be used for emergency calls will not be configured with an outgoing
COR list, and hence will beavailable to all callers. Thesame principle applies to all internal directory numbers. Because they are not configured with anoutgoing COR list, they all are reachable by everyone. The dial peer for international calls will be protected with outgoing COR list intl. The member ofthis outgoing COR list (pstn-intl) isnot listed in the incoming COR list ofeither Phone2 or Phone3. This way, neither ofthese phones can place international calls. Asmentioned earlier. Phonel does nothave an incoming COR list, and therefore, the outgoing COR list at the international dial peer isignored for calls from Phone 1, Finally, all other PSTN dial peers (local and national calls) are protected with outgoing COR list local-ntl. The incoming COR list ofPhone2 includes the member ofoutgoing COR list local-ntl (pstnlocal-ntl) and therefore can dial local and national PSTN destinations but is not able to dial
internationally. The incoming COR list ofPhone3 includes a member that iscalled no-pstn that isnot listed in any outgoing COR list. Ilence, this incoming COR list does not provide access
to any protected pattern. Its only use is to change from the default behaviorthat in the absence
ofan incoming COR list all outgoing COR lists are ignored and hence all outbound dial peers
are available. You could also configure COR list Phone3 with no member, and itwould have the same effect. Ilow ever, it isrecommended that you always include at least one member ner
COR list.
2-68

The figure shows an example ofa standalone dial plan configuration for a Cisco IOS router that
is enabled with Cisco Unified SRST.

Requirements for external calls during SRST mode:
Phonel (3001) should have unlimited access.
Phone2 (3002) should not be allowedto place international calls.
Phone3 (3003) should be allowed to dial only headquartersphones

(2 .) and emergency (911)
Mam Site Remote Site
Phonel
Manager
Phone2
Phone3
The example shows a headquarters site with a PSI'N number of511 555-2xxx, and a remote
site witha PSTN number of 521 555-3xxx. four digits are used for internal calls(including
calls between the main site and remote site).
There are three phones atthe remote site. During SRS'f fallback. Phonel (using directory number 3001) should have unlimited access. Phone2 (directory number 3002) should not be allowed toplace international calls, and Phonc3 (directory number 3003) should be allowed to
place only internal calls. Four-digit dialing to the headquarters should work: the calls should be
sent to the main site over the PSTN.
) 20'0 Cisco Systems, Inc
2-67
Combinations of COR Lists and Results

COR List on COR List on
Result
Incoming Dial Peer

No COR No COR
Outgoing Dial Peer

No COR COR list that is
Call will succeed.
Call will succeed. By default, the incoming dial peer
applied for outgoing

calls
has the highest COR priority when no COR is applied. Ifyou apply no COR for an incoming call leg to a dial peer, the dial peer can make a call out of any other dial peer, regardless of the COR configuration on the outgoing dial peer. Call will succeed By default, the outgoing dial peer has the lowest priority. Because there are some COR configurations for incoming calls on the incoming or originating dial peer, it is a superset of the outgoing-call COR configuration for the
outgoing or terminating dial peer.
COR list that is applied for incoming calls
No COR

(superset of COR list
COR list that Is
that is applied for outgoing calls on the

outgoing dial peer)
applied for outgoing calls (subsets of COR list that is applied for incoming calls on the incoming dial peer)
COR list that is
Call will succeed. The COR list for incoming calls on the incoming dial peer is a superset of the COR list for outgoing calls on the outgoing dial peer

(subset of COR list that is applied for
Call will not succeed. The COR list for incoming

calls on the incoming dial peer is not a superset of
applied for outgoing calls (supersets of

COR list that is
the COR list for outgoing calls on the outgoing dial

peer.
outgoing calls on the

outgoing dial peer)
applied for incoming calls on the incoming dial peer)
2-66
Cisco Unified SRST Dial Plan Commands: COR

You can assign calling privileges to IP phones when they are in SRS'f mode by using COR
commands.
Cisco Unified SRST Dial Plan Commands: Class of Restriction
router(config-cm-fallback)#
cor {incoming I outgoing} cor-list-name [cor-list-number

starting-number - ending-number | default]
Configures a COR on dial peers associated with directory

numbers (ephone-dn)
The command cor configures a COR ondial peers that are associated with directory numbers.
The keyword, incoming specifies that the COR list is tobe used by incoming dial peers. The keyword outgoing specifies that the COR list is tobe used by outgoing dial pers.
The parameter cor-list-name is the COR list name.
The parameter cor-list-number is a COR list identifier. The maximum number ofCOR lists
thatcan be created is 20.and the listsconsist of incoming or outgoing dial peers. The first
six COR lists are applied to a range ofdirectory numbers, 'fhedirectory numbers that do not ha\e a COR configuration arc assigned lo the default COR list, as long asa default
COR list has been defined.
The parameters starting-number - ending-number define the director- number rangefor

example. 2000 to 2025.
fhe ke\ word default instructs the routerto use an existingdefault COR list.
fhe complete configuration ofCOR is discussed in the Implementing Cisco Voice

Communications and QoS (CVOICF) course. The table presents an overview only.
Centralized CalI-Processing RedundancyImplementation
2-65
Cisco Unified SRST Dial Plan Commands: Number Modification
(Profile Activation)
Voice translation profiles can be bound to dial peers, source groups, trunk groups, voice ports,
and the voice service POTS.
SRST Dial Plan Commands: Number
Modification (Profile Activation)
router(config-volcaport)#
translation-profile {incoming | outgoing} name * Assigns a translation profile to a voice port

router(config-cm-fallback>#
I translation-profile {incoming | outgoing} name

' Assigns a translation profile to the call-manager-fallback
Cisco IOS service
In this example, the voice translation profile is bound to a voice port.
To assign a translation profileto a voice port, you use the translation-profile command in
voice-port configuration mode.
The keyword incoming specifies that this translation profileprocessesincoming calls. The keywordoutgoing specifies that this translation profileprocessesoutgoingcalls. The parameter name is the name of the translation profile.
The voice translation profiles can also be bound to call-manager-fallback Cisco IOS service.
The structure of the command is identical.
Note
The incoming direction ofthe voice translation profile that is boundto the CiscoCallManager
fallback Cisco IOS service processes the calls comingfrom IP phones that are registered
with the router.
For more information about voice translation profiles, refer to Cisco TechNotes Number Translation Using I oice Translation Profilesat
http:/^vww,cisco.coni/en/[;S/tech/tk652/tk90/technologies^ci)nfiguration_examplc()9l86a()08().5
fS18a.shtml and TechNotes Voice Translation Rules at
http://wwu.cisco.com/en/L;S/tech/tk652/lk90/iechnologies_tech..nole09186a0080325e8c.shlm!.
2-64
(Voice Translation Rules)

In voice translation rules, sets of number modification rules are defined.
SRST Diaf Plan Commands: Number
Modification (Voice Translation Rules)

router (confi gl #
voice-translation-rule number
Defines a translation rule for voice calls

router(cfq-translation-rulel#
rule precedence /match-pattern/ /replace-pattern/
[type {match-type replace-type} [plan {match-type replacetype}]]

* Defines a translation rule
To define a translation rule for voice calls, use the voice-translalion-rulc command in global configuration mode.
Number: The number that identifies the translation rule. The range is from 1 lo
2147483647.
To define a translation rule, use the rule command in voice translation-rule configuration
mode.
The parameter precedence defines thepriority of the translation rule, fhe range is from I to
15.
The parameter Imatch-patternl is a stream editor (SED) expression thatis used to match incoming call information, fhe slash (/) is a delimiter in thepattern.
pattern in the callinfonnation. Theslash is a delimiter in the pattern.
The parameter Ireplace-patternl isa SED expression that isused toreplace the match The optional construct type match-type replace-type allows for modification ofthe number type ofthe call. Valid values for the match-type argument are these: abbreviated, any,
international, national, network, reserved, subscriber, unknown. Valid values for the
replace-type argument are abbreviated, international, national, network, reserved,

subscriber, unknown.
The optional construct plan match-type replace-type allows for modification ofthe numbering plan of the call. Valid values for the match-type argument are any, data, ermes.
isdn, national, private, resen-ed, telex, unknown. Valid values for the replace-type
argument are data, ermes. isdn. national, private, reserved, telex, unknown.
2-63
(Voice Translation Profiles)

The combination of voice translation profiles and voice translation rules creates a powerful tool for modifying numbers so that they match dial plan needs.
SRST Dial Plan Commands: Number
Modification (Voice Translation Profiles)

router(config)#
I voice-translation-profile name
Defines a translation profile for voice calls
router(cfq-translation-profile)#
translate {called | calling | redirect-called | redirecttarget | callback} translation-rule-number Associates a translation rule with a voice translation profile
To define a translation profile for voice calls, you use the voice-translation-profile command
in global configuration mode.
The parametername definesthe name of the translation profile. The maximum lengthof the
voice translation profile name is 31 alphanumeric characters.
To associate a translation rule with a voice translation profile, you use the translate command in voice translation-profile configuration mode:
called: Associates the translation rule with called numbers
calling: Associates the translation rule with calling numbers

redirect-called: Associates the translation rule with redirected called numbers
redirect-target: Associates the translation rule with transfer-to numbers and callforwarding final destination numbers
callback: Associates the translation rule with the numberto be used by IP phones for
callbacks
Note
While ona call, IPphones display the calling-party number. When callbacks are placed from call lists, the callback number {if present) is utilized for the outbound call, and notthe callingparty number that was shown while the call was active.
translation-rule-number: The number of the translation rule to use for the call translation. The valid range is from 1 to 2147483647. There is no default value.
2-62
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) u8.0
The keyword extension-length sets the number of extension digits that will appear as a caller ID followed by the parameter length, which is the numberof extension digits. The extension length must match the setting for IP phones in Cisco Unified Communications
Manager mode, 'fhe range is from I to 32.
The optional keyword evtension-pattern sets the leadingdigit patternof an extension number when the patternis difTerent from the leadingdigits that are defined in the pat.jm variableof the F.164 telephone number, such as when site codesare used. The parameter extension-pattern that follows defines the leading digit patternof the extension number. It comprises one or more digits and wildcard markers or dots (.). For example, 5.. would
include extensions 500 to 599: and 5... would include extensions 5000 to 5999. The
extension pattern configuration should matchthe mappingof internal to external numbers

in Cisco Unified Communications Manager.
Theoptional keyword no-reg prevents the I7..164 numbers in the dial peerfrom registering
with the gatekeeper.
fhe example for the dialplan-pattcrn command shows how lo create a dial plan pattern for directory numbers 500 lo 599that is mapped lo a DID range of 408 555-5000 to 5099. Ifthe
router receives an inbound call to 408 555-5044, then the dial plan pattern command is matched and the extension of the called I7,. 164 number. 408 555-5000, is changed lo directory number
544. If an outbound calling-party extension number (544) matches thedial plan pattern, the
calling-part) extension will beconverted to the appropriate L.I64 number (408 555-5044). The
F..I64 calling-party number will appear as the caller ID:
Router (config)# call-manager-fallback Router(config-cm-fallback)# dialplan-pattern 1 40855550..
extension-length 3 extension-pattern 5..
Since Cisco Unified SRST 8.0.the dialplan-pattcrn command has been used in the opposite
way with the addition of the keyword demote tothe end ofthe command. In this case it demotes IF phone directory numbers thatarespecified in F.I64 format with a + prefix to
shorter extensions, which are to be used internally. Extemal callers place calls to the phones,
using E.164 format with a-f prefix. Ifthe calls are not natively received in this format from the PSTN (which they rarely are), you have to transform the called number accordingly. Internal
users.howe\er. can dial each other by usingshorterextensions, which arc set up by the dialplan-pattern command with the demote argument:
Router(config)# call-manager-fallback Router(config-cm-fallback)# dialplan-pattern 1 +415526....
extension-length 5 demote
In this example, phones are configured with directory numbers+415526.... and have tobe called that way from the outside. Internal users, however, can call each other by using the last
five digits (6....).
Note
Thedialplan pattern command with thedemote argument isalso available in Cisco Unified
Communications Manager Expressand hence can also be used forCisco Unified SRST
when Cisco Unified Communications Manager Express is used in SRST mode.
2-61
Cisco Unified SRST Dial Plan Commands: Open Numbering

Plans
To activate overlap receiving on ISDN interfaces, you use the isdn overlap-receiving command in interface configuration mode.
Cisco Unified SRST Dial Plan
Commands: Open Numbering Plans

router(conflq-if)#
isdn overlap-receiving [T302 ms]
Enables overlap receiving on ISDN interfaces

router(conflq-cm-fallback)#
timeouts interdigit aec
Configures the interdigit timeout value for all Cisco IP phones

attached to a router
dialplan-pattern tag pattern extension-length length [extension-pattern extension-pattern]

[no-reg] [demote]
Creates a global prefix that can be used to expand or demote the

intemally used directory numbers
The isdn overlap-receiving command is applicable on BRl interfaces or on the ISDN interface
ofTl/El controllers in PRI mode.
The optional parameter T302 defines the number of milliseconds that the T302 timer should
wait beforeexpiring. Validvalues for the milliseconds argumentrange from 500 to 20000.The
default value is 10000 (lOseconds).
Caution
Modification of the T302parameter, whenconnectedto public networks, might disablethe

function.
To configure the timeout value to waitbetween dialed digits for all Cisco IP phones that are attached to a router, usethe timeouts interdigit command in call-manager-fallback
configuration mode.
The parameter sec defines the interdigit timeout duration, in seconds, for all Cisco IP phones. Valid entries are integers from 2 to 120.
To create a global prefix that can be used to expand the extension numbers of inbound and
outbound calls into fully qualified E.164 numbers, youuse thedialplan-pattern command in
call-manager-fallback configuration mode.
The parameter tag is the unique identifier that is used before the telephone number. The tag
number is any number from I to 5.
The parameter pattern is the dial plan pattern, such as the area code, theprefix, and the first oneor twodigitsof theextension number, plus wildcard markers or dots (.) for the
remainder of the extension number digits.
2-60
Implementing CiscoUnified Communications Manager, Pari2 (CIPT2) v8.0
description PSTN-emergency destination-pattern 911 port 0/1/0

forward-digits all
> Cisco Systems, inc 2010
2-59
Cisco Unified SRST Dial Plan Commands: Dial Peer (Cont)

This table contains common classes ofPSTN calls in the NANP
and lists the pattern that is used for each class. An access code
of 9 should be used to indicate a PSTN call.These patterns
have to be reachable in SRST mode:
Call Type Emergency
Services
Local
911
[2-8)11 [2~9]xx-xxxx 1[2-9]xx [2-9]xx-xxxx
Long distance or national

International
Toll-free
Premium
011+countrycode+number
1[800,866,877,8 88]xxx-xxxx
1 900xxx-xxxx
976-xxxx
The table represents the most common classes ofPSTN calls in the Nortli American Numbering Plan (NANP) and lists the pattern that is used for each class.
An access codeof 9 should be usedto indicate a PSTN call.
The patterns in the table are the minimum patterns that must be reachable in SRST mode. This example lists the configuration of dial peers that would be needed to reach all the numbers that
are indicated.

description PSTN-LD
destination-pattern 91 [2-9] .. [2-9]

port 0/1/0
forward-digits 11
description PSTN-local destination-pattern 9 [2-9] port 0/1/0 dial-peer voice 3 pots
description PSTN-international
destination-pattern 9011T
port 0/1/0
prefix 011
i
dial-peer voice 4 pots description PSTN-emergency

port 0/1/0
forward-digits 3
2-58
Note
Details about the meanings of these special characters and about Cisco IOS dial peer
configuration in general are provided in theImplementing Cisco Voice Communications and
QoS (CVOICE) course.
The optional control character T indicates that the dcslination-pattcrn value is avariablelength dial string. Using this control character enables the router to wait until all digits arc
received before routing the call.
To associate adial peer with aspecific voice port, use the port command in dial peer
configuration mode.
The parameter slot-number defines the number of iheslot in the router inwhich the voice interface card (VIC) is installed. Valid entries depend onthe number ofslots that the router
platform has.
The parameter/jo/7 defines the voice port number. Validentries are 0 and I.
)2010 CiscoSystems. Inc
2-57
Cisco Unified SRST Dial Plan Commands: Dial Peer

The dial-peer command is the main component for configuring dial plans on Cisco IOS
routers.
Cisco Unified SRST Dial Plan Commands: Dial Peer
router(config)M
| dial-peer voice tag [pots | voipj

- Defines the dial peer
router(config-dial-peer) #
|destination-pattern [+]Btring[T]
Specifies either the prefix or the complete E.164 telephone
numbertobeused tbradial peer
router(conflg-dlal-peer)B
I port slot-number/port
Associates a dial peer with a specific voice port
To define a particular dial peer, specify a voice encapsulation method, and enter dial peer configuration mode, you use the dial-peer voice command in global configuration mode. The parameter tag specifies digits that define a particular dial peer. The range is from 1to
2147483647.
The keyword pots indicates that this peer isa plain old telephone service (POTS) peer;
voip indicates that this peer is a VoIPpeer.
To specif; either the prelix orthe complete E. 164 telephone number tobe used for a dial peer,
you use the destination-pattern command in dial peer configuration mode.
The optional character+ indicates that an E.164 standard numberfollows.
The parameter string defines aseries ofdigits that specify apattern for the E. 164 orprivate
dialing plan telephone number. Valid entries are the digits 0 through 9, the letters A
through D. and these special characters:
2-56
implementing Cisco Unified Communications Manager, Part 2 (CIPT2) vS.O
Additional Cisco Unified SRST Dial Plar
Requirements (Cont.)
Preservation of calling privileges Cisco Unified Communications Manager CoS should be taken over into SRST dial plan.
- Requires appropriate COR configuration at SRST

gateway.
Preservation ofdialing behavioron variable-length numbers

Tuning of interdigit timeout, Use of # key to terminate dialing. Use of overlap sending if supported by PSTN.
Ifthe calling privileges (which in normal mode are controlled by Cisco Unified Communications Manager) have tobe preserved in SRS'f mode, class ofrestriction (COR)
configuration has to be used.
fhe handling ofvariable-length numbers should also be preserved in SRST mode, fhis includes tuning ofthe interdigit timeout, the possibility to use the # key toterminate dialing:
and the implementation of overlapsending.
2-55
Additional SRST Dial Plan Requirements

The goal of Cisco Unified SRS'f dial plan design should be to reach the largest degree of analogy between usability in normal mode and in SRST mode. The telephony service should have the same design for the user, regardless of the mode that the system is in.
Additional Cisco Unified SRST Dial Plan
Requirements
Preservation of calling-party number presentation on inbound
PSTN calls
Includes international and national access codes
Includes PSTN access codes to enable one-click callback from lists
Preservation of on-net dial plan - Internally used numbers for remote sites have to be
transformed to their PSTN format.
- Applies to calling-party numbers of inbound calls and called-party numbers of outbound calls.
Ideally, the numbers in call lists (such as missed calls) have the correct format (PSI'N access code plus PSTN phone number) that is required for callback so that users do not have to edit the number manually. In this case, the calling party ID of incoming calls from the PSTN needs to be modified by voice translation profiles and voice translation rules.
Abbreviated dialing between sites of the site code plus the extension number is possible in SRST mode. Voice translation profiles have to be used to expand the called numbers to PSTN format for intersite dialing.
2-54
Cisco IOS Gateway MGCP Fallback and Cisco Unified SRST Dial Plan Configuration
This topic describes the minimum dial pian configuration steps that are needed for communication between phones in SRST mode and the PSTN. Minimum SRST Dial Plan to Enabl Calls Between PSTN and Remote
Dial peer configuration must have destination patterns that correspond to the PSTN access code. ISDN overlap receiving has to be enabled if PSTN uses overlap sending. Transformation between internally used directory numbers and externally used PSTN numbers has to be configured. Dial plan pattern command allows automatic
transformation.
Voice translation profiles can be used when more features and granularity are required. Use of ISDN type of number Use of different internal and external DID ranges
The minimum requirement for a dial plan in SRST mode is that it must enable the remote site users to place and receive calls from the PSTN. At least one dial peer must be configured lo enable calls to the PSTN. The destination pattern of that dial peer has to correspond to the PS IN access code (for example, 9T). 'fhe more elegant wa\ is to configure several dedicated dial peers with destination patterns that match the number patterns in a closed numbering plan, such as 91 (91 followed by 10 dots). In countries that have open numbering plans, the only destination pattern that is needed is 9T. Because of the variablelength of dialednumbers, the router is waitingfor the interdigittimeout (1302) or for a hash (#) sign to indicate the end of the dial string.Cisco Unified SRSTversion 4.1 and Cisco Unified Communications Manager F.xpress Version 4.1 do not support the
overlap sending feature to the PSI'N. fhe receiving of ISDN overlap dialing from PSTN is supported but has lo be enabledon the interlaces. To shorten the wail time for users afterthe; complete the dial string, it is possible to reduce the inlerdigit timeout from thedefault of 15
seconds.
Dial plan pattern configuration is a powerful tool forthe modification of incoming called
numbers to match remote site extensions.
2-!
If different sites requiredifferent dialing patterns (for example, an international deployment where each country has different PSTN access codes and international access codes), it is
recommended that you specify the PSTN number to be used for CFUR in H.I64 format with a + prefix. The CFUR CSS should match a \+! router pattern and refer to a route list, which is configured to use the Standard Local RouteGroupof the callingdevice. At the egress gateway, after path selection has been performed using the local route group, the called number can be modified by global transformations (via a called-party transformation CSS configured at the egress gateway), based on the individual requirements of the selected egress gateway.
2-52

"fheCFUR feature is a way to reroutecalls placed to a temporarily unregistered destination phone. Theconfiguration of CFUR consists of twomain elements: destination selection and
CSS.

Setting CFUR on phone lines:
Can pointloaPSTNdesttnation Can point to \oice mail
Cisco Unified Communications ManagerAdministration > Call Routing :

Directory Number
When the directory number isunregistered, calls can be rerouted to the voice mail that is
associated with theextension or to a directory number that is used to reach the phone through
the PSTN. The latter approach ispreferable when a phone islocated within a site whose VAN link is down. Ifthe site is equipped with SRST. thephone (and itseolocated PS'fN gateway)
will reregister with the eolocated SRST router. The phone isthen able to receive calls placed to
its PSI'N direct inward dialing (DID) number.
In this case, the appropriate CFUR destination isthe corresponding PSTN DID number ofthe original destination directory number. Configure this PSTN DID in the destination field, along
with applicable access codes and prefixes (for example. 9 1415 555-1234). Cisco Unified Communications Manager attempts toroute the call tothe configured destination
number b\ using the CFUR CSS ofthe called directory number. The CFUR CSS is configured on the target phone and is used by all devices that are calling the unregistered phone.
As a result, all calling devices will use the same route pattern, route list, and route group to
place the call. Ifaspecific route group is defined in the route list, all CFUR calls to agiven unregistered device will be routed through the same unique gateway, regardless ofthe location ofthe calling phone. In this case, it is often recommended that you select a centralized gateway as the egress point to the PSTN for CFUR calls and configure the CFUR CSS to route calls to
the CFUR destination through this centralized gateway.
Abetter solution istouse the local route group feature. When you use this feature, the route list does not refer to a specific route group, but "Standard Local Route Group" is added to the route list instead, fhe route group that isto be used for the calls is then determined by the local route
sitescan refer to different route groups viatheirdevice pool configuration.
group that is configured at the device pool ofthe calling device. In this case, phones at different
>2010 Cisco Systems Inc
2-51
Step 2: Setting Max Forward Unregistered Hops to DN

The Cisco CallManager service parameter Max Forward Unregistered Hops to DN in Cisco
Unified Communications Manager reduces the impact thaiis caused by CFUR routing loops.
Step 2: Setting Max Forward

Unregistered Hops to DN
Max Forward Unregistered Hops to DN service parameter:
Default is 0 (counter disabled).
A reasonable value is 2.
Cisco Unified Communications ManagerAdministration > System >

Service Parameter > Cisco CallManager
; r,-.^l!J-i-E''
,;
'-1
,F4jsf
'.-ê^.!-^-*^'
-ata
:;Fal"
.-,* >-V*i- >*lrT W.I-.- r.V
Trn-
W:T-UC
' 1-ti. - 1
jO^LC^-î^_^ _ ^
-" - 1'*
'.'
or\i VI'' me liriTdrêriiai'
v^ Onlyafter the FtrBl ihueiMicn
This parameter specifics the maximum number offorward unregistered hops that are allowed
for a director, numberat one time. It limitsthe numberof times that the call can be forwarded
because of the unregistered directory number when a forwarding loop occurs. Use this count to stop forward loops for external calls that have been forwarded by CFUR, such asintercluster IP phone calls and IP phonc-to-PSTN phone calls that are forwarded toeach other. Cisco Unified
Communications Manager terminates thecall when the value that is specified in thisparameter
is exceeded, fhe default 0 disables the counter but not the CFUR feature. The allowed range is
from 0 to 60.
2-50
Cisco Unified Communications Manager Dial

Plan Configuration for SRST Support
This topic describes theconfiguration that is necessary for adjusting the Cisco Unified
Communications Manager dial plan to work with Cisco Unilied SRST.
SRST Dial Plan Configuration Procedure in

Define a CSS for CFUR.
Set the Max Forward Unregistered Hops to DN parameter. Configure CFUR at directory numbers of remote phones.
Step 1: Define a CSS for CFUR

You must adjust the Cisco Unified Communications Manager dial plan to ensure the reachability of remote site phones by their extensions even if the remote site runs in SRS'f mode. The parameter that enables this adjustment is the CFUR destination setting, which has to be defined on even' line of an SRS'f-enabled remote site phone. This parameter was introduced in Cisco Unified Communications Manager Version 4.2.
I he CFUR feature forwards calls to unregistered (disconnected or logged out) director;' numbers for the defined destination, "fhe destination might be the PSTN number of a phone at a remote site or the voice mail for a user in a Cisco Unified Communications Manager Extension
Mobility setting.
Cisco Unified Communications Manager attempts to route the call to the configured destination number by using the CFUR calling search space (CSS) of the directory number that was called. CFUR causes routing loops whenever there is a single disconnected SRST phone in which the remote location is not in SRST mode. Internal calls to that directory number will be forwarded lo the CFUR (PSTN) destination and will be received by the remote site gateway in normal mode. This gateway will process the call as usual, sending the signaling lo its Cisco Unified Communications Manager subscriber. Then Cisco Unified Communications Manager will again fonvard the call to the PSTN, causing an inevitable routing loop.
To limit the impact of these routing loops, Cisco introduced a Cisco CallManager service parameter: Max Fonvard Unregistered I lops to DN. When activated, this counter limits the
calls thai arc fon\arded lo one CFUR destination.
MGCP Fallback Configuration Example

The figure shows an example of an MGCP gateway fallback configuration for a Cisco IOS
router that is enabled with Cisco Unified SRST.
MGCP Fallback Configuration Example

SRST# configure terminal
SRST(config)# ccm-manager fallback-mgcp SRST(config)# application

SRST(config-app)# global SRSTfconfig-app-global)# service alternate Default SRSTIconfig-app-global)# end
SRST#
TheCisco Unified SRST router is installed at a small branch officesitewith three IP phones. Here is the configuration that is necessary forthe Cisco Unified SRST routerto perform the
MGCP gateway fallback in this environment:
SRST(config)#ccm-manager fallback-mgcp SRST(config)#application SRST(config-app)#global

SRST(config-app-global)#service alternate Default SRST(config-app-global)#end
SRST#
Note
More commaindsmight
be necessary, depending on the complexity of the deployment.
2-48
Steps 1 and 2: Enabling MGCP Fallback and Setting Fallback

Service
The Cisco IOS command ccm-manager fallback-mgcp enables the gateway fallback feature and allows an MGCP voice gateway to provide call-processing services through Cisco Unified SRST or other configured applications when Cisco Unified Communications Manager is
unavailable.
Steps 1 and 2: Enabling MGCP Fallback and Setting Fallback Service

router (config)#
ccm-manager fallback-mgcp
Enables the MGCP gateway fallback feature.

router (config) #
call application alternate Default

or
router Iconfig-app-global)W service alternate Default
Specifies that the voice application named Defaulttakes over ifthe MGCP call agent is not available; this action allows a
fallback to H.323 or SIP. Enter the service alternate
command in global application configuration mode. Use either of these commands, depending on Cisco IOS
Software release.
The call application alternate Default command specifies that the default voice application takes o\er ifthe MGCP call agent is not available, fhiscommand allows a fallback to H.323 or
SIP. which means that local dial peers are considered for call routing.
You enter the sen ice alternate Default command in the global application configuration mode. To na\igate to this location, perfonn these steps:
Step 1
To enterapplication configuration mode to configure applications, use the application command in global configuration mode.
Step 2
To enter global application configuration mode, use the global command in

application configuration mode.
Enter eitherof the two commands, depending on the Cisco IOSSoftware release. The newer configuration method is the servicecommand.
As discussed in the previous lesson, analog calls are preserved in the event of MGCP fallback. In order toprovide call preservation during switchback, you must enable call preservation for
H.323 using the following commands:
voice service voip
h323
no h225 timeout keepalive
Cisco IOS Gateway MGCP Gateway Fallback Configuration

This topic describes the configuration steps that are needed to activate the MGCP gateway
fallback feature on a Cisco IOS router.
MGCP Gateway Fallback Configuration

Procedure in Cisco IOS Router
1
2
Activate MGCP gateway fallback.

Define the service to fall back to.
Configuration of the MGCP gateway fallback on a Cisco IOS router to support the MGCP fallback function requires these two steps:
Activation of MGCP gateway fallback

Definition of the service to fall back to
Toenable outbound calls while in SRST mode on an MGCP gateway, youmust configure two
fallback commands on the MGCP gateway. These two commands allow SRST to assume control overthevoice portandovercall processing on the MGCP gateway. With CiscoIOS Software releases earlier than 12.3(14)T, configuration of MGCP gateway fallback requires the use of the ccm-manager fallback-mgcp andcall application alternatecommands. With Cisco IOS Software releases later than I2.3(I4)T, configuration of MGCP gateway fallback requires the use of the ccm-manager fallback-mgcp and service commands. Note Both commands have to beconfigured. Configurations will not be reliable if only theccmmanager fallback-mgcp command is configured.
To use CiscoUnified SRST on an MGCP gateway, you mustconfigure CiscoUnified SRST and MGCP gateway fallback on the same gateway.
2-46
Implementing Cisco Unified Communications Manager. Part2 (CIPT2) v8.0
>20IOCisco Systems, Inc.
Cisco Unified SRST Configuration Example

fhe figure shows anexample of a Cisco Unified SRST configuration to support SCCPcontrolled IP phones.
Cisco Unified SRST Configuration Example

Main Site
Remote Site
SRST(config)# call-manager-fallback
SRST(config-cm-fallback)# ip source-address 172.47.2.1 port 2000

SRST(config-an-fallback! tt max-ephones 3 dual-line
SRST(config-cm-fallback]# max-dn 6
SRST(config-cm-fallback)# limit-dn 7960 2

SRST(config-cm-fallback)# keepalive 20
SRSTlconfig-cm-fallback)# end
SRST#
"fhe SRST router is installed at a small branch office site with three IP phones, each having two
lines (six lines intotal). The IP address 172.47.2.1 isconfigured onthe Fthemct interface where the IP phones are connected. Here isthe configuration thai you must perform for the Cisco
Unified SRST router to operate in this environment:
SRSTtt configure terminal SRST(config)# call-manager-fallback SRST(config-cm-fallback)# ip source-address 172.47.2.1 port
2C00
SRST(config-cm-fallback)# max-ephones 3 dual-line

SRST(config-cm-fallback)# max-dn 6
SRST(config-cm-fallback)# limit-dn 7960 2 SRST(config-cm-fallback)# keepalive 20 SRST(config-cm-fallback)# end

SRST#
Note
More commands might be necessary, depending on the complexity ofthe deployment
) 20'0 Cisco Systems. Inc
Centralized CalI-Processing RedundancyImplementation
2-46
Steps 5 and 6: Setting Maximum Directory Numbers Per Phone and Keepalive Timer
To optimize perfonnance of the system, it is recommended that you use the two commands that
are shown in the figure.
Steps 5 and 6: Setting Maximum Directory Numbers Per Phone and Keepalive Timer
|limic-dn (7910 / 7335 / 7940 / 7960} max-lines

* Limitsthe directory number lines on Cisco IP phones during
SRST mode.
* Default is 6-line maximum.
router(config-cm-fallback} #
Ikeepalive oecondg
* Sets the time interval, in seconds, between keepalive messages that are sent to the router by Cisco IP phones.
Default is 30.
The optional Cisco IOS command limit-dn limitsthe directory number lineson Cisco IP phones during SRST mode, depending on device types.
Note This command mustbe configured during initial Cisco Unified SRST router configuration,
before any phone actually registers with the Cisco Unified SRST router. However, the
number of lines can be modified at a later time.
The setting for maximum lines is from 1to 6.The default number of maximum directory lines is setto 6. Ifthere is any active phone with the lastline number greater than this limit, warning
infonnation is displayed for phone reset.
The optional Cisco IOS command keepalive sets the time interval, in seconds, between
keepalive messages thataresent to therouter by Cisco IPphones. Therange is 10 to 65535.

Default is 30.
The keepalive interval is the lime between keepalive messages that aresentby a network
device.
The default keepalive timer is 30 seconds.
2-44
Implementing Cisco Unified Communicalions Manager, Part2 {CIPT2) v8.0
Steps 3 and 4: Setting Maximum Directory Numbers and

Telephones
"fhe ne\t two commands, max-dn and max-ephone. are mandatory because the default value?
for both commands are defined as 0.
Steps 3 and 4: Setting Maximum Directory Numbers and Telephones

rouCer(conflg-cm-fallback)W
max-dn max-directory-numbers [dual-line] preference-order]
[preference
Sets the maximum number of directory numbers or virtual
voice ports that can be supported by the Cisco Unified SRST

router and activates the dual-line mode
router (config-cm-fallback) #
__^_
Imax-ephones max-phones
Configures the maximum number ofCisco IP phones that can

be supported by the Cisco Unified SRST router
The Cisco IOS command max-dn sets the maximum numberof directory numbers or virtual
voice ports that can be supported by the router, and activates the dual-line mode. The maximum
numberis platform-dependent. The default is 0.
The dual-line keyword isoptional. Itallows IP phones in SRS'f mode tohave a virtual voice
port with two channels.
Note Thedual-line keyword facilitates call waiting. Call Transfer, and conference functions by
allowing two calls tooccur onone line simultaneously. In dual-line mode, all IP phones on
the Cisco Unified SRST router support two channels per virtual voice port.
The optional parameter preference sets the global preference for creating the dial peers for all director) numbers that are associated with the primary number. The range is from 0to 10. The
default is 0. which is the highest preference.
Note
The router must berebooted in order to reduce thelimit ofthedirectory numbers orvirtual voice ports after the maximum allowable number is configured,
To configure the maximum number ofCisco IP phones that can be supported by aCisco
Unified SRS'f router, use the max-ephones command incall-manager-fallback configuration
mode. The default is 0. and the maximum configurable number is platform-dependent.
Note The router must be rebooted in order to reduce thelimit ofCisco IP phones after the
maximum allowable number is configured.
20-0 Cisco Syslems. Inc
2-43
Steps 1 and 2: Enabling Cisco Unified SRST and Setting Cisco

Unified SRST IP Address
The figure describes the commands for the firsttwo Cisco Unified SRST configuration steps.
Steps 1 and 2: Enabling SRST and Setting Cisco Unified SRST iP Address
router (confiq)#
Enables the Cisco Unified SRST feature and enters Cisco
call-manager-fallback configuration mode.

router (config-cm-fallback)#
ip source-address ip-address [port port]

[any-match strict-match]
Enables the router to receive messages from the Cisco IP phones through the specified IP addresses and provides for
strict IP address verification.
The default SCCP port number is 2000.
The Cisco IOS command call-manager-fallback enters call-manager-fallback configuration

mode.
The Cisco IOS command ip source-address enables therouter to receive messages from the Cisco IP phones through the specified IP addresses and provides for strictIP address verification. The default port number is 2000. This IPaddress will besupplied later asan SRST reference IP address in Cisco Unified Communications ManagerAdministration. The ip source-address command is a mandatory command. Thefallback subsystem does not start if the IP address ofthe Ethernet port towhich the IPphones are connected (typically the Ethemet interface of the local Cisco Unified SRST gateway) isnot provided. Ifthe port number
is not provided, the default value (2000) is used.
The any-match keyword should beused to instruct the router topermit Cisco IP phone
registration even when the IP server address that is used by the phone doesnot match the IP source address. You can use this option to allow registration of Cisco IPphones on different
subnetsor on subnetswithdifferent default DHCProutersor different TFTP server addresses.
The strict-match keyword should beused to instruct the router to reject Cisco IPphone registration attempts ifthe IP server address that isused by the phone does not exactly match the source address. By dividing the Cisco IP phones into groups on different subnets and giving each group difTerent DHCP default-router orTFTP server addresses, this option can beused to
restrict thenumber of Cisco IP phones that areallowed to register.
2-42
>2010 Cisco Systems, Jnc.
Cisco IOS Gateway SRST Configuration

This topic describes the configuration steps for enablingCisco Unified SRSTon the Cisco IOS
router.
Cisco Unified SRST Configuration

Procedure in Cisco IOS Router
: Enable Cisco Unified SRST
2
;; a :: 6
Define IP address and port to which the SRST service

binds.
Define maximum number of directory numbers to support. Define maximum number of IP phones to support. Define maximum numbers allowed per phone type. Define phone keepalive interval.
To configure Cisco Unified SRST on a Cisco IOS router tosupport the Cisco IP phone
functions, follow these steps:
Step 1
Step 2
Step3
Step 4
Fnable Cisco Unified SRST. sothat itenters call-manager-fallback configuration

mode.
Define the IP address and port to which the SRS'f service binds.
Define the maximum number of directory numbers to support.
Define the maximum number of IP phones to support.
Step 5
Step 6
Note
Define the maximum numbers thatare allowed per phone tjpe.

Definethe phone keepalive interval.
Steps 5 and 6 are optional.
Tip
When Cisco Unified SRST is enabled, Cisco IP phones do not have to be reconfigured while
in catl-manager-fallback configuration mode, because phones retain the same configuration
that was used with Cisco Unified Communications Manager.
2-41
Step 2: Device Pool

The SRST reference is assigned to IP phones by using device pools.
Step 2: Device Pool

SRST reference to device pool assignment:
SRST reference definition is selected from the drop-down menu in the device-pool configuration.
Cisco Unified Communications ManagerAdministration > System > Device Pool
Roaming Sairttv bettings -
Dftte/Ti-nc Grouo' Pe jion *

Media Resource Grcup Us*
Locator
Nefwort Locale
BkST Reference* Connection Monitor Duration***

Physical Location
Ctvê MabiJjty Group
Administrators select the configured SRST reference from the drop-down menu in the device pool configuration.
Note Ifdevices are associated with this SRST reference, a message is displayed, saying that
devices must be reset for the update to take effect.
2-40
implemenbng Cisco Unified Communications Manager, Part 2 (CJPT2) v8.0
>201DCisco Systems, inc.
Step 1: SRST Reference

An SRST reference comprises the gateway, which can provide limited Cisco Unified Communications Manager functionality when all other Cisco Unilied Communications Manager servers for an IP phone are unreachable.
Step 1: SRST Reference

Create a new SRST reference in the system menu:
It must have a unique name.
The IP address and port numbers of the Cisco Unified SRST gateway must be defined.
Cisco Unified Communications ManagerAdministration > System > SRST

i SftSI Reference Information
"amf *
IF i^ddr-5G" SIP NtVAC'k IP ASd-csi
SRST-Hemcltl
];;;! |
5H5T CtrafiMte P'wJf Pjri' ;-i35

_j [s SSFT Sccurr'
SRST references detemiine the gateways that IP phones will search when (hey attempt to
complete a call if the Cisco Unified Communications Manager is unavailable.

Administrators must configure Cisco Unified Communications Manager with a uniqueSRST reference name that specifies the IP address of (he CiscoUnilied SRSf gateway. The default TCP port number 2000 is normally used. The SIP network and IP address applies to Cisco Unified SIP SRST. If Cisco Unified SIP SRST is used, the IP address and port that are used by the SIP protocol of the Cisco Unified SRSf gateway have lo be specified: thedefault port number is 5060. Theconfigured address
and port will be used by SIP phones to register with theCisco Unified SIP SRST gateway.
For Cisco Unified SRSTgateways that supportSCCPphones with defaultport number2000
with secure SRST disabled, it is not necessary to add an SRST rclcrcncc if the IP address of the
Cisco Unified SRST gateway is the default gateway of the IP phone. In this case,you can use the option Use Default Gateway at the device pool of the affected IPphones.
2-39
Cisco Unified Communications Manager SRST Configuration

This topic describes the configuration stepsfor enabling CiscoUnified SRST in the Cisco
Unified Communications Manager environment.
SRST Configuration Procedure in Cisco

1. Create a new SRST reference.
Assign an SRST reference to device pool.
The role of Cisco Unified Communications Manager regarding the SRST feature is to provide the phones with the needed information for finding the relevant SRST gateway to register with when they lose contact with Cisco Unified Communications Manager subscribers.
The first step is to define an SRST reference. This reference contains information about IP
addresses and ports of SRST gateways for SCCP and Session Initiation Protocol (SIP) phones. Because the SRST functions are different for SIP and for SCCP, the addresses and ports are
also different.
The second step is to provide a group of phones with this information by assigning the SRST reference to a proper device pool, which is then assigned to the phones.
2-38
MGCP Fallback and Cisco Unified SRST Configuration

Requirements
When configuring MGCP fallback and Cisco Unified SRST,you must take several steps at
different locations.
MGCP Fallback and Cisco Unified SRST
Configuration Requirements
MGCP fallback and Cisco Unified SRST configuration consist of the following components:
SRST references for phones have to be configured in Cisco Unified Communications Manager.
MGCP fallback and Cisco Unified SRST has to be enabled
and configured on the Cisco IOS gateway. The CFUR feature has to be configured on the Cisco Unified Communications Manager to reach remote sites in SRST
mode.
An SRST dial plan has to be implemented on the remote site gateways to ensure connectivity for remote sites in SRST
mode.
You need to use the Cisco Unified Communications Manager Administration to define the SRST references for phones. You must also configure (he Call Forward Unregistered (CFUR) feature and set the CFUR destination of lines on remote site phones to the correct public switched telephone network (PSTN) number on the Cisco Unified Communications Manager
Administration to enable reachable remote sites in SRS'f mode.
On Cisco IOS gateways, you must enable and configure the MGCP fallback and Cisco Unified SRSf features. In addition, you must implement a simplified SRST dial plan on the remote site gateways to ensure connectivity for remote sites in SRST mode.
2-37
Configuration Overview
This topic describes the high-level configuration of Cisco Unified SRSTand of MGCP gateway
fallback on Cisco IOS routers.
Configuration
Main Site
Remote Site
Manager
In Cisco IOS
Software, MGCP
fallback and Crsco
Unified SRST must
be enabled and
configured.
Activate and configure the MGCP gateway fallback feature on the Cisco IOS router. Cisco Unified SRST must be configured on the side of the Cisco Unified Communications Manager and on the side of the Cisco IOS router.
2-36
Lesson 2
Implementing SRST and MGCP Fallback

Overview
fhis lesson describes how to configure CiscoUnified Survivable Remote SiteTelephony (SRST) on Cisco IOS routers to provide redundancy to Cisco Skinny Client Control Protocol (SCCP) phones. It also describes how to configure the Media Gateway Control Protocol (MGCP) gateway fallback feature. In addition, this lesson illustrates how to configure features
like musicon hold (MOH)and voice-mail integration for Cisco Unified SRST.
Objectives
Upon completing this lesson. \ouwill be able to configure Cisco Unified SRST to provide call
survivability for IPphones, and MGCP fallback for gateway survivability, fhis ability includes
beingable to meet theseobjectives:
Describe the configuration requirements at Cisco Unified Communications Manager and at

the SRST gateway
Describe how lo configure Cisco Unified Communicalions Manager to enable SRSI for
remote phones
Describe how to configure a Cisco IOS router for SRS'f
Describe how to configure a Cisco IOS router to support MGCP fallback
Describe how to configure Cisco Unified Communications Manager to route calls to

unregistered devices via the PSTN
Describe how to configure a Cisco IOS router with a dial plan for SRST operation
Summary
Summary
MGCP fallback works in conjunction with Cisco Unified SRST to provide telephony service to remote IP phones during WAN
failure.
The Cisco Unified SRST switchover time depends on the keepalive timers and on the number of Cisco Unified Communications Manager servers in the Cisco Unified Communications Manager group applied to the remote phones. The MGCP gateway fallback default application is H.323 or SIP.
The Cisco Unified SRST version is linked with Cisco IOS
Software release.
When Cisco Unified SRST is active, you must take several measures to ensure connectivity from remote sites to PSTN destinations, between different sites, and inside the site itself.
References
Cisco Svstems. Inc. Cisco UnifiedCommunications System8.x SRND, April 2010. http://'\vw\v.eiseo.com/cn/L^S/docs/voiee_ip_comm/ciiem/srnd/8x/uc8x.html Cisco Systems. Inc. Cisco UnifiedCommunications ManagerAdministration Guide Release 8.0(1). February 2010. hltp://ww.cisco.com/en/US/docs/voice ip comin/cucm/admin/8 0 l/ccmcfg/'bccm-801cm.html
Cisco Systems. Inc. Cisco UnifiedSurvivable RemoteSite Telephony Version 8.0,

November 2009.
http:.;V\\w'w,eisc().com/en/l!S/pmd/'collateral/voiccsvv/ps6788/Vcallcon/ps2l6Wdata^heet e
78-57048l.html
2-34
Cisco Unified SRST Dial Plan Requirements Example

Call-routing components on Cisco IOS routers and Cisco Unified Communications Manager
arc necessary before a dial plan will work in SRS'f mode.
Cisco Unified SRST Diaf Plan
Requirements Example
The dial plan enabled by Cisco Unified SRST has to include the following components:
CFUR on the Cisco Unified Communications Manager side Dial peers, COR, dial plan pattern, and voice translation profiles on the Cisco IOS router site
Dial peer with destination pattern
Remole Site
.?.T (MIntsto_PSTN
Cisco
COR lists deny access for
Unified Communications
900-services dial jjeer
Manager
Configuration includes dial plan pattern and voice translation profiles to allow extension-only dialing.
CFUR must be defined on the Cisco Unified Communications Manager side. Configuring the
Cisco IOS router is a little more complex when vou use dial peers, COR. dial plan pattern, and \oice translation profiles to define the simplified Cisco Unified SRST dial plan.
Keeping Calling Privileges Active in SRST Mode

Undernormal conditions in multisite deployments with centralized call processing, you
implement calling privileges by using partitions and CSSs within Cisco Unified
Keeping Calling Privileges Active in SRST

Mode Calling privilegesare implemented in Cisco Unified Communications Manager by using partitions and CSSs.
In the case of a WAN failure, all centralized routing
information is lost, including mappings of calling privileges.

COR is the mechanism to use in implementing calling privileges on SRST routers:
- Tags have to be defined for each type of call. - Outgoing COR lists containing a single member tag
correspond to partitions.
- Incoming COR lists containing subsets ofthe member tags correspond to CSS.
However, when IP WAN connectivity is lost betweena branch site and the central site, Cisco Unified SRSTtakes controlof the branch IP phones, and the entire configuration that is related to partitions andCSSs is unavailable until IP WAN connectivity is restored. Therefore, it is desirable to implement classes of service within the branch router when running in SRST mode.
Forthis application, you mustdefine classes of service in Cisco IOSrouters by using the class of restriction (COR) functionality. You can adapt the COR functionality to replicate the Cisco Unified Communications Manager concepts of partitionsand CSSs by following these main
guidelines:
Define named tags for each type of call that you want to distinguish.
Assign basic outgoing COR listscontaining a single tag each to the outgoing dial peersthat
should not be available to all users. These outgoing COR lists are equivalent to partitions in
Assigncomplexincoming COR lists containing one or more tags to the directory numbers
that belong to the various classes of service.
2-32
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v9.Q
CFUR Example with Globalized Call Routing

The figure shows the same scenario, but thistimewith globalized call routing.
CFUR Example with Globalized Cal Routing

Route Pattern
Partition. System
Device Pool
LRG Site2-GW
3001
Phone
CFUR *152155530O1
CFUR CSS System
There is only a single \+! route pattern, the referenced route list has local route groups enabled. All phones use the same CFUR CSS. which provides access to the partition of the global route pattern, fhe egress gatewa; is selected by the local route group feature. Localization of the called number occurs at the egress gateway by global transformations.
Ifa called is placed to an unregistered phone of Site l, die CFUR destination+152I5553001 is called using the single off-net route pattern, which is configured to use the local route group (in the referenced route list). Consequently, like with any other PSTN call, CFUR calls use the local gateway instead of the HQ gateway, regardless of the location of the caller. There is no need for all callers to use the same gateway for CFUR calls. In addition, all CFUR destination numbers are specified in global format (E. 164 with +- prefix).
'2010 Cisco Systems, Inc.
Centralized Call-Processing Redundancy Impfementation
2-31
CFUR Example Without Globalized Call Routing

"Hie example illustrates the call flow with CFUR without local route groups.
CFUR Example Without Globalized Call

Routing
CFUR caii from HQ
phone to Stie 1 phone

uses MO PSTN
galeway
Route List
Route Group: HQ-GW
Ptione
CFUR 915215553001 CFUR CSS HQ
JP ;.,)!: K)ir> hiic;2 ph:*^; tc '~Wt ' pSn">si<; t;;K-.s HG
There are three sites: HQ, Site I, and Site 2. The remotesites are backed up by SRS'f gateways. If IP connectivity between site 1 andthe HQfails, Site 1 phones will failover to SRST mode.
They can still call the HQ and Site 2 viathe PSTN. When an HQ phone attempts to call a phone at Site 1which is unregistered in Cisco Unified Communications Managerthe call is placed to the CFUR destination configured at the Site 1phone (915215553001 in thisexample). The
CFUR CSS of the Site 1 phoneensuresthat a route pattern9.@which refers to the HQ
gatewaycan be accessed. Therefore, the call is redirected to the PSTN number of the called
phone and sent to the HQ gateway.
When a user at Site 2 attempts to call a phone at Site 1, the same thing happens. The CFUR destination 915215553001 is called using the CFUR CSS configured at the Site 1 phone and
therefore matches the 9.@ route pattern that is referring to the HQgateway and not to a 9.fy route pattern referring to a Site2 gateway. Therefore, the call will utilize the IP WAN to get from Site 2 to the HQ and from there it will break out to the PSTN towardsSite 1.
If there were more sites, they would all use the HQ gateway for CFUR calls to Site 1. This can lead to suboptimal routing. In addition, differentroute patterns may be needed depending on the destination of the CFUR call. In an international deployments, the CFUR destination numbermay be a mix of national and international numbers. Each destination numberhas to be specified in a way that it can be routed by the CFUR CSS. There is no common format for all CFUR destinationssome may be specified in national format, others in international format.
2-30
CFUR Interaction with Globalized Call
Routing (Cont.)
Optimized gateway selection with multiple sites:
Without using local route groups the CFUR CSS determines the gateway used for the CFUR call
* The CFUR CSS is set at the phone that is unregistered {in

SRST mode)
- All callers use the same CFUR CSS to reach such an
unregistered phone
Ifcallers are at different sites, they all have to use the same gateway (typically the main site gateway is used) - With local route groups each spoke site can use its local
gateway for CFUR calls
CFUR number is the same for all callers regardless of the originating site
Without using local routegroups, the CFUR CSS determines the gateway that is used for the CFUR call. The CFUR CSS of the phonethat is unregistered is used not the one of the phone
that tries to reach the unregistered phone. This means that all callers use the same CFUR CSS
when calling an unregistered phone (the CFUR CSS configured at the destination phone). Consequently, if callers arc located at different sites, they will all use the same gateway for the CFUR call. Usually the main site gateway is used for that purpose; that means that the CFUR CSS (applied to all phones) provides access lo PSTN route patterns that use the main site gateway (via the referenced route list and route group).
With local route groups, each caller can use its local gateway for CFUR calls; there is no need
to use the IP WAN touards the main site and then break out to the PS'FN with the CFUR call at
the main site gateway. Depending on the deployment this can be a huge improvement for reaching sites that lost IP connectivity to Cisco Unified Communications Manager.
2-29
CFUR Interaction with Globalized Call Routing

CFUR canbenefit from globalized call routing in multisite deployments, especially when a Cisco Unified Communications Managercluster serves multiplecountries.
CFUR Interaction with Globalized Cal!
Routing
CFUR can benefit from globalized call routing:
- Ifglobalized number is used as CFUR destination number - CFUR calls are placed to global number - Single route pattern (\+!) sufficient for all CFUR calls - Same route pattern can be used for AARand PSTN
access
- Route pattern refers to single route list - Route list includes only "Standard Local Route Group"
- CFUR CSS can be the same for all phones
If globalized numbers arc used as CFURdestinations, callsto unregistered phones (for example, phones that lost IP connectivity to Cisco Unified Communications Manager and which are in SRST mode) are using the only configured off-net route pattern \+! for CFUR. All calling devices will use the same route pattern, route list, and route group to place the call, "fhis route pattern is a general off-net route pattern and is used for PSTN calls, AAR calls, as well as by CFUR calls, 'fhe CFUR CSS can be the same for all phones and the local gateway will be used for the CFUR call because local route groups are configured.
2-28
a director;' numberwhose CFUR setting is configured for voice mail. At the same time, this configuration would alsolimit potential loops to two fordirectory numbers whose CFUR configuration sends calls through the PSTN.
Note Cisco Unified Communications Manager Extension Mobility directory numbers should not be configured to send CFUR calls to the PSTN DID that is associated withthe directory number. The directory numbers of Cisco Unified Communications Manager Extension Mobility profiles in the logged-out state are deemed to be unregistered; therefore, any calls to the PSTN DID number of a logged-out directory number would trigger a routing loop To ensure that calls made to Cisco Unified Communications Manager Extension Mobility directory numbers in the logged-out state are sent to voice mail, you must configure their
corresponding CFUR parameters to send calls to voice mail.
2-27
CFUR Considerations CFUR was first implemented in Cisco Unified Communications Manager Version 4.2.
CFUR Considerations
CFUR was introduced in Cisco Unified Communications
Manager v4.2. CFUR points to PSTN destinations or voice mail. Using CFUR to forward calls to PSTN number for disconnected phones in remote sites causes routing loops. To reduce the impact of routing loops, service parameter limits the number of CFUR hops per call. CFUR for Cisco Extension Mobility lines should always point to voice mail to avoid routing loops.
As mentioned earlier, the CFUR feature allows calls that are placed to a temporarily
unregistered phone to be rerouted to a configurable number.The configuration of CFUR

comprises two main elements;
Destination selection: When the directory number is unregistered, calls can be rerouted to voice mail or to the directory numberthat was used to reach the phone through the PSTN. Calling search space (CSS): Cisco Unified Communications Manager attempts to route the call to the configured destination number using the CFUR CSS of the directory number that was called. The CFUR CSS is configured on the target phone and is used by all devices that are calling the unregistered phone.
If a phone is unregistered while the gateway that is associated with the direct inward dialing (DID) number of that phone is still under the control of Cisco Unified Communications Manager, CFUR functionality can result in telephony routing loops. For example, if a phone is simply disconnected from the network, the initial call to the phone would prompt the system to attempt a CFUR call to the DID of the phone through the PSTN. The resulting incoming PSTN call would, in turn, trigger another CFUR attempt to reach the directory number of the same phone, triggering yet another CFUR call from the central PSTN gateway through the PSTN. This cycle could repeat i'sclf until system resources are exhausted.
'fhe Cisco CallManager service parameter Max Forward UnRegistered Hops to DN in the Clusterwide Parameters (FeatureForward) section in Cisco Unified Communications Manager Administration controls the maximum number of CFUR calls that are allowed for a directory number at one time. The default value of 0 means that the counter is disabled. If any directory numbers are configured to reroute CFUR calls through the PSTN, loop prevention is required. Configuring this service parameter to a value of 1 would stop CFUR attempts as soon as a single call is placed through ihe CFUR mechanism. This setting would also allow only one call to be forwarded to voice mail, if CFUR is so configured. Configuring this service parameter to a value of 2 would allow up to two simultaneous callers to reach the voice mail of
2-26 Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0 ) 2010 Cisco Systems, Inc.
Ensure Connectivity from Main Site Using CFUR

During fallback, main site users still should be able locall remote site users by using their
extension numbers.
Ensure Connectivity from Using CFUR
in
Remote site has lost connectivity to main site. Phones are registered to remote gateway.
Cisco Unified Communications Manager at the main site does not roule calls
to the directory numbers of affected IP phones, which are now unregistered in Cisco Unified Communications Manager.
CFUR allows routing to alternate numbers for affecled (unregistered) IP

phones.
Main Site
1001 status is
Remote Site
unregistered
Configured CFUR
9 1 408 555-1001
Communications
Manage
DID' 408 555-
Remote
100110 1003
Gateway
Cisco Unified Communications Manager considers the remote site phones as unregistered and
cannot route calls to the affected IP phone directorv' numbers. Therefore, if main site users dial
internal extensions during the IP WAN outage, the calls will fail (or go to voice mail). To allow remote IP phones to be reached from other sites, you can configure Call Forward Unregistered (CFUR) at the remote site phones. You should contigurc the CFUR destination at each remote IP phone with the PSTN number of the IP phone so that internal calls from other sites get forwarded to the PSTN number of an IP phone that is currently unregistered and is
therefore not reachable over the IP network.
Centralized Cal I-Processing Redundancy Implementation
2-25
Ensure Connectivity for Remote Sites

When Cisco Unified SRST is active, you musttakeseveral measures to ensure connectivity from remotesites to PSTN destinations, betweendifferentsites, and insidethe site itself.
Ensure Connectivity for Remote Sites

PSTN connectivity:
* You must implement dial peers with destination patterns corresponding to the PSTN access code. Voice translation profiles modify the calling-party number to
enable callback.
* Interdigittimeout adopts open numbering plans that do not

have a fixed number of digits.
Intrasite and intersite connectivity: Voice translation profiles expand the called number to PSTN
format for site code dialing. * The command dialplan pattern modifies incoming called PSTN numbers to match internally used extensions.
To guarantee PSTN connectivity, you must implement dial peers with destination patterns corresponding to the PSTN access code. In H.323or SIP gateways, these dial peers must be presentfor normal operation. When MGCP gateways are used, dial peers are activated by the MGCP gateway fallback mechanism. Interdigit timeout adopts open numbering plans that do
not have a fixed number of digits.
Voicetranslation profilesthat are applied to dial peers, the voice interface, or the voice port modify the calling party ID to enable callback from call lists.
For intrasite and intersite connectivity, voice translation profiles are configured to expand called numbers to PSTN format during fallback.
The Cisco IOS command dialplan-pattern in call-manager-fallback configuration mode modifies incoming called numbers to match the remote site extensions, 'fhis command also ensures that internal extensions can be dialed even though the lines are configured with the site code and extension, "fhe Line Text Label settings that are defined in Cisco Unified Communications Manager will not be applied to the Cisco Unified SRST phones, so the complete directory number that is applied to the line will be visible to the user.
2-24
Implementing Cisco Unified Communications Manager, Pan 2 (CIPT2) v8.0
Dial Plan Requirements for MGCP Fallback and

Cisco Unified SRST Scenarios
Thistopic describes therequirements of standalone dial plans for working with MGCP fallback
and Cisco Unified SRST.
Cisco Unified SRST Dial Plan Requirements far

Calls from the Remote Site
Cisco Unified SRST-mode dial plan should be as close to normal mode as possible:
Remote site users need to reach one another by extension.
Remote site users need to reach the internal extensions of main site users.
* Remote site PSTN access should workas usual, includingclass of service.

isco Unified Communicalions Calls to main sile extensions
Manager applies the

dial plan for all sites
need to be changed to PSTN

numbers; class ol service
must be enforced
during normal operation

Unified Communicalions
Manager
Cisco Unified SRST
needs a simplified dial
plan for remote sites in

SRST mode
SRST failo\er lea\es the remote site independent from the complex dial plan that is implemented in Cisco Unified Communications Manager in the main site. The Cisco Unified SRST router needs to have a minimal dial plan that is implemented lo allow for all remote site phones, all main site phones, and all PSTN destinations to be reached with the same numbers as
in standard mode.
During fallback, users should be able to dial main site directorv' numbers as usual. Because these calls have to be routed over the PSTN during fallback, main site extensions have to be
translated to E.164 PSTN numbers at the PSTN gateway. Most enterprises limit the range of destinations that are reachable from specific extensions by
applying a class of service to the extensions, fhis limitation should still be valid during times in
SRST mode.
2-23

Cisco Unified SRST v8.x also introduces support for multiple music on hold (MOH) sources.

Cisco Unified SRST v8.0 supports up to five MOH groups:
Supports SCCP phones only.
Each group can be configured with individual MOH file.

Multicast MOH can be enabled or disabled per MOH group.
Each group is configured with directory numbers that should be

applied to it.
Supported by Cisco Unified Communications Manager Express in

SRST mode, as well.
Files can be cached in router RAM.
Traditional MOH configuration still supported,
- Configured under Cisco Unified SRST (standalone or Cisco

Unified Communications Manager Express)
- Applies toall phones thathave no MOH group assigned

* All SIP phones
SCCP phones if directory numbers are not specified in MOH

group
Before Cisco Unified SRST v8.x. only asingle MOH file was supported by Cisco Unified SRST. Cisco Unified Communications Manager Express in SRST mode, and Cisco Unified
Cisco Communications Manager Express in standalone mode.
Cisco Unitied SRST v8.x allows you toconfigure up tofive additional MOH sources by
configuring MOH groups.
Only SCCP IP phones support these newly introduced MOH groups. You can configure each MOH group with an individual MOH file that is located in the flash memory of the router, and you can enable multicast MOH for each MOH group. Each MOH group is configured with the
on hold.
directory' number ranges that should utilize the corresponding MOH group when callers are put
The traditional MOH configuration for Cisco Unified SRST and Cisco Unified
have not been specified in any MOH group.
Communications Manager Express is still supported. Itisused by all phones that do not have a
MOH group assigned. All of these phones are SIP and SCCP phones whose directory numbers
MOH files can becached inrouter RAM. This process isuseful toreduce the amount of read
operations in flash, but it requires enough available RAM at the router. You can specify a
maximum size per MOH file in order to limit RAM usage for MOH file caching.
2-22
Plus (+) Prefix and E.164 Support in Cisco Unified SRST

a plus (-t-) prefix.
Cisco Unified SRST version 8.0 introduces support for directory numbers in E. 164 format with
Plus (+) Prefix and E.164 Support in

Cisco Unified SRST
Cisco Unified SRST8.0supports directory numbers with +

prefix:
IP phones can usedirectory numbers in E.164 format with +prefix.

* SIP and SCCP phones supported Special dial plan pattern command can be used to demote E.164
number to internal extension.
- Allows internal extensions to be used to call phones with E 164

number
Reversefunctionality from standarddial planpattern command Calls from outside are placed to E 164 numberwith + prefix. Voicetranslation profiles are extended by translationof callback
number
- Allows separate translation of calling-party numberand callback

number
Enables different number to be used for callback rather than numbershown on phone display
SIP and SCCP IP phones can fallback to SRST and register with adirectory number in E. 164
format with a+prefix. Assigning directory numbers in E. 164 format ensures globally unique
numbers: the + sign is prefixed in orderto indicate thatthe number is in E. ]64 format.
Note
The E 164standard describes telephone numbers in international format. E 164numbers are globally unique numbers within the PSTN and startwith the country code.
Cisco Unified SRST and Cisco Unified Communications Manager Express in SRST mode allow internal callers to use internal extensions for calling IPphones that have numbers in
E.164 format. A new dial plan pattern command hasbeen introduced with Cisco Unified SRST v8.x to achieve the demotion of the I:. 164 number to the internally used shorter numbers. While
the standard dial plan pattern command expands to a longer PSTN format any directory
numbers that are applied tophone lines, the new dial plan pattern command has the opposite
function: Itallows internal callers to dial shorter, internally used extensions, which are
expanded to the applied directory numbers in E.164 format.
Outside callers dial the IP phone directory numbers as configuredwith a 4 prefix and the
complete E.164 number.
At the IPphones, the calling-party number that isshown on the phone display can be
transformed independently from the number that will be used for callback. This transformation
is possible because ofa newly introduced translation type in voice translation profilesa
translation rule of the callback number.
2-21
Lesson 4
Implementing a Dial Plan for

International Multisite
Deployments
Overview
Multisite dial plans have to addressspecial issues,such as overlapping and nonconsecutive director;'numbers, publicswitchedtelephone network(PSTN)access, PSTN backup,and tailend hop-off(TEHO). This lessondescribes how to build multisitedial plans using Cisco Unified Communications Managerand Cisco IOS gatewayconfiguration. The lessonalso describes the conceptof globalized call routinga new way of buildingdial plans in
international multisite deployments.
Objectives
Uponcompleting this lesson,you will be able to implement a dial plan to supportinbound and outbound PSTN dialing, site-code dialing, and TEHO in an international environment. This ability includes being able to meet these objectives:
List dial plan issues and possible solutions

Describe how site codes and transformation masks solve issues that are caused by
overlapping directory numbers
Describe how to implement PSTN access in a multisite deployment

Describe how to implement selective PSTN breakout Describe how to use the PSTN as a backup for calls to other VoIP domains Describe how to implement TEHO Describe the concept of globalized call routing and how it simplifies dial plans in international multisite deployments with centralized call processing Explain special considerations for implementing globalized call routing
Multisite Dial Plan Overview

This topic lists dial plan requirements for multisite deployments with centralized call processing.
Dial Plan Requirements for Multisite Deployments with Centralized Call Processing
Implementing access and site codes; - Allows routing independent of directory numbers Solves overlapping and nonconsecutive directory-number
ranges
Implementing PSTN access: - Simple, prioritized list of gateways forall PSTN access TEHO (gateway selection based on PSTN destination)
Implementing PSTN backup:
MGCP fallback in case of MGCP gateways

- SRST for IP phone fallback at remote site
- Call Forward Unregistered at central site
In multisite environments with centralized call processing, you use these dial plan solutions: Access and site codes: By adding an access code and a site code lo director},' numbers of remote locations, you can provide call routing that is based on the site code instead of on directory numbers. As a result, directory numbers do nol have to be globally unique,
although they must be unique within a site. Configuration requires route patterns, translation patterns, partitions, and calling search spaces (CSSs).
Implementing PSTN access: You implement PSTN access within a Cisco Unified Communications Manager cluster by using route patterns, route lists, route groups, partitions, and CSSs. When implementing TEHO. you use the same dial plan configuration elements: however. \ou have lo configure more entities, which makes the configuration
more complex.
Implementing PSTN backup: The IP WAN that is used in a multisite deployment with centralized call processing is backed up by Media Gateway Control Protocol (MGCP) fallback. Cisco Unified Survivable Remote Site Telephony (Cisco Unified SRST) or Cisco Unified Communications Manager Express in SRS'f mode, and Call Forward Unregistered(CFUR).
1-108
ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)v8 0
Dial Plan Requirements for Multisite Deployments with

Distributed Call Processing
Dial plan requirements for multisite deployments with distributed call processing are like the dial plan requirements ofmultisite deployments with centralized call processing.
Dial Plan Requirements for Multisite Deployments
with Distributed Call Processing Implementing access and site codes: - Allows routing independent of directory numbers - Solves overlapping and nonconsecutive directory number
ranges
Implementing PSTN access:
- Simple, prioritized listofgateways forall PSTN access - TEHO (gateway selection based on PSTN destination)
Implementing PSTN backup: - Route lists and route groups for path selection:
First choice: on-net
Second choice: off-net
In multisite environments with distributed call processing, you use these dial plan solutions:
Access and site codes: Byadding an access codeanda site codeto directory numbers of remote locations, you can provide call routing thatis based on thesite code instead of on directory' numbers. As a result, directory numbers do nothave to be globally unique, although they must be unique within a site. Configuration elements include route patterns
and translation patterns.
Implementing PSTN access: You implement PSTN access within a Cisco Unified
Communications Manager cluster by usingroute patterns, route lists, routegroups, partitions, and CSSs. When implementing TEHO, you use thesame dial plan configuration elements; however, you have to configure more entities, which makes the configuration
more complex.
ImplementingPSTN backup: Backup of the IP WAN is provided by route lists androute groups with on-net (prioritized) and off-net (PSTN)paths.
Implementing Multisite Deployments
1-109
Dial Plan Scalability Solutions

Dial plan requirements for multisite deployments with distributed call processing are like the dial plan requirements of multisite deployments with centralized call processing.
Dial Plan Scalability Solutions
aH Agent
Ca IASeni Call Agent
Call Agent
Call Agent CallAgent
Dial plan scalability issues can be solved by Call Control Discovery (CCD) CCD allows dynamic exchange of call routing information utilizinga SAF-enabled
network
In large networks with severalcall agentssuch as Cisco Unified Communications Manager

Express. Cisco Unified Communications Manager, Cisco Unified Border Element, Cisco
Unified SRST.and Cisco IOS gatewaysthe implementation and maintenance of dial plans
can be very complex.
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, fhis implementationmodel does not scale at all and therefore is suitable only for smaller deployments. In a hub-and-spoke deployment model, call-routing infonnation for each call-routing domain is configured onh once at the centralized call-routing entity. This centralized call-routing entity can be a SIP network service or an H.323 gatekeeper. Such a solution scales better than lullmesh 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 perfonned
at the centralized call-routing service. Further. PSTN backup has to be implemented independent!; ai each call-routing domain. With Call Control Discovery (CCD). a new feature that was introduced with Cisco Unitied Communications Manager Version 8. 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.
1-110
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2] uB.O
CCD solvesdial plan scalability issues by allowingCisco Unified Border Element, Cisco Unified SRST.Cisco Unified Communications Manager, Cisco Unified Communications Manager Express, andCisco IOS gateways to advertise and learn call-routing information in the form of internal directory numbers and PSTN numbers or prefixes. CCD utilizes the Cisco ServiceAdvertisement Framework (SAF).SAF is a network-based, scalable, bandwidth-efficient, real-time approach to service advertisement and discovery.
Note
CCD is described in more detail in a later lesson of this course.
1-111
Implementing Site Codes for On-Net Calls

This topic describes how to use site codes in multisite environments.
Access and Site Codes

Users dial access and site code, followed by directory number;
directory numbers do not have to be unique across sites because of

site identification
Cisco Unified
Communication;]
Manager
Nonconsecutive 000-2157
2365-2999 ""
Numbers
Inthe example, two sites have overlapping and nonconsecutive directory' numbers. To accommodate unique addressing of all endpoinls. site-code dialing is used. Users dial anaccess code (8 in this example), followed by a three-digit site code. When calling thephone with directory number 1001 at the remote site, a user who islocated atthe main site has to dial
8222.1001. For calls in the other direction, remote usersdial 8111-1001. Whendistributed call
processing is used, each Cisco Unified Communications Manager cluster isaware ofonly its own director) numbers indetail. For all directory numbers that are located at the other site, the
call is routed to a Cisco linified Communications Manager server at the other site that is based
on the dialed site code.
1-112
Digit Manipulation Requirements for Using Access and Site

Codes
The figure shows digit manipulation requirements for site code implementation.
Digit Manipulation Requirements When

Using Access and Site Codes
Main Site
Remote Site
Cisco Unified
Communications
Manager
Outgoing: Cisco Unified

Incoming: Cisco Unified

Communicalions Manager adds access code and
strips access code and site code

from called number.
site code to calling number.
When you are using site codes in mullisite environments with distributed call processing, call processors must strip off the access and site code from the called number on outgoing calls. If
access and site codes are configured before the "." (dot) in the route pattern, you can easily strip them offusing the discard digits instruction (DDI) on the route pattern orroute list. For incoming calls, you need to use translation patterns to add the access code and appropriate site
code that are used to get to ihe callersite.
1-113
Centralized Call-Processing Deployments: Access and Site

Codes
site codes are implemented in adifTerent way. as shown in the figure.
Ifoverlapping director) numbers exist in acentralized call-processing deployment, access and
Centralized Call-Processing
Deployments: Access and Site Codes
Cisco Unified
Communications
Manager
The example shows two sites with centralized call processing. Directory numbers in the main
site("headquarters." or "HO" in the figure) and the remote site(-'branch." or "BR'" in the
figure) partially overlap. Again, access and site codes are used losolve the problem of
overlapping directory numbers.
However, in this case, partitions and CSSs need lobedeployed ina way that phones at the
remote site do notsee director) numbers of main-site phones, and vice versa. Then a translation
pattern is added per site.
The translation pattern of each site includes the access and site code of the respective site. Phones ateach site have a CSS assigned, which provides access tothe directory numbers of the local site and the translation pattern for the other site orsites, fhetranslation patterns are
configured witha transformation mask that strips off the accesscode and site code. Further,
each translation pattern must have a CSS. which provides access to only those director) numbers that are located at the target site ofthe respective translation pattern, fhis way., all phones can dial local directory numbers and site-code translation patterns for accessing other
sites. After a user dials an intersite number(composed of the accesscode,site code, and
director)' number), the corresponding translation pattern is matched. The translation patlern strips the site code and access code sothat only the directory number remains. This directory number is matched again in the call-routing tableusing a CSS that hasaccess only to the
directory numbers of the site, which was identified bv the site code.
1-114
Implementing PSTN Access in Cisco IOS Gateways

This topic describes how to implement PSTN access in a multisiteenvironment.
Dial Plan Requirements for PSTN

Access
Perform this digit manipulation at Cisco Unified Communications
Manager (in the case of MGCP gateways) or at the H.323 gateway:

Outgoing calls (to PSTN).
- Calling number transfix ma Iion
If no DD range, transform all directory numbers to (single)PSTN number.
If DID range, add prefix
Called number t"an storm at ion
Strip access code
Incoming calls (from PSTN).

Calling number transformation
Transform to complete PSTN number and add access code.

ConsiderTON.
Called number transformation
If DID range, stnp PSTN prefix to directory number.
If no DO, route call to attendant or IVR application.
When implementing PSTN access, the following digit manipulation has tobe performed b:fore
the call is sent outto thePSTN. Digit manipulation has to bedone in Cisco Unified Communications Manager when anMGCP gateway isbeing used, and it can beperformed either in Cisco Unified Communications Manager orat an H.323 gateway.
Outgoing calls to the PSTN:
Calling number transformation: Ifno direct inward dialing (DID) range isused at
the PSTN, transform all directory numbers to the same, single PSTN number in the
calling number. If DID is used, extend the directory numbers to a complete PSTN
number.
Called number transformation: Strip the access code.
Incoming calls from the PSTN:
Calling number transformation: Transform calling number loa complete number

{considering the ISDN typeof number [TON]), andadd the access code.
Called number transformation: If DID isused, strip offthe office code, area code, and countrycode (if present) to getto thedirectory number. If DID is notused, route
the call tothe attendant ortothe interactive voice response (IVR) application.
1-115
PSTN Access Example

The figure illustrates an example ofdigit manipulation that isperformed for incoming and
outgoing PSTN calls.
PSTN Access Example

408 555DID XXXX 714 555-2222
PSTN
Outgoing Cisco Unified

Call from 1001 to 9 1 714 555-2222 Call from 408 5551001 to 1 714 5552222
Communications Manager or H 323
gateway strips access code from

called number.
Manager or H.323 gateway adds

Call from PSTN
PSTN prefix to called number.

Call from 9.1-
Incoming Cisco Unifed Communications Manager or gateway adds access code and
Call from 714
longdistance 1 to calling number. Cisco

Unified Communications Manager or gateway
714 555-2222 to 1001
555-2222 to 408
555-1001
stnps PSTN prefixfrom called number.
As shown in the example, internal numbers have to be represented as valid PSTN numbers, and
PS'fN numbers should be shown with the accesscode 9 internally.
Note
Adding the access code (and changing 10-digit PSTN numbers to 11-digit PSTN numbers, including the long-distance "1" digit) tothe calling number ofincoming calls isnot required. Adding it. however allows users to call back the number from call lists (such as received
calls or missed calls) without having toedit thenumber by adding therequired accesscode
1-116
Implementing Cisco Unifed Communications Manager, Part 2 (CIPT2) v8.0
ISDN TON
fhis subtopicdescribes how to manage PSTN numbers that are based on their TON.
ISDN TON
U.S. TON in ISDN provides infonnation about number format:
Subscriber
7-digit subscriber number
- 3-dig* exchange code

4-digit station code
National
10-dgrt number 3-digt area code

7-digit subscriber number
International
Variablelength (11 digitsfor U.S. numbers) Country code (1 digitfor U.S. country code 1)
* Area coders digits for U.S. area code)
Subscribernumber (7 digitsfor U.S.subscriber number)
| Number has lobe transformed differently depending onthe TON.
The TON isused tospecify in which format a number (such as calling number orcalled
number) isrepresented. Tohave a unique, standardized way to represent PSTN numbers in
Cisco UnifiedCommunications Manager, the numbers have to be transformed based on the
TON.
For example, ifthecalling number of an incoming PSTN call is received with a TON
subscriber, the PSTN access code can be prefixed so that the user can place a callback without
editing thenumber. Ifthe calling number is in national format, then the PSTN access code and the national access code areprefixed. Ifa calling number is received with an international TON. the PSTN access code and the international access code are prefixed.
In countries with fixed-length numbering plans, transforming the numbers is not required, because users can identify the type ofcalling number that isbased on the length. In this case, users can manually prefix the necessary access codes. In countries with variable-length
numbering plans, however, it can be impossible to identify whether thecallwas received from
the local area code, from another area code ofthe same country, orfrom another country by just looking atthe number itself. In such cases, the calling numbers ofincoming PSTN calls have to
be transformed based on the TON.
implementing Multisite Deployments
1-117
Example: ISDN TONCalling Number Transformation of

Incoming Call
The figure illustrates an example ofperforming TON-based digit manipulation on the calling
number of the incoming call.
Example: ISDN TONCaliing Number

Transformation of Incoming Gall
Site 1 Mam Site 403 555-1111
Site 2
14 555-2222
408 555-
DIDXXXX
Manager
PSTW
^^1^4132673333
Incoming Calls
with Different TONS
1001-1099
Site
1
2
TON
I Subscr&er
National
Calling Number
5551111
Required Catling Number Transformation/

9.5551111
I7145552222
19.1714555 2222
~3
International
j49404132673333
}9.011464O4132673333
In the example, the main site gateway receives three separate calls, and callbacks should be
possible without requiring the user to edit the number. The first call is received from the local
area with a subscriber "ION and a seven-digit number. This number needs only to beprefixed with access code9. Thesecond call,which is received with national TON and 10digits, is
modified by the addition ofaccess code 9and the long distance I,all ofwhich are required for placing calls back to the source ofthe call. The third call is received from another country (Germany, in this case) with an international TON. For this calk the access codes 9and 011
ha\c to be added to the received number, which begins with the country code.
1-118
Implementing Selective PSTN Breakout

This topic describes how to implement selective PSTN breakout in a multisite environment.
Selective PSTN Breakout Configuration

Options
Gateway selection by CSS - Each site uses a device-specific CSS. - Site-specific route pattern is matched. - Route pattern refers to site-specific route list. - Route list includes site-specific route group, - Route group refers to site-specific gateways. Gateway selection by local route group feature - Matched route pattern refers to systemwide route list. - Route list refers to Standard Local Route Group. - Device pool of calling device is configured with route group
to be used.
- Eliminates the need for multiple (site-specific) route lists,

route patterns, partitions, and CSS.
- Preferred option since the introduction of local route groups (Cisco UnifiedCommunications Manager \fersion 7).
"ITiere aretwo ways to select the local gateway forPSTN calls. One way is to configure a sitespecific set of route pattern, partition, CSS, route list, androutegroup. If you apply a sitespecific CSS at theend. a site-specific routegroup is used. This implementation model was the only oneavailable before Cisco Unilied Communications Manager version 7.
With Cisco Unified Communications Manager version 7, thelocal route group feature was
introduced. With local route groups, all sites that share the same PSTN dial rules can use one
and the same route pattern (orsetof route patterns). Theroute pattern (orset of route patterns) isput into a systemwide route list, and this route list includes the local route group. Atthe device pool of thecalling device, oneof theconfigured route groups is configured to bethe Standard Local Route Group for thiscaller. Inthismodel, the routegroupthat is used is determined bythedevice pool of thecalling device and notby its CSS. Thelocal route group feature simplifies dial plans because iteliminates the need for duplicate CSS, partitions, route patterns, and route lists. Since local route groups have been introduced, they arethepreferred
method for local gateway selection.
1-119
Configuring IP Phones to Use Local PSTN Gateway

Ina multisite deployment, there typically aremultiple PS'fN gateways (usually one persite).
Selective PSTN breakout ensures that local gateways are used to access the PSI'N.
Configuring IP Phones to Use Local

PSTN Gateway
IP phones located in the main site use the main-site gateway for
PSTN access. Remote phones use their local gateway:
Single 9.@ route pattern.
Route list configured to use local route group
Phone device pool configured with route group to be used by phone.
- Mamsite device pool and remote site device pool refer to differentroute groups.
PSTN 470 555Cisco Unified Communications 1234 Remote Site
Main Site
Manager
From a dial plan perspecti\ c.you create one 9Ar route pattern (assuming that the North
American Numbering Plan [NAN PI is used). This route pattern is in a partition that is part of a
global CSS that is used by all phones, fhe route pattern refers lo asystemwide route list that is configured to use the local route group. At the site-specific device pools, the standard local
route group isset to the route group thai includes the site-specific gateway. In the example, there would be a device pool for the main site and a device pool for the remotesite. There would bea main site route group, including themain site gateway, and a remote site
route group, including the remote site gateway. IP phones at the main site and at the remote site
can now be configured with the same CSS. They all will match the same route pattern and
hence will use the same roule list. Based on the local route group feature, however, they will
alwavs use their local PSTN gateway for PSTN breakout.
Note
The local route group is configured with NANP PreDot digit stripping, by default. If the H.323
gateway expects calls that arereceived from Cisco Unified Communications Manager and
that would be routed to the PSTN to includethe PSTN prefix 9, appropriate digit
manipulation has to beconfigured in Cisco Unified Communications Manager. In this case,

the best solutionwould be to configure the called-partytransformation patterns and apply
gateway-specific called-party transformation CSS atthe gateways.
1-120
!) 2010 Cisco Systems, Inc
Implementing PSTN Backup for On-Net Intersite

Calls
"Ihis topic describes how to use the PSTN as a backup for on-net intersite calls.
PSTN Backup
If the IP WAN (ICT) fails, calls are rerouted over the PSTN:
8 (site code).XXXX route pattern per site. Route pattern points to route lists (first option: ICT; second option:
Local Route Group).
Remote Site
Main Site
Cisco Unified
Communications
Manager
1001-1099
1001-1099
The figure shows a multisite deployment with two sites. Each site has its own Cisco Unified Communications Manager cluster. Intersite calls should use the intercluster trunk (ICT) over
the IP WAN. However, what if the IP WAN is down? Since both sites have access to the
PSTN, the PS'fN should be used as a backup for intersite calls.
To ensure that phones at different sites always use their local gateway for PSTN backup, a route list is configured that includes the ICT as the first option and the local route group as the second option. This way. there is no need to have multiple, site-specific route lists with a difTerent. site-specific route group as second entry.
1-121
Digit Manipulation Requirements for PSTN Backup of On-Net

Intersite Calls
PSTN backup for on-net calls can be easily provided by route lists and route groups that give priority lo the intercluster trunk instead of the PSTN gateway.
Digit Manipulation Requirements for PSTN Backup of On-Net intersite Cal

Digit manipulation is implemented differently
depending on the selected path.

Incoming Cisco Unifed Communications Manager
Outgoing Cisco Unified Communications Manager transforms internal called number

(access and site code plus directory number)
Id PSTN number Cisco Unified
or gateway translates calling number of PSTN gateway of other site to internal number (access
and site code followed by directory number of caller |if DID used] or attendant);
Cisco Unified Communcations Manager or
Communications Manager Iransterms calling

number to PSTN number.
gateway strips PSTN prefix from called number
Call from
Call from
ICT First Cho.ce
1001 to 1001
8111 1001 to 1001
Outgoing Cisco Unified Communications Manager sSips access code and sue
code from called number
Incoming Cisco Unified

aofls access code and site
code to calling number
When you areusing PSTN backup for on-net calls,you must address internal versus external dialing. While on-netcalls usual!) use site codes and directory numbers, calls that arc sent through the PS'fN haveto use PSI'N fonnal. Digit manipulation requirements vary depending
on the path that i> taken for the call:
Digit manipulation requirements when you use the ICT{first choice in route listand route
group):
At the calling site: The accessand site codes are removed from called number.
At the receiving site: The access and site codes are added to the calling number.
Digit manipulation requirements when you use the PS'fN (secondary choice in roule list
and route group):
At the calling site: The internal called number, which comprises an accesscode, site code, and director} number, is transformed to the PSI'N numberof the called
phone. The calling number is transformed to the PSTN number of the calling phone.
Note IfDID is not supported, the PSTN number of the site, rather than the PSTN number of the IP
phone, is used in called number and calling number.
When difTerent digit manipulation configuration is required depending on the selected path, thedigit manipulation settings areeither eonligured at a path-specific
route group or by using global transformations.
1-122
Implementing Cisco Unified Communicalions Manager, Part 2 (CIPT2) 8.0
'2010 Cisco Systems, Inc
At the receiving site: The PSTN callingnumberis recognized as a PSTN numberof

an on-net connected site and transformed to the internal number: access and site
code, followed by the directory numberof the callingphone (if DID is used at the calling site)or of the attendant of the calling site (if DID is not used at the calling site), The callednumberis transformed to an internal directory numberand routed to the IP phone (if DID is used at the receivingsite) or to an attendant(if DID is not
used at the receiving site).
ImplementingMultisite Deployments
1-123
Implementing TEHO
This topic describes how to implement TKMO in a multisite environment.
Implementing TEHO
PSTN breakout occurs at gateway located closest to the PSTN
destination.
* Route partem for each area that can be reached at different costs, one per site, indifferent partition Route patterns point to route lists (with different priorities of gateways; cheapest gateway first, local gateway next).
Phone CSS or local route group for correct route-pattern selection.

.470
406 555Cisco Unified Communications
I'.
. RSIN
DID XXXX L'

Manager
,-
""t470 555-1234
Remote
Phones
Local Path
When you implement 11:HO. PSTN breakout occurs at the gateway that is closest to the dialed PS 1N destination. Basically, this action occurs because you create a route pattern for each destination area that can be reached at dilTerent costs, 'fhese route patterns refer to route lists that include a route group for the TF.HO gateway first and the local route group as the second
entry so that the local gateway can be used as a backupwhen the IP WAN cannot be used.
Note The use of TEHO might not be permitted in your country or by your provider. There can also be issues with emergency calls Therefore, ensure that your planned deployment complies
with legal requirements
1-124
Implementing Cisco Unifed Communications Manager. Part 2 (CIPT2) v8 0
Considerations for Using Remote PSTN Gateways

When using backup TEHO. you have to consider several potential issues.
Considerations When Using Remote PSTN Gateways

What should the calling number look like?
Using PSTN number of originating site at TEHO gateway: - Keeps standard numbering to the outside. - Callbacks from the PSTN are possible. - Legal issue in some countries or not permitted by provider. - There are issues with emergency dialing. Replacing PSTN number of originating site by PSTN number of
TEHO site;
- Confuses called party. - Called party might always use signaled calling number in the future to reach calling party.
- If DID is supported on only one gateway, IVR script at the

gateway without DID has to know how to route calls to directory
numbers of all sites.
- There are issues with emergency dialing.
The first thing to consider when you are using TEi 10 is what number you want to use for the calling number of the outgoing call. Basically, there are two options for configuring the calling number for the outgoing call: Use the PSTN number of the originating site at the TEHO gateway: When using the PSTN number of the originating device for the caller ID of a TEHO call, the called party is not aware that TEHO has been used. Standard numbering is maintained tor all PSTN calls, regardless of the egress gateway; callbacks to the calling number are possible. Ilowcver, sending calls lo the PSTN with PSTN caller IDs of other sites may not be permitted, or the receiving PSTN provider may remove caller IDs from the signaling messages.
Sending calls out of a gateway with the calling number of another site might not be permitted in your country or by your provider. There can also be issues with emergency calls. Therefore, ensure that your planned deployment complies with legal requirements.
Caution
Replace the PSTN number of the originating site by the PSTN number of the TEHO
site: Whenusing the callingnumberof the backup gateway, called partiesmay get confused about the number that should be used when calling back. For instance, they may updatetheir address books with the differentnumberand inadvertently end up sendingcalls to the TEHO site every lime ihey call. Further, DID ranges would have to include remote phones or IVR scripts (automated attendants) to be able to route calls to phones located in
any site, regardless of where the PSTN call was received.
Caution Using a remote gateway for PSTN access mightnot be permittedin your country or by your provider. There can also be issues with emergency calls. Therefore, ensure that your planned deployment complies with legal requirements.
1-125
In general, it is highly recommended that you use the local route group feature when implementing TEHO. In order to provide a local backup for TEHO calls, call processing must route all calls ditTerentlv. based on the source (physical location) and on the dialed number, when the TEHO path cannot be used. When you are not using local route groups, this approach can require a huge amount of route patterns, partitions. CSS. and route lists, resulting in complex dial plans. Suchdial plans are difficult to maintain and troubleshoot.
Note You must also consider Call Admission Control (CAC) when implementing TEHO. When the
primary (TEHO) path is not admitted, the local gateway should be used instead. More
information about CAC is provided in a separate module of this course.
1-126
Implementing Cisco Unified Communications Manager. Pari 2 (CIPT2) v8.0
TEHO Example Without Local Route Groups

This subtopic illustrates the dial plan requirements when you are implementing TEHO without
local route groups.
TEHO Example Without Local Route

Groups
Eacfi site has a different mute pattern and
route ist tor each ol the other sites.
Each site has one additional route pattern ana route list for generic PSTN access (to
non-TEHO PSTN destnations|.
T1T
LI
=j_
In the example, there are five sites in a centralized call-processing deployment. Each site uses identical call-routing policies and numbering plans, but the site-specific details of those policies prevent customers from provisioning a single set of route pattern and route list that works for all sites. This principle applies when no local route groups are used (as it was the case before Cisco Unified Communications Manager Version 7).
Although the primary path for a given TEHO PSTN destination is always the same (the appropriate TEHO gateway), the backup path is different for each site (the local gateway of the site where the call has been placed). Without a backup path, TEI10 would require only one route pattern per TEHO destination number and would refer to only the corresponding TEHO gateway from its route list and route group. However, as the IP WAN is used for TEHO calls, it is not recommended that you configure a single path only. Therefore, TEHO configurations easily end up in huge dial plans: Each site requires a different route pattern and route list for each of the other sites. In addition, each site has one generic route pattern for non-TEHO PSTN
destinations (using the local gateway).
Note Some route patterns in the figure include the character"." multiple times (for example,
9.1 703.XXX.XXXX). In this case, theV character is used to illustrate the different
components of the number patterns in order to make it easier to interpret the patterns. In reality, the"." in route patterns is used only once when being referenced by a corresponding DDI, for example the PreDot DDI.
J-127
TEHO Example Without Local Route Groups (Cont.)

For each TEHO route pattern, the first entry in the route list is the
TEHO location: the second entry is the local gateway. For non-TEHO destinations, there is only one entry (local gateway)
in the route list
* Forn sites, n ' n route patterns and route lists are required.
Sit J
PwfltioiB
s-ch
Spacn
Route
Panems
Lists
Bou
p.6ia,
css-bui 1
19.tiMJj].)ax) \'"^ |
ha fir ITS l
K.-M*4ttft 1
IstSTJIKJXXlLf |fHaT'|
|*1*1).XKX.XKXXI I*1 '"' 1

hi . |BL" MpTltP"--!
-SliUBIIIUCMl 1' |
RL 'B\ I4, SJ !
[as Trrni'
|MUmr**l
F IB BI4. 1
\>B'fW,
In the example, the configuration for one site (Boulder) is illustrated. There is a TEHO route
pattern for area code 703 (Hemdon) that refers to the route list RE-Bldr-I Irdn. This route lists
uses the Hemdon gateway first and the (local) Boulder gateway as a backup. There is also a
route pattern for area code 972 (Richardson), again using a dedicated route list for calls from Boulder to Richardson (with the Richardson gateway preferred over the local Boulder
gateway). 'fhere are tuo more such constructs for the other two sites. Finally, there is a generic PSI'N route pattern (9/d) for all other PSTN (that is. non-TEHO) calls. The generic PSTN route pattern refers to a route list that contains only the local gateway. All five route patterns are in the Boulder partition (P-Bldr) so that they can be accessed only by Boulder phones (using the Boulder CSS "CSS-Bldr").
In summan. for each TEHO destination there is a route pattern per originating site that refers to a dedicated route list utilizing the appropriate TEHO gateway before the local gateway. For n sites, there are n * (n - \) of these patterns. In addition, each site has a generic route pattern referring lo a dedicated route list containing the local gateway only. This generic route pattern increases the total number of route patterns and route lists to n * n. In large TEHO deployments, this approach does not scale.
Note Some route patterns in the figure include the character"" multiple times (for example, 9.1.703 XXX XXXX) In this case, the "." character is used to illustrate the different
components of the number patterns in order to make it easier to interpret the patterns In reality, the "." m route patterns is used only once when being referenced by a corresponding DDI, for example the PreDot DDI
1-128
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) wB.O
TEHO Example with Local Route Groups

When implementing TEHO with local route groups, youcanreduce thenumber of route
patterns and route lists from n * n lo n + I.
TEHO Example with Local Route Groups

Caling
Search Route Patterns Roule
Spaces
Lists
Bouklo.
'
>.i*<a.xxxjatxi{'*i'Hn, M.7W.XXXJM* *|P!-

t.i.lTs.sxjjaice llnâm
> <=><
IP-4y**m |
I
.; |
l.tWWXXJDIUt[H|>hn>
M-..
*><-
N * 1 reduction
B.l*M,xjaxx ffp
"WW
***!!*(. I
N2 -> N+1 reduction
This reduction is possible because, for each TEHO destination, one route pattern is sufficient. The route pattern refers to a destination-specific route list, which lists the route group containing the TEHO gateway first, followed by the entry "Default Local Route Group." Because the backup path is now determined by the device pool of the calling device instead of being explicitly listed in the route list, the route list has a generic format and can be used by all
sites.
For every TEHO destination, one route pattern and one route list is required. In addition, for non-TFHO destinations, again, a single route pattern and route list can be utilized by all sites. This route pattern (9.@) refers to a route list, which includes the "Default Local Route Group"
entry.
Note Some route patterns in the figure include the character V multiple times (for example,
9.1.703.XXX.XXXX). In this case, the "." character is used to illustrate the different
components of the number patterns in order to make it easier to interpret the patterns. In reality, the "." in route patterns is used only once when being referenced by a corresponding DDI, for example the PreDot DDI.
1-129
TEHO Example with Local Route Groups (Cont.)

Dial plan simplification with local route groups:
The number of route patterns and route lists for TEHO
destinations is reduced from n* (n- 1) ton (20to5 in this example with 5 sites).
* The number of route patterns and route lists for non-TEHO destinations is reduced from n to 1 (5 to 1 in ihis example). * The total number of route patterns and route lists is reduced from n " n to n + 1 (25 to 6 in this example).
* The number of partitions and CSS is reduced from n to 1 (5 to 1 in this example).
The number of gateways, route groups, and device pools

remains the same (n).
In the example (five sites), using local roule groups simpliiies the dial plan that is described
here:
The number of route patterns and route lists for TEHO destinations is reduced from n * In - 1) to n. In the example, the reduction is from 20 to 5. fhe number of route patterns and route lists for non-TEHO destinations is reduced from
n to 1 (5 to 1 in this example).
Thus, the total number of route patterns and route lists is reduced from n * n to n + 1
(25 to 6).
The number of partitions and CSS is reduced from n to I (5 to 1).
The number of gateways. route groups, and de\ ice pools remains the same: ti.
1-130
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8 0
Implementing Globalized Call Routing

This topic describes how globalized call routing is implemented and how it simplifies international multisite dial plans.
Globalized Call-Routing Characteristics

Allows one format to be used for routing to PSTN
destinations.
E.164 format with + prefix is used. Users can still type PSTN numbers in local format.
Localized input is globalized at call ingress. Routing is based on numbers in + format. At call egress, numbers are localized depending on the egress device. International dial plans are substantially simplified.
With globalized call routing, all calls that involve extemal parties are based on one format. All
numbers are normalized as follows:
Normalized called-party numbers E.164 format with the + prefix is used for external destinations. Therefore, called-number
normalization is the resultof globalization. Internal directory numbers are used for internal destinations. Normalization is achievedby strippingor translating the callednumberin
internally used directory numbers.
Normalized calling-party numbers
E.164 global format is used for all calling-party numbers, except calls that are from an internal number to another internal number. Such purely internal calls use the internal directory' number for the calling party number.
If sources of calls (users at phones, incoming PSTN calls at gateways, calls received through
trunks, and so on) do not use the normalized format, the localized call ingress must be normalized before being routed, fhis requirement applies to all received calls(coming from gateways and trunks, as well as from phones), and it appliesto both the calling-and calledparty numbers.
Note
Except for the internal calls that were mentioned (where the destination is a directory number and, inthe case of an internal source, the source is a directorynumber), all numbers are normalized to the E.164 global format. Therefore, call routing that is based on the normalized numbers is referred to as globalized call routing.
1-131
After the call has been routed and path selection (if applicable) has been perfonned. the egress
device typically must change the nomialized numbers lo the local fonnat. fhis situation is
referred to as localized call egress. focalized call egress applies to these situations:
Calling- and called-party numbers for calls that arc routed to gateways and trunks: If the PSTN or the telephony system on the other side of a trunk docs not support globalized call routing, the called- and calling-party numbers must be localized from the global format. For example, the called-party number +494012345 would have to be changed to
011494012345 before the call could be sent out lo the PSTN in (he United States.
Calling-party numbers for calls that are routed from gateways or trunks to phones: This situation applies lo the phone user who does not want to sec caller IDs in a global format. For example, ifa user at a U.S. phone wants to seethe numbers of PSTN callers who arc in the same area code, that user may want to see each number as a seven-digit
number and not in the+1 XXXXXXXXXX fonnat.
Localized call egress is not needed for the called-party number of calls that arc routed to phones, because internal directory numbers are the standard (normalized) fonnat for internal destinations (regardless of the source of the call), fhese numbers might have been dialed differenth initialK. however: in that case, this localized call ingress was nomialized before call
routing.
Localized call egress is also not required for the calling-party numberof internal calls (internal to internal) because, again, the standard for the calling-party number of such calls is to use
internal director, numbers.
Globalized call routing simplifies international dial plans because the corecall-routing decision is always based on the same fonnat. regardless of how the number was initially dialed and
regardless of how the number looks at the egress device.
1-132
Globalized Call Routing: Number Formats

This subtopicdescribes the numberformats that are used by globalized call routingand explains some commonly used expressions.
Globalized Call Routing: Number

Formats
Call Ingress Call Routing
Call Egress
Calling Localized E 164

Called Localized E.164
To External
Calling. Directory Number

Called According lo Loca
Dal Rules (PSTN Access
Codes. International
From Extemal:
Calling: Localized E.164

Called: Directory Number
Access Codes, Etc ) or E 164 (Click to Dial, Call

Lists, Etc
From Internal: ^^Sg

Calling Directory Number
Called: Directory Number
To Interna
Calling Directory Called. Directory
The table explains expressions that are commonly used to describe globalized call routing. The table refers to the figure.
Term Number normalization
Description
The process of changing numbers to a well-defined, standardized (normalized) format. In this case, all external phone numbers are
changed to global E.164 format.
Number
The process of changing numbers to global E.164 format. Exampte: Because the normalized format is global E.164 (see "Number Normalization"), you normalize a called number (for example, 4085551234) by globalizing the numberthat is, by changing the number to global format (for example, +14085551234).
globalization
Number
localization
The process of changing from normalized format (in this case, global
format) to local format. Usually, the local format is the shortest possible format that does not conceal relevant information. An example of local format is 555-1234 instead of +1 408 555-1234, or
972 333-4444 instead of +1 972 333-4444 (assuming that the device

where localization occurs is located in +1408 area). Incoming PSTN
call
Call from PSTN to internal phone. Like all calls, such a call consists
of two call legs (incoming and outgoing). See also "Call ingress" and "Call egress." On an incoming PSTN call, the incoming call leg (call
ingress) is PSTN gateway to Cisco Unified Communications Manager; the outgoing call leg (call egress) is Cisco Unified
Communications Manager to internal phone.
1-133
Term
Description Call from internal phone to PSTN Like all calls, such a call consists of two call legs (incoming and outgoing). See also "Call ingress" and
Outgoing PSTN
call
"Call egress." On an outgoing PSTN call, the incoming call leg (call
ingress) is internal phone to Cisco Unified Communications Manager;
the outgoing call leg (call egress) is Cisco Unified Communications Manager to PSTN gateway. Call ingress
Call egress Incoming call legcall received by Cisco Unified Communications Manager
Outgoing call legcall routed to destination by Cisco Unified Communications Manager. PSTN number in partial (subscriber, national, international) E.164
format. See "Number localization."
Localized
E 164 (number) E.164 (number]
PSTN number in complete E.164 format with + prefix.
On the left side of the figure, call ingress is illustrated by two types of call sources:
External callers: Their calls are received by Cisco Unified Communications Manager
through a gateway or trunk. In the case of a PSTN gateway, calling- and called-party numbers are usually provided in localized E.164 format.
Internal callers: Their calls are received from internal phones, in the case of calls to internal destinations (for example, phone to phone), calling- and called-party numbers are typically provided as internal directory numbers. In the case of calls to external destinations (for example, phone to PS'fN). the calling number is the directory number (at call ingress time) and the called number depends on the local dial rules for PS 1N access. These dial rules can differ significantly for each location.
The center of the figure illustrates the standards that are detlned for normalized call routing. As mentioned earlier, because most calls use global E.164 format, this type of call routing is also referred to as globalized call routing. Ilere are the defined standards:
External to internal:
Calling-party number: h. 164 Called-party number: directorv' number
External to external (if applicable):
Calling-party number: F.164 Called-party number: E.164
Internal to internal:
Calling-party number: directorv number Called-party number: directory number
Internal to external:
Calling-party number: E.I64 Called-party number: E.164
1-134
At the right side of the figure, call egress is illustrated by two types of call targets:
Gateways: When sending calls to the PSTN, localized E.164 format is used for both the calling- and called-party numbers. The format of these numbers (especially of the calledparty number) can significantly differ based on the location of the gateway. For example, the international access code in the United States is 011, and in most European countries, it
is 00.
Phones: When a call from an internal phone is sent to another internal phone, the call should be received at the phone with both the calling and called number using internal directory numbers. Because this format is the same format that is used by globalized call routing, there is no need for localized call egress in this case. When a call from an external caller is sent to an internal phone,most users (especially users in the United States)prefer to see the calling number in localized format (for example, national and local calls should be displayedwith 10digits). The called numberis the directorynumberand usually is not displayed on the phone.
It is evident from the figure that there are several situations where the numbers that are
provided at call ingress do not conform to the normalized format to be used forcall routing. These situations applyalso to call egress, wherethe normalized format is not always used when the call is delivered. Therefore, localized call ingresshas to be normalized (that is. globalized)
and globalized fonnat has to be localizedat call egress.
1-135
Normalization of Localized Call Ingress on Gateways

The figure illustrates how localized call ingress on gateways getsnormalized.
Normalization of Localized Call Ing on Gateways
Cisco Unified Communicalions

Called Number
Manager
Globalized
Call Routing
GW gateway DP device pool SP service parameter
Ilere are the requirements for normalizing localized call ingress on gateways:
Changing the calling number from localized E.164 fonnat to global E.164 fonnat Changing the called number from localized E.164 fonnat to directory numbers for calls to
internal destinations
Changing the called number from localized E.164 formal to global E.164 fonnat for calls to
external destinations (if applicable)
As shovsn in the figure, the calling number canbe normalized by incoming calling-party
settings. Thev are configured at the gateway oralthe device pool, orthey can be configured as
CiscoUnified Communications Manager serviceparameters. The figure provides an example
for a gateway in San Jose:
Prefix for incoming called-party numbers with number typesubscriber: +1408 Prefix for incoming called-party numbers with number type national: +1
Prefix for incoming called-party numbers with number type international: +
The called numbercan be normalized bv significant digits that are configured al the gatewav
(applicable onlv ifno calls lo other external destinations are permitted and a fixed-length number plan is used), or bv translation patterns, orby incoming called-party settings (if available at the ingress dev ice). In the example, the gateway is configured with four significant
digits.
1-136
Normalization of Localized Call Ingress from Phones

The figure illustrates how localized call ingress on phones gets normalized.
Normalization of Localized Call from Phones

"\ar-B= Pt-z.r-es If- Sur- Joss;E*;:e:-a: - r i c e N^shdk -ÔoSSEixXX
Ingress
M35k
; i
Examffi {Phones -n &an Josei

9011 '> DDIPifcQot Prefix \-
Y
Local zed Call Ingress
To External.
Globalization
91 ::-SjXX{2-9!XXXXXX -' UDI

PieOa, Psefis* \
Calling Number tor

External Destinations External Phone Number MasK
9[2-9]XX/XXX > DDI PreD?!.

P:e:ix '1W3
Cisco Unified Communicalions
(Translation Pattern! Calling Directory Number
Manager
Caled According iq Local

Dial Rules (PSTN Access
Codes. International Access
Codes. Etc
Call)ng:E.l64
Called: E.164
ToExternal:
t CJ
Globalized
CallRoutng
,<3niple if'hooes ir= HarriDu'c,}

To Internal.
C0O'-> DDI Pr~DM Prefi* ->

DO -:> DDIPieDoi Prefi* +49
Calling. Directory Number

Called Directory Nimber
Here are the requirements for normalizing localized call ingress on phones:
For calls to external destinations: Changing the calling number from an internal director} number to FT 64 fonnat. Changing the called number to K.164 format if any other format
was used (according to local dial rules).
For calls to internal destinations: No normalization is required.
As shown in the example, you can normalize the calling-party number for calls to external destinations by configuring an extemal phone number mask (in E.164 format) at the phone. You can normalize the called-party number by using translation patterns where you would also apply the extemal phone number mask to the calling-party number. In the figure, examples for phones that are located in Hamburg, Germany, and San Jose, California, are given.
1-137
Localized Call Egress at Gateways

The figure illustrates how you can implement localized call egress at gateways.
Localized Call Egress at Gateways

Calling Localized E 164
Called. Localized E 164*
Localized Call Egress

Called Number
Called Parly
Transformation CSS
(GW. DP)
Manager
Globalized
Call Routing
Calling Number Calling Party

Trans form a lion CSS
(GW. OP)
GW gateway. DP device pool
The only requirement is to change the calling and called number from global F.164 format to
localized F., 164 fonnat.
You can change the format by configuring called- and calling-party transformation patterns, puttingthem into partitions, and assigning the appropriate called-and calling-party transformation CSS to gateways. You can configure called- and calling-party transformation CSS at the de\ice (gateway or trunk) and al the device pool.
The tables that are presented in this section refer to the example that is provided by the figure. Hie first table shows the configuration ofthe called-party transfoniiation patterns that are applicable to the SanJosegateway (based on partition andcalled-party transformation CSS).
Transformation Pattern
\+.!
Performed Transformation
DDI PreDot, Prefix 011

DDI PreDot DDI PreDot
\+.1 XXXXXXXXXX \+1408.XXXXXXX
Note
In this example, the San Jose gateway does not use number types. Therefore, 011 has to
be prefixed on international calls, and the 1 of national calls is conserved. Forlocal calls,
only the last seven digits are used.
1-138
Implementing Cisco Unified Communications Manager. Part 2 (CIPT2)v8 0
The next table shows how you would configure the called-party transformation patterns that are applicable to a gateway in Hamburg, Germany (based on partition and called-party
transformation CSS).
\+ !
DDI PreDot, number type: international DDI PreDot, number type: national
DDI PreDot. number type: subscriber
\+49.1 \+4940 !
Note
In this example, the Hamburg gateway is using number types instead of international (00) or national (0) access codes (in contrast to the San Jose gateway, which does not use number
types).
The next table shows how you would configure calling-party transformation patterns that are applicable to the San Jose gateway (basedon partitionand calling-party transformation CSS).
\+ i
Perfonned Transformation
DDI PreDot; number type: international DDI PreDot; number type: national
\+1. XXXXXXXXXX VH408.XXXXXXX
DDI PreDot; number type: subscriber
Note
In the example, subscriber, national, and international number types are used at the San Jose gateway for the calling-party number. If no number types were used, due to the fixedlength numbering plan, the number type could also be determined by its length (seven-digit numbers when the source of the call is local, 10-digit numbers when the source of the call is national, or more than 10 digits when the source of the call is international). In reality, however, countries that use the NANP typically use 10-digit caller IDs for both national and
local callers
Having nonlocal calling-party numbers implies the use of TEHO or PSTN backup over the IP
WAN. This scenario is not permitted in some countries or by some PSTN providers. Some providers verify that the calling-party number on PSTN calls that they receive matches the
locally configured PSTN number. If a different PSTN number is set for the caller ID, eit.ier
the call is rejected or the calling-party number is removed or replaced by the locally assigned PSTN number
The final table shows how you would configure calling-party transformation patterns that are applicable to a gateway in Hamburg, Germany (based on partition and calling-party transformation CSS).
\+.! \+49.l \+4940.!
DDI PreDot, number type: international DDI PreDot, number type; national
DDI PreDot, number type: subscriber
1-139
Localized Call Egress at Phones

fhe figure illustrates how \ou can implement localized call egress at phones.
Localized Call Egress at Phones

Localzed Call Egress
The only requirement is that you change the calling number from global li. 164 fonnat to
localized F.164 fonnat.
You can change the fonnat by configuring calling-party transformation patterns, putting them into partitions, and assigning the appropriate calling-parly transformation CSS to IP phones. As mentioned earlier in this lesson, you can configure calling-party translomialion CSS at the phone and at the de\ ice pool. The two tables that are presented in this subtopic arc in reference to the example that is provided by the figure. The first table shows how you would contigurc the calling-party transformation patterns that are applicable to a phone that is located in San Jose (based on
partition and calling-part} transformation CSS).
VM.XXXXXXXXXX VH408XXXXXXX
DDI PreDot DDI PreDot
Note
In this example, international calls are shown in standard normalized format (E 164 format with + prefix) because there is no W calling-party transformation pattern. National calls are shown with 10-digit caller IDs, and local calls are shown with 7-digit caller IDs.
1-140
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2)v8 0
The next table shows how you would configure the calling-party transformation patterns that arc applicable to a phone that is located in Hamburg, Germany (basedon partitionand callingparty transformation CSS).
\+49 ! \+4940.l
Performed Transformation DDI PreDot, Prefix 0

DDI PreDot
Note
Because there is no \+! calling- party transformation pattern, international calls are
preserved in normalized format (E.164 with + prefix). As opposed to the San Jose example,
phones that are located in Hamburg do prefix the national access code (using 0, which is equivalent to the long-distance 1 in the NANP). The reason is that, in Germany, variablelength PSTN numbering plans are used and therefore national and local numbers cannot be distinguished based on their length (like in the United States, with 7- and 10-digit numbers). When the national access code 0 is prefixed to numbers that are used by national callers, a user can identify national calls by their leading 0.
Note
When users call back PSTN callers, the globalized number is used for the outgoing call.
Therefore, there is no need to edit the localized number from a call list and add PSTN access codes and national or international access codes.
1-141
Globalized Call-Routing Example: Emergency Dialing

In a multisite deployment with centralized call processing, it might be desirable to simplify emergency dialing b\ introducing a globalized emergency number (or one globalized
emergency number for each emergency service).
Globalized Call-Routing Example: Emergency Dialing

Note local emergency numbers (for example, 112 in the European Union,
999 in the United Kingdom. 000 in Australia). Introduce a corporate emergency number (for example, 888) that can be used at all sites (globalized emergency number).
Allow local emergency numbers in addition to corporate

emergency number:
Per site. Only local emergency number is permitted (for example, 112 can be used m the European Union, 999 can be used only in the United Kngdom. and soon|.
Globally All local emergency numbers are permitted at all sites (roaming
users can use home emergency number).
Local emergency numbers are globalized to corporate emergency number

(for example, 888) at call ingress by translation patterns.
Corporate emergency number is localized at egress gateway by called-party

transformation CSS (for example, 868 is changed to 112 at EU gateway, to 999 at UK gateway, and to 000 at Australian gateway].
Having a globalized emergency numberallowsroamingusers who might not be awareof the local emergencv dial rulesto use a corporate emergency number that is accessible from all
sites.
In addition, however, localized emergency dialing should still be supported, so that a user can
dial eitherthe locally rele\ ant emergency numberor the corporate emergency number.
Here is how to implement such a solution; You introduce one or more corporate emergency numbers. In addition. \ou allow localized emergency dialing. It can he limited to local emergency
dialing rules persite (for example, an Austrian emergency number can be dialed only from phones that are located in Austria), or you can globally enable all possible local emergency numbers. Having all possible local emergency numbers thatare globally enabled would allow a roaming user to use the emergency number that is local to thesite where the user is located, or theemergency number thatthe userknows from the home location of the user (forexample, a UK userdials 999 while roaming in Austria), or the corporate emergency
number.
Ifa user dials a localized emergency number, that numberis first normalized (that is. translated) to the corporate emergency number. A route pattern exists only forthis corporate emergency number, and you configure the corresponditig route listto use the
local route group.
1-142
At the gateway that is used to process the call, you localize the corporate emergency number (the globalized emergency number) by using called-party number transfonnations at the gateway. This localization ensures that, regardless of which emergency number was dialed, the gateway that sends out the emergency call uses the correct number as expected
at this site.
Note
In deployments with more complex emergency calls, like in the United States with E911, such a solution is not applicable because there are other requirements for emergency calls. In such a scenario, the emergency call is routed via a dedicated appliance (Cisco Emergency Responder) that is reached via a computer telephony integration (CTI) route
point.
)2010Cisco Systems.Inc.
1-143
Globalized Call-Routing Example: Emergency Dialing (Cont.)
Called-Party 000
Route
Pattern Transformation
Australian User in E U
112
3 Translation Patlems 000 112 999 Route List
/
/
f
*
Syslem
Cailed-Party
Transformation
nn
Route Lisl
-' :'
Mask BBS
Syslem
Roule
33
Called-Party
Transformation
Group
Default
LRG
UK Gateway
8B8 ^ 999
Any User in UK
In the example, a corporate emergency number of 888 has been established. In addition. Australian. E.U.. and UK emergene; numbers are supported at all sites oflhe enterprise. The appropriate numbers (000. 112. and 999) are translated (normalized) to the corporate (global) emergency number 888. A route pattern888 exists, which refersto a roule lisl that has been configured to use the local routegroup. You will considertwo sites in this example: one in the European Union and one in the United Kingdom. Hach site has its own PSTN gateway (or "GW" in the figure): phonesat each site are configured with a site-specific device pool. The de\ ice pool of each site has its local routegroup that is set to a site-specilic route group.
You will examine fouremergenc} calls: A IK user dials 999 (IK emergency number):
The dialed UK emergency number999 is translated lo the corporate emergency number

888. After translation, the 888 route pattern is matched. The route list of the route pattern
refers to the local routegroup. Because the emergency call was placed from a UK phone, the local routegroup in the devicepool of the phone refers to the UK gateway. At thai
gateway, a global transformation of the called number (from 888 to 999) is configured.
Therefore, the call exits the UK gateway with a destination numberof 999, which is the appropriate emergency number to be used in the United Kingdom.
Any user who is located in the United Kingdom dials888 (corporate emergency
number):
Because no local emergency number was dialed exceptthe corporate emergency number 888. no translation is required. The call immediately matches routepattern 888. The route listof the route pattern refers to the local route group. Because theemergency call was
placed from a UK phone, the local route group in the device pool of the phone refers to the UKgate\sa\. Atthat galewa\. a global transformation of the called number (from 888 to 999) isconfigured, "fherefore. the call exits the UK gateway with a destination number of
999. uhich is the appropriate emergency numberto be used in the United Kingdom.
1-144
ImplementingCisco Unified Communications Manager. Part 2 (CIPT2)v8.0
An E.l. user dials 112 (E.U. emergency number): The dialed E.U. emergency number 112 is translated to the corporate emergency number 888. After translation, the 888 route pattern is matched. The route list of the route pattern refers to the local route group. Because the emergency call was placed from an E.U. phone, the local route group in the device pool of the phone refers to the E.U. gateway. At that gateway, a global transformation of the called number (from 888 to 112) is configured. Therefore, the call exits the E.U. gateway with a destination number of 112, which is the appropriate emergency number to be used in the E.U. An Australian user, currently located at an E.U. site, dials 000 (Australian emergency number):The dialed Australian emergency number 000 is translated to the corporate emergency number 888. After translation, the 888 route pattern is matched. The route list of the route pattern refers to the local route group. Because the emergency call was placed from an E.U. phone, the local route group in the device pool of the phone refers to the E.U. gateway. At that gateway, a global transformation of the called number (from 888 to 112) is configured. Therefore, the call exits the E.U. gateway with a destination number of 112, which is the emergency number in the European Union.
The Australian user can use an E.U. phone (with an E.U. extension), or use their own device
Note
with device mobility enabled, or use an E.U. phone with their own extension (by using Cisco Extension Mobility). In all three scenarios, the emergency call would work fine as described earlier. The reason is that the device pool of the phone will be the E.U. device pool in all three scenarios (with device mobility enabled, the home device pool would be replaced by the roaming device pool), and hence the local route group is always the EU-GW.
The only problem would be if the Australian user were using their own device with device
mobility disabled. In this case, the local route group would refer to the Australian gateway, and therefore the call would be sent through the Australian gateway instead of through the
local E.U. gateway. The localized egress number would be appropriate for an Australian gateway (transformed to 000), so that the user would get connected to an Australian
emergency service.
1-145
Considering Globalized Call-Routing Interdependencies

This topic describes how globalized call routing interacts with other dial plan features.
Globalized Call-Routing Interaction

Other Dial Plan Features
with
Globalized call routing simplifies the implementation of several dial plan features in an international
environment:
TEHO
AAR
SRST or CFUR
Cisco Device Mobility Cisco Extension Mobility
Globalized call routingsimplifies the implementation of severaldial plan features in an international deployment, fhe affected dial planfeatures include TEHO, automated alternate routing (AAR). Cisco Unified SRST andCEUR. Cisco Device Mobility, andCisco Extension
Mobility.
If TEHO is configured, the appropriate TEHO gateway is used for the PSTN call. The TEHO route list can include the Default Local Route Groupsettingas a backup path. In this case, if the priman. (TEHO) path is nota\ailable.the gateway that is referenced by the local route group of the applicable device pool will be used for the backup path. I(The device pool
selection is not static, but Cisco Unified Device Mobility is used, the gateway olThe roaming site will be used as a backup for the TEHO path.
Thesame situation applies lo Cisco Extension Mobility. When a user roams to another site and
logs in to a local phone. PSTN calls will use the local gateway (ifTEHO isnot configured) or
the local gateway uill be used as a backup (if TEHO is configured). The local gateway
selection is not based on the Cisco Extension Mobility user profile, but on the device pool ot
the phone where the user logs in. fhe line CSS. however, isassociated with the user profile,
and therefore the user can dial PSTN numbers the same way that the user does at home, fhe
localized input is then globalized. After call routing and path selection occur, the globalized number is localized again based ontherequirements of theselected egress device. The localized input fonnat that theuser used can be completely different from the localized format
that is used at call egress.
1-146
Implementing Cisco Unifed Communications Manager. Part 2 (CIPT2)v8.0
Globalized Call RoutingTEHO Advantages

fhis subtopic reviews the advantages of using globalized call routing in an international dial
plan that uses TEHO.
Globalized Cal! RoutingTEHO Advantages

With local route groups, there is no need to have duplicate TEHO patterns for each originating site.
Local PSTN backup is selected by local route group.

Called number has to be in a format that can be manipulated at primary path (TEHO gateway) and backup gateway.
Ifgateways are in separate countries, having the called number in globalized format is easier.
As discussed earlier,when you are using local route groups, there is no need to have duplicated TEHO route patterns for each originating site. Instead, the local PS'fN gateway is selectedby the local route group feature when the TEHO path cannot be used. Whencombining globalized call routing with local route groups,you do not have to care about the variouspossible input formats for the TEHO call-routing decision. No matter how the user dialed the number, it is changed to globalized format before it is routed. Because the called number is then localized after call routing and path selection, you can localize the called- and calling-party number differently at the primary gateway (TEHO gateway) and the backup gateway (localgateway). However, the global transformations that you configure for each egress gateway all refer to a single formata globalized format regardless of how the user dialed the destination. This globalized format that is combined with local route groups for local backup gateway selection, makes implementing TEHO much simpler. Without globalized call routing, youwould haveto perform localization at the egress gateway differently foreach
originating site.
)2010Cisco Systems, Inc
1-147
Globalized Call RoutingTEHO Example

The figure shows an exampleof TEHO when globalized call routing is used.
Globalized Call RoutingTEHO Example

EU. Gateway Called_Par!
000 14065551234
USTEHO-
\* i -> PreDot,
ISDN Number
Pattem
E U User 900 14085551234

Globalization
Type1 International
Roule Ust
TEHO-U S
(Localized
UK Gateway
Ingress
Roule Ust
-j^|&! Transformation
Called-Party
(Three
Translalion
TEHO-U S
9 5551234
Patterns)
Route
Groups
1)U S RG 2) Default
LRG
U.S. Gateway
Called-Party
User n U S .Area
Code 408 Primary Path Backup Path
.s3*2T*
Transformation
At the call ingress side, there are three PSTN dial rules: E.U.. UK,and United StatesThe same rules applv to the egress gateways: the E.U.. UK, and U.S. gateways all require dilTerent digit manipulation when you are sending calls to the PSTN.
As long as users areallowed to roam between sites and TEHO with local backup is inplace,
users can dial each PSTN destination differently at each site. In addition, if the TEHO path is
notavailable, the local gateway (which again can be anyof the three) is used for backup. With
globalized call routing, vou do not have to consider all possible combinations ofingress and egress, butyou consider call ingress and call egress independent of each other.
All that vou need to configure is translation patterns for each of the PSTN dial rules (E.U.. UK. and United States), "fhen vou create TEI10 route patterns that refer to the TEHO gateway as the
first choice, and to the local gateway as the backup, using the local route group feature. At the
egress gatewavs. vou configure the called- and calling-party transfonnations, where you do not
match on all possible input formats again, buton a globalized format only.
1-148
Summary
fhis topic summarizes the keypoints that werediscussed in this lesson.
Summary
Multisite dial plans should support selective PSTN breakout with backup gateways, PSTN backup for on-net calls, TEHO, and intersite calls using access codes and site codes.
* With the addition of an access code and site code to directory numbers at each site, directory numbers no longer have to be globally unique. When calls are routed to the PSTN, calling directory numbers have to be transformed to PSTN numbers, and access codes used on dialed patterns have to be removed to ensure that calling number and called number are in accordance with PSTN numbering schemes. Selective PSTN breakout means that different gateways are used for PSTN access, depending on the physical location of
the caller.
Summary (Cont.)
When the PSTN is used as a backup for intersite calls, internal directory numbers and internally dialed patterns have to be transformed to ensure that calling number and called number are in accordance with PSTN numbering schemes.
When you implement TEHO, calls to the PSTN are routed differently, based on the physical location of the caller and
the PSTN number that was dialed. This difference ensures
that the call uses the IP WAN as much as possible and
breaks out to the PSTN at the gateway that is closest to the

dialed PSTN destination.
Globalized call routing is a dial plan concept in which the call routing is based on E. 164 numbers with a + prefix.
Globalized call routing reduces the complexity of dial plans substantially and makes it easier to implement features such as device mobility, extension mobility, AAR and CFUR, or TEHO in international deployments.
1-149
References
Cisco Svstems. Inc. Cisco UnifiedCommunications System 8.x SRND, April 2010.
http:/.''www.cisco.coni'en'US'VJoes'voice ip comm/cuem/srnd/Xx.'uc8x.html Cisco Systems, Inc. Cisco Unified ( ommunications Manager Administration Guide
Release'8.0(1/. Eebruary 2010.

http:"'www cisco.com.civI'S'docs'voice ip comm/cuem/admin/8 0 |/ccmdg/hccin-80lcm.htinl
Cisco Svstems. Inc. Cisco IOS Voice Configuration Library (with Cisco IOS Release 15.0 updates). July 2007.
http:;\\v\vv.cisco.coni'cnT'S'doc.s/ios'!2 .Vvvf c'cisco ios voice configuration librarv

lossarv/vcl.htm
1-150
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) vS.O
Module Summary
lliis topic summarizes the key points that were discussed in this module.
Module Summary
Specific issues apply to Cisco Unified Communications Manager multisite deployments. These issues include bandwidth consumption in the IP WAN, IP WAN reliance, suboptimal call routing, and NAT or security issues.
Special solutions can solve issues that apply to multisite deployments. These solutions include the use of various codecs, SRST and MGCP fallback, selective PSTN breakout,
and the use of Cisco Unified Border Element.
Connection options for multisitedeployments include various types of trunks and gateways. A multisite dial plan should support site-code dialing, PSTN backup, and TEHO. Globalized call routing simplifies international multisite dial plans.
This module discussed the issues thatapply to Cisco Unified Communications Manager multisite deployments and their possible solutions. Itdescribed thevarious connection options for muitisite deployments and how they are implemented. Itthen described how to implement a multisite dial planthat covers site-code dialing, public switched telephone network (PSTN)
backup, and tail-end hop-off (TEHO).
References
Cisco Systems. Inc. Cisco Unified Communications System 8.xSRND, April 2010.
http:.'7'vvvvw.cisco.com/en/US/docs/voice_ip_c()mm/cucm/snid/8x/uc8x.htnil
CiscoSystems, Inc. Cisco Unified Communications Manager Administration Guide

hitp:/.'vv-w-w.cisco.com/cn/US/docs/voice_ip_comm/cucm/adinin/8 0_l/ccmcfg/bccm-80lcm.html
Cisco Systems. Inc. Cisco IOS Voice Configuration Library (with Cisco IOS Release 15.0
updates). July 2007.
hup; 7ww w.cisco.com/'en/US/does/ios/l2..3/vvf_c/cisco. ios_voice...configuration librarv_g

lossaryvcl.htm
>2010Cisco Systems, inc.
1-151
1-152
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8 0
Module Self-Check
Use the questions here to review whatyou learnedin this module. The correct answersand
01)
Which of the following is not an issue in Cisco Unified Communications Manager multisite deployments? (Source: Identifying Issues in a Multisite Deployment)
A) D) C) D) E) availability quality bandwidth security Call Admission Control
Q2)
Which of these statements does not apply to IP networks? (Source: Identifying Issues in a Multisite Deployment) A) B) C) D) IP packets can be delivered in incorrect order. Buffering results in variable delays. Tail drops result in constant delays. Bandwidth is shared by multiple streams.
Q3)
Which statement most accurately describes overhead for packetized voice? (Source: Identifying Issues in a Multisite Deployment) A) B) C)
D)
VoIP packets are large and sent at a high rate. The Layer 3 overhead of a voice packet is not significant. Voice packets have small payload size and are sent at high packet rates.
Packetized voice has the same overhead as circuit-based voice.
Q4)
In a multisite deployment, IP phone and packets are affected by WAN failures. (Source: Identifying Issues in a Multisite Deployment)
A) data, video
B)
C)
signaling, data
data, media
D) Q5)
signaling, media
Which two of the following are dial plan issues in multisite deployments? (Choose two.) (Source: Identifying Issues in a Multisite Deployment) A) B) C) D) F) overlapping directory numbers overlapping E.164 numbers variable-length addressing centralized call processing centralized phone configuration
Q6)
Which of these is a requirement for performing address translation for Cisco IP phones? (Source: Identifying Issues in a Multisite Deployment)
A) use DHCP instead of fixed IP addresses
B)
exchange media streams with the outside world
C)
D)
use DNS insteadof hostnames in Cisco UnifiedCommunications Manager

exchange signaling information with the outside world
>2010CiscoSystems.Inc.
1-153
Q7)
Which of the following is not a solution for multisite environments? (Source: Identifying Multisite Deployment Solutions)
A) B) C) D) QoS site codes SRST MGCP
Q8)
When implementing QoS. how is the quality of voice streams provided? (Source:
Identifying Multisite Deployment Solutions)
Q9)
Which two statements are tme about bandwidth solutions in a multisite deployment? (Choose two.) (Source: Identifying Multisite Deployment Solutions)
A) B)
C)
RTP-header compression compresses the RTP header to 2 bytes.

WAN bandwidth can be conserved by using low-bandwidth codecs within a
remote site.
WAN bandwidth can be conserved by deploying local media resources.
D)
E)
Voice compression is part of RTP-header compression.

Multicast MOH from branch router flash totally eliminates the need to send
MOH over the WAN.
QIO)
Which tuo statements are tme about availability? (Choose two.) (Source: Identifying
Multisite Deployment Solutions)
A) B) C)
CFNB is required to enable main-site phones to call remote-site phones during

SRST fallback.
SRS'f provides a fallback for Cisco IP phones. MGCP fallback allows the gateway to use local dial peers when the call agent
is not reachable.
D)
F)
AAR is required to enable phones to reroute calls over the PS'fN when the IP
WAN is down.
MGCP fallback and SRS'f cannot be implemented at the same device.
Ql 1) Whichof the following are notdial-plan solutions for multisite Cisco Unilied Communications Manager deployments? (Choose two.) (Source: Identifying Multisite
Deplovment Solutions)
A) B) C) D) access and site codes TEHO globalized call routing shared lines
E)
overlap signaling
QI2)
Which Cisco IOS feature provides signalingand media proxy functionality in order to eliminate the need for NAT? (Source: Identifying Mullisite Deployment Solutions)
A) B) C) Cisco Unilied Border Element in flow-through mode Cisco PIX Firewall Cisco Unitied IP-to-Proxy Gateway
D)
Cisco Unilied Border Element in flow-around mode
1-154
implementing Cisco Unified Communications Manager. Pari 2 (CIPT2) v8.0
Q13)
Whichofthe following is nota connection option for a multisiteCisco Unified Communications Managerdeployment? (Source: Implementing Multisite Connections)
A) SIP trunk
B) C)
D)
SIP gateway H.323 gateway

H.225 trunk
Q14)
Which two commands are required to enable MGCP at a gateway when using the configuration server feature? (Choose two.) (Source: Implementing Multisite
Connections) A) B) mgcp seep
C) D) E) Q15)
ccm-manager config server ip-address ccm-manager config ccm-manager seep
Which parameter is set in the H.323 gateway configuration window in order to strip the called party number to a certain number of digits? (Source: Implementing Multisite
Connections)
A) B) C)
Called Party Digits Mask Significant Digits Calling Party Transformation Mask
D) F) QI6)
Number-Length Discard Digit Instruction
Which two tmnks are not configured with the IP address ofthe next signaling device in the path? (Choose two.) (Source: Implementing Multisite Connections)
A) H.225 trunk
B)
C)
nongatekeeper-controlled intercluster trunk

SIP trunk
D)
E)
gatekeeper-controlled intercluster tmnk

MGCP trunk
Q17)
Where do you configure SIP timers and features for an SIP trunk? (Source:
Implementing Multisite Connections) A) B) C) D) SIP profile SIP security profile SIP tmnk security profile common trunk profile
Q18)
Which ofthe following needs to be specified in the gatekeeper configuration window when adding a gatekeeper to Cisco Unified Communications Manager? (Source:
Implementing Multisite Connections)
A) B)
C)
H.323 ID of the gatekeeper

IP address ofthe gatekeeper
zone name
D)
technology prefix
1-155
QI9)
Which statement about implementing PSTN backup for the IP WAN is true? (Source:
Implementing a Dial Plan for International Multisite Deployments) A) B) C) In distributed deployments. PSTN backup for intersite calls requires CFUR. PSTN backup requires a signaling proxy at each site. The on- and oft-net paths are required in route groups for PSTN backup in a centralized deplovment.
D)
Q20)
CFUR allows remote-site phones to use the PSTN for calls to the main site.
What is required for implementing access and site codes in a centralized deployment? (Source: Implementing a Dial Plan for International Mullisite Deployments)
A) B) C) D) Q2I)
a separate translation pattern per destination site, which is configured with a CSS that prov ides access to the destination site a separate translation pattern per source site, which is configured with a CSS that provides access to the source site a separate translation pattern per source site, which is configured with the partition ofthe destination site a separate translation pattern per destination site, which is configured wfth the partition ofthe destination site
Which ofthe following is not a valid type of number code for incoming ISDN PSTN calls? (Source: Implementing a Dial Plan for International Multisite Deployments)
A) B) C) D) international national subscriber directorv- number
Q22)
fhe PSTN egress gateway can be selected in which two of these ways? (Choose two.) (Source: Implementing a Dial Plan for International Multisite Deployments)
A) B) C) D) by the partition ofthe calling device based on the CSS ofthe gateway bv the local route group feature based on the matched roule pattern when route patterns exist once per site
F)
Q23)
by the standard local routegroup that is configured at the gateway device pool
Where can digit manipulation be performed when digit manipulation requirements vary for the on- and off-net paths? (Source: Implemenlinga Dial Plan for International
Multisite Deployments)
A)
B) C) D)
per route group ofthe route list

route pattern directorv number translation pattern
Q24)
When implementing TEHO for national calls and using the local PSTN gateway as a
backup, how many route patterns arerequired fora cluster with three siteslocated in different area codes?(Source: Implementing a Dial Plan for International Multisite
Deplov ments)
A) B) C) D)
3. when not using the local route group feature 6. when using the local route group feature 9. when not using the local route group feature 4. when using the local route group feature
1-156
Implementing Cisco Unitied Communications Manager. Part2 (CIPT2) v8 0
Q25)
Which of these is used to globalize the callingparty number of inbound PSTN calls? (Source: Implementing a Dial Plan for International Multisite Deployments)
A)
B)
globalization type
called number
C) D) Q26)
inbound gateway identifier number type
The implementation of globalized call routing does not simplify the deployment of which two of these features? (Choose two.) {Source: Implementing a Dial Plan for International Multisite Deployments)
A)
TEHO
B) C) D) E) F) G)
Device Mobility
AAR
MOH
Cisco Extension Mobility

SRST
local conference bridges
1-157

on
02) Q3i O-ti
05) 061 Q7) OS)
E
C C D
A.C
B D
Voice packets are given absolute pnority over other traffic

C. V: B.C
I).)-. A B
Q9) QIO)
qui 012) 013) 014)
C. D
B
Q15> 016)
017)
A. D
A B
Q18) 019) Q20) 0^1) 022) 02?) 024)

025)
C
A
D c. n
A
Q26)
D.G
1-158
Module 2

Overview
The capability to use centralized call-processing devices that are located at remote sites depends on the availability of Cisco Unified Communications Manager at the main site. To provide these devices with a backup, you can use Media Gateway Control Protocol (MGCP)
fallback and Cisco Unified Survivable Remote Site Telephony (SRST).
This module describes the mechanisms for providing call survivability and device failover in remote sites. It describes how to configure Cisco IOS routers as Cisco Unified SRST gateways and how to use Cisco Unified Communications Manager Express in Cisco Unified SRST mode.
Module Objectives
Upon completing this module, you will be able to implement call-processing resiliency in remote sites by using Cisco Unified SRST, MGCP fallback, and Cisco Unified Communications Manager Express in Cisco Unified SRST mode. This ability includes being able to meet these objectives:
Describe the mechanisms for providing call survivability and device failover in remote
sites, including the functions, operation, and limitations of each mechanism
Configure Cisco Unified SRST to provide call survivability for IP phones, and MGCP fallback for gateway survivability
Configure Cisco Unified Communications Manager Express to provide telephony services
to IP phones if the connection to the centralized call agent is lost
2-2
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v80
Lesson 1
Examining Remote Site Redundancy Options

Overview
"fhis lesson provides an overview ofthevarieties ofremote site redundancy inCisco Unified Communications Manager multisite installations, 'fhese various mechanisms areillustrated to give you an understanding of how the technologies interact to deliver reliable communication
sen.ices. Theremote siteredundancy mechanisms include the Media Gateway Control Protocol (MGCP) and Cisco Unilied Survivable Remote Site Telephony (SRST).
Objectives
Upon completing this lesson, youwill be able to describe the mechanisms forproviding call survivability and device failover inremote sites, including thefunctions, operation, and
limitations of each mechanism. This ability includes being able to meet these objectives:

Describe remotesite redundancy optionsand comparetheir characteristics

Describe how Cisco Unified SRST works Describe how MGCP fallback works
Describe Cisco Unified SRST versions, their protocol support, their features, and the required Cisco IOS Software releases
Describe dial plan requirements for MGCP fallback and Cisco UnifiedSRST
Remote Site Redundancy Overview

This topic describes the various technologies that are used toprovide remote site redundancy for small and medium remote sites in a Cisco Unified Communications Manager environment. Cisco Unified SRS'f and MGCP gatewav fallback are the key components to the delivery of
fail-safe communication services.
SRST and MGCP Fallback

In the case of a WAN failure, the Cisco Unified Communications
Manager servers are unreachable for devices located in remote
sites. Service survivability is provided by two technologies:

* Cisco Unified SRST provides call control services to remote IP phones. MGCP fallback provides voice gateway functions when the MGCP call agent
is not in control of the media gateway
Main Site
RSIN Remote Site
Cisco Unifed
Communications
Manager
Cisco Unified Communications Manager supports Cisco Unitied IP phones at remote sites that
are attached to Cisco multiservice routers across the WAN. Before Cisco Unified SRST was available, when the WAN connection between a router and the Cisco Unified Communications
Manager failed or when connectivity with Cisco Unified Communications Manager was lost. Cisco Unified IP phones on the network became unusable for the duration ofthe failure.
Cisco Unified SRST overcomes this problem and ensures that Cisco Unified IP phones offer
continuous (although minimal) service by providing call-processing support for Cisco Unified
IP phones directly from the Cisco Unified SRS'f router. The system automatically detects a failure and uses Simple Network-Enabled Auto Provision (SNAP) technology to autoconfigure the branch office router to provide call processing for Cisco Unified IP phones that are registered with the router. When the WAN link or connection to the primary Cisco Unitied Communications Manager subscriber is restored, call processing reverts lo the primary Cisco Unified Communications Manager.
MGCP gatewav fallback is a mechanism that allows a Cisco IOS router to continue to provide voice gateway functions even when the MGCP call agent is not in control ofthe media gateway, fhese voice gatewav functions are implemented through a fallback mechanism that
activates the so-called default technology application. The gateway then works in the same way
as a standalone H.323 or Session Initiation Protocol (SIP) gateway.
Remote Site Redundancy Technologies

'fhe table lists the capabilities ofdifferent remote site redundancy technologies.
Remote
Site Redundancy Technologies

Cisco Umfied SRST
Cisco Unified
MGCP
Fallback
Unified SRST SCCP
Cisco Unified
Communications
SIP SRST
SIP
Manager Express in
SRST Mode
SCCP
Provides
dGCP-eontrolled
redundancy for
Deivered service ISDN cal
gateways
Faitoack to
phones
Basic
phones
Basic
phones Cisco Unified Communications
Cisco IOS
defaut
telephony
service
Yes
SIP proxy
service
Yes
technology
preservation
Manager Express
Yes
(no MGCP)
(no MGCP)
Yes
(no MGCP)
Yes
Analog/CAS call preservation

Maximum number of
(NA)
1500
450
phones
To use Cisco UnifiedSRSTas your fallback modeon an MGCP gateway, you must configure Cisco Unified SRST and MGCP fallback on the same gateway. MGCP and Cisco Unified SRST have had the capability to be configured on the same gateway since Cisco IOS Software
Release 12.2(11)T.
Cisco Unified SRSTalso provides a basic set of featuresto SIP-based IP phones. This set of
Cisco Unified SRST basic features is also known as Cisco Unified SIP SRST. Cisco Unified
SIP SRST has to be enabledand configured separately on Cisco IOSrouters. Cisco Unified SRST versions 3.3 and earlier provide a SIP Redirect Server function; in subsequent versions,
this function acts as a back-to-back user agent (B2BUA).
Cisco Unilied Communications Manager Express in Cisco Unified SRST mode provides more features to a smaller maximum number of IP phones by falling back to Cisco Unified Communications Manager Express mode. The main feature enhancements include presence, Cisco Extension Mobility, and support of local voice-mail integrations.
VoIP call preservation sustains connectivity for topologies in which signaling is managed by an entity (such as Cisco Unified Communications Manager) that is different from the other endpoint and that brokers signaling between the two connected parties.
Call preservation is useful when a gateway and the other endpoint (typically a Cisco Unifi ;d IP phone) are eolocated at the same site and the call agent is remote. In such a scenario, the call agent, the gateway with the remote endpoint, will more likely experience connectivity failures.
Cisco Unified Communications Manager Express version 8.0 supports a maximum of 450 IP phones (Cisco IOS 3945E router) while Cisco Unified SRST version 8.0 supports up to 1500 IP phones on the same platform. Refer to "Cisco Unified Communications Manager Express 8.0" (http://v\^^v.eisco.coni/en.TJS/prod/collatcral/voiccsvv/ps6788/vcallcon/ps4625/data_shcct_c78567246.html) for more details about the supported number of phones.
i 2010 Cisco Systems. Inc.
2-5
When to Use MGCP Fallback

MGCP gateway fallback that is configured as an individual feature can be used by a public switched telephone network (PSTN) gateway if H.323 (orsome other voice application Iis configured as a backup service. Cisco Unified SRST and MGCP fallback must be configured
on the same gateway if this singlegateway should provide Cisco Unified SRSI' fallback service
to phones and MGCP gateway fallback.
When to Use MGCP Fallback
MGCP fallback allows MGCP-controlled gateways to

fall back to a default telephony application like H.323
orSIP:
Might be used as a standalone feature to provide analog

phones locally attached to a Cisco IOS router with survivability
Is most often used together with Cisco Unified SRST, which has been supported on the same Cisco IOS router since Cisco IOS Software Release 12.2(11)T Provides gateway functionality to Cisco Unified IP phones
in SRST mode
No call preservation for ISDN PRI or BRl interfaces
Although MGCP gatewav fallback is most often used together with Cisco Unified SRST to provide gateway functions to IP phones in Cisco Unified SRS'f mode, it can also be used as a standalone feature. One example is that for a fax application server that uses a PRI ISDN interface that is controlled by MGCP, connectivity to the PSTN can be preserved by MGCP gateway fallback. Another example of an MGCP-fallback standalone configuration is a mechanism that allows analog interfaces that arc controlled by Skinny Client Control Protocol (SCCP) to stay in service even when the WAN connection to the Cisco linified Communications Manager is down. MGCP gatewav fallback preserves active calls from remote site IP phones lo the PSTN when
analog or channel associated signaling (CAS) protocols are used, for ISDN protocols, call
preservation is impossible, because Layer 3 ofthe ISDN stack is disconnected from the MGCP
call agent and is restarted on the local Cisco IOS gateway. Consequently, for active ISDN calls, all call-state infonnation is lost in cases of switchover to fallback operation.
When to Use Cisco Unified SRST

Cisco Unified SRST provides Cisco Unified Communicalions Manager with fallback support for Cisco Unified IP phones that are attached to a Cisco router ona local network.
When to Use Cisco Unified SRST Cisco Unified SRST provides limited call control service to SCCP and SIP phones in remote sites
during WAN outage: Supports up to 1500 IP phones during fallback service Supports secure voice fallback (ifsecurity is enabled) Allows simple, one-time configuration for SRST fallback
service
Only basic telephony feature support - No message-waiting indication - No advanced features such as Cisco Extension Mobility or
presence
Cisco Unified SRST enables routers to provide basic call-processing support for Cisco Unified
IP phones when they loseconnection to remote primary, secondary, and tertiary Cisco Unified
Communications Manager installations or when the WAN connection is down.
Cisco UnifiedSRSf also supportssecurity features. If IP phones are configured with security mode authenticated or encrypted in Cisco Unified Communications Manager and secure Cisco Unified SRST is deployed, securityfeatures of Cisco IP phones are preservedduring fallback. Cisco Unified SRSTcan support SIP phoneswith the standard RFC 3261 feature locallyand
across SIP WAN networks. With Cisco Unified SIP SRST, SIP phones can place calls across SIP networks in the same way that SCCP phones do.
Cisco Unified SIP SRST supports the following call combinations: SIP phone to SIP phone, SIP phone to PSTN or router voice port, SIP phone to SCCP phone, and SIP phone to WAN
VoIP using SIP.
SIP proxy, registrar, and B2BUA servers are key components of a SIP VoIP network. These servers are usually located in the core of a VoIP network. If SIP phones that are located at remote sites at the edge ofthe VoIP network lose connectivity to the network core (because of a WAN outage), they may be unable lo make or receive calls. Cisco Unified SIP SRST functionality on a SIP PSTN gateway provides service reliability for SIP-based IP phones in the event of a WAN outage. Cisco Unified SIP SRST enables the SIP IP phones to continue to
make and receive calls to and from the PSTN and also to make and receive calls to and from
other SIP IP phones.
When the IP WAN is up. the SIP phone registers with the SIP proxy server and establishes a connection to the B2BUA SIP registrar (B2BUA router). But any calls from the SIP phone go to the SIP proxy server through the WAN and out to the PSTN.
2-7
When the IP WAN has failed or the SIPproxy server hasgonedown, the call from the SIP phone cannot getto the SIP proxy server. The SIP phone instead goes through the B2BUA
router and out to the PS'fN.
Note
The B2BUA acts as a user agent to both ends ofa SIP call. The B2BUA is responsible for
managing all SIP signaling between both ends of the call, from call establishment to
termination Each call is tracked from beginning to end, allowing the operators of the B2BUA to offervalue-added features to the call. To SIP clients, the B2BUA acts as a user agent server on one side and as a user agent client on the other (back-to-back) side. The baste
implementation of a B2BUA is defined in RFC 3261.
Cisco Unified SRSTdoes not supportenhanced features such as presence or Cisco Extension Mobility. Message Waiting Indicator (MWI) is also not supported in fallback mode.
2-8
When to Use Cisco Unified Communications Manager Express

in SRST Mode Cisco Unified Communications Manager Express in SRST mode enables routers to provide call-processing support to Cisco Unified IP phones by Cisco Unified Communications Manager Express ifthe phones lose connection toremote primary, secondary, and tertiary Cisco Unified
Communications Manager installations or if the WAN connection is down.
When to Use Cisco Unified Communications
Manager Express in SRST Mode

Cisco Unified Communications Manager Express in SRST mode provides backup telephony service during WAN outage:
- Supports automatic Cisco Unified SRST configuration (basic
features only). Additional features can be applied globally by templates or on a per-phone basis by manual configuration.
All features available in Cisco Unified Communications
Manager Express are supported.
- Features not supported by standard Cisco Unified SRST

have to be statically configured (by templates or per phone).
- Mix of preconfigured phones and automatically configured phones is supported.
When Cisco Unified SRST functionality is provided by Cisco Unified Communications Manager Express, you can use automatic provisioning of phones like with standard Cisco Unified SRST. However, due to the wide feature support of Cisco Unified Communications Manager Express, more features can be utilized, compared with standard Cisco Unified SRS'f. Examples of features that are provided only by Cisco Unified Communications Manager Express in SRST modeare Call Park,presence,Cisco Extension Mobility, and accessto Cisco Unity Voice Messaging services using SCCP. These features, however, cannot be configured automatically when a phone falls back to SRST mode. If a certain feature is applicable to all phones or directory numbers, the configuration can be applied by a corresponding template. If features have to be enabled on a per-phone (or perdirectory number) basis, they have to be statically configured.
Phones that do not require unique feature coniiguration can be configured automatically so that only those phones that require individual configuration have to be statically configured in Cisco Unified Communications Manager Express.
Cisco Unified SRST Operation

This topic describes die function of Cisco Unified SRST.
Cisco Unified SRST Function; Normal Situation

Branch IP phones register with Cisco Unified Communications Manager
IP phones exchange keepalive messages with the central Cisco Unified Communications Manager across the WAN. Cisco Unified Communications Manager manages all call
processing
Main Site
Manager
-W.N
Cisco Unified Communications Manager supports Cisco Unified IP phones al remote sites that are attached to Cisco multiserv ice routers across the WAN. fhe remote site IP phones register with Cisco Unitied Communications Manager. Keepalive messages are exchanged between IP phones and the central Cisco Unified Communications Manager across the WAN. Cisco Unified Communications Manager at the main site manages the call processing for the branch IP phones.
2-10
Cisco Unified SRST Function: Switchover Signaling

When Cisco Unified IP phones lose contact with Cisco Unified Communications Manager, they register with the local Cisco Unified SRST router tosustain the call-processing capability that
is necessary to place and receive calls.
Cisco Unified SRST Function:
Switchover Signaling
Ifthe WAN linkfails, IP phones lose contact with Cisco Unified Communications Manager IP phones register with local gateway.
Gateway queries IP phones for configuration and it autoconfigures

itself.
Main Site
Remote Site
Register
~T
Cisco Unified
Communications
T1
Manager
Cisco Unified SRST configuration provides the Cisco Unified IP phones with the alternative
call control destination ofthe Cisco Unified SRST gateway.
When the WAN link fails, the Cisco Unified IP phones lose contact with the central Cisco Unified Communications Manager but then register with the local Cisco Unified SRST
gateway.
The Cisco Unified SRST gateway detects newly registered IP phones, queries these IP phones for their configuration, and then autoconfigures itself. The Cisco Unified SRST gateway uses SNAP technology to autoconfigure the branch office router to provide call processing for Cisco
Unified IP phones that are registered with the router.
Cisco Unified SRST Function: Call Flow After Switchover

Cisco Unified SRS'fensures that Cisco Unified IP phones offercontinuous service by providing call-processing support directly from the CiscoUnified SRST router, using a basic
set of call-processing features.
Cisco Unified SRST Function: Cal! Flow After Switchover

Calls between remote site phones survive switchover. Remote site calls using the local non-MGCP gateway survive switchover. - Gateway provides call processing for duration of WAN failure.
Cisco Unified SRST features such as autoprovisioning and failover are

supported
Main Site
Remote Site
Public E.164 Cisco Unifed Communications
"L*
j-
Calls ~*q|S
Manager
The Cisco Unified SRST gateway uses the local PSI'N breakout. Cisco Unified SRST features, such as call preservation, autoprov isioning. and failover are supported. During a WAN connection failure, when Cisco Unified SRST is enabled, Cisco Unified IP phones display a message informing users that ihe phone is operating in Cisco Unified Communications Manager fallback mode. This message can be adjusted.
While in Cisco Unified Communications Manager fallback mode, Cisco Unified IP phones
continue to send out keepalive messages to attempt to re-establish a connection with Cisco Unified Communications Manager at the main site.
2-12
implementing Cisco Unified Communications Manager, Part 2 (CIPT2) v8.0
Cisco Unified SRST Function: Switchback

Cisco Unified IP phones attempt to re-establish aconnection with Cisco Unified Communications Manager at the main site periodically when they are registered with aCisco
Unified SRST gateway.
Cisco Unified SRST Function:

Switchback
WAN link isrestored, and IPphones areable tore-establish contact with
Cisco IP Phones re-register with their primary Cisco Unified Communications

Manager
Call processing reverts tothe primary Cisco Unified Communications

Manager
Main Site
Reregister
Public E 164
RemoteSite
Cisco Unified \**r

Communications
^ _
j&.^.
Calls
Manager
The default time that Cisco Unified IP phones wait before attempting to re-establish a connection to aremote Cisco Unified Communications Manager is generally up to 120
seconds.
When the WAN link or connection to the primary Cisco Unified Communications Manager is
the Cisco IOS router: immediate switchback, graceful switchback (after all outgoing calls on
SRST returns to standby mode.
restored, after aconfigured waiting behavior, the Cisco Unified IP phones reregister with their
primary Cisco Unified Communications Manager. Three switchback methods are available on
the gatewav are completed), or switchback after aconfigured delay. Once switchback is completed.'call processing reverts to the primary Cisco Unified Communications Manager, and
2-13
Cisco Unified SRST Timing

It typically takes three times the keepalive period for aphone lo discover that its connection to Cisco Unified Communications Manager has failed. The default keepalive period is 3(1 seconds.
Cisco Unified SRST Timi
Cisco Unifed SRST Router

' ii i "'
TCPKeepalrvepelault30Sec
;
i i
E Time for SRST
h
Apprai 60 Sec Aopror, 60 Sec
WAN connection fails
Afterthree missed keepalive messages,
j Registration Process
I 10-20 Sec TCP Keepalive
Detault 30 Sec
Phone regrsters with SRST ruuler
*i SRST router pulls IPphone coniiguration *j Phone fully associatedwith SRST rouler
: WANconnection restored phone
ti re establishesTCPconnector keepalive
Switchback Timer
Default 120 Sec
j from Unified CM* received agan
Unified CM - Cisco Unrfied CommunicationsManager
Ifthe IP phone has an active standby connection that is established with a Cisco Unilied SRST
router, the fallback process takes 10 to 20 seconds after the connection with Cisco Unified Communications Manager is lost. An active standby connection to a Cisco Unified SRS'f
router exists onlv- ifthe phone has a single Cisco Unified Communications Manager in its Cisco Unified Communications Manager group. Otherwise, the phone activates a standby connection
to its secondary Cisco Unified Communications Manager.
Note
The time that it takes for an IP phone to fall back to the Cisco Unified SRST router can vary
depending on the phone type Phones suchas the Cisco Unified IPPhone 7902G, 7905G.
and 7912G models can take approximately 2 5 minutes to fatl back to SRST mode.
Ifa Cisco Unified IP phone has multiple Cisco Unified Communications Manager systems in its Cisco Unified Communications Manager group. Ihe phone progresses through its list before attempting to connect with its local Cisco Unified SRST router. Therefore, the time that passes
before the Cisco Unified IPphone eventually establishes a connection with the Cisco Unified SRST router increases witheach attempt to contact to a Cisco Unified Communications
Manager. Assuming that each attempt to connect to aCisco Unified Communications Manager
takes about 1minute, the Cisco Unified IPphone inquestion could remain offline for 3 minutes or more following a WAN link failure. You can reduce this time by setting the keepalive timer
toa smaller value. You can configure the keepalive timer by using the Cisco CallManager
service parameter Station Keepalive Interval.
While in SRST mode. Cisco Unified IP phones periodically attempt to re-establish a connection
with Cisco Unified Communications Manager at the main site. The defaulttime that Cisco Unified IP phones wait before attempting to re-establish a connection to Cisco Unified Communications Manager is generally 120 seconds.
2-14
MGCP Fallback Operation

This topic describes howthe MGCP gateway fallback mechanism works.
MGCP Gateway Fallback:

Normal Situation
MGCP gateways register with Cisco Unified Communications Manager.
MGCP gateways exchange keepalive messages with the central Cisco

Unified Communications Manager across the WAN. Cisco Unified Communications Manager is the MGCP call agent.
Manager
MGCP gateway fallback is a feature that improves the reliability of MGCP branch networks. A WAN link connects the MGCP gateway at a remote site to the Cisco Communications Manager at a central site, which is the MGCP call agent. If the WAN link fails, the fallback feature keeps the gateway working as an H.323 or SIP gateway and re-homes back to the MGCP call agent when the WAN link is active again. MGCP gateway fallback works along with the Cisco
Unified SRST feature.
Cisco IOS gateways can maintain links to up to two backup Cisco Unified Communications Manager servers in addition to a primary Cisco Unified Communications Manager. This redundancy enables a voice gateway to switch over to a backup server if the gateway loses communication with the primary server. The secondary backup server takes control ofthe devices that are registered with the primary Cisco Unified Communications Manager. The tertiary backup takes control ofthe registered devices if both the primary and secondary backup Cisco Unified Communications Manager systems fail. The gateway preserves existing connections during a switchover to a backup Cisco Unified Communications Manager. When the primary Cisco Unified Communications Manager server becomes available again, control reverts to that server. Reverting to the primary server can occur in several ways: immediately, after a configurable amount of time, or only when all connected sessions are
released.
2-15
MJ3CP Gateway Fallback: Switchover

The MGCP gateway performs a switchover to its default technology when the keepalives between Cisco Unified Communications Manager and the Cisco MGCP gateway are missing.

Switchover
If the WAN link (ails. MGCP gateways lose contact with Cisco Unified Communications Manager. MGCP gateway tnes to connect to the fallback Cisco Unified
MGCP gateway falls back to its default application (H.323 or SIP).

Mam Site
Remote Siti
Cisco Unified Communicati
Manager
The MGCP gatewav fallback feature provides the following functionality: MGCP gateway fallback support: All active MGCP analog, F.l CAS, and Tl CAS calls are maintained during the fallback transition. Callers are unaware ofthe fallback transition, and the active MGCP calls are cleared only when the callers complete their calls (hang up). Active MGCP PRI backhaul calls are released during fallback. Any transient MGCP calls (that is. calls that are not in the connected state) are cleared at the onset ofthe fallback
transition and must be attempted again later.
Basic connection services in fallback mode: Provides basic connection services for IP
telephony traffic that passes through the gateway. When the local MGCP gateway transitions into fallback mode, the default H.323 session application assumes responsibility
for managing new calls. Onlv basictwo-party voice calls are supported during the fallback period. When a usercompletes an active MGCP call,the MGCP application processes the
on-hook event and clears all call resources.
2-16
MGCP Gateway Fallback: Switchback

The switchback or re-home mechanism is triggered by the re-establishment ofthe TCP connection between Cisco Unified Communications Manager and the Cisco MGCP gateway.

Switchback
When the WAN link is restored, MGCP gateway starts the re-home function.
MGCP gateway reregisters with Cisco Unified Communications Manager. Gateway switches back lo nomial MGCP application mode.
Cisco Unified
Communications
Manager
ITic MGCP-gateway-fallback feature provides the re-home functionality to switch back to

MGCP mode.
Re-home function in gateway-fallback mode detects the restoration of a WAN TCP connection to the primary Cisco Unified Communications Manager server. When the fallback mode is in effect, the affected MGCP gateway repeatedly tries to open a TCP connection to a Cisco Unified Communications Manager server that is included in the prioritized list of call agents. This process continues until a Cisco Unified Communications Manager server in the prioritized list responds. The TCP open request from the MGCP gateway is recognized, and the gateway reverts to MGCP mode. The gateway sends a RestartlnProgress (RSIP) message to begin registration with the responding Cisco Unified Communications Manager.
All currently active calls that are initiated and set up during the fallback period are maintained by the default H.323 session application, except ISDN Tl and EI PRI calls. Transient calls are released. After re-home occurs, the new Cisco Unified Communications Manager assumes responsibility for controlling new IP telephony activity.
2-17
MGCP Gateway Fallback Process

The MGCP gateway maintains a remote connection to a centralized Cisco Unified Communicalions Manager cluster by sending MGCP keepalive messages to the Cisco Unilied Communications Manager server at 15-second intervals.
MGCP Gateway Fallback Process
MGCP Gateway
! He- .si;
TCP Keepalive Detault 15 Sec
-j -.. rv-.,-.
alien:, yar-j :;
J WAN connection fails

: After two missed keepalive messages.
; .->'niu.>','jli(,rri MdrSs!'.
Gateway falls back to default application

H 323 or SIP
WAN connection restored, gateway re-establishes TCP connection; keepalive Perform switchback immediately after active can
have finished, after a fixed amount of time,
from Csco Unified Communications Manager rece ved again
or al a fixed tune of day
If the active Cisco Unified Communications Manager server fails to acknowledge receipt ofthe
keepalive message within 30 seconds, the gateway attempts to switch over lo thenextavailable
Cisco Unified Communications Manager server.
If none ofthe Cisco Linified Communications Manager servers responds, the gateway switches into fallback mode and reverts to the default H.323 session application tor basic call control. H.323 is a standardized communication protocol that enables dissimilar devices to communicate with each other by using a common set of codecs, call setup and negotiating
procedures, and basic data-transport methods. Thegateway processes calls on itsown using
H.323 until one ofthe Cisco Unified Communications Manager connections is restored.
2-18
ImplementingCisco Unitied Communications Manager, Part 2 (CIPT2)vB.O
Cisco Unified SRST Versions and Feature

Support
required Cisco IOS Software release.
This topic describes Cisco Unified SRST versions, their protocol support and features and the
Cisco Unified SRST Versions

Cisco Unified
Feature
Communications
il SRST Mode
Cisco Unified
Cisco Unified
Cisco Unified
ô/.T,658
SRS?e.O
15.0(1)XA
SRST 71
124(22)YB 15.0<1)Mon ISR
G2
SRST 43
12,4(11JXZ
Minimum Cisco 12.4(11)XJ IOS Software 15.0{1) forversion

Release
Presence
&0
/
Extension
Mobiity
Eight active
cats per line
^ (new in 8.0) "' (new in ad)
Support for
E.164 numbers
with + prefix
Five additional MOH streams
(new in 8.0)
(SCCP only)
memory requirements than older releases, so make sure that you consider these requirements
before upgrading. n
Software that is running on the router. Each Cisco IOS Software release implements one particular Cisco Unified SRST version. You can upgrade to anewer version ofCisco Unified SRST via aCisco IOS update. Some ofthe recent Cisco IOS Software releases have higher
The version ofthe Cisco Unified SRST application depends on the release ofthe Cisco IOS
For detailed information about Cisco Unified SRST versions and their hardware and feature support, refer to the Cisco Unified Survivable Remote Site Telephony Version 8.0 data sheet"
data_shect c78-57048i.html.
http://w^vv.cisco.com/cn/LlS/prod/collatcraI/voicesw/ps6788/vcallcon/ps2l69/
2-19
Cisco Unified SRST 8.0 Platform Density

The maximum number of IP phones that are supported by the Cisco Unified SRST feature depends on the Cisco IOS router platform that is used.
Cisco Unified SRST 8.0 Platform
Density
j
Platform
Maximum Number of"

IP Phones
4 15
800 Series
1861
2801-2851 2901-2951
25-100
35-250
3825, 3845
3925-394 5E
350, 730
730-1500
The figure shows asummarv ofthe maximum number ofphones that Cisco Umtied SRST
routers can accommodate. For more details, such as minimum memory requirements, refer to -Cisco Unified SRST 8.0 Supported Firmware. Platforms, Memory, and Voice Products
Note
(imp'/.'vvwvvci^co.coni.ctTU'S./docs/voice ipeomm/cusrst/rcquircmcnts/guidc/srsXOspc.himl)
These maximum numbers of IP phones are for common Cisco Unified SRST configurations
only Systems with large numbers of IP phones and complex configurations may not work on
all platforms and can require additional memory or ahigher performance platform.
2-20
implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8 0
1-106
Summary
Summary
1Connection options for multisite deployments include
gateways and trunks.
When implementing MGCP gateways, you do most of the configuration in Cisco Unified Communications Manager. When implementing H.323 gateways, you must configure both Cisco Unified Communicalions Manager and the
gateway with a dial plan.
Trunk support in Cisco Unified Communications Manager

includes SIP and three types of H.323 trunks.
SIP trunk implementation includes trunk and dial plan configuration in Cisco Unrfied Communications Manager. When configuring nongatekeeper-controlled ICTs, you must specify the IP address ofthe peer; gatekeeper-controlled ICTs and H.225 trunks require that you configure an H.323
gatekeeper instead
References
For additional infonnation. refer to these resources:
Cisco Sv stems. Inc. Cisco Unified Communications System 8.x SRND, April 2010. http:/ www.cisco.com'cn'l 'S/does/voice ip comni/'cucm/smd/oVucSvlitmi
Cisco Svstems. Inc. Cisco UnifiedCommunications ManagerAdministration Guide
Release 8.0(1>. Februarv 2010.
http:/';vuv wxisco.com/cn/1 :S.;docs.'\oicc_iji_coinm/cucm/admin/S I) l/ccmefg/hccm-80!cin.litinl
Cisco Systems. Inc. Cisco IOS Voice Configuration Library (with Cisco IOS Release 15.0 updates}. July 2007. hltp:/v\v\v\.ciM.'o.coni,'cn.'US/'docs/iosT2 3/vvf_c/cisco_ios voice_conf!giii'ation_librarv_t
iossarv \cl.htm
1-105
Unified CM* Gatekeeper-Controlled ICT and H.225 Trunk Configuration (Cont.)
Choose previously configured gatekeeper.
Trunks can register as terminal or gateway with the
gatekeeper. Choose Gateway as the terminal
a^
Enter the gatekeeper zone il
which the trunk should be
Enter the prefix that should

be registered with the gatekeeper.
registered.
* Unified CM - Cisco Unified Communications Manager
Finally, you need to provide the gatekeeper information. From the drop-down list, choose the gatekeeper that this trunk should register to, and then choose the terminal type. Cisco Unified Communications Manager can register trunks as terminals or gateways with an H.323 gatekeeper. Usually die terminal type is set to Gateway. In the Technology Prefix field, enter the prefix, which should be registered with the gatekeeper.
Note The prefix that you enter is the prefix that the trunk will register with the gatekeeper. It can,
but does not have to, include a technology prefix. In the example, a prefix of 408 is used.
More information about prefixes and technology prefixes is provided in the Implementing Cisco Voice Communications and QoS (CVOICE) course.
Then enter the zone in which the trunk should be registered.

Tip The H.323 zone name is case-sensitive. Make sure that it matches the zone name that has been configured at the gatekeeper.
1-104
Unified CM* Gatekeeper-Controlled ICT and H.225 Trunk Configuration (Cont.)

Unified CM* Administration: Device > Trunk > Add New
i.flaiKi.f^j.jijiWiMifiSffi'Mx^'
Enter trunk name,
Choose trunk
descnpiion. and
type and click

Next
device pool
| ' Unrfied CM - Cisco Unified Communications Manager |
After vou have configured the gatekeeper, you can add the gatekeeper-controlled trunk.
Navigate to Dc\ice > Trunk and click Add New. fhen choose the trunk type. As discussed earlier in this lesson, there are two tvpes of gatekeeper-controlled 11.323 trunks: gatekccpeicontrolled ICTs (which vou have to use when connecting to a version of Cisco CallManager
earlier than version 3.2) or 11.225 trunks (which are used to connect to Cisco Unified Communications Manager Version 3.2 or later, as well as other H.323 devices such as gateways or conferencing svstems).
After selecting the trunk tvpe. enter a name and description for the trunk and choose the device pool that should be used.
Implemenling Multisite Deployments
1-103
Cisco Unified Communications Manager GatekeeperControlled ICT and H.225 Trunk Configuration
This subtopic describes how to implement gatekeeper-controlled H.323 trunks in Cisco Unified
Unified CM* Gatekeeper-Controlled ICT

and H.225 Trunk Configuration
Cisco Unified Communications ManagerAdministration: Device > Gatekeeper > Add New
i ? Add the gatekeeper to Cisco Unified Communications Manager. Add gatekeeper-controfled intercluster trunk or H.225 trunk.
Catek*pT IiJi
Enter IP address
gatekeeper.
Enter description.
Make sure
gatekeeper is
enabled.
| Unified CM =Cisco Unifed Communicalions Manager |
To adda gatekeeper-controlled H.323 trunk (an H.225 trunkor a gatekeeper-controlled ICT), you first need to add a gatekeeper to Cisco Unified Communications Manager. Navigate to Device >Gatekeeper andclickAdd New. In the Gatekeeper Configuration window, enterthe IP address ofthe H.323 gatekeeper and a description, 'fhen makesure that the Enable Device
check box is checked.
1-102
Manager Nongatekeeper-Controtled
ICT Configuration (Cont.)
^'^msammmtm
tritlsl^-.l-.,!^
Enter IP address
of device on other side.
Then enter the II* address or addresses ofthe Cisco Unified Communications Managerservers
ofthe other cluster.
Note
Because the nongatekeeper-control led ICT does not use a gatekeeper for address resolution, you must manually enter the IP addresses of the devices on the other side.
) 2010 Cisco Systems,'
1-101
Intercluster and H.225 Trunk Implementation

Thistopic describes how to implement H.323 trunks in CiscoUnitied Communications
Manager.
Nongatekeeper-controlled iCT Configuration

Device > Trunk > Add New
BMkTaFlnd/Ua
E3
Enter trunk name,
First, crioose trunk
description, and device pod
type and dick

Next
The figure shows how to add a new nongatekeeper-controlled ICT. First, you navigate to
Device > Trunk-and then click Add New.
Next, you must choose the appropriate trunk type. After you click Next, the Trunk Configuration window appears, where you can configure the nongatekeeper-controlled ICT. Enter a device name and description, and choose the device pool that should be used.
1-100
SIP Trunk Configuration (Cont.)

SIP trunk security profiles are used to enable and disable security features on SIP trunks; you configure them by navigatingto System > Security Profile > SIP Trunk Security Profile Adefauft profile (with security disabled) exists. SIP profiles are used to set timers and some feature settings. You configure them by navigating to Device > Device Settings > SIP Profile. A default profile
exists
Enter IP address of
other device at end of SIPtrimk
You must choose
SIP trunk,
security profile, and SIP profile These parameters are mandatory.

no default values
exist
In the SIP Information area of the Trunk Configuration window, enter the destination addr:ss.
This IP address is for the dev ice that is located on the other end ofthe SIP trunk. This device
can be a Cisco Unified Border Element, Cisco Unified Communications Manager Express, or any other SlP-capable device, such as a third-party SIP proxy server. In addition, you must choose a SIP trunk security profile and a SIP profile. Both parameters are
mandator, and do not have a default value.
The SIP trunk security profile is used to enable and configure security features on SIP trunks, such as Transport Layer Security (TLS) with two-way certificate exchange, or SIP digest authentication. One default SIP trunk security profile exists: the nonsecure SIP trunk profile, which has security disabled. You can configure additional SIP trunk security profiles by nav igating to System > Security Profile > SIP Trunk Security Profile. The SIP profile is used to set timers, Real-Time Transport Protocol (RIP) port numbers, and some feature settings (such as Call Pickup Uniform Resource Identifiers [URIs], call hold ringback. or caller ID blocking). One default SIP profile exists: It is called a standard SIP profile. You can configure additional SIP profiles by navigating to Device > Device Settings >
SIP Profile.
SIP Trunk Implementation

Thistopic describes how 10 implement SIPtrunks in CiscoUnified Communications Manager.
Manager SIP Trunk Configuration

Cisco Unified Communications Manager Administration: Device
> Trunk > Add New
.?d.n Dev>u P'Mo col
SIB In,nl
SIP
DHJfiDnjr,
T^kU
Drtult
V
. -
t.v. J"
*s
V
common :=.,.=. Cn*,u. '- . N3ne

cadi clu*iô;n"
HUHBSJ-.M...1 . Sr.- D"Uk,ll
.N=r
LOC.OT '
AAA Ofou;
-cc.Ncr
< Non
PicHtCiCiur,.,;,,'
B.3.C.Cn,r.;U-mor
,00,
C
3*4,T>n.
t4.*J.n.d
yln^^T '.idio ~ii is aj :tl-..i.,u !*- .ot

1, ' i t , Nim
To add a SIP trunk in Cisco Unified Communications Manager, navigate to Device > Trunk and click Add New. Then, in the Trunk Type drop-down list, choose SIP Trunk and click
Next.
In the Trunk Configuration window, enter a name and description for the SIP tmnk and choose the device pool that should be used.
1-98
Trunk Types Used by Special Applications

This subtopic describes additional trunk types that can be configured in Cisco Unified Communications Manager.
Trunk Types Used by Special Applications

You can configure additional trunk types in Cisco
UnifiedlCommunications Manager that are used by
specialjapplications.
Cisco: Extension Mobility Cross Clusters: Special trunks configured between Cisco Unified Communications Manager clusters that should allow Ci^co EMCC logins
- Orly SIP supported

Call Qontrol Discovery:
- Spbcial trunks configured in Cisco Unified Ccjnmunications Manager clusters that refer to anSAFenabled network providing Call Control Discovery features
H.323 and SIP supported
Some applications require special trunk types to be configured.
For example, when implemenling Cisco Fxtension Mobility Cross Clusters (FMCC) a dedicated trunk has to be configured between the Cisco Unified Communications Manager clusters that allow users ofthe remote cluster to log in locally using Cisco FMCC. These trunks, which are exclusivelv configured for Cisco EMCC. have to use the SIP protocol; 11.323 is not supported bv Cisco FMCC. Another application that requires special trunks to be
configured is Call Control Discovery (CCD). Whenyou use CCD. internal directorv' numbers
as well as the associated external PS'fN numbers are advertised and learned from a Service
Advertisement Framework (SAF)-enabled network, fhese trunks can be cither SIP or 11.323 and must be explicitly enabled for SAF.
Note More information about Cisco EMCC and SAF trunks will be provided in the corresponding
lessons of this course.
Gatekeeper-Controlled ICT and H.225 Trunk Configuration

Overview
The figure illustrates the most important configuration elements for implementing agatekeepercontrolled ICT or H.225 trunk inCisco Unilied Communications Manager.
Gatekeeper-Controlled ICT and H.225 Trunk Configuration Overview

Cisco Unified
10.1.1 1
Communications
GK Prefix. 408 GK Prefix:

409
Cisco Unified Com municat ions
Manager 10.2.1.1
Cluster
Manager
Cluster
Gatekeeper-controlled ICT and
H.225 trunk configuration:

* Gatekeeper (GK)
Manager
Cluster
Trunkpointingto gatekeeper Route pattern, route list, route group
The trunk (which points to the gatekeeper), the route group, the route list, and the route pattern
configuration are the elements ofthe gatekeeper in which you have to specify the IP address of the gatekeeper. This implementation is like the implementation ofagateway.
1-96
Trunk Implementation Overview

This topic describes how to configure trunks in Cisco Unified Communications Manager.
Nongatekeeper-Controlled ICT and SIP

Trunk Configuration Overview
Cisco Unifed
Communications
Nongalekeeper-Conlrolled :CT
102 1 1
Manager Cluster
Cisco Unified Communica
Manager
Cluster
Access and Site Code. 9 222
4- Digit
Directory
Numbers
Nongatekeeper-controlled ICT
and SIP trunk configuration:
Cisco Unified
Communicalions
- Trunk with IP address of peer
Manage
Cluster
Route pattern, route list, route group
The figure illustrates the most important configuration elements for implementing a SIP or nongatekeeper-controlled ICT in Cisco Unified Communications Manager, "fhese elements arc the configuration ofdie trunk itself, in which you have to specify the IP address ofthe peer, as well as the route group, route list, and route pattern configuration, fhis implementation is like
the implementation of a gatewav.
'2010 Cisco Systems. Inc
ImplementingMultisite Deployments

This subtopic describes how to configure a Cisco IOS router as an H.323 gateway.

10-digit numbers are sent to Cisco Unrfied Communications Manager on incoming PSTN calls in this configuration. Digit manipulation on gateway or in Cisco Unified Communications Manager
is required to get to 4-digit directory numbers.
interface FastEthernet0/0
ip address 10.1.1.101 255.255.255.0

h323-gateway voip interface h323-gateway voip bind ercaddr 10.1.1.101
1

destination-pattern 511555....
session target ipv4:10.1.1.1

incoming called-number 9T
codec gTllulaw
1
dial-peer voice 21 pots destination-pattern 9T

direct-inward-dial
port 0/0/0:23
When configuring an H.323 gateway, the first task is to enable H.323 at one IP interface. If
multiple IP interfaces are present it is recommended that you use a loopback interface.
Otherwise, if the interface that has been selected for H.323 is down, the H.323 application will not work, even if-other interfaces could be used to route the IP packets. In this example, there is
only one Ethernet interface, and H.323 has been enabled on that interface, using the h323gateway voip interface and h323 gateway voip bind srcaddr IP address commands. In contrast to MGCP gateways in which the call agent takes care of call routing, H.323 gateways require local dial plan configuration. In the example, the H.323 gateway is configured with a VoIP dial peer that routes calls that are placed to the PSTN number 511555... ofthe gateway toward Cisco Unified Communications Manager. The gateway receives these calls from the PSTN because 511555 1001-1003 is the direct inward dialing (DID) range ofthe PSTN interface (port 0/0/0:23). In addition, the PSTN gateway is configured with a POTS dial peer that routes all calls starting with 9 out to the PSTN, using the ISDN PRI (port 0/0/0:23). Note that the configured digits of a destination pattern in a POTS dial peer are automatically stripped off. Therefore, the 9 is not sent out to the PSTN. In the other direction, the gateway does not perform any digit manipulation because VoIP dial peers do not strip off any digits automatically. Cisco Unified Communications Manager receives H.323 call setup messages for calls that were received from the PSTN in their entire length (usually 10 digits). Because the internal directorv numbers arc four digits, either Cisco Unified Communications Manager or
the H.323gatewav need to be configured to strip the leadingdigits so that the remaining four digits can be used to route the call to internal directory numbers.
Note More informationon how to implement digit manipulation is provided in the next lesson of
this module.
1-94
Cisco Unified Communications Manager H.323 Gateway Configuration

This subtopic describes how to configure an 11.323 gateway in Cisco Unified Communications Manager.
Manager H.323 Gateway Configuration

Cisco Unified Communications ManagerAdministration: Device > Gateway > Add New > H.323 Gateway
Configure gateway IP address, desenption, and device pool.

:c.;:::
-""-
tlon
- inbiund (<<-
10-digit numbers recei\ed from the
..^--,r, ;,,-,
- s ">o -"" -'"
<
NO"!
>
PSTN are stripped down to 4-digit internal directory numbers.
*:j
-:
Is
zm
<. -.-
l1.!
, ,,. ,
Hi.i-.-,,] N, . ,
'JE-.ll.;rt..t,Lr
I,
i . , -
:-,-,, ,d
>:>,
To add an H.323 gateway to Cisco Unified Communications Manager, navigate to Device > Gateway and click Add New. fhen, from the Gateway Type drop-down list, choose H.323 and
click Next.
In the tiateway Configuration window, enter the IP address ofthe 11.323 gateway in the Device Name field, enter a description, and select the device pool that should be used. If Cisco Unified Communications Manager should consider only some ofthe called digits, you can set the significant digits parameter to the numberof least significant digits that shouldbe used for routing inbound calls. In the example that is provided in the previous topic, in which the gateway sends complete 10-digit PSTN numbers to Cisco Unified Communications Manager, setting the significant digits to 4 wouldallow the incoming calls lo be routed to internal director; numbers without any additional configuration (such as translation patterns).
1-93
Step2
Step 3
Configure oneor more VoIP dial peerspointing to Cisco Unified Communications

Manager.
Configure one or moredial peers pointingto the PSTN.
1-92
H.323 Gateway Implementation Review

This topic describes how to implement an H.323 gateway.
H.323 Gateway Implementation

Overview
Configure H.323 gateway in
Manager.
PSTN
Configure Cisco IOS gateway:

10.1.1.1
IP address used for H.323
Dial peer pointing to Cisco

Unified Communications
Manager
- Dial peer pointing to PSTN
1001-1003
To implement an H.323 gatewav. you first must add the gatewav to Cisco Unified Communications Manager. When adding the gateway, you need lo specify the IP address ofthe
gateway.
Note
More information about the H.323 protocol and H.323 gateway characteristics have been
provided in the ImplementingCisco Voice Communications and QoS (CVOICE) course. MGCP gateway implementation with Cisco Unified Communications Manager has been covered in detail in the Implementing Cisco Unified Communications Manager Part 1 (CIPT1) course This topic is only a high-level review of H 323 gateway implementation.
Then vou need to configure the Cisco IOS gateway by following these steps:
Step 1
Configure the H.323 gateway, specifying its H.323 ID and the IP address to use. You do this configuration on any interface, typically on a loopback interface, Fnsure that you use the same IP address that you configured in Cisco Unified
Communications Manager for the H.323 gateway.
Note
Ifthe IP address that is configured in Cisco Unified Communications Manager does not match the IP address that is used by the gateway, Cisco Unified Communications Manager considers the H 323 signaling messages to be sent from an invalid (unknown) source and
ignores them. However, itdoes not ignore the messages ifpromiscuousoperation has been permitted (thisservice parameter can be configured in Cisco Unified Communications
Manager)
201D Cisco Syslems. Inc.
1-91
mgcp
mgcp call-agent 10.1.1.1 2427 service-type mgcp version 0.1 mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse mgcp package-capability rtp-package mgcp package-capability sst-package mgcp package-capability pre-package no mgcp package-capability res-package no mgcp package-capability fxr-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp rtp payload-type g726rl6 static
1-90
Configuring Cisco IOS Gateway for MGCPExample

The figure shows an example of a Cisco IOS MGCP gateway that pulls its configuration from a
configuration server.
Configuring Cisco IOS Gateway for

MGCPExample
controller El
linecode
0/1/0
framing bdb3
Only the commands in red have been manually configured. Commands in

black have been added via
crc4
y. i
-r.-yp
EiirealoTS
-,hvi,~! a:-.. -
interface SerialQ/1/0:15
isdn incoming-voice voice

1,tJ" i!'''-'' l5 '"r-r^^-r
TFTP Commands in blue are
mandatory for manual MGCP configuration.
ccm-manager music-on-hold ccm-manager config server 10.1,1,1 ccm-manager config :-<;. j. '.H\i-*<u>,il
version 0.1
::.
..: : 2427
service-type
mgcp
mgcp rtp unreachable timeout 1000 action n otify
mgcp modem passthrough voip mode nee
mgcp package-capability rtp-package

mgcp package-capability sat-package mgcp package-capability pre-package
no mgcp package-capability res-package
no mgcp package-capability fxr-package no mgcp timer receive-rtcp mgcp sdp simple mgcp rtp payload-type g726rl6 static
mgcp profile default
In the example, there is one Cisco Unified Communications Manager server (providing call processing and TFTP services) with the IP address 10.1.1.1. 'fhere is a Cisco IOS MGCP gateway with a connection to the PSTN using an Fl interface (port 0/1/0). The gateway and its
HI PRI endpoint have been added to Cisco Unified Communications Manager. At the gatewav.
the commands ccm-manager config server 10.1.1.1 and ccm-manager config server have
been entered. No MGCP configuration commands have been manually entered, because the MGCP configuration is automatically downloaded and applied by the configuration server
feature.
After the gatewav downloaded its cnf.xml configuration file from the Cisco Unified Communications Manager TFTP server, these MGCP commands were added and saved to
NVRAM: controller SI 0/1/0
framing crc4
linecode hdb3
pri-group timeslots 1-31 service mgcp

!
interface Serial0/l/0:15
isdn switch-type primary-4ess isdn incoming-voice voice

isdn bind-13 ccm-manager
i
ccm-manager mgcp
ccm-manager music-on-hold
If Foreign Exchange Station (FXS) or Foreign Exchange Office (FXO) interfaces are to be MGCP-controlled, enable MGCP on the corresponding plain old telephone service (POTS) dial peersby usingthe service mpepapp command.
Enable MGCP.
Note
More information about manual configuration of MGCP gatewaysis provided inthe CVOICE
course.
Mixed use of configuration server and manual configuration:
Follow the same procedure asfor the MGCP gateway configuration, using the
configuration server.
Disable the configuration server, using the ccm-managerconfig command, Manually remove configuration that is received from the configuration server, or
add more configuration to it.
Note
Be aware that, as long as the configuration server isactive onthe Cisco IOS gateway, every
time the MGCP endpoint is resetfrom Cisco Unified Communications Manager, the Cisco IOS configuration also will be rewritten. In addition, when you reload theMGCP gateway, the MGCP configuration will be rewritten as long as the configuration server is enabled. Therefore, itis common practice to use the configuration only for initial configuration when manual changesare required. After you modify the downloaded configuration, you deactivate the configuration serverso thatthe manually addedchangesare preserved
Also, whenyou reset an MGCP gatewayor MGCP endpoint inCisco Unified
Communications Manager, thegateway orendpoint is not automatically resetat therouter.
Therefore, when the configuration server feature is not enabled on the Cisco IOS gateway,
you need to follow the next procedure inorder to reset an MGCP gatewayor MGCP
endpoint.
First, reset the MGCP gatewayor MGCP endpoint inCisco Unified Communications Manager. Then enterthe no mgcp command, followed by the mgcp command in
configuration at the Cisco IOS gateway.
L
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) v8.0 2010 Cisco Systems, Inc
Cisco IOS Gateway MGCP Configuration Methods Review

This subtopic reviews how to configure a Cisco IOS MGCP gateway to integrate with Cisco
Unified Communications Manager.
Cisco IOS Gateway MGCP
Configuration Methods Review

Various ways exist to configure MGCP on the Cisco
IOS gateway:
Configuration server
Cisco IOS configuration will be downloaded automatically.

Recommended and easiest way. Manual configuration
Cisco IOSconfiguration for controller and MGCP must be

entered manually.
- Fast way to configure fractional T1/E1.

Mixed
Initial configuration received by configuration server. Configuration server will be disabled, and configuration
can be altered manually.
Ailer adding the MGCP gatewav in the Cisco Unified Communications Manager web administration, vou need to configure the Cisco IOS MGCP gateway to register ittothe Cisco Unified Communications Manager, 'fhere are three methods for configuring a Cisco IOS
Software-based gateway to register itto Cisco Unified Communications Manager via MGCP: Cisco IOS MGCP gateway configuration with theuse of a configuration server:
Specifv the IP address ofthe configuration server (Cisco Unified Communications

Manager TFTP server).
If more than one Cisco Unified Communications Manager TFTP server is deployed
inthe Cisco Unified Communications Manager cluster, configure the gateway with
all Cisco Unified Communications Manager TFTP server IP addresses.
Fnable the configuration server feature. Manual Cisco IOS MGCP gateway configuration:
Specify the IP address ofthe MGCP call agent (Cisco Unified Communications
Manager server).
processing (that is. running the Cisco CallManager service), configure the gateway with aprimary and redundant call agent by specifying the IP addresses oftwo Cisco
Unified Communications Manager call-processing servers.
Configure global MGCP parameters.
Ifmore than one Cisco Unified Communications Manager server is used for call
Examples ofglobal MGCP configuration commands arc mgcp packet and mgcp
rtp commands.
MGCP Gateway Implementation Review

This topic describes how to implement an MGCP gateway.
Cisco Unified Communications Manager Gateway Configuration Procedure

1
2 3
Add an MGCP gateway.

Add voice modules. Add VICs to the modules.
4 5
Add and configure MGCP endpoints. Configure the MGCP gateway.
To implement an MGCP gateway, you first need to add the gateway to Cisco Unified Communications Manager. Next, you add voice modules and voice interface cards (VICs) to the gatewav. and finally, you configure the endpoints.
Note More informationabout the MGCP and MGCP gateway characteristics are provided in the ImplementingCisco Voice Communications and QoS (CVOICE) course. MGCP gateway implementation with Cisco Unified Communications Manager has been covered in detail in Implementing Cisco Unitied Communications Manager, Part 1 (CIPT1) course. This topic is only a high-level review of MGCP gateway implementation.
After adding the MGCP gateway and its endpointsand configuring the endpoints in Cisco Unified Communications Manager, you need to configure the MGCP gateway itself. Cisco Unified Communications Manager stores at its TFTPserver an XMLconfiguration file that can be downloaded by the MGCP gateway. Alternatively, you can configure the gateway manually.
1-86
With a gatekeeper-controlled ICT. you configure only one trunk. That trunk then communicates via the gatekeeper with all other clusters that are registered to the gatekeeper. If a cluster or subscriber becomes unreachable, the gatekeeper automatically directs the call to another subscriber in the cluster or rejects the call if no other possibilities exist, fhis action allows the call to be rerouted over the PSTN (if required) with little incurred delay. With a single Cisco gatekeeper, it is possible to have 100 clusters that arc registering a single trunk each, with all clusters able to call each other. With nongatekeeper-controlled trunks, this same topology would require 99 trunks to be configured in each cluster. The gatekeeper-controlled ICT should be used for communicating only with other Cisco Unified Communications Managers,because the use of this trunk with other 11.323 devices might cause problems with supplementary services. In addition, a gatekeeper-controlled ICT must be used for backward compatibility with Cisco Unified Communications Manager versions earlier than Version 3.2 (referred lo as Cisco CallManager). Ihe H.225 trunk is essentially the same as the gatekeeper-controlled IC'1. except that't has the
capability of working with Cisco Unified Communications Manager clusters (Version 3.2 and
later), as well as other 11.323 devices, such as Cisco IOS gateways (including Cisco Unified Communications Manager Express), conferencing systems, and clients. This capability is achieved through a discovery mechanism on a call-by-call basis. This type of trunk is the
recommended H.323 tmnk if all Cisco Unified Communications Manager clusters are at least
Version 3.2.
1-85
H.323 Trunk Comparison

The table compares characteristics ofthe three available H.323 trunk types.
H.323 Trunk Comparison
NongaiefteeperControlledlCT
GatekeeperControBedlCT
IP address resolution
Gatekeeper call
admission
IP address specified in trunk configuration

NO
IP address resolved by H.323 RAS {gatekeeper)
Yes,byH3Z3RflS (gatekeeper)
Scalable
Scalabiity
Limited Cisco Unified
Peer
Communications
Manager
eJS^jESiSSS
The nongatekeeper-controlled ICT isthe simplest, since itdoes not use a gatekeeper. Itrequires
the IPaddress ofthe remote Cisco Unified Communications Manager server or servers to be
specified, because the dialed number isnot resolved toan IP address by a gatekeeper. Call Admission Control (CAC) can be implemented by locations but not by gatekeeper CAC.
Scalability is limited because no address resolution is used andall IP addresses have to be configured manually. The nongatekeeper-controlled ICT points to theCisco Unified
Communications Manager server ofthe other cluster.
You may define up to three remote Cisco Unified Communications Manager servers in the
same destination cluster. The trunk will automatically load-balance across all defined remote
Cisco Unified Communications Manager servers. In the remote cluster, it is important to

configure a corresponding ICT (nongatekeeper-controlled) thathas a Cisco Unified Communications Manager group containing the same servers that were defined as remote Cisco
Unified Communications Manager servers in the first cluster. Asimilar configuration is required in each Cisco Unified Communications Manager cluster that isconnected by the ICTs.
Fora larger number of clusters, the gatekeeper-controlled ICT should be used instead ofthe nongatekeeper-controlled trunk. The advantages of using the gatekeeper-controlled tmnk are
mainly the overall administration ofthe cluster and failover times. Nongatekeeper-controlled
trunks generally require that a full mesh oftrunks be configured, which can become an administrative burden asthe number ofclusters increases. In addition, ifa subscriber server ina cluster becomes unreachable, there will be a 5-second (default) timeout while the call is attempted. Ifan entire cluster isunreachable, the number ofattempts before either a call failure ora rerouting ofthe call over the PSTN will depend onthe number of remote servers that are
defined for the tmnk and on the number oftrunks in the route list or route group. Ifthere are
many remote servers and many nongatekeeper-controlled trunks, the call delay can become
excessive.
1-84
H.323 Trunk Overview

The figure illustrates varioustypes olT1.323 trunks.
H.323 Trunk Overview

Cisco Unified
Nongatekeeper-Con trolled ICT
Cluster B
Manager
Cluster A
Cisco Unified
Com mu nica tions

Manager
Cluster D
In the example, the Cisco linified Communications Manager cluster Auses anongatekeepercontrolled ICT to Cisco Unified Communications Manager cluster B. In addition. Cisco
Unified Communications Manager cluster A isconfigured with a gatekeeper-controlled ICT .
The gatekeeper-controlled ICf points to agatekeeper, which is used for address resolution. In
this example, the gatekeeper can route calls between Cisco Unified Communications Manager
clusters A. C. and D.
1-83
SIP Trunk Characteristics

This subtopic describes the characteristics of a SIP trunk.
SIP Trunk Characteristics

Distributed dial plan
Can be connected to any device supporting SIP, including Cisco IOS gateways, Cisco Unified Border Element, remote Cisco Unified Communications Manager dusters. SIP network servers (proxy), and others Simple, customizable protocol; rapidly evolving feature set
Main
Site
SIP uses the distributed call-processing model, so a SIP gateway or proxy has its own local dial plan and performs call processing on its own. A Cisco Unified Communications Manager SIP tmnk can connect to Cisco IOS gateways, a Cisco Unified Border Element, other Cisco Unified Communications Manager clusters, or a SIP implementation with network servers (such as a SIP proxy).
SIP is a simple, customizable protocol with a rapidly evolving feature set.
Note When you use SIP trunks, Media Termination Points (MTPs) might be required if the endpoints cannot agree on a common method of dual tone multifrequency (DTMF)
exchange.
1-82
ImplementingCisco Unified Communications Manager, Part 2 (CIPT2)vS.O
Cisco IOS Gateway Protocol Comparison Review

fhe figure reviews the advantages and disadvantages of 11.323 gateways. MGCP-controIlcd
gateways, and SIP gateways.
Cisco IOS Gateway Protocol

Comparison Review
Dial plan drectty on
the gateway
Translations defined
Centrafzed dial plan configuration Centralzed gateway

configuration
Dal plan directly on the

gateway
Translations defined
per gateway
Pros
per gateway Third-party telephony

system support
Regional
requrements that can

be met
Simple gateway configuration

Easy implementation
More specific cal routing Advanced tax support
Third-party gateway inleroperablity Third-party end-device support
Support of QSIG
supplementary services
Cons
Complex configuration
Extra cal I-routing

configuration for survivability
Lessfeaturesupport
fach ofthe three gateway protocols has advantages and disadvantages when compared with
each other. There is no generally "best" gateway protocol. You should select the most
appropriate protocol, depending on the individual needs and demands in a Cisco Unified
Communications Manager environment.
Note The Implementing Cisco Voice Communications and QoS (CVOICE) course provides
detailed information on functions and features ofthe H.323, MGCP, and SIP.
Cisco IOS Gateway Protocol Functions Review

The table reviews Cisco IOS gateway protocol functions by protocol.
Cisco IOS Gateway Protocol Functions

Review
^^^^H Function
Clients NFAS QSIG Fractional T1/E1
MGCP
H.323
sip
Intelligent'
Supported Not supported Easy to implement
TCP or UDP
ASCII
^^H
Dumb
Intelligent
Supported Not supported Easy to implement
TCP
Not supported
Supported
More effort to
implement
TCP and UDP
ASCII No Yes' No
Signaling protocol
Code basis
Binary (ASN.1)
Yes Yes Yes
Call survivability
FXO caller ID
Yes
Yes
Yes
Call applications
usable
I' Support irtroQuced with Cisco Unrfied Communications Manager Version 8.0 |
As shown in the table, the three main gateway signaling protocolsMGCP, H.323, and SIP provide various features and functions when implemented with Cisco Unified Communications
Manager and Cisco IOS gateways.
1-80
Cisco Unified Communications Manager Connection Options
Overview
In Cisco Unified Communications Manager, you can configure gateways and trunks for connections to the public switched telephone network (PSTN) or to other VoIP domains.
Manager Connection Options Overview

Gateways - H.323 (any H 323 device when not using a gatekeeper)
- MGCP
Skinny Client Control Protocol

Trunks H.323
Direct connection to another Cisco Unified
Communications Manager cluster Connection to any H.323 device via a gatekeeper

SIP
* Connection to any SIP device
Gateways areconfigured bv the VoIP protocol (hat they use. Cisco Unified Communications Manager supports H.323 gateways. Media Gateway Control Protocol (MGCP) gatewavs. and Skinny Client Control Protocol (SCCP) gatewavs. Trunks can be configured as H.323 trunks
(three types are available) or SIP trunks.
Trunks and gatewavs arcconfigured when connecting to devices that allow access to multiple endpoints. If the destination is a single endpoint. phones areconfigured. Phones can be
configured as SCCP. SIP. or 11.323.
When Cisco Unified Communications Manager routes calls lo a device that is using MGCP. SCCP. or SIP. it is obvious which type of deviceto add. becausethese protocols can be
configured onlv with either a gateway or a trunk. Inthe case of 11.323. however, an H.323 gateway as well as an H.323 trunk can be configured, and it is important to know whether to use the gateway or the trunk. You use H.323 trunks only when connecting toanother Cisco
Unified Communications Managerserver (eithera clusteror a standalone Cisco Unified Communications Manager server, in the caseof Cisco Unified Communications Manager
Business fdition) or when using an H.323 gatekeeper.
H.323 gatewavs are configured when connecting to any other H.323 device that isnot an endpoint. Such dev ices can be Cisco IOS H.323 gateways or11.323 gateways ofother vendors.
1-79
Multisite Connection Options

This topic provides an overview of connection options in multisite environments.
Connection Options for Multisite Deployments

Main
Site
The figure shows a Cisco Unified Communications Manager cluster at the main site with these
connections to other sites:
Intercluster trunk (ICT) to another cluster located at a different site An H.323 gateway that is located at a remote site
A Session Initiation Protocol (SIP) trunk that is connected to an Internettelephony service

provider (ITSP) via a Cisco Unified Border Element
1-78
12010 Cisco Systems, tnc.
Lesson 3
Implementing Multisite
Connections
Overview
Cisco Unified Communications Manager multisite deployments can use various connection
options between sites. Ihis lesson describes connection options and explains how toconfigure
them.
Objectives
Upon completing this lesson, you will be able to configure gateways and trunks in multisite
nvironmenls. This ability includes being able to meet these objectives:
Identify the characteristics ofthe trunk and gateway types that aresupported by Cisco
Describe how lo implement MGCP gateways

Describe bow to implement 11.323 gateways
Describe various types of trunks that aresupported by Cisco Unified Communications

Manager
Describe how to implement SIPtrunks in Cisco Unitied Communications Manager Describe how to implemeni intercluster and H.225 trunks in Cisco Unitied
1-76
2010 Cisco Systems; Inc.
References
for additional information, refer to these resources:
Cisco Svstems. Inc. Cisco Unified Communicalions System 8.x SRND, April 2010.
lutp: Asww.cisco.com/en/US/docs.voice ip comm/cucm/^rnd/8\/uc8\.h(inl Cisco Svstems. Inc. ('isco (Unified Communications Manager Administration Guide
Imp: 'wwu,ciscn.com/eiiT,S/doev\oice_ip_comm/cucm/admin/8 OJ/cemciU/bccm-801

cm.him!
20)0 Cisco Systems. Inc
1-75
Summary
Summary
Multisite deployment solutions include QoS, efficient use of IP WAN bandwidth, backup scenarios in caseof WAN failure
access and site codes, and the use ofthe Cisco Unified
Border Element.
QoS allows certain communication flows to be processed

with higher priority than others.
deploying mixed conference bridges or transcoders using '

RTP-header compression, and deploying local media
resources.
You can conserve bandwidth by using low-bandwidth codecs
Summary (Cont.)
Cisco Unified Communications Manager availability features
Extension Mobility, and Cisco Unified Mobility. You can build multisite dial plan solutions by using Cisco IOS
gateway and Cisco Unified Communications Manaqer dial
plan tools.
include fallback for IP phones, CFUR, AAR, and CFNB and mobility features such as Cisco Device Mobility, Cisco '
Communications Manager and IP phones, from the outside
completely hides internal devices, such as Cisco Unified
ACisco Unified Border Element in flow-through mode
1-74
'2010 Cisco Systems. Inc.
Cisco Unified Border Element in Flow-Through Mode

The figure illustrates how the use of aCisco Unified Border Element protects inside devices such afasco Unified Communications Manager and IP phones by acting as asignaling and
media proxy.
Cisco Unified Border Element in

Flow-Through Mode
Company A
10.1 1 1
Signaling and
Media Packets
Public IP Address B
ITSP
Repackaged
Cisco Unified
Communications
Manager
SCCP
Private IP
10.2.1.5 Address:
Public IP
AddressA
Private IP Network' 1000.0/8
10.3.1.1
..1.1.110 10 31.1 Signaling: 10.

RTP-1Q2.1.5.O10311
|~| Signaling: A(Public IP) to B IP) | (Public

RTP: A(Public IP) to B(Public IP)
and the IP phone has aprivate IP address of 10.2.1.5. ACisco Unified Border Element o, t the Cisco Unified Communications Manager cluster to the outside world, in this case.
In the example. Cisco Unilied Communications Manager has aprivate IP addrcs of 10.1.1.1.
^ ninternet telephony service provider (ITSP,. The Cisco Uinfie Border hcment is configured in flou-through mode and uses an internal private IP address ot 10... Iand an
external public IP address of A.
Tend he packets to the IP address ofthe ITSP (IP address D). Instead it sends them to the
ternalkddressoHhe^
When Cisco Unified Communications Manager wants to signal calls to the ITSP. it does not
configuration Cisco Unified Border Element then establishes asecond cal leg to the 1ISP.
unCi
call is set up the Cisco Unified Border Element terminates Rl Ptoward the ITSP. using its
blic IP address A the source and IP address B as the desUr.UoÔcc the as (ITSP)
pX II' address, and sends the received RTP packets to the internal IP phone, using its
internal IP address.
This solution allows Cisco Unified Communications Manager and IP phones to communicate on v htne ntemal. priv ate IP address ofthe Cisco Unified Border Element, he onlv IP dre h sible to the ITSP is the public IP address ofCisco Unified Border f.lcment.
Multisite Deployment implementation

2010 Cisco Systems, inc
1-73
NAT and Security Solutions

This topic describes solutions to NAT and security issues in multisite environments. CiscoUnified Border Element as a Solution to
NAT and Security Issues in Multisite
Environments
Cisco Unified Border Element acts as an application proxy:

Splits calls between inside and outside into two call legs. Supports signaling interworking{SIPand H.323).
- Signaingonly(flow-around)
Two modes:
- Signaling andmedia (flow-through)
*h?!6^,31need IPconnectivity to outside. Communications Manager) !?ms (IP phores- Cisco Unified do not
" &nl*,Fisco ^"'^ Bordw dement needs tohave ^ public IP address
- Solves NAT and security issuesforinternal devices.
- Only Cisco Unified Border Element itself needs to behardened.
" ?SJ^-a9en? and flp P^ndition perform similar functions and can sometimes be used as an alternative. " !lnert;altefives avaiable (trusted relay points, proxies in Cisco
Adaptive SecuntyApptance [ASA])..
way, Cisco Unified Border Element splits off-net calls inside and outside into two separate call
to 11.323, H.323 to SIP. and H.323 to H.323.
When Ctsco Unified Communications Manager servers and IP phones need to connect lo the Internet. Cisco Unified Border Element can be used as an application proxy. When used in this
,,'.-!f rder Element also features signaling interworking from SIP to SIP SIP
The Cisco Unified Border Element can function in two modes:
Flow-around: In this mode, only signaling is intercepted by Cisco Unified Border

Unified Border Element). Only signaling devices (Cisco Unified Communications
Manager) are hidden from the outside.
Element Media exchange occurs directly between endpoints (and>*M around Cisco
' ,Fir"?M0U?h: Element (byflowing through **media slr<*ms are Element). BothCisco In thiS m0dc" both siSnalinS Cisco Unified Border intercepted by Cisco Unified Border
Unified Communications Manager and IP phones are hidden from the outside.
so NAT and security issues for internal devices (Cisco Unified Communicalions Manager '
In flow-through mode, only Cisco Unified Border Element needs to have apublic IP address
ouZe it should be hardened-against attacks. Unified B0nler Hlement is "P""" ^the outside, it sh tTu 7 I"' BCaUSe CiSC
1-72
Implementing Cisco Unitied Communications Manager, Part 2(CIPT2) vS.O
Localization of callingparty numbers a. phones: Caller IDs sPl yed at phon n also be localized so that the end users are not lim.ted to seeing all callers ,n WA* fonnat Again, global transfonnations (ofthe calling-party number only in this case) can Tsed sothat caller 1 which might be different at each site. -^^^'^ Ds. format Similarh. the globalized calling-party number is also maintained in call lists so that users can place callbacks to globalized numbers without needing lo edit the number.
transfonnations. globalized call routing drastically reduces the s^^%*ld]

plans Features such as TEHO. AAK. SKST. CEUR. Cisco Device Mobil, y. and Cisco
Extension Mobilitv can be implemented much more easily in international deployments.
Substantial simplification of dial plans: With local route groups and global

1-71
Globalized Call Routing Advantages

There are several advantages ofglobalized call routing that are especially applicable to
international multisite deployments.
Globalized Call-Routing Advantages

Globalized call routing allows one format to be used to store
orconfigure PSTN numbers (E.164 with + prefix). Speed dials, fastdials, call forward destinations, AAR
destinations, etc., look the same at all sites.
Manually typed numbers following local rules areglobalized

at ingress.
Local requirements are managed atthe egress device, not by

separate patterns and associated route lists.
Common format can be used in address books and can be

exchanged worldwide.
Calling party numbers shown at phones can be shown in

localized format, but globalized format can be used for
callbacks.
International dial plans are substantially simplified.
Hereare the advantages:
Universal format to store or configure PSTN numbers: With globalized call routing
you can configure or save all PSTN numbers in auniversal format that you can use
worldwide, regardless of local PSTN dial rules.
PSTN destinations that are configured in Cisco Unified Communications Manager
and that are independent ofthe site that is used for dial-out: Speed dials fast dials call forward destinations. AAR destinations, and Cisco Unified Mobility remote destinations share the same format. Because all call routing is based on this format, calls to these numbers will work from anywhere within the cluster, regardless ofthe requirements ofthe
local PSTN gateway.
Transformation of input at call ingress: When implementing globalized call routing vou
can allow end users to manually dial numbers as they normally do. Ifyou globalize their localized input during call ingress, any input format can be supported, while call routine
itself is based on a standardized format.
Localization at call egress: The various requirements that are applicable at various egress
the egress device, regardless ofthe matched route pattern and route list.
devices can be easily managed during call egressthat is, atler call routing and path selection-^ using features such as global transformations that allow digit manipulation at
Utilization across different devices: Address book entries can be shared by all devices centralized directories regardless ofthe used endpoint. For example, cell phones and Cisco source (tor example, aLightweight Directory Access Protocol [LDAP] directory)
1-70
that support E.164 format and the +prefix. This situation allows the utilization of
Unified Communications Manager can synchronize their directories from one and the same
Internal to Internal
Calling-party number: directorv' number Called-party number: directorv' number

Calling-part} number: f.164
Internal to External
Called-party number: H.164
At the right side ofthe figure, call egress is illustrated by two types of call targets:
Gateways
and the called-partv number. The fonnat of these numbers (especially ofthe called-party number) can significant differ based on the location ofthe gateway (for example, various
international access codes in the United States [0111 versus the LTJ [00]).
Phones
When sending calls to the PSTN, the localized E.164 format is used tor both the callmg-
...
When acall from an internal phone is sent to another internal phone, the call should be
, ,
,,,
received at the phone with both the calling and called number using internal director} numbers Because this fonnat is also used by globalized call routing, there ,s no need ior localized call egress in this case. When acall from an external caller is sent to an internal
localized fonnat. For example, acall from the local area code should be displayed with
phone.
phone! most users (especially users in the United States) prefer lo see the calhng number ,n
sev en digits. The called number is the director}' number and usually is not displayed al the
delivered. Therefore, localized call ingress has to be normalized (that is. globalized), and
globalized fonnat has to be localized at call egress.
It is evident from the figure that, in several situations, the numbers that are provided at call ingress do not conform to the normalized format to be used for call routing. 1he same situation occurs with cal! egress, where the normalized fonnat is not always used when the call is being
Multisite DeploymentImplementation
1-69
Globalized Call RoutingThree Phases

The figure provides an overview about the three phases that are involved in globalized call
routing.
On the left side ofthe figure, call ingress is illustrated by two types ofcall sources:
External callers: Their calls are received by Cisco Unified Communications Manager through agateway or tmnk. In aPSTN gateway, calling- and called-party number are
usuallv provided in localized E.164 format.
Internal callers: Their calls are received from internal phones. Ifcalls to internal
destinations (for example, phone to phone), calling- and called-party numbers are typically
to PSTN), the calling number is the directory number (at call ingress time) and the called
provided as internal directory numbers. Ifcalls to extemal destinations (for example, phone
number depends onthe local dial rules for PSTN access. These dial rules can differ
significantly per location.
globalized call routing. Here arethe defined standards:

External to internal
mentioned earlier, because most calls use global E.164 format, this process is also referred to as
The center ofthe figure illustrates the standards that are defined for normalized call routing As
Calling-party number: E.164
Called-party number: directory number

Calling-party number: E.164 Called-party number: E.164
External to external (if applicable)
1-68
Globalized Call-Routing Overview

(Cont.)
Afterthe call is routed and path selection has been
performed, theegress device can change from

globalized to local format; Applies to calling- and called-party number for all calls routed
to gateways and trunks
Applies to calling-party number for calls routed from

gateways and trunksto phones
* Does not apply to called-party number for all calls routed to phones (as internal directory numbers are the standard
formatfor internal destinations)
Does not apply to calling-party numbers for calls routed from

internal to internal (as internal directory numbers are the
standard format in this case)
Alter the call has been routed and path selection (ifapplicable) has been performed, the destination dev ice might need to change the nomialized numbers lo local format. 1his situation
is referred to as localized cal! egress.
Localized call egress applies tothese kinds ofnumbers:
Calling- and called-partv numbers for calls that are routed to gateways and trunks: If
the PSTN or the telephonv svstem on the other side of atrunk docs not support globalized
call routine the called- and calling-party numbers need lo be localized from global format.
An example would be to change the called-party number +494012345 to 011494012345

before sending the call out tothe PSTN in the United Slates.
Calling-party numbers for calls that are routed from gateways or trunks to phones:
area code as 7- or 10-digil numbers and not with 1 followed by 10 digits.
example, auser at aU.S. phone may want to see PSTN callers who are located in the same
1ocalized call egress is not needed for the called-party number ofcalls that are routed to
fhe nhone user mav want to see caller IDs in alocal format rather than aglobal format, for
destinations (regardless ofthe source ofthe call). These numbers might have been dialed ditTerentlv initially. In that case, however, this localized call ingress was normalized before call
routing.
phones because internal director}' numbers are the standard (normalized) formal for internal
to internal), because typically the standard for ihe calling-parly number ot such calls is lo use
internal directory numbers.
Note
Localized call egress is also not required for the calling-party number of internal calls (internal
When internal directory numbers are not unique (for example, when there are overlapping
directory numbers at various sites), the called- and calling-party numbers of internal calls
can be globalized at call mgress and localized at call egress just like external calls.

1-67
Assuming that all internal directory numbers are unique, this format is the most common:
stripping or translating the called number to internally used directory numbers. Normalized calling-party numbers: E.164 global format with a+prefix is used for all calling-party numbers, except for those formats ofcalls from internal to internal Such purely internal calls use the internal directory number for the calling-party number.
Normalized called-party numbers: K. 164 global format with a+prefix is used for extemal destinations. Therefore, called-number normalization is achieved by globalization Internal directory numbers are used for internal destinations. Normalization is achieved bv'
normalized before being routed. This principle applies to all received calls (coming from gateways and tmnks as well as from phones), and it applies to both the calling- and called-partv
Note Except for the mentioned internal calls (where the destination is adirectory number and in
the case of an internal source, the source is a directory number), all numbers are normalized to E.164 global format. Therefore, this call-routing implementation model is referred to as
globalized callrouting.
tmnks. and so on) do not use normalized format, the localized call ingress needs to be
Ifsources of calls (users at phones, incoming PSTN calls at gateways, calls received through
1-66
"
Globalized Call-Routing Overview Globalized call routing simplifies the implementation of international Cisco Communications
Manager depknments.
Globalized Call-Routing Overview

Globalized call routing simplifies implementation of
International multisite deployments:
Gail routing ss based on globalised nnmDers
Called number: E.164 format with + prefix (except for calls

to internal destinations)
- Calling number E.164 format with +prefix (except for

calls from internal to internal)
If sources ofcalls (users at phones, incoming PSTN calls at
gateways, etc.) use different format, their localized call ingress needs to be globalized before being routed. Applies to phones aswell asto gateways and trunks
Applies to called- and calling-party numbers
Globalized call routing consists ofihe following main components:
. Normalization: Localized call ingress (that is, local dial rules) is normalized to acommon dialed destinations onlv in normalized format (like with 4dialing from directories).
input is required.
fonnat (E 164 with +prefix). This action would not be necessary ifall endpoints and users
However it is serv unlikelv that only +dialing would be pennilted. When manually typing anumber, users still want to follow their local dial rules. Therefore, normalization of tins
. Routing that is based on global numbers: When all dialed numbers have been globalized
to L164 format, local dial rules do not apply during call routing. They were relevant only during call ingress. All call routing occurs based on numbers in globalized format. . Ioealization of numbers before handing off the call: After call routing and path selection, the local dial rules ofthe selected device have to be used, for example when a user calls an international PSTN destination through aU.S. gateway 011 has to be prefixed
to the number, while in Europe 00 is commonly used. Localized call egress ,s implemented
at the gatewav or tmnk that routes the call out oi the cluster.
In general, call routing is based on normalized numbers. As mentioned earlier, the most Lion format that if used is the globalized format, where both the called- and caling.part} numbers are globalized for calls that are not exclusively internal. For such internal calls
^8^00 numbers can be used as long as they are unique. If, for example, over apping
die'on numbers are used, then it is common to use the globalized format also or rouing
call is routed.
such int'ersite calls. End users do not have to dial phones at other sites by using the ET 64 formal, but their localized ingress (typically including site codes) will be globalized before the
Multisite Deployment Implementation 1-65
Dial Plan Components in Multisite Deployments

The table shows dial plan components and their configuration elements inCisco Unified Communications Manager and in Cisco IOS gateways.
Dial Plan Components in Multisite

Deployments
Dial Plan Component
Cisco IOS Gateway
Cisco Unitied
Endpoint addressing *
selection
Cal routing and path
SilSS6^"' <**"Mnic POTS, dialpeers

,
Dfrectorynumtter
Dialpeers
Routepatterns,routegroups, route Isfs, translationpatterns,

partitions. CSSs
Digit manipulation
Voicetranslation profiles using prefix, dlgjt-trlp. forward-digit*, and

num-exp commands
Translationpatterns, route patterns, route lists, significant digits, catted-amicaMhg-parfy transformations, fccoming caibd-artdcailng-pafty
Partitions, CSSs, lime
Caling privieges
Cal coverage
COR and COR Hats
schedules, time periods, FACs

Line groups, hunt lists, hunt
raalpeers/catr""" " ~~
appicaa'ons, ephone hunt
groups
Note
Alt these elements have been discussed in other courses, such asImplementing Cisco
Voice Communications and QoS (CVOICE) and Implementing Cisco Unified Communications Manager, Part 1(CIPT1). However, information onhow to use these
elements to implement a dial plan in multisite deployments is provided in a separate lesson

of this module.
1-64
'2010 Cisco Systems. Inc.
Least Cost Routing, tail-end hop-off (TEHO), and PSTN backup: Can be implemented b> appropriate call routing and path selection that is based on priorities. Globalized call routing: In this dial plan implementation, all received calls arc normalized
toward a standardized fonnal. fhe formal that isused in call routing isglobalized format, because all numbers are represented in E. 164 format with a4 prefix, 'fhe process of nomializine the numbers as dialed by end users (localized ingress) istherefore also referred
to as globaUzation. Once the localized input has been globalized during ingress, the call is
routed based on globalized numbers. After call routing and path selection, the called
number is localized during call egress, depending on the selected egress device.
Multisite Deploymenl Implementation

1-63
Dial Plan Solutions

This topic provides an overview about dial plan solutions in multisite deployments
Dial Plan Solutions for Multisite
Deployments
Overlapping and nonconsecutivenumbers
- Solved by access code and (unique) site code. - Allows routing independent directory numbers. - Appropriate digit manipulation required.
Variable -length numbering
- Dial string length determined by timeout or use of# key.

- Overlapsendingand receiving.
* DID ranges and PSTN addressing - Use ofinteractive voice response applications (AA B-ACD etc
or attendant required rf no DID numbers.
- Directory numbers appended to PSTN number (with variablelength dial plansif supported by PSTN).
Numberpresentation (ISDN TON) LeastCost Routing, TEHO, PSTN backup
- Call routing and path selection based on prioritized paths.

Globalized call routing
Dial plan issues in multisite deployments can be solved in the following ways: Overlapping and nonconsecutive numbers: Solved by implementing access codes and site codes tor intersite dialing. This approach allows call routing that is independent of directorv numbers. Appropriate digit manipulation (removal ofsite codes in called number of outgoing calls) and prefixing ofsite codes in calling number ofincoming calls are
required.
Variable-length numbering plans: Dial string length is determined by timeout Overlap sending and receiving is enabled, allowing dialed digits to be signaled one by one instead
of being sent as one whole number.
Direct inward dialing (DID) ranges and E.164 addressing: Solutions for mapping of
numbers invariable-length numbering plans.
voice response (IVR) applications to transfer calls, and extensions that are added to PSTN
internal directory numbers to PSTN numbers include DID, use ofattendants or interactive
' 5ITT1 TmbT^reSeu!aIi0n '" 'SDN (,ype f number'or T0N>: Di8jt manipulation that ,s based on TON enables the standardization ofnumbers that are signaled using
different TONs.
1-62
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) vS.O
S2010 Cisco Systems, Inc.
Mobility Solutions
This subtopic provides an overv iew about mobility solutions that solve issues that are the result ofroaming users and devices, and multiple telephones (office phone, cell phone, home phone,
and so on).
Mobility Solutions
When users or devices roam, the resulting limitations in
features can be solved by mobilitysolutions:
Cisco Device Mobility
- Solves issuesthat result from roaming devices (region, location,

SRST reference, AAR group, CSS. etc.)
- Makes Cisco Unified Communications Manager aware of

Cisco IP Communicator) Cisco Extension Mobility
physical location of IP phone (usually software phone such as
Solves issueofmissing personal IPphone setting that results from using a different IPphone in another office (directory
number. CSS, etc.)
- Allows users to log in to IP phone and get personal configuration

applied to currently used IP phone
Cisco Unified Mobility
Solves issues ofhaving different phones (office IP phone, cell

phone, home officephone, etc )
Allows usersto be reached by a single number, independent of

thephonethat is actually used
When users or de\ ices roam between sites, issues arise that can be solved by these mobility
solutions:
Cisco De* ice Mobilitv: Solves issues that arc caused by roaming devices, including invalid device configuration settings such as regions, locations, SRST reference. AAR
groups, calling search spaces (CSSs). and so on. The Cisco Device Mobility feature of _
location ofthe device to be automatically overwritten ifthe device appears in adifferent
phvsical location.
Cisco Unitied Communications Manager allows device settings that depend on the physical
. Cisco Extension Mobilitv: Solves issues that are the result of roaming users using shared
guest IP phones that are located in other offices. Issues include wrong directory number,
phone configuration ofthe logged-in user.
missing IP Phone Services subscriptions. CSS. and so on. Cisco Extension Mobility allows users to log in to guest phones and to replace the configuration ot the IP phone with the II
Cisco I'nified Mobilitv: Solves issues of having multiple phones and consequently
phone that isactually used.
multiple phone numbers, such as an office phone, cell phone, home (office) phone, and so on. Cisco Unitied Mobility allows users to be reached by asingle number, regardless ot the
Cisco Device Mobility and Cisco Extension Mobility will be discussed in detail in later
lessons of this course. Cisco Unified Mobility has been discussed in detail in the
Note
Implementing Cisco Unified Communications Manager, Part 1(CIPT1) course
Multisite Deploymenl Implementation

1-61

The figure illustrates how AAR improves availability in multisite environments.

AAR allows rerouting of calls over PSTN if not enough
bandwidth for VoIP calls:
Alternate destination isderived from theextemal phone number mask and ,

prefix configured per AAR group.
Individual destinations canbe configured perphone.
Cisco Unified
Communications
Manager
CAC Failure lo IP Phone
of User X (1009)
possible to reroute on-net calls thatfailed CAC overthe PSTN.
affected user. AAR and CFNB improve availability in multisite environments by making it
the PSTN (instead of over the IP WAN). It is alternately rerouted to the cell phone ofthe
IP phone. This option is also known as Call Forward No Bandwidth (CFNB) In the example because the remote site does not have PSTN access, the call is not rerouted to the IP phone over
using AAR. The AAR feature includes an option that allows the alternate number to be set per
Ifa call over the IP WAN is not admitted by CAC, the call can be rerouted over the PSTN
1-60
Implemenling Cisco Unrfied Communications Manager, Part 2(CIPT2) v8.0
Using CFUR to Reach Users of Unregistered Software IP

Phones on Their Cell Phones
This subtopic describes how CFUR can be used to route calls lo the cell phones ofusers who
have shut down PCs that have asoftphone installed.
Using CFUR to Reach Users of Unregistered

Software IP Phones on Theif Cell Phones When a user at the main site shuts down a laptop with
Cisco IP Communicator:
The Cisco Unified Communications Manager ofthemain site does not route callstothe affected IPphone directory number. - CFUR allows routing toalternate numbers ofuser (for example, a
cell phone number)
Main Site
Communicator
PC Shutdown
1007 Unregistered
CFUR
Cell Phone
9 1512 555-1999
E12 555-1999
_y
If amobile user has alaptop with asoftphone (for instance, Cisco IP Communicator) and shuts down the laptop. CFUR can be used to forward calls placed to the softphone to the cell phone of auser The user docs not have to set up Call Forward All (Cl'A) manually before closing the
softphone application. However, ifthe softphone is not registered, calls are forwarded to the cell phone ofthe user. This action is another application ofthe CFUR feature that improves
availabilitv in Cisco Unified Communications Manager deployments.
Note
This application isfor CFUR, which isnot related to SRST.

1-59
During WAN Failure This subtopic describes how you can use CFUR to route calls to IP phones at remote locations
during IP WAN failure.
Using CFUR to Reach Remote-Site IP Phones Over the PSTN
Using CFUR to Reach Remote-Site IP Phones Over the PSTN during WAN Failure
The remote site lost connectivity to main site. Phones are registered to remotegateway: Cisco Unified Communications Manager for main site does not route calls tothe affected IP phone directory numbers.
- CFUR allows routing to alternate numbers for affected
(unregistered) IP phones.
can use its local dial plan to route calls that are destined for the IP phones in the main site over the PSTN. But how should intersite calls be routed from the main site to the remote site while
the IP WAN is down?
As discussed before, IP phones that are located at remote locations can use an SRST gateway as abackup for Cisco Unified Communications Manager in case of IP WAN failure The gateway-
number. Therefore, if users al the main site dial internal extensions during the IP WAN outage their calls will fail (or go to voice mail). To allow remote IP phones to be reached from the IP ' phones at the main site, you can configure CFUR for the remote-site phones CFUR should be configured with the PSTN numbers that are used at the remote site so that internal calls for
remote IPphones are forwarded to the appropriate PSTN number.
other entries in its dial plan ifadialed number matches aconfigured but unregistered directory'
The problem in this case is that Cisco Unified Communicalions Manager does not consider anv
J
1-58
J

fhe figure illustrates the operation ofCisco Unified SRST when IP phones lose connectiv.h
tvith their primary- Cisco Unified Communications Manager.

Communication between Cisco Unified Communications Manager and IP phonesis broken.
IP phones register with local gateway (either SRST or Cisco

Unified Communications Manager Express in SRST mode).
Main Sile
Remote Site
Register
Manager
Remote
Gateway
When Cisco IP phones lose contact with Cisco Unified Communications Manager, they register
with the local Cisco Unified SRST router lo sustain the calI-processing capability that is
necessary to place and receive calls.
The Cisco Unified SRST gatewav automatically detects afailure, queries IP phones for
configuration, and automaticallv configures itself. The Cisco Unified SRST gateway uses Simple Netuork-lnablcd Auto Provision (SNAP) technology to autoconfigure the branch office router to prm ide call processing for Cisco IP phones that are registered with the router. Cisco Unified Communications Manager Express in SRST mode can be used instead of standard Cisco Unified SRST functionality. In this case. IP phones register with Cisco Unified Communications Manager F.xpress when they lose the connection to their primary Cisco Unified Communications Manager server. Cisco Unified Communications Manager F.xpress m SRST mode provides more features than standard Cisco Unified SRSI.

1-57
Fallback for IP Phones: Normal Operation

deployment with centralized call processing.
This subtopic describes how fallback for IP phones improves availability in amultisite
Fallback for IP Phones: Normal
Operation
Remote IP phones are registeredwith Cisco Unified Communications Managerover IPWAN.
Cisco Unified Communications Manager controls IP phones.

Main Site
Manager
Remote
Gateway
availability of remote IP phones.
Fallback for IP phones is provided by the Cisco Unified SRST feature and improves the
enables the gateway to provide call-processing services for IP phones. IP phones register with
server group configuration ofthe IP phones). The Cisco Unified SRST obtains the
central site, which is the call-processing device. Ifthe WAN link fails, Cisco Unified SRST
AWAN link connects IP phones at aremote site to the Cisco Communications Manager at a
the gateway (which is listed as abackup Cisco Unified Communications Manager server in the
configuration ofthe IP phones and can route calls between the IP phones or out to ihe PSTN.
The figure illustrates normal operation ofCisco Unified SRST while the connectivity between IP phones and their primary server (Cisco Unified Communications Manager) is okay:
' f!T?e 'Pphnes ^ reSis,ered with Cisco lJn'ted Communications Manager over the IP WAN.
Cisco Unified Communications Manager manages call processing for IP phones.
1-56
MGCP Fallback: Fallback Mode
The figure illustrates operation of MGCP fallback in fallback mode-when the connectivity
the call agent (Cisco Unified Communications Manager) is lost.
MGCP Fallback: Fallback tVlode
Communication between Cisco Unified Communications Manager and MGCP gateway is broken.
to
MGCP gateway falls back toits default call-control

application (H.323 or SIP).
Main Site
When the MGCP gatewav loses the connection to its call agent, it falls back to its detault callcontrol application (POTS. H.323. or SIP). The gateway now uses alocal dial plan configuration, such as dial peers, voice translation profiles, and so on. Ilence. .1 can operate
be able to process calls when the connection to its call agent is lost.
independent ofits MGCP call agent. Without MGCP fallback, the MGCP gateway would not

?010 Cisco Systems.
1-55
MGCP Fallback: Normal Operation

This subtopic describes how MGCP fallback improves availability in amultisite environment.
MGCP Fallback: Normal Operation

MGCP gateway isregistered with Cisco Unified Communications
Manager over IP WAN.
Cisco Unified Communications Manager isthe MGCP call aqent

controlling the MGCP gateway.
MGCP gateway fallback is afeature that improves the availability ofremote MGCP gateways.
fails, the fallback feature keeps the gateway working as an H.323 or SIP gateway and re-homes
Communications Manager at acentral site, which is the MGCP call agent. Ifthe WAN link
AWAN link connects the MGCP gateway ataremote site to the Cisco Unified
back to the MGCP call agent when the WAN link becomes active again.
agent (Cisco Unified Communications Manager) is okay:
WAN.
The figure illustrates normal operation of MGCP fallback while the connectivity lo the call
The MGCP gateway is registered with Cisco Unified Communications Manager over the IP
Cisco Unified Communications Manager is the call agent ofthe MGCP gateway that is controlling its interfaces. The gateway does not have (or does not use) alocal dial plan
because all call-routing intelligence is at the call agent.
1-54
PSTN Backup
The figure illustrates how calls can use the PSTN as abackup in case oflP WAN failure.
PSTN Backup Intersite calls are rerouted over the PSTN in the case of an IP
WAN failure.
Main Site
Cisco Unified
Communications
Manager
1001-1099
1001-1099
In the example, calls to the remote site arc configured to use the IP WAN first and then use the
PS 1N as a backup option.

i 2010 Cisco Systems, Inc
1-53
Availability
This topic describes solutions to availability issues in multisite deployments.
Availability Options
1 PSTN backup
1 MGCP fallback
1Fallback for IP phones:

- Cisco Unified SRST
- Cisco Unified Communications Manager Express

in Cisco Unified SRST mode
CFUR
AAR and CFNB
Mobilitysolutions:
- Cisco Extension Mobility

- Cisco Device Mobility - Cisco Unified Mobility
These options can improve availability:
Public switched telephone network (PSTN) backup: Use the public switched telephone
network (PSTN) as a backup for on-net intersite calls.
B ^GCP fallback: Configure an MGCP gateway to fall back and use the locally configured
configured dial plan, which is ignored when the gateway is in MGCP mode.
plain old telephone service (POTS), H.323, or SIP dial peers when the connection to its call agent .s lost. This approach enables you to effectively make the gateway by using alocallv
' !?i,bcaCk fr IP phonCS: IP Phones thal reSister ver the IP WAN can have alocal Cisco
server mtheir Cisco Unified Communications Manager group configuration When the
features than standard Cisco Unified SRST.
IOS SRST gateway that is configured as abackup Cisco Unified Communications Manager
reregister wuh the local Cisco Unified SRST gateway. Alternatively, Cisco Unified ' Communications Manager Express can be used in SRST mode, which provides more
connection to the primary Cisco Unified Communications Manager server is lost thev can
Call Forward Unregistered (CFUR): CFUR is acall-forwarding configuration of IP

phones that becomes effective when the IP phone is not registered.
Automated alternate routing (AAR) and Call Forward No Bandwidth (CFNB)- AAR cacSrFvp 1S a;al|-forwardin8 configuration of IP phones, which becomes effective by ,J1 T?CdVer thC PS When calls over the IP WAN are ot admied
when AAR is used.
Mobility solutions: When users or devices roam between sites, they can lose features or
on any device via a single (office) number.
1-52
Fx^lnPrh l^ and Cisco Dev.ce Mobility can solve such issues. In addition these Extension Mobility âtinr,beCaUSe f' Change " thir actUal ^sicaI loc*ion. Cisco features allow integration ofcell phones and home office phones by enabling reachability
-âuimy
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) vS.O
Preventing Too Many Calls by CAC

This subtopic describes different methods of limiting the number ofconcurrent calls by CAC.
Preventing Too Many Calls by Cai
Admission Control
CAC is used to limit the number of calls:
Locations
Bandwidth limit applicable to components within a cluster.

Includes calls to and from gateways and trunks.
- Special implementation oflocations. Allows calls to flow through two routers (RSVP agents).
- Call leg between routers uses RSVP to limit bandwidth.

SIP precondition
Like RSVP-enabled locations but between SIPdomains
(e.g., two clusters interconnected via a SIP trunk).

zones.
Gatekeepers
- Bandwidth control for calls between H.323 gatekeeper
Cisco Unified Communications Manager allows the number of calls to be limited by these
CAC mechanisms:
1ocations' Cisco Unified Communications Manager location-based CAC is applicable to calls between two entities thai arc configured in Cisco Unified Communications Manager. These entities can be endpoints such as phones or devices that connect to other call-routing domains such as trunks or gateways. However. CAC applies to the devices that are part o the Cisco Unified Communications Manager cluster, even ifthey represent an external call
the maximum bandwidth that is configured per location is checked at both ends, t alls
within a location arc not subject tothe bandwidth limit.
routing domain (in case of trunks). If ingress and egress device are in different locations,
. Resource Reservation Protocol (RSVP)-cnabled locations: RSVP is aspecial way ,i
and egress devices arc both part ofthe Cisco Unified Communications Manager cluster. . Session Initiation Protocol (SIP) Preconditions: SIP Preconditions lutjn Hke
RSVP-enabled locations except that it is designed for SIP trunks on y W SH ith
configure locations. When RSVP is configured to be used bclween apair ol locations, the audio streams fious through two routers, so-called RSVP agents. The cal eg between the to RSVP agents is subject to Cisco IOS RSVP CAC. Like with standard locations, ingress
Preconditions, calls through aSIP trunk flow through alocal Cisco IOSrouter at each end ofthe SIP trunk splitting the call into three call legs-just like with RSVP-enabled
locations. However, in this case the call is not within acluster but bclween clusters.
H.323 zones.
. Gatekeepers- Gatekeepers arc used in the 11.323 world and provide address resolution and
CAC funSs HI 323 gatekeepers can be configured lo limit the number ofcalls between
Mullisite Deployment Implementation
1-51
2010 Cisco Systems.
Alternatives to Multicast MOH from Branch Router Flash

router flash cannot be used.
This subtopic shows alternatives that you should consider when multicast MOH from branch
Alternatives to Multicast MOH from
Branch Router Flash
If multicast MOH from branch router flash cannot be

used, consider these alternatives;
- Using multicast MOH:
- Reduces the number of MOH streamssent overthe IP

WAN,
- Requires less bandwidth than unicast MOH. Using G.729 for MOH to remote sites:
- Putremote IP phones and MOH server into different

regions.
- Allow only G.729 between these two regions.
- These actions reduce the required bandwidth per MOH

stream.
Ifmulticast MOH from branch router fiash cannot be used (for instance, because the branch router does not support the feature or does not have aCisco Unified SRST feature license) vou
can consider these alternatives:
Using multicast MOH: When using multicast MOH over the IP WAN you can significantly reduce the number of required MOH streams. Thus, less bandwidth is required compared with multiple unicast MOH streams. The IP network, however, has to support multicast routing for the path from the MOH server to the remote IP phones.
Using G.729 for MOH to remote sites: Ifmulticast MOH is also not an option (for
different reg.ons. and you need to limit the audio codec between these two regions to 8
link. The bandwidth savings are identical to the bandwidth savings that you achieve when "f'y/29 and cRTP for standard audio streams, which was discussed earlier To use U729 for MOH streams, you have to put the MOH server and the remote IP phones into
individual MOH stream requires less bandwidth and hence reduces the load on the WAN
instance, because multicast routing cannot be enabled in the network), you may still be able to reduce the bandwidth that is consumed by MOH. When you change the codec that is used for the MOH streams to G.729 and you potentially enable cRTP on the IP WAN each
1-50
Multicast MOH from Branch Router Flash: Cisco IOS

Configuration Example This subtopic shous the required Cisco IOS commands to enable multicast MOH from branch
router flash.
Multicast MOH from Branch Router Flash: Cisco IOS Configuration Example
Cisco Unified
Com muni cation s
Manager
MOH
Configuration
DA 239 1 1 1 DP 16334 Ma" Hops
TTL 1
Main Site
_._
WAM.
call manage r-a llbJ ck

max
Remote Site
ephone a
dn 1
ip source- add
moh moh-f. le.
ess
10.2 .2.2
multicast moh 239
1.1. 1 port
16384
In the example, the name ofthe audio file on the branch router Hash is moh-lile.au. and the configured multicast address and port number are 239.1.1.1 and 16384. respectively. Ihe optional route command can be used to specify asource interface address lor the multicast stream If no route option is specified, the multicast stream will be sourced from the configured
Cisco Unified SRST default address as specified by the ip source-address command under the Cisco I'nificd SRST configuration (10.2.2.2 in this example). Note that you can stream only a
single audio file from flash and that you can use only asingle multicast address and port
number per router.
ACisco Unified SRST license is required regardless of whether the SRST functionality will
actually be used. The license is required because the configuration for streaming multicast
one extension (using the max-dn command) must be configured.
MOH from branch router flash is done in the SRST configuration mode and, even ,tSRSI functionality will not be used, at least one IP phone (using the max-ephones command) and

1-49
5. The router at the remote site is configured as an SRST gateway. In its Cisco Unified SRST configuration, multicast MOH is enabled with destination address 239 11Iand port 16384. The Cisco Unified SRST gateway streams MOH all the time (even if not in fallback
mode).
6. The IP phone listens to the multicast MOH stream that was sent from the Cisco Unified
At no time do MOH packets cross the IP WAN.
SRST gateway to IP address 239.1.1.1, port 16384, and plays the received MOH stream.
1-48
implementing Cisco Unrfied Communications Manager, Part 2(CIPT2) .8.0
20,0 Cisco Systems, Inc.
Multicast MOH from Branch Router Flash Example

The figure illustrates how multicast MOH from branch router Hash works.
Flash Example
When remote phone is put on hold Clko Unified Communicate Manager signals phone
to listen to DA 2391 1 1 DP 16384 andplay thereceived stream
Unified
Unified
Communicalions
Identical MOH
Packets Created
Communications
Manager MOH Packets

Dropped Here (TTL
Exceeded)
Manager MOH
Configuralion DA 239 1 1 1
DP 163B4
Here by SRST MOH
Max Hops
TTL 1
multicast MOH with adestination (multicast group) address of239.1.1.1. the destination port
16384. anda max-hops TTI.value of 1.
In the example the Cisco Unified Communications Manager MOH server is configured for
The Cisco Unilied SRST gateway that is located at the remote silc is configured with the same destination IP address and port number as the Cisco Unified Communications Manager MOH
server.
When a remote phone is put on hold, here iswhat happens:
1, According to the MRGL ofthe remote phone, the Cisco Unified Communications Manager
MOH server is used as the media resource for MOH.
2. Cisco Unified Communications Manager signals the IP phone to receive MOH on IP

address 239.1.1.1-port 16384.
} The Cisco Unified Communications Manager MOH server sends multicast MOH packets
toIP address 239.1.1.1. port 16384. with a TTL value of 1.
4 The router that is located at the central site drops the multicast MOH packet that is sent out
by the Cisco Unified Communications Manager MOH sewer because TTL has been
exceeded.

1-47
Instead of setting the max-hops parameter for MOH packets to 1,you can useone of these
methods:
Configure an access control list (ACL) on the WAN interface: Configure an ACL onthe
WAN interface at the centralsite to disallow packetsthat are destined to the multicast group address or addresses from being sent out the interface.
Note
Depending on the configuration of MOH in CiscoUnified Communications Manager, a

separate MOH stream for each enabled codec is sent per multicast MOH audio source The streams are incremented either based on IP addresses or based on port numbers (recommendation is per IP address). Assuming that one multicast MOH audio source and G.711 a-law, G.711 mu-law, G.729, and the wideband codec are enabled, there will be four multicast streams Makesure that allof them are included in the ACL to prevent MOH
packets from being sent to the IP WAN.
Disable multicast routing on the WAN interface: Donotconfigure multicast routing on

the WAN interface, to ensure that multicast streams are not forwarded into the WAN.
When you use multicast MOH from branch router flash. G.711 has to be enabled between the
Cisco Unified Communications Manager MOH serverandthe remote IP phones. This action is necessary because the branchSRST MOH feature supportsonly G.711. Therefore, the stream that is set upby Cisco Unified Communications Manager in thesignaling messages also has to be G.711. Because the packets arenot sentacross the WAN, configuring the high-bandwidth G.711 codec is not a problem as long as it is enabledonly for MOH. All other audio streams
(such as calls between phones) that are sent over the WAN should use the low-bandwidth
G.729 codec.
1-46

This subtopic explains how you can use multicast MOH from branch router fiash toreduce the
bandwidth that is required on the IP WAN.

Flash
Multicast MOH from branch router flash is a feature for multisite deployments with centralized call processing:
Mworks only with multicast MOH It is based on MOH capabilities of SRST
Cisco IOS SRST gateway is configured lor multicast MOH

MOH stream is sent independent of SRST stalus (even if no failover scenario)
Cisco United Communications Manager and IP phone are not aware that SRST
gateway is invoked
IP phone is configured lo use Cisco United CommunicationsManager multicast

MOH server
Cisco Unified Communications Manager MOH server is configured for max-hops 1 Cisco Unilied Communications Manager MOH server and branch router use same
multicast adoress arx) port number
Cisco UnifiedCommunications Manager signals its MOH server address and port
nurnberto IPphone
Cisco UnifiedComniumcat ons Manager MOHserver packets are dropped at WAN router Because max-hops value TTL in IP packet header has bean exceeded
SRSTrouter generates multicast MOH stream with same multicast address and
portthai was used by Cisco Unified Communications Manager MOH IP prwne listens lo signaled address and portand plays received stream
Multicast MOH from branch router fiash is a feature for multisite deployments that use centralized call processing.
Ihe feature works only with multicast MOI 1and isbased on MOH capabilities ofCisco
Unified SRST. The Cisco IOS SRSTgateway is configured for multicast MOH and
continuously sends a MOH stream, regardless ofitsSRST mode (standby orfallback mode).
In fact, neitherCisco Unified Communications Manager nor the remoteIP phones are aware
that the Cisco Unified SRST gateway isinvolved. To them, itappears asthough a multicast MOH stream has been generated by the Cisco Unified Communications Manager MOH server
and has been receded by the remote IP phones.
Therefore, the remote IPphones are configured to use the centralized Cisco Unified Communications Manager MOII server astheir MOH source, fhe Cisco Unified Communications Manager MOH server isconfigured for multicast MOH (mandatory), and the
max-hops \alue in the MOI Iserver configuration is set to 1for the affected audio sources. The
max-hops parameter specifies the Time to Live (TTL) value that isused in the IP header ofthe
number for their streams. This way, MOH packets that are generated bythe Cisco Unified
RTP packets, "fhe Cisco Uni lied Communications Manager MOI 1server and the Cisco IOS SRST gatewav that is located at the remote site have to use the same multicast address and port
Communications Manager MOH server atthe central site are dropped by the central-site router
because ITI. has been exceeded. As a consequence, the MOII packets donotcross the IP
WAN. The SRST gateway permanently generates amulticast MOH stream with an identical multicast IP address and port number. The IP phone simply listens tothis stream as it appears
to becoming from the Cisco Unified Communications Manager MOH server.
1-45
Mixed Conference Bridge

The figure shows how ahardware conference bridge in mixed mode can be used to reduce the
bandwidth that is required on the IP WAN.
Mixed Conference Bridge

Mixed (hardware) conference bridoes enable low-bandwidth codecs to beused by remote conference participants.
Hardware
Conference Bridge
(Mixed)
Manager
-WAN-
Remote Site
In this example, ahardware conference bridge is deployed at the main site. The hardware conference bndge is configured to support mixed conferences, in which members use various
canjoin the conference using a low-bandwidth codec.
codecs. Headquarters IP phones that join the conference can use G.711, while remote IP phones
1-44
Note
Calls between IP phones at headquarters and remote IP phones do not require a transcoder. They simply use the best allowed codec that is supported on both ends. G.729.
Atranscoder is invoked only when the two endpoints of acall cannot find acommon codec
that is permitted by region configuration. This principle is illustrated in this example. The remote IP phones (which support G.711 and G.729) are not allowed to use GV11 over the
IP WAN and the headquarters voice-mail system and software conference bridge do not
signaling identifies the need for a transcoder.
support G729 Cisco Unified Communications Manager detects this problem that is based on its region configurations, and the capability negotiation that is performed during call setup
.
Bandwidth 8kb/s between BR and XCODER: This bandwidth ensures that the RTF streams between remote IP phones and the transcoder. which are sent over the IP W do AN.
not use (J.711.
order for the G.711 -onh devices at headquarters lo be allowed to send G.711 to the
transcoder.
Bandwidth 64 kb/s between headquarters and XCODER: This bandwidth is required in

1-43

When implementing transcoders in order to allow G.711-only devices to communicate with remote IP phones using G.729. you need to consider the following guidelines.

Cisco Unified CommunicationsManager transcoder support
requires the following configuration:
Cisco Unified Communicalions Manager supports only hardware transcoder
resources.
- Hardware transcoding media resource is requred. - Transcoding media resource has lo be configured h Cisco IOS router.
- Transcoding media resource has to be added to Cisco Unified Communications Manager.
IP phones and G.711-only devices (such as third-party voice mail or software
conference bridges) in headquarters are pui into a dedicated region (e.g.,

headquarters).
- Remote IP phones are put into a dedicated region (e.g., BR). Transcoders are put into a dedicated region (e.g., XCODER).
Limitaudio bandwidth between regions headquarters and BR to 8 kb/s. Limitaudio bandwidth between regions headquarters and XCODER to 64
kb/s.
Limitaudio bandwidth between regions XCODER and BR to 8 kb/s.
As a first step, jou need to implement the transcoding media resource. CiscoUnified
Communications Manager does not support software transcoding resources. Therefore, the only
option is to use a-hardware transcoding resource by first configuring the transcoder at the Cisco
IOS router and then adding the transcoder toCisco Unified Communications Manager. The second step isto implement regions in a way that only G.729 ispermitted onthe IP WAN, and the transcoder can be used ifrequired. To do so, you place all IPphones and G.711-only devices, such as third-party voice-mail systems orsoftware conference bridges that are located in the headquarters, in one region. You place remote IPphones in another region (called, for example, branch, or BR). Thetranscoding resource is putinto a third region (called for
example. XCODER).
Now the maximum codec for calls within and between regions have tobe specified as follows:
Bandwidth 64 kb/s within BR: This bandwidth allows local calls between remote IP
phones to use G.711.
Bandwidth 64 kb/s within headquarters: This bandwidth allows local callswithin the
headquarters to use 0.711. These calls are not limited to calls between IP phones. They
also include calls to the G.711-only third-party voice-mail syslem orcalls that use the
G.711-only softwareconference bridge.
Bandwidth 64 kb/s within XCODER: Because this region includes only the transcoder media resource, this setting isnot relevant since there are no calls within this region.
Bandwidth 8 kb/s between BR and headquarters: Thisbandwidth ensures that calls
between remote IP phones and headquarters devices (such as IP phones, software conference bridge, and voice-mail system) do not use G.711 as the bandwidth for calls that
traverse the IP WAN is limited.
1-42
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) u8.0
Transcoders The figure illustrates how you can use transcoders to reduce the bandwidth that isrequired on
the IP WAN.
Transcoders
Ifa device supports G 711 only, transcoders enable low-bandwidth
codecs to be used over the IP WAN
In the example, a third-part; voice-mail system that supports only G.711 is deployed atthe
main site. One Cisco UnifiedCommunications Manager server is providing a software
conference bridge (which also supports G.711 only). Ifremote phones are configured lo use
G.729 over the IPWAN. they cannot join conferences oraccess the voice-mail system. To allow these IP phones touse G.729 and toaccess the G.711-only services, you deploy a
hardware transcoder at the main site.
Remote IP phones now send G.729 voice streams to the transcoder over the IP WAN. The transcoder changes the stream to G.711 and then passes iton to the conference bridge orvoicemail sNStem.
1-41
Codec Configuration in Cisco Unified Communications

Manager
The codec that is used for a call isdetermined by the region configuration in Cisco Unified
Codec Configuration in Cisco Unrfied
Thecodec that will be used depends on the region configuration in Cisco Unified Communications Manager;
Each region is configured with a maximum audiobandwidth per call:
- Within the configured region
- Toward specific other regions (manually added) Toward all otherregions (which havenotbeen manually added)
Region is assigned to a device pool.
Device pool is assigned to a device.
Whichcodec actuallygets used depends on the capabilitiesof the

two devices:
- Best codec is the one that is supported by both devices and

does not exceed bandwidth requirements of codec that is permitted in the region configuration.
- If devicescannotagree on a codec, a transcoding deviceis

invoked.
Each region in Cisco Unified Communications Manager isconfigured with the maximum audio
bandwidth requirements to be used per call:
Within the configured region
Toward a specific other region (manually configured) Toward all other regions (not manually configured)
Regions are assigned to device pools (one region per device pool), and adevice pool is assigned to each device. Which codec isactually used depends on the capabilities ofthe two devices and does not exceed the bandwidth requirements ofthe codec that is permitted in
region configuration. If devices cannot agree on a codec, a transcoder is invoked.
devices that are involved in the call. The assigned codec is the one that is supported by both
1-38

The figure illustrates the effect of using RTP-header compression to conserve bandwidth on the
IP WAN.

The use of a low-bandwidth codec and cRTP reduces
the bandwidth requirements of a call on a WAN link. 82.4

kb/s
EuHaiEIS2IuilE5Z3
6 1 20 I 8 I 12 1 ieo
Manager
Remote Site
packetization period) is being passed along aFrame Relay link. The frame has atotal size ot 206 Bcomprising 6Bof frame Relay header. 20 Bof IP header. 811 of UDP header. 12 Bof
RTP header, and 160 Bofdigitized voice, fhe packet rate is50 packets per second (p/s).
resulting ina bandwidth need of 82.4 kb/s.
In the example, a \oice packet for a call that has default settings (G.711 codec and a 20-ms
When % use cRTP and change the codec toG.729. the required bandwidth changes as ou follows: The frame now has atotal size of28 or30 Bper frame comprising 6bytes ofFrame
preserved), and 20 Bof digitized, compressed voice. The packet rate is still 50 p/s (because the packetization period was not changed), resulting in bandwidth needs of 11.2 or 12 kb/s.
Seven G.729 calls with cRTP enabled require less bandwidth than one G.711 call without cRl'P (assuming that cRTP is used without preserving the UDP checksum).
Note While the audio codec configuration affects the end-to-end path, cRTP only affects WAN
links where cRTP isenabled RTP header compression isconfigured on a per link basis.
Relay header. 2or 4Bof cRTP header (depending on whether the UDP checksum is
1-37
with local members using G.711 and remote members using low-bandwidth codecs, you
codecs.
Deploying transcoders or mixed conference bridges: If low-bandwidth codecs are not supported by all endpoints, you can use transcoders sothat low-bandwidth codecs can be used across the IP WAN. Then have the voice stream transcoded to G.711. For conferences
can deploy mixed conference bridges (hardware only) that support members with various Deploying local music on hold (MOH) servers or using multicast MOH from branch
router flash: Deploying local MOH servers means thatCisco Unified Communications
Manager servers have to be present at each site. In centralized call-processing models in which this requirement does not apply, itisrecommended that you use multicast MOH
from branch router flash. This approach eliminates the need ofstreaming MOH over the IP
routing should be enabled in the network in order for multicast MOH function properly. Limiting the number ofvoice calls using CAC: Use CAC to avoid oversubscription of
WAN bandwidth by too manyvoice calls.
WAN. Ifthis approach isnot an option, you should use multicast MOH instead ofunicast MOH to reduce the number of MOH streams that have to traverse theIPWAN. Multicast
1-36
Cisco Systems. Inc. 2010
Solutions to Bandwidth Limitations

"fhis topic describes solutions to bandwidth limitations.
Options to Reduce WAN Bandwidth

Bandwidth in the IP WAN can be conserved by: Using low-bandwidth codecs over the IP WAN Fordevices requiring G.711, deploytranscoders.
For remote conference participants, deploy mixed
conference bridges or transcoders.
Using RTP-header compression
Deploying local annunciators or disabling remote

annunciators
Deploying local conference bridges Deploying local MTPs (ifrequired)
Deploying transcoders or mixed conference bridges (if

needed)
Deploying local MOH server or using multicast MOH from

branch router flash
Limiting numberofvoice calls by using CAC
You can conserve bandwidth on the IP WAN by using these methods:
Using low-bandwidth codecs: When you use low-bandwidth (compression) codecs, such as G.729. the required bandwidth for digitized voice is 8kb/s. compared to the 64 kb/s that
is required b\ G.71! (Layer 2overhead not considered).
I. sing RTP-header compression: When using RIP-header compression (compressed

RTP. orcRTP). vou can compress the IP. User Datagram Protocol (UDP). and RTP header
to 2or 4B(depending on whether the UDP checksum is preserved), compared lo the 40 B that Urequired bv these headers ifcRTP is not used. It is enabled per link. It can be
selecmeh used on a slim WAN link (in general, below 768 kb/s) and does nol need lobe
enabled end-to-end across all WAN links.
Deploying local annunciators or disabling remote annunciators: Ifspoken
announcements are not required, you can disable the use ofannunciators for IP phones that do not have a local annunciator. Otherwise, you can deploy local annunciators. Cisco Unilied Communications Manager supports annunciators that are running only on Cisco Unilied Communications Manager servers (provided by the Cisco IP Voice Media
Streaming Application service). Therefore, you can implement local annunciators only if \ou deploy alocal Cisco Unified Communications Manager cluster or ifyou are using
clustering o\er the IP WAN.
Deploving local conference bridges: If you deploy local conference bridges, the IP WAN
is not used ifall conference members are at the same site as the conference bridge.
m Deploving local Media Termination Points (MTPs): If MTPs are required, you can
services.
deploy them locally at each site to avoid the need lo cross the IP WAN when using Ml P

The figure illustrates how local conference bridges can keep voice traflic oft*the IP WAN.

A local conference bridge at the remote site keeps RTP streams away from the IP WAN for conferences hosting only remotely located participants. Use MRGLs to control which phones use which conference bridge.
You can use the same solution for MTPs.
Cisco Unified
Communication a
Manager
As shown in the figure, if a local conference bridge is deployedat the remotesite, it keeps voice streams off the IP WANfor conferences in which all members are physically located at the remote site. You can implement the same solution for MTPs. MRGLs specify which conference bridge (or MTP)should be used and by which IP phone.
1-40
The figure shous howyou can conserve bandwidth on the IP WAN by sendingdisabling
annunciator streams to remote phones.
In multisite deployments with centralized call processing, MRGLscan
be used to disable annunciator streams to the remote site.
In multisitedeployments with distributed call processing, local

annunciators can be used at each site
C'Sco Unified Communicalions
Manager
If announcements should not be sent over the IP WAN, Media Resource Group Lists (MRGLs)
canbe used so thatremote phones do not have access lo the annunciator media resource.
Note Because not every call requires annunciator messages, and because the messages are usually rathershort, the bandwidth that should be preserved by disabling the annunciator is
marginal.
QoS Advantages
QoS can improve the Quality of Voice (QoV) calls by giving priority to RTP packets.
QoS Advantages With QoS enabled, voice traffic has absolute priority
over other traffic.
Prevents jitter caused by variable queuing delays

Ensures enough bandwidth for signaling Prevents packetloss caused bytail dropsin queues
Voice
(Highest)
Voice is always served first
Data [High, Such as IP Precedence: 4)

Data (Medium, Such
as IP Precedence: 2)
Data (Low, Such as Precedence: 0}
With QoS enabled, voice traffic is given absolute priority queuing ("PQ" in the figure) over all other traffic. This approach prevents jitter, which is caused by variable queuing delays. It also
prevents lost voice packets, which are caused by tail drops that occur when buffers are complete. To avoid the complete blocking ofother traffic, you should limit voice bandwidth. The number ofvoice calls should also be limited by CAC so that there isnot more voice traffic
than there is bandwidth that has been reserved for it.
Finally, to ensure proper service for voice calls, you should configure QoS to guarantee a certain bandwidth for signaling traffic. Otherwise, despite the fact that the quality ofactive
calls may be okay, calls cannot betorn down, and new calls cannot beestablished.
Note
QoS is not discussed further in this course. For more information, refer to the Implementing
Cisco Voice Communications and QoS (CVOICE) course.
1-34
QoS
This topic describes how quality ofservice (QoS) can solve voice quality issues.
QoS Review
QoS allows certain communication flows to be
processed with higher

priority than others:
i '.-. Traffic is identified. Traffic is divided into
classes.
Voice Mission-Critical Best-Effort
,;>
QoS policy is applied per

class.
Voice M_
irst
il Best-Effort
Away* Laaaa^
The primarv goal of QoS is 10 provide better service, including dedicated bandwidth, controlled jitter and latency {required bv some real-lime and interactive traffic), and improved loss
characteristics, by giving priority lo certain communication flows. It is also important to make sure that providing priority for one or more flows docs not make other flows fail. Fundamental. QoS enables vou to provide better service to certain flows. You can provide
better sen ice bv cither raising the priority ofaflow or limiting the priority ol another flow.
QoS refers to the capabilit\ ofanetwork lo provide belter service to selected network traffic.
Some of QoS mechanisms are congestion management, congestion avoidance, and link
When you implement QoS. the implementation is split into three major steps:
Traffic is identified (voice, signaling, data, and so on).
traffic, and soon).
efficiencv
Traffic is div ided into classes (real-time traffic, mission-critical traffic, less important
QoS policy is applied per class, specifying how to serve each class.
Multisite Deployment Implementatii

1-33
Multisite Deployment Solution Overview

This topic provides an overview ofsolutions to issues that arise in Cisco Unified
Communications Manager multisite deployments.
Multisite Deployment Solutions

SRST.
Main Site
QoS, CAC, RTP

Header
PSTN
Backup,
MGCP
Fallback
Compression,
Local Media Resources
Cisco Unrfied
Communications
Remote Site
Manager
The figure illustrates amultisite deployment that incorporates the following solutions to
multisite deployment issues:
Availability issues are solved by Cisco Unified Survivable Remote Site Telephony (Cisco
Unified SRST) and Media Gateway Control Protocol (MGCP) fallback.
Quality and bandwidth issues are solved by quality ofservice (QoS), Call Admission Control (CAC). Real-Time Transport Protocol (RTP)-header compression, and local media
resources.
Dial plan solutions include access and site codes, as well as digit manipulation. Network Address Translation (NAT) and security issues are solved by the deployment ofa
Cisco Unified Border Element.
1-32
Implementing Cisco Unified Communications Manager, Part 2(CIPT2) 1/8.O
Lesson 2
Identifying Multisite
Deplovment Solutions
Overview Amultisite deplounent introduces several issues that do not apply lo single-site deployments.
neei
When implementing Cisco Unified Communications Manager in amultisite environment, you need to address these issues, fhis lesson provides information on how lo solve issues that arise
in multisite deployments.
Objectives
Upon completing this lesson, you will be able to describe solutions for multisite deplovment
issues.
Thisabilitv includes beingableto meet these objectives:

Describe solutions lo mullisite deployment issues
Describe how QoS solves quality issues inmultisite deployments Describe solutions to bandwidth limitations in multisite deployments Describe survivability and availability features in multisite deployments Describe solutions for dial plan issues in mullisite deployments
Describe how aCisco Unified Border Element can solve NAT and security solutions in
mullisite deployments
Summary
This topic summarizes the keypoints thatwerediscussed in this lesson.
Summary
Multisite deployment issues include quality issues, bandwidth
issues, availability issues, dial plan issues, and NAT and
security issues.
- When there is congestion, packets have to be bufferedor they can get dropped. Bandwidth in the IP WAN is limited and should be used as efficiently as possible. In a multisite deployment, some services depend on the
availability ofthe IP WAN.
1Amultisite dial plan has to addressoverlapping and nonconsecutive numbers, variable-length numbering plans
DID ranges, and ISDN TON, and itshould minimize PSTN
costs.
When CiscoUnified Communications Manager and IP phonesneed to be exposedto the outside, they can be
subject to attacks from the Internet.
References
Cisco Systems. Inc. Cisco Unified Communications System 8.x SRND, April 2010.
hup://\vww.eisco.C(>m/en/US/docs/voice_ip_comm/cucni/srnd/8x/uc8x.html Cisco Systems. Inc. Cisco Unified Communications Manager Administration Guide
http://uv\u .cisco.com/en/US/docs/voice.._ip_.comm/cucm/admm/8 0 l/ccmcfg/bccm-801

cm.himl
1-30
Example: NAT Security Issues

fhe figure illustrates the private IP addresses ofCisco Unified Communications Manager
server and the IP phone that is being translated to public IP addresses.
Example: NAT Security Issues

Cisco Unilied Communications Manager, orCisco Unified Communicalions Manager
Express, and IPphones aremade accessible from theInternet by NAT

Company A
Pnvate IP
Company A
Public IP
Company B
Public fP
Company 8
Pnvate IP
10.0.0.0(8
Company A
'
Public IP A
Manager
vateIP Network
""" Private IPNetwork 100 00 Attacks canbedirected against Unified Communications 1000O
Manager/Cisco Unified Communications Manager
Express and IP phones
In the example, both Companv Aand Company Buse IP network 10.0.0.0/8 internally. For the companies to communicate over the Internet, the private addresses are translated to public IP addresses. Companv Auses public IP network A. and Company Buses public IP network B.
All Cisco Unified Communications Manager servers and IP phones arc reachable from the
Internet and communicate with each other.
2010 Cisco Systems.
1-29
NAT and Security Issues

This topic describes NAT and security issues in Cisco Unified Communications Manager
multisite environments.
NAT and Security Issues in Multisite

Environments In single-site deployments, Cisco Unified Communications Manager
and IPphonesusually do notrequire access to public IPnetworks:
- NATis not required.
- Not reachablefrom theoutside, - Notsubjectto attacksfromoutside.
1 In multisite deployments, VPN tunnels can be used: - Requires gateway configuration ateach site.
- Allows only intersitecommunication.
- Blocks accessto and from outside (unless traffic istunneled).

VPNs cannot be used in some cases:
- Connections to ITSPsor domains underdifferent administration. - NAT required: Cisco Unified Communications (Manager and IP
phones exposed to the outside.
- Cisco Unified Communications Manager and IP phones are

subject to attacks.
usually use private IP addresses, since there is no need to communicate to the outside IP world NA Tis not configured, and attacks from the outside are not possible at all.
In single-site deployments. Cisco Unified Communications Manager servers and IP phones
between sites. The VPN tunnels allow only intersite communication; access to the protected internal networks is not possible from the outside, but only from the other site (through the tunnel). Therefore, attacks from the outside are blocked at the gateway. To configure IPsec
the configuration of IPsec VPNs.
In multisite deployments. IP Security (IPsec) virtual private network (VPN) tunnels can be used
such as when the two sites are under separate administration, and security policies do not allow NAT tor Cisco Unified Communications Manager servers and IP phones. Once Cisco Unified Communications Manager servers and IP phones are reachable with public IP addresses thev will be subject to attacks from the outside world, which introduces potential securitv issues '
VPNs, you must configure gateways at each site. Sometimes this configuration is not possible
In these cases, or when connecting to apublic service such as an ITSP, you must configure
1-28
The ideal solution for alarge deployment would allow an automatic recognition ofroutes. Internal as well as external (for PSTN backup) numbers should be advertised and learned by
call-routing entities. Adynamic routing protocol for call-routing targets would address
scalabilit} issues in large deployments.
Call control discovcrv (CCD). a feature that is based on the Cisco Service Advertisement
detail in a later module of this course.
Framework (SAF) provides such functionality. CCD and Cisco SAF are explained in more

C 2010 Cisco Systems. Inc

Cipt 2 Vol 1&2

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cipt 2 Vol 1&2

Загружено:

Авторское право:

Доступные форматы

Table of Contents

Learner Skills and Knowledge Course Goal and Objectives

Cisco Glossary of Terms Your Training Curriculum

Multisite Deployment Implementation

Identifying Issues in a Multisite Deployment

Multisite DeploymentIssues Overview

Quality Issues Example: Jitterand Packet Drops

Example: Bandwidth Issues

Example: Variable-Length Numbering, E.164 Addressing, and DID

Optimized Call Routing and PSTN Backup

1-18 1-20 1-21 1-22 1-23

Example: Overlapping and Nonconsecutive Numbers

Issues Caused by Different PSTN Dialing

1-26 1-28 1-29

identifying Multisite Deployment Solutions

Multisite Deployment Solution Overview

Low-Bandwidth Codecs and RTP-Header Compression

1-37 1-38 1-39 1-40

Codec Configuration in Cisco Unified Communications Manager

Local vs. Remote Conference Bridges

Guidelines for Transcoder Configuration

Multicast MOHfrom Branch Router Flash: Cisco IOS Configuration Example

Preventing Too Many Calls by CAC

PSTN Backup MGCP Fallback; Normal Operation

Fallback for IP Phones; Normal Operation

1-58 1-59 1-60 1-61

Dial Plan Components in Multisite Deployments

Cisco Unified Border Element in Flow-Through Mode

Implementing Multisite Connections

Cisco Unified Communications ManagerConnection Options Overview

1-78 1-79 1-80

H 323 Trunk Comparison

Configuring Cisco IOS Gatewayfor MGCPExample

Cisco Unified Communications Manager H.323 Gateway Configuration

Gatekeeper-Controlled ICT and H.225 Trunk Configuration Overview

1-93 1-94 1-95

Implementing a Dial Plan for International Multisite Deployments

Example: ISDN TONCalling NumberTransformation of Incoming Call

Configuring IP Phones to Use Local PSTN Gateway

DigitManipulation Requirements for PSTN Backup of On-Net Intersite Calls

)2010 Cisco Systems, Inc.

Considerations for Using Remote PSTN Gateways

1"127 1"129 ]-] 31

Considering Globalized Call-Routing Interdependences

Normalization of Localized Call Ingress from Phones

1-138 1-140 1-142

Module Self-Check Module Self-Check Answer Key

Objectives Remote Site Redundancy Overview

Remote Site Redundancy Technologies

When to Use MGCP Fallback When to Use Cisco Unified SRST

When to Use Cisco Unified Communications Manager Express inSRST Mode

Cisco Unified SRST Function: Switchback Cisco Unified SRST Timing

Support for Multiple MOH Sources

Keeping Calling Privileges Active in SRST Mode

2010 Cisco Systems, Inc.

Implementing Cisco Unified Communications Manager, Part2(CIPT2) v8.0

Implementing SRST and MGCP Fallback

Cisco Unified Communications Manager Dial Plan Configuration for SRSTSupport

Step 2: Setting Max Forward Unregistered Hops to DN

Cisco Unified SRST Dial Plan Commands: Open Numbering Plans

Cisco Unified SRST Dial Plan Example Summary

Implementing Cisco Unified Communications Manager Express in SRST Mode