Best SIP-CUBE LAB PDF

LTRUCC-2150
Cisco Unified CM 10.0 SIP Trunking, Session

Management, Intercluster Lookup Service (ILS)
and URI Dialing
Cisco Live San Francisco 2014
Paul Giralt (pgiralt@cisco.com)

Rafael Muller (rmuller@cisco.com)
POD10
Table of Contents
Introduction to Lab ............................................................................ 7
Prerequisites .................................................................................... 9
Lab Diagram ................................................................................... 10
Lab Overview ................................................................................. 11
Before You Begin ............................................................................ 12
ILS/GDPR Overview ......................................................................... 13
Hub or Spoke ....................................................................................................................... 14
Advertisements .................................................................................................................... 15
Configure ILS on Unified CM SME Edition .......................................... 17

Task 1: Configure Cluster ID ........................................................................................... 17
Task 2: Configure ILS on Unified CM SME ...................................................................... 17
Configure ILS on Unified Communications Manager Leaf 1 .................. 19

Task 4: Configure ILS on Unified Communications Manager Leaf 1 ................................ 19
Configure ILS on Unified Communications Manager Leaf 2 .................. 21

Task 6: Configure ILS on Unified Communications Manager Leaf 2 ................................ 21
Task 7: View ILS Mesh topology ..................................................................................... 22
Dial Plan for Unified CM Leaf Cluster 1 ............................................. 23

Task 8: Configure partitions on Leaf Cluster 1 ................................................................ 25
Task 9: Configure CoS Calling Search Space for Leaf Cluster 1 ..................................... 26
Task 10: Configure CoR CiscoLive_National CSS ........................................................... 27
Task 11: Configure CoR CiscoLive_International CSS ..................................................... 27
Task 12: Configure CSS_Inbound_ILS CSS .................................................................... 28
Configure Translation Patterns for Leaf Cluster 1 ............................... 29

Task 13: Configure National Translation Pattern .............................................................. 29
Task 14: Configure International Translation Pattern with # ............................................. 30
Task 15: Configure International Translation Pattern without # ........................................ 31
Configure SIP trunk and Route List to SME in Leaf Cluster 1 ............... 32
Task 16: Configure SIP trunk to Unified CM SME ............................................................ 32
Task 17: Configure Route Group ..................................................................................... 33
Task 18: Configure Route List ......................................................................................... 34
Dial Plan for Unified CM Leaf Cluster 2 ............................................. 36

Task 19: Configure partitions on Leaf Cluster 2 ............................................................... 37
Task 20: Configure CoS Calling Search Space for Leaf Cluster 2 ................................... 38
© 2014 Cisco Systems, Inc. All rights reserved Document for POD10. Page 2 of 140
Task 21: Configure CoR CiscoLive_National CSS ........................................................... 39
Task 22: Configure CoR CiscoLive_International CSS ..................................................... 39
Task 23: Configure CSS_Inbound_ILS CSS .................................................................... 40
Configure Translation Patterns for Leaf Cluster 2 ............................... 41

Task 24: Configure National Translation Pattern .............................................................. 41
Task 25: Configure International Translation Pattern with # ............................................. 42
Task 26: Configure International Translation Pattern without # ........................................ 43
Configure SIP trunk and Route List to SME in Leaf Cluster 2 ............... 44
Task 27: Configure SIP trunk to Unified CM SME ............................................................ 44
Task 28: Configure Route Group ..................................................................................... 45
Task 29: Configure Route List ......................................................................................... 46
ILS/GDPR with Centralized Unified CM SME ....................................... 47

Configure SIP Route String for Unified CM Leaf 1 .............................. 49
Task 30: Configure SIP route string ................................................................................. 49
Configure SIP Route String for Unified CM Leaf 2 .............................. 50

Task 31: Configure SIP route string ................................................................................. 50
Configure Unified CM SME Dial Plan ................................................. 51

Task 32: Configure Partitions in Unified CM SME ............................................................ 52
Task 33: Configure Calling Search Space in Unified CM SME ......................................... 53
Configure SIP Trunks on Unified CM SME .......................................... 54

Task 34: Configure SIP Trunk to Unified CM Leaf 1 ......................................................... 54
Task 35: Configure SIP Trunk to Unified CM Leaf 2 ......................................................... 54
Task 36: Configure SIP Trunk to Unified Border Element ................................................. 55
Configure Route Groups and Route Lists in Unified CM SME ............... 57

Task 37: Configure Route Group for Unified CM Leaf 1 ................................................... 57
Task 38: Configure Route Group for Unified CM Leaf 2 ................................................... 58
Task 39: Configure Route Group for Unified Border Element ........................................... 58
Task 40: Configure Route List for Unified CM Leaf 1 ....................................................... 59
Task 41: Configure Route List for Unified CM Leaf 2 ....................................................... 59
Task 42: Configure Route List for Unified Border Element ............................................... 60
Configure SIP Route Pattern in Unified CM SME ................................. 61

Task 43: Configure SIP Route Pattern for Unified CM Leaf 1 ........................................... 61
Task 44: Configure SIP Route Pattern for Unified CM Leaf 2 ........................................... 62
Configure Phone Line in Unified CM Leaf 1 ....................................... 63

Task 45: Configure Global Dial Plan Replication for Phone #1 ......................................... 63
Task 46: Configure advertisement for Enterprise Alternate Number ................................ 64
Task 47: Configure advertisement for +E.164 Alternate Number ..................................... 64
Configure Phone Line in Unified CM Leaf 2 ....................................... 65
Task 48: Configure Global Dial Plan Replication for Phone #1 ......................................... 65
Task 49: Configure advertisement for Alternate Number ................................................. 66
Task 50: Configure advertisement for +E.164 Number .................................................... 66
Validate learned patterns via ILS/GDPR ............................................. 67

Task 51: Validate learned patterns on Leaf Cluster 2 ...................................................... 67
Task 52: Place calls with Cisco Jabber Client.................................................................. 68
Configure PSTN Route Patterns Leaf Cluster 1 .................................. 70

Task 53: Add US NANP static route pattern on Leaf Cluster 1 ........................................ 70
Task 54: Add International static route pattern on Leaf Cluster 1 .................................... 71
Configure PSTN Route Patterns Leaf Cluster 2 .................................. 72

Task 55: Add US NANP static route pattern on Leaf Cluster 2 ........................................ 72
Task 56: Add International static route pattern on Leaf Cluster 2 .................................... 73
Configure PSTN Route Patterns Unified CM SME ................................ 74

Task 57: Add US NANP static route pattern on Unified CM SME ..................................... 74
Task 58: Add International static route pattern on Unified CM SME ................................. 75
CUBE General Configuration ............................................................ 76

Task 59: CUBE General Configuration ............................................................................. 76
Task 60: Configure media inactivity ................................................................................. 78
CUBE Box to Box Redundancy .......................................................... 79

Task 61: Configure redundancy between CUBEs ............................................................ 79
Task 62: Configure IPC between CUBEs ......................................................................... 79
Task 63: Configure track interface objects ...................................................................... 80
Task 64: Configure HSRP on Inside Interfaces ................................................................ 81
Task 65: HSRP Tracking and Priorities ............................................................................. 81
Task 66: Configure HSRP delay timers ............................................................................ 82
Task 67: Configure HSRP group name ............................................................................ 82
Task 68: Verify configuration of HSRP on Internal Interfaces ........................................... 83
Task 69: Configure Service Provider HSRP Interface ...................................................... 83
Task 70: Configure Redundancy Inter-device ................................................................. 84
CUBE Server Groups ....................................................................... 86

Task 71: Define internal server groups ............................................................................ 86
Task 72: Define external ( service provider ) server groups............................................. 86
E164 Dial Maps ............................................................................... 87

Task 73: Configure internal E164 Dial Map ...................................................................... 87
Task 74: Configure service provider E164 Dial Map ........................................................ 87
CUBE Dial Peers ............................................................................. 88

Task 75: Configure Dial Peers between CUBE and Unified CM SME ............................... 88
Task 76: Configure redundancy bind ............................................................................... 90
Task 77: Configure Dial Peer between CUBE and the Service Provider........................... 91
Task 78: Enable CCSIP debugs on Active Cube .............................................................. 92
Configure CUBE Dial Plan Normalization ............................................ 94

Task 79: Convert from +E.164 to NANP for Called Numbers to the PSTN ....................... 94
Task 80: Convert from +E.164 to NANP for Calling Numbers to the PSTN ...................... 94
Task 81: Convert Called Number from NANP to +E.164 for Inbound Calls from PSTN .... 95
Task 82: Convert calling number from NANP to +E.164 for inbound calls from PSTN ..... 95
Task 83: Configure Translation profile for inbound dial-peers ......................................... 96
Task 84: Add translation profiles to dial-peers ................................................................ 96
Task 85: Place PSTN call from CUCM ............................................................................. 97
CUBE DO to EO configuration ........................................................... 98

Task 86: Enable DO-EO on Outbound Dial Peers ............................................................ 99
Task 87: Verify EO-DO Configuration .............................................................................. 99
Enhanced Event Tracing ................................................................ 101

Task 88: Enable monitor event trace .............................................................................101
Task 89: Disable event-trace automatic file dump.........................................................101
Task 90: Configure event-trace memory footprint.........................................................101
Task 91: Place calls for event-monitor ..........................................................................102
Task 92: Configure dump file destination path...............................................................103
Task 93: Event-trace file dump .....................................................................................103
CUBE / SME OPTIONS Ping Configuration ........................................ 105

Task 94: Configure OPTIONS ping on CUBE dial-peers ................................................106
Task 95: Configure OPTIONS pings on Unified CM SME ...............................................107
Task 96: Add OPTIONS Ping Profile to the SIP Trunk ....................................................107
Enabling URI Dialing ...................................................................... 108

Task 97: Create a new End User and associate Primary Extension................................109
Task 98: Verify Directory URI Mapping ..........................................................................109
Task 99: Check URI replication ......................................................................................110
SME Normalization Script (Modify Diversion Header) ........................ 111

Task 100: Add a new normalization script to SME .........................................................111
Task 101: Apply Normalization Script to CUBE SIP Trunk ..............................................112
Translate Inbound DID to Lab Number ............................................. 114

Task 102: Create a new Partition in SME for inbound translations .................................114
Task 103: Create a new CSS to restrict access to Inbound Translations .......................114
Task 104: Add Inbound Translations partition to the Inbound PSTN CSS ......................115
Task 105: Create Translation Pattern to Translate PSTN number ..................................116
Task 106: Add number to e164 Pattern Map .................................................................116
Use Session Trace feature to view SIP call flow ............................... 120
Debug SIP call on CUBE ................................................................ 124
Task 107: Initiate debugs on Unified Border Element ....................................................124
Task 108: Copy log file from CUBE to your Cisco Live Workstation ...............................125
Task 109: Read the log file in Translator X .....................................................................126
Detailed tracing on Unified Communications Manager ....................... 129

Task 110: Navigate to Cisco Unified Serviceablity .........................................................129
Task 111: Enable detailed tracing for Call Manager Service ..........................................130
Unified Communications Manager trace collection ............................ 132

Task 112: Trace collection with RTMT ...........................................................................132
Task 113: Read UCM trace files with TranslatorX ..........................................................134
Task 114: Tracing a call end to end ...............................................................................137
Notes ........................................................................................... 138

Notes ........................................................................................... 139
Notes ........................................................................................... 140
Introduction to Lab
Enterprises and service providers are increasingly moving from traditional TDM-
based telephony to IP-based networks. While enterprises have been deploying IP
telephony within their networks for many years now, it is only recently that service
providers have started to provide IP-based trunking services. These trunking
services are based on the Session Initiation Protocol (SIP). SIP trunking services
typically terminate on a session border controller (SBC) that serves as a
demarcation point between the enterprise and the service provider much in the
same way that a firewall separates two data networks. The Cisco Unified Border
Element (CUBE) is Cisco’s SBC product.
SIP is also becoming increasingly important within the enterprise. Most enterprise
telephony vendors leverage SIP to communicate with each other and there are
numerous applications that use SIP as their interface to other devices, for example,
Unified Messaging, Voicemail, and Audio or Video Conferencing applications. One
challenge that SIP brings to the table is that, although it is referred to as a
“standard”, it really is just a large collection of RFC’s that vendors can interpret in
different ways or can implement only the pieces they require. As a result, there is
an increasing need to be able to interconnect these disparate systems as well as
adapt to the various SIP implementations. Most companies also have a large
installed based of legacy TDM and H.323-based telephony systems. Cisco Unified
Communications Manager Session Management Edition (SME) offers session
management capabilities for the enterprise. SME provides a rich feature set that
allows an enterprise to centrally manage various aspects of their real-time
communications such as voice and video and interconnect disparate systems from
multiple vendors and service providers.
The world of telephony has traditionally been based on static dial plans. If one
system needs to send calls to another system, a static pattern is configured
(potentially with wildcards) that indicates the trunk to use to send the call. If that
route is unavailable, there may be redundant routes that are, again, statically
configured. Some routes may even require manipulation of the digits, for example in
the case of rerouting a call to the public switched telephone network (PSTN) in the
case of a failure. This manipulation has also traditionally been statically configured
on each system that requires that functionality.
As communications migrate from segregated communications that put Voice,
Video, Instant Messaging and Email in separate realms of responsibility, the industry
is moving towards an environment of true unified communications and
collaboration. The traditional concept of a phone number has slowly started moving
to internet-style addressing that looks a lot like an email address.
This identification mechanism is known as a SIP URI (uniform resource identifier).
As it looks like an email address, SIP URI’s within an enterprise generally cannot be
summarized. For example, if bob.smith@cisco.com and bob.jones@cisco.com are
both on different Unified CM clusters within the enterprise, how do you summarize
those “routes”? There is really no way to summarize which means that every cluster
needs to know how to get to URI’s individually as opposed to through a summary.
Routes to other domains (e.g. @webex.com, @apple.com) can be summarized by
their domain or leverage DNS to look up the domain.
Cisco Unified Communications Manager 9.0 introduced the Inter-cluster Lookup
Service (ILS) feature to address this very problem. This feature made it possible for
multiple Unified CM clusters to share URI reachability information.
While ILS was a great innovation allowing all clusters to easily share URI dial plan
information, this left a hole where traditional numeric dial plans still required static
configurations. Also, URI’s could not be dialed over the traditional PSTN, so any
kind of failover to the PSTN in the event of a network outage or CAC limit was
impossible.
Unified CM 10.0 addresses these issues by extending the capabilities of ILS into a
new feature called Global Dial Plan Replication (GDPR). GDPR improves how ILS
works for URIs and also adds the ability to advertise traditional numeric routes
between clusters. With GDPR, every cluster knows how to reach directory numbers
anywhere in the network without the need to configure any numeric routes between
clusters.
In this lab, you will learn how to create an environment that uses ILS and GDPR to
establish a global dial plan. In this multiple cluster environment, you will configure
these features to establish calls between different endpoints in the network
including calls to and from the PSTN. A centralized Unified CM SME will be utilized
to aggregate the dial plan and provide access towards the PSTN via a centralized
SIP trunk that uses a Cisco Unified Border Element (CUBE) as the Session Border
Controller towards a service provider.
Prerequisites
A basic understanding of Cisco Unified Communications Manager Administration is
highly recommended in order to complete this exercise in time. Even though we will
provide step-by-step instructions, you should have a basic understanding of:
• Cisco IOS configuration
• Cisco Unified Communications Manager Dial Plan Management (Calling
Search Spaces, Partitions, Translation Patterns)
• Understanding of SIP
If you are unfamiliar with configuring Cisco IOS devices, here are a few basic
commands to get you started. If you are already familiar with IOS, you can skip to
the next page.
To access an IOS device, use the telnet/SSH client provided and authenticate with
the provided username and password. In this lab, the provided username and
password will automatically log you into the enable mode, so it is not necessary to
enter the command ‘enable’.
To configure the router, enter the command ‘config t’. To exit configuration mode,
type ‘end’ or type control-Z. IOS has various levels of hierarchical configuration.
For example, if you enter ‘interface g0/0’ while in configuration mode, you are
moved to the interface configuration mode. To back-out one level, use the
command ‘exit’. To save your configuration, exit configuration mode and enter the
command ‘wr’ (or you can use the command ‘copy running-configuration startup-
configuration’.
Lab Diagram
Your lab network contains the following products:
• Cisco Unified Communications Manager (x2)
• Cisco Unified Communications Manager Session Management Edition (SME)
• Cisco Unified Border Element (CUBE) (x2)
• Cisco Jabber for Windows 9.6 client (x2)
Each pod of this lab accommodates up to two students. Every pod is identical with
the exception of the IP addresses and phone numbers. This manual is customized
for your assigned pod number, but you may also refer to the online documentation
at http://siplab.ciscolive.com for details.
All these devices are located in a Cisco lab and the connection back to the lab is via
a VPN connection. To connect to the lab, click on the link to the VPN connection on
the siplab.ciscolive.com site if the connection has not already been established for
you.
The following diagram is a high-level topology of the devices you will be
configuring in the lab. Your CUBE routers will also connect to a simulated PSTN
network as well. You will be configuring all the components shown in the diagram
below.
10.0.110.11 10.0.110.1
10.0.110.10 2
10.0.110.40
10.0.110.5 10.0.110.6
0 0
Lab Overview
There are several high-level tasks you will complete in this lab:
1. Configure ILS/GDPR
2. Configure Dial Plan and Session Management Edition
3. Configure Trunks and Route String routing
4. Configure static PSTN routes
5. Configure CUBE and High Availability
6. Enable URI Dialing
7. Bonus Troubleshooting section
You can find access information to your pod on http://siplab.ciscolive.com
Before You Begin
Several pieces of the lab have already been pre-configured for you so that you can
spend your time focused on learning about ILS, GDPR, Session Management, and
CUBE. The following has already been configured for you:
• IP Addresses
• IP Routing
• Unified CM and Unified CM SME are installed
• Services are activated
• Jabber endpoints have been added and registered to Unified CM (some configuration
changes will be necessary)
• Users have been added to Unified CM
Additionally, there is a simulated service provider network to which you will connect
to route calls out to the PSTN.
Without further ado, let’s get on with the lab.
ILS/GDPR Overview
ILS provides a mechanism by which Cisco Unified Communications Manager
clusters can distribute information amongst each other. URI’s and directory
numbers are two of the things that ILS can distribute, but ILS also distributes the list
of all clusters that are part of the ILS network.
This makes configuration of ILS very simple. If you already have an existing ILS
network and want to add another cluster to the topology, you just point the new
cluster to any existing cluster in the topology and the new node will automatically
learn about all the other clusters in the network and establish replication links to the
other clusters as needed.
In the following diagram we can see clusters 1 and 2 are already peered with each
other using ILS.
When Cluster 3 is introduced into the network, you just need to peer to one of the
clusters participating in the ILS network. For example, in the diagram above we
peer Cluster 3 with Cluster 1. This is what happens:
1. ILS is enabled on Cluster 3 to point towards Cluster 1.
2. Cluster 1 sends the ILS topology to Cluster 3.
3. Cluster 3 then can establish connectivity to the other ILS peers in the network to begin
replicating data with them.
This is a very high level view of the communications between the clusters. Some
important things to keep in mind:
1. The ILS process only runs in the publisher node of Unified Communications Manager
cluster. This has changed from Unified CM 9.x where ILS ran on multiple nodes in the
cluster. In Unified CM 10.0, advertisements are stored in the local database, so database
replication within the cluster takes care of getting advertised data to the subscribers.
2. Clusters can be configured to take one of two roles: SPOKE or HUB as described next.
Hub or Spoke
In an ILS network a cluster can be configured to be a spoke or as a hub. A hub
shares information across the network with all other hubs and as well as spokes
that are peered to that hub. A spoke only shares the information with its configured
hub. All hub clusters form a full mesh for replication.
This provides a mechanism for creating structure across an ILS network. Depending
on the size of the ILS network the use of a spoke might play a role in your network
to reduce the size of the full mesh across Unified Communication Manager clusters.
In a scenario where a customer has a Unified CM SME cluster centrally located in
the network and various Unified Communications Manager Leaf clusters, the
network could be configured as follows:
In a hub and spoke topology, the central hub clusters are in charge of relaying the
advertisements of the topology to all the spokes. While this topology seems clean it
can delay the advertisement of patterns across the network. As a rule a cluster can
never be more than 3 hops away from any other cluster. This is because a spoke
can only peer with a hub and all hubs are fully meshed. With the default 10 minutes
synchronization timer, a new pattern can take up to 30 minutes to propagate across
the network in the worst-case scenario, however those timers can be tuned to
speed up the replication process. The diagram below shows the time it takes an
advertisement to get from one spoke to another in the case where the two spokes
are peered with different hub clusters.
When we look at fully meshed environment where each cluster is a hub, each
cluster establishes a full mesh with the other hub members of the ILS network so
advertisements only ever take at most one replication cycle to get to other clusters
as shown below.
From an administrator’s point of view, Unified Communications Manager establishes

the full mesh automatically. The administrator only needs to establish a connection
to one of the hub clusters in the network and it will establish a connection to all
known hub clusters configured in the ILS network.
Advertisements
ILS/GDPR provides 4 separate “buckets” containing patterns that are shared across
the network.
1. Enterprise Alternate Numbers
2. E164 Alternate Numbers
3. Enterprise Patterns
4. E164 Patterns
Included with each of these are:

1. Advertised by cluster identifier
2. Route string
3. Updated Sequence Number
Each of these plays a key role in how calls are routed across the network. The most
important information is the route string. The route string provides the routing
information that Unified CM uses to get the call to the correct cluster.
ILS/GDPR maps a given URI or Directory Number to a route string. A route string is
nothing more than a domain to route the call to. For example, John Chambers’
phone might be registered to the San Jose, CA Unified CM cluster represented by
the route string sjc.cisco.com, so the URI chambers@cisco.com will be associated
with the route string sjc.cisco.com.
A cluster still needs to know how to route calls for a given route string. As we will
see later, there are different approaches to this.
+13912102001
leaf1-POD10-ciscolive
leaf1-POD10.ciscolive.com
Once a cluster has received and stored information about remote patterns, it is
stored locally in the Unified CM database. Database replication takes care of
making sure all the subscribers know about the learned advertisement. The
distinction between a statically configured Route Pattern and learned Directory
Number is that each learned pattern is associated with a route string instead of a
device or route list.
The diagram below shows what happens when a user dials a pattern that has been
learned via GDPR/ILS.
10.0.110.60
Match:82103001
82103001
Dials:82103001
The user dials 82103001 which matches route string leaf2-POD10.ciscolive.com.

Unified CM then does a look up for leaf2-POD10.ciscolive.com which points to a
SIP trunk that then routes the call to the cluster with the destination phone.
Configure ILS on Unified CM SME Edition
Log into your Unified CM SME cluster (10.0.110.40) using a web browser and log in
to Unified CM Administration. You can also click on the link from the
siplab.ciscolive.com site.
SME CM IP Username Password
POD10 10.0.110.40 Administrator c1sco123!
Task 1: Configure Cluster ID

The first step in configuring ILS is to configure the Cluster ID. The Cluster ID is
defined under Enterprise Parameters. This step is critical because every cluster in
an ILS network must have a unique cluster ID. Follow these steps to configure the
cluster ID:
1. Go to System > Enterprise Parameters
2. Enter sme-POD10-ciscolive in the Cluster ID field.
3. Click Save.
sme-POD10-ciscolive
The ILS configuration section is found in the Advanced Features menu on Unified
CM:
Task 2: Configure ILS on Unified CM SME

Next you will enable ILS to start a new ILS network. In Unified CM SME, perform the
following steps:
1. Go to Advanced Features > ILS Configuration
2. Change the Role from Standalone Cluster to Hub Cluster
3. Click the checkbox Exchange Global Dial Plan Replication Data with Remote Clusters
4. In the box named Advertised Route String change the configuration that is created by
default based on DNS to sme-POD10.ciscolive.com
5. Change the Synchronize Clusters Every to 1. This will speed up the process of advertising
patterns in the lab. Changing the value to 1 in a large production environment should be
analyzed more carefully.
6. ILS can use two different forms of authentication for the replication network - either TLS
certificates or a password. You must choose one method and use it throughout the entire
network. To use TLS certificates, you must manually copy certificates between all the
clusters so that they will trust each other. With a password you just need to configure the
same password on all the clusters. For this lab we will use a password. Under ILS
Authentication configure the password c1sco123.
7. Click Save
sme-POD10.ciscolive.com
Once you click Save, ILS will display a popup window that asks for you to enter a
registration server. Because this is the first cluster in the ILS network there is no
registration server, so just click OK with the value empty. This will start the ILS
process.
Once configured, the ILS service will start on the publisher node of the Unified CM
Cluster. The bottom of the ILS configuration page should contain a table of
established ILS peers. A peer to itself should be on the list.
P OD 1
0 P OD 1
0
Configure ILS on Unified Communications Manager Leaf 1
Next you will enable ILS on the other clusters to create the replication network.
Following very similar steps that you used to configure ILS on the Unified CM SME
cluster, you will configure ILS on the first Leaf Cluster.
Use a web browser to connect to the IP address listed below and log in to Unified
CM Administration on your first leaf cluster:
CUCM Leaf 1 Username Password

Just as before, the first step in setting up ILS is to configure the Cluster ID. This is
configured under Enterprise Parameters. Follow these instructions:
2. Enter leaf1-POD10-ciscolive in the Cluster ID field.
3. Click Save.
Task 4: Configure ILS on Unified Communications Manager Leaf 1

Next enable ILS on the cluster and add it to the existing network you configured on
the Unified CM SME cluster.
4. In the box named Advertised Route String configure leaf1-POD10.ciscolive.com
5. Change Synchronize Clusters Every to 1
6. Under ILS Authentication, select Use Password and configure c1sco123 as the password.
7. Click Save.
For this cluster, you want to peer it with the Unified CM SME cluster you previously
configured. Instead of leaving the field blank to register to itself, provide the IP
address of the Unified CM SME cluster publisher IP address. For your pod the IP
address is 10.0.110.40. Enter this as the Registration Server and click OK.
10.0.110.40
Immediately after activating ILS, you will only see the local cluster on the list. If you
refresh the page, you should see the Unified CM SME cluster show up on the list of
ILS clusters as well.
Configure ILS on Unified Communications Manager Leaf 2
Now configure ILS on your second Unified CM cluster just as you did for the first.
Log into your second Unified CM cluster (10.0.110.60). Use a Web Browser to
connect to the IP address listed below and log in to Unified CM Administration:
CUCM Leaf1 Username Password

The first step we will do when configuring ILS is to configure the Cluster ID.
Configure the cluster ID under Enterprise Parameters.
2. Enter leaf2-POD10-ciscolive for the Cluster ID
3. Click Save
Task 6: Configure ILS on Unified Communications Manager Leaf 2

Now enable ILS on the second cluster by following these steps:
4. In the box named Advertised Route String configure leaf2-POD10.ciscolive.com
5. Change Synchronize Clusters Every to 1
6. Under ILS Authentication, select Use Password and configure c1sco123 as the password.
7. Click Save
For this cluster, you want to peer it with the Unified CM SME cluster you previously
configured. Instead of leaving the field blank to register to itself, provide the IP
address of the Unified CM SME cluster publisher IP address. For your POD the IP
address is 10.0.110.40. Enter this as the Registration Server and click OK.
10.0.110.40
Once completed this task, you can see the full mesh configuration of the ILS
clusters for this POD. Each node will show the peers across the network.
Task 7: View ILS Mesh topology

To observe the topology established across the ILS peers
1. Go to Advanced > ILS Configuration on any or all of your Unified CM clusters. If you are
already on this page, click the Refresh button at the top of the page.
2. At the bottom of the page you will see a table containing the peer status.
POD10 POD10
P OD 10
POD10
POD10
POD10
You should see 3 separate Unified Communications Clusters in the topology. These
show the role for each of these clusters, the cluster ID and the advertised route
string that each cluster is providing.
Dial Plan for Unified CM Leaf Cluster 1
Before you configure the dial plan components we will spend a few moments going
over the dial plan design for this lab to highlight some of the advantages that
Unified CM 10.0 and ILS/GDPR provides.
Let’s start with one of the leaf clusters. This diagram shows the structure of the
calling search spaces, partitions, translation patterns, and domain patterns that will
be used to route calls between clusters. The areas highlighted in yellow are the
portions related to GDPR.
In this simple dial plan, we will only have a single class of service that permits all
national and international calls, but the design could be expanded to include various
classes of service. We are also using a globalized +E.164 dial plan whereby all
patterns are first globalized to +E.164 format before being routed. This allows us to
look through the advertised GDPR patterns for a match before attempting to send a
call out to the PSTN, thereby facilitating the ability to keep calls on-net if you are
dialing an enterprise destination.
As mentioned earlier, GDPR routes are placed into one of four “buckets” –
Enterprise Alternate Numbers, +E.164 Alternate Numbers, Enterprise Patterns, and
+E.164 Patterns. The distinction between a Number and a Pattern is that a Number
is a single DN whereas a Pattern may contain wildcards. As you will see later, the
two are configured differently. Upon learning patterns from the GDPR network, the
patterns/numbers learned from each “bucket” are placed into a user-configurable
partition. By default, four partitions are already created for you, however you may
change them. To view the configuration of the partitions, navigate to Call Routing >
Global Dial Plan Replication > Partitions for Learned Numbers and Patterns.
You should see a screen like this:
You can see the partitions that are configured by default. Also notice that you can
configure whether learned numbers or patterns should be marked as urgent priority
or not. This is helpful to avoid inter digit timeout when dialing on-net patterns when
you have variable length patterns in your dial plan as well. For example, if you have
a pattern for +44! to reach the United Kingdom and are also learning an on-net
number of +44234567890, you would want the call to route immediately to that
number without having to wait for inter digit timeout. By marking learned numbers
as Urgent, you can make this happen.
In addition to the four pre-configured partitions, you will be adding the following
partitions in the next section:
Partition Name Description
PT_DN164 All Phone Lines will be in this partition in +E.164 format
PT_LocalFeatures Would normally contain things like Call Park Numbers
PT_Abbreviated_Dial Patterns for abbreviated 8+7 digit dialing
PT_GDPR SIP Domain Patterns to reach Route Strings
PT_Local_Translation Would normally contain any local cluster translations
PT_Global_Translation Translation Patterns to globalize PSTN calls by stripping off the access code (9) and
converting to +E.164
PT_Local_Route_Patterns +E.164 Route Patterns for reaching Local numbers
PT_National_Route_Patterns +E.164 Route Patterns for reaching National numbers
PT_Intl_Route_Patterns +E.164 Route Patterns for reaching International numbers
Let’s configure the partitions for both leaf clusters.
Task 8: Configure partitions on Leaf Cluster 1

Use a Web Browser to connect to the IP address listed below and log in to Unified
CM Administration:
1. Go to Call Routing > Class of Control > Partition

2. Click on Add New
3. Now add the following partitions to Leaf Cluster 1
Partitions
PT_DN164
PT_LocalFeatures
PT_Abbreviated_Dial
PT_GDPR
PT_Local_Translation
PT_Global_Translation
PT_Local_Route_Patterns
PT_National_Route_Patterns
PT_Intl_Route_Patterns
4. Click Save.
Task 9: Configure CoS Calling Search Space for Leaf Cluster 1
Next configure the calling search spaces on the leaf clusters. You will configure 4
different calling search spaces on this cluster. The following table describes the
calling search spaces:
CSS Name Description
CSS_COS_CiscoLive_International Contains all patterns a phone can reach. These patterns include local
patterns to other phones as well as GDPR-learned patterns/numbers and
patterns to globalize PSTN-dialed numbers.
CSS_COR_CiscoLive_National Contains +E.164 routes for both on-net and off-net patterns to reach
national numbers. Used after using translation patterns to globalize
numbers to +E.164 format.
CSS_COR_CiscoLive_International Contains +E.164 routes for both on-net and off-net patterns to reach
international numbers. Used after using translation patterns to globalize
numbers to +E.164 format.
CSS_Inbound_ILS Only has access to local patterns on the cluster. This will be used as the
inbound CSS for SIP trunks from other clusters.
To configure the first calling search space on cluster 1, do the following:

1. Go to Call Routing > Class of Control > Calling Search Space
2. Click Add New
3. Under Name enter CSS_COS_CiscoLive_International
4. For the partitions select in the following partitions in this order:
CSS_COS_CiscoLive_International
PT_DN164
Directory URI
PT_LocalFeatures
PT_Abbreviated_Dial
Global Learned E164 Numbers

Global Learned E164 Patterns
Global Learned Enterprise Numbers

Global Learned Enterprise Patterns
PT_GDPR
5. Click Save
Task 10: Configure CoR CiscoLive_National CSS
2. Click Add New.
3. Under Name enter CSS_COR_CiscoLive_National
Select the following partitions in this order:
CSS_COR_CiscoLive_National
PT_DN164

PT_GDPR
4. Click Save
Task 11: Configure CoR CiscoLive_International CSS

2. Click Add New.
3. Under Name enter CSS_COR_CiscoLive_International
4. Select the following partitions in this order:
CSS_COR_CiscoLive_International
PT_DN164

PT_GDPR
5. Click Save
Task 12: Configure CSS_Inbound_ILS CSS
Finally, configure a CSS for the SIP trunks that will be receiving calls from other
clusters.
2. Click Add New.
3. Under Name enter CSS_Inbound_ILS
Select the following partitions in this order:
CSS_Inbound_ILS
PT_DN164
PT_Abbreviated_Dial
Directory URI
4. Click Save
Configure Translation Patterns for Leaf Cluster 1
CM Administration:
Task 13: Configure National Translation Pattern

All outbound calls will use an access code of 9 followed by standard North
American numbering plan dialing. These calls will be globalized to +E.164 format.
For national calls, this means stripping the 9 and prefixing a plus (+). After
translating, the pattern uses a CSS that looks for the globalized number amongst
the local +E.164 patterns, the GDPR-learned patterns as well as route patterns to
the PSTN in case there is no on-net match.
1. Go to Call Routing > Translation Pattern in Unified CM Administration on Unified CM #1
2. Click Add New
3. Enter 9.1[2-9]XX[2-9]XXXXXX in the Translation Pattern text box
4. Change the Partition to PT_Global_Translation
5. Change the Calling Search Space to CSS_COR_CiscoLive_National
6. Select the checkbox for Provide Outside Dialtone
7. Select the checkbox Urgent Priority
8. Select the checkbox Do Not Wait for Interdigit Timeout On Subsequent Hops
9. Change Discard Digits to PreDot under Called Party Transformations
10. Enter a + for Prefix Digits (Outgoing Calls)
11. Click Save
Field Value
Translation Pattern 9.1[2-9]XX[2-9]XXXXXX
Partition PT_Global_Translation
Calling Search Space CSS_COR_CiscoLive_National
Discard Digits PreDot
Prefix Digits (outgoing) +
Task 14: Configure International Translation Pattern with #
Now do the same for international calls. The outside access code is 9 followed by
the international access code of 011. You will configure a pattern to strip the 9011
and append a plus (+). We also want to allow users to indicate end of dialing with a
trailing # sign, so you must configure two patterns – one with a # and one without.
Let’s start with the one that has a #:
2. Click Add New
3. Enter 9011.!# in the Translation Pattern text box
5. Change the Calling Search Space to CSS_COR_CiscoLive_International
9. Change Discard Digits to PreDot Trailing-# under Called Party Transformations.
11. Click Save
Field Value
Translation Pattern 9011.!#
Calling Search Space CSS_COR_CiscoLive_International
Discard Digits PreDot Trailing #
Task 15: Configure International Translation Pattern without #
The last translation pattern is to allow for international dialing without the # to
indicate end of dialing. If the pattern doesn’t match an internal pattern via
ILS/GDPR, inter digit timeout will occur on this translation and the caller will have to
wait due to variable length patterns that exist globally.
2. Click Add New
3. Enter 9011.! in the Translation Pattern text box
7. De-Select the checkbox Urgent Priority
8. De-Select the checkbox Do Not Wait for Interdigit Timeout On Subsequent Hops
9. Change Discard Digits to PreDot under Called Party Transformations.
11. Click Save
Field Value
Translation Pattern 9011.!
Configure SIP trunk and Route List to SME in Leaf Cluster 1
There are different ways of routing calls when using GDPR/ILS. Because GDPR
simply provides a route string that maps to a dialed number or URI, you can choose
how calls to those route strings are actually routed. One approach is to configure
trunks directly between clusters so that calls to a specific route string are routed
directly to the cluster. This requires forming a full-mesh of SIP trunks between
clusters. At this time, ILS does not replicate the SIP trunk information for automatic
formation of this mesh.
Another approach is to use a generic SIP route pattern to send calls to any route
string up to the Unified CM SME cluster and have the specific route strings
configured only on Unified CM SME. For this lab, we will use this second approach.
Each leaf cluster will be configured with a SIP trunk pointing to the Unified CM SME
cluster.
CM Administration:
Task 16: Configure SIP trunk to Unified CM SME

Perform the following steps to add the SIP trunk pointing to the Unified CM SME
cluster:
1. Go to Device > Trunk
2. Click Add new
3. Select SIP Trunk
4. Select SIP for Device Protocol

5. Select None(Default) for Trunk Service Type
6. Click Next
7. Configure the following parameters:
Parameter Configuration
Device Name POD10-SME-SIP-TRUNK
Device Pool Default
Calling Search Space CSS_Inbound_ILS
Destination 10.0.110.40
SIP Trunk Security Profile Non Secure SIP Trunk Profile
SIP Profile Standard SIP Profile

8. Click Save
9. Click OK on the popup
10. Click Reset.
11. On the Reset popup click Reset
12. Click Close
Make sure you reset the trunk as listed in the last two steps, otherwise the SIP
trunk will not come up and calls will fail.
Task 17: Configure Route Group

Now you must configure a route group that contains the SIP trunk pointing to
Unified CM SME:
1. Go to Call Routing > Route/Hunt > Route Group
2. Click Add New
3. Enter POD10-RG-SME for the Route Group Name
4. Select POD10-SME-SIP-TRUNK from the Available Devices list
5. Click Add to Route Group
6. Click Save
The screen should be similar to the following:
POD10-RG-SME
POD10-SME-SIP-TRUNK
POD10-SME-SIP-TRUNK ( All Ports )
Task 18: Configure Route List

Next, associate the route group containing the SIP trunk to a route list.
1. Go to Call Routing > Route/Hunt > Route List
2. Click Add New
3. Configure the following parameters
Configuration Parameter
Name POD10-RL-SME
Cisco Unified Communications Manager Group Default

4. Click Save
5. Click on Add Route Group
6. Select the route group POD10-RG-SME-[NON-QSIG]
7. Click Save
8. Click OK
The screen for the Route List should look like this:
POD10-RL-SME
POD10-RG-SME
POD10-RG-SME
Dial Plan for Unified CM Leaf Cluster 2
Now you must repeat the same steps for the second leaf cluster. The dial plan is
identical on the second cluster.
As mentioned earlier, GDPR routes are placed into one of four “buckets” –
Enterprise Alternate Numbers, +E.164 Alternate Numbers, Enterprise Patterns, and
+E.164 Patterns. The distinction between a Number and a Pattern is that a Number
is a single DN whereas a Pattern may contain wildcards. As you will see later, the
two are configured differently. Upon learning patterns from the GDPR network, the
patterns/numbers learned from each “bucket” are placed into a user-configurable
partition. By default, four partitions are already created for you, however you may
change them. To view the configuration of the partitions, navigate to Call Routing
> Global Dial Plan Replication > Partitions for Learned Numbers and
Patterns. You should see a screen like this:
You can see the partitions that have already been created for you. Also notice that
you can configure whether learned numbers or patterns should be marked as
urgent priority or not. This is helpful to avoid inter digit timeout when dialing on-net
patterns when you have variable length patterns in your dial plan as well. For
example, if you have a pattern for +44! to reach the United Kingdom and are also
learning an on-net number of +44234567890, you would want the call to route
immediately to that number without having to wait for inter digit timeout. By marking
learned numbers as Urgent, you can make this happen.
In addition to the four pre-configured partitions, you will be adding the following
partitions:
Partition Nam e Description
PT_DN164 All Phone Lines will be in this partition in +E.164 format
PT_LocalFeatures Would normally contain things like Call Park Numbers
PT_Abbreviated_Dial Patterns for abbreviated 8+7 digit dialing
PT_GDPR SIP Domain Patterns to reach Route Strings
PT_Local_Translation Would normally contain any local cluster translations
PT_Global_Translation Translation Patterns to globalize PSTN calls by stripping off
the access code (9) and converting to +E.164
PT_Local_Route_Patterns +E.164 Route Patterns for reaching Local numbers
PT_National_Route_Patterns +E.164 Route Patterns for reaching National numbers
PT_Intl_Route_Patterns +E.164 Route Patterns for reaching International numbers
Follow these steps to add the partitions to the second leaf cluster:
Task 19: Configure partitions on Leaf Cluster 2

CM Administration:
1. Go to Call Routing > Class of Control > Partition

2. Click on Add New
3. Now add the following partitions to Leaf Cluster 2
Partitions
PT_DN164
PT_LocalFeatures
PT_Abbreviated_Dial
PT_GDPR
PT_Local_Route_Patterns
4. Click Save.
Task 20: Configure CoS Calling Search Space for Leaf Cluster 2
Next configure the calling search spaces on the leaf clusters. You will configure 4
different calling search spaces on this cluster. The following table describes the
calling search spaces:
CSS Nam e Description
CSS_COS_CiscoLive_International Contains all patterns a phone can reach. These
patterns include local patterns to other phones as
well as GDPR-learned patterns/numbers and patterns
to globalize PSTN-dialed numbers.
CSS_COR_CiscoLive_National Contains +E.164 routes for both on-net and off-net
patterns to reach national numbers. Used after using
translation patterns to globalize numbers to +E.164
format.
CSS_COR_CiscoLive_International Contains +E.164 routes for both on-net and off-net
patterns to reach international numbers. Used after
using translation patterns to globalize numbers to
+E.164 format.
CSS_Inbound_ILS Only has access to local patterns on the cluster. This
will be used as the inbound CSS for SIP trunks from
other clusters.
To configure the first calling search space on cluster 2, do the following:

2. Click Add New
3. Under Name enter CSS_COS_CiscoLive_International
4. For the partitions select in the following partitions in this order:
PT_DN164
Directory URI
PT_LocalFeatures
PT_Abbreviated_Dial


PT_GDPR
5. Click Save
Task 21: Configure CoR CiscoLive_National CSS

2. Click Add New.
3. Under Name enter CSS_COR_CiscoLive_National
CSS_COR_CiscoLive_National
PT_DN164

PT_GDPR
5. Click Save
Task 22: Configure CoR CiscoLive_International CSS

2. Click Add New.
3. Under Name enter CSS_COR_CiscoLive_International
CSS_COR_CiscoLive_Local

PT_GDPR
6. Click Save
Task 23: Configure CSS_Inbound_ILS CSS
Finally, configure a CSS for the SIP trunks that will be receiving calls from other
clusters.
2. Click Add New.
3. Under Name enter CSS_Inbound_ILS
CSS_Inbound_ILS
PT_DN164
PT_Abbreviated_Dial
Directory URI
Configure Translation Patterns for Leaf Cluster 2
CM Administration:
Task 24: Configure National Translation Pattern

All outbound calls will use an access code of 9 followed by standard North
American numbering plan dialing. These calls will be globalized to +E.164 format.
For national calls, this means stripping the 9 and prefixing a plus (+). After
translating, the pattern uses a CSS that looks for the globalized number amongst
the GDPR-learned patterns as well as route patterns to the PSTN in case there is
no on-net match.
2. Click Add New
3. Enter 9.1[2-9]XX[2-9]XXXXXX in the Translation Pattern text box
5. Change the Calling Search Space to CSS_COR_CiscoLive_National
11. Click Save
Field Value
Translation Pattern 9.1[2-9]XX[2-9]XXXXXX
Calling Search Space CSS_COR_CiscoLive_National
Task 25: Configure International Translation Pattern with #
Now do the same for international calls. The outside access code is 9 followed by
the international access code of 011. You will configure a pattern to strip the 9011
and append a plus (+). We also want to allow users to indicate end of dialing with a
trailing # sign, so you must configure two patterns – one with a # and one without.
Let’s start with the one that has a #:
2. Click Add New
3. Enter 9011.!# in the Translation Pattern text box
9. Change Discard Digits to PreDot Trailing-# under Called Party Transformations.
11. Click Save
Field Value
Translation Pattern 9011.!#
Discard Digits PreDot Trailing #
Task 26: Configure International Translation Pattern without #
The last translation pattern is to allow for international dialing without the # to
indicate end of dialing. If the pattern doesn’t match an internal pattern via
ILS/GDPR, inter digit timeout will occur on this translation and the caller will have to
wait due to variable length patterns that exist globally.
2. Click Add New
3. Enter 9011.! in the Translation Pattern text box
7. De-Select the checkbox Urgent Priority
8. De-Select the checkbox Do Not Wait for Interdigit Timeout On Subsequent Hops
11. Click Save
Field Value
Translation Pattern 9011.!
Configure SIP trunk and Route List to SME in Leaf Cluster 2
There are different ways of routing calls when using GDPR/ILS. Because GDPR
simply provides a route string that maps to a dialed number or URI, you can choose
how calls to those route strings are actually routed. One approach is to configure
trunks directly between clusters so that calls to a specific route string are routed
directly to the cluster. This requires forming a full-mesh of SIP trunks between
clusters. At this time, ILS does not replicate the SIP trunk information for automatic
formation of this mesh.
Another approach is to use a generic SIP route pattern to send calls to any route
string up to the Unified CM SME cluster and have the specific route strings
configured only on Unified CM SME. For this lab, we will use this second approach.
Each leaf cluster will be configured with a SIP trunk pointing to the Unified CM SME
cluster.
CM Administration:
Task 27: Configure SIP trunk to Unified CM SME

Perform the following steps to add the SIP trunk pointing to the Unified CM SME
cluster:
2. Click Add new
3. Select SIP Trunk
4. Device Protocol will be SIP

5. Trunk Service Type will be None(Default)
6. Click Next
Device Name POD10-SME-SIP-TRUNK
Device Pool Default
Calling Search Space CSS_Inbound_ILS

9. Click Reset.
10. On the Reset popup click Reset.
Make sure you reset the trunk as listed in the last two steps, otherwise the SIP
trunk will not come up and calls will fail.
Task 28: Configure Route Group

Now you must configure a route group that contains the SIP trunk pointing to
Unified CM SME:
1. Go to Call Routing > Route/Hunt > Route Group
2. Click Add New
3. Enter POD10-RG-SME for the Route Group Name
4. Select POD10-SME-SIP-TRUNK from the Available Devices list
5. Click Add to Route Group
6. Click Save
The screen should be similar to the following:
POD10-RG-SME
POD10-SME-SIP-TRUNK
POD10-SME-SIP-TRUNK ( All Ports )
Task 29: Configure Route List
Next, associate the route group containing the SIP trunk to a route list.
1. Go to Call Routing > Route/Hunt > Route List
2. Click Add New
Name POD10-RL-SME
Cisco Unified Communications Manager Group Default
4. Click Save
5. Click on Add Route Group
6. Select the route group POD10-RG-SME-[NON-QSIG]
7. Click Save
The screen for the Route List should look like this:
POD10-RL-SME
POD10-RG-SME
POD10-RG-SME
ILS/GDPR with Centralized Unified CM SME
As mentioned earlier, ILS/GDPR takes care of replicating number and URI mappings
to a route string, but each cluster must be configured to route those route strings.
This provides deployment flexibility. ILS/GDPR can be configured such that clusters
can route calls from leaf nodes to leaf nodes. While this will work, the configuration
can become laborious when a significant number of clusters are in the network
because it would require a full mesh of trunks as shown below. With this design,
the number of SIP trunks scales exponentially as you add clusters.
Another approach is to send all calls to Unified CM SME and let it route calls by
route string to each node. The following figure shows the trunk configuration with
Unified CM SME.
With this design, when a new cluster is introduced into the network, the
administrator only needs to add the route string for the new cluster in Unified CM
SME. The number of SIP trunks scales linearly as you add clusters.
With this configuration, all the leaf clusters are configured to send all calls to the
organization’s top-level domain to Unified CM SME. Unified CM SME is then
configured with the specific sub-domains matching to the route strings for each
cluster.
For example, if Cluster 1 learns a pattern or URI from Cluster 2 and that pattern has
an associated route string of leaf2-POD10.ciscolive.com, Cluster 1 is configured
with a generic pattern of *.ciscolive.com that sends calls to Unified CM SME.
Unified CM SME is then configured with a SIP route pattern of leaf2-
POD10.ciscolive.com pointing to Cluster 2. The following diagram shows this call
flow:
le D1
af
PO
2- 0. c
isc
m
co
ol
e.
ive
liv
.c
o
isc
om
c
*.
Note that the request URI for the SIP call to Unified CM SME contains the originally
dialed number or URI, not the route string. This means that Unified CM SME needs
to look in its GDPR table to find the route string for the pattern again. It performs the
same ILS/GDPR search and routes the call to the destination because it will contain
a specific match for that SIP Route Pattern. Every leaf cluster will contain a single
SIP Route Pattern with the wild card *.ciscolive.com pointing to Unified CM SME.
In the next section you will configure the SIP route patterns needed to route the
calls via the route strings.
Configure SIP Route String for Unified CM Leaf 1
Use a Web Browser to connect to the IP address listed below
and log in to Unified CM Administration:
Task 30: Configure SIP route string

1. Go to Call Routing > SIP Route Pattern
2. Click Add New
IPV4 Pattern *.ciscolive.com
Route Partition PT_GDPR
SIP Trunk/Route List POD10-RL-SME
4. Click Save
You should have a screen similar to the following:
POD10-RL-SME
Configure SIP Route String for Unified CM Leaf 2
Use a Web Browser to connect to the IP address listed below
and log in to Unified CM Administration:
Task 31: Configure SIP route string

2. Click Add New
IPV4 Pattern *.ciscolive.com
SIP Trunk/Route List POD10-RL-SME
4. Click Save
You should have a screen similar to the following:
POD10-RL-SME
Configure Unified CM SME Dial Plan
Now that you have configured the Unified CM Leaf clusters to route calls to the
Unified CM SME, you need to configure the dial plan on Unified CM SME. This dial
plan is simplified because it does not have a Class of Service and Class of
Restriction structure. That is left for the Unified CM leaf clusters to manage.
As you may have noticed, Unified CM SME is also participating in the ILS/GDPR
network. It is also learning patterns from the network just as the Unified CM Leaf
clusters are in this network. Calls that are received from the Unified CM Leaf nodes
are routed based on pattern matching to a SIP route string from the advertisements
learned across the ILS network.
For this lab we are also leveraging Unified CM SME for centralized trunking for
PSTN calls. For this reason you will also configure SIP trunks toward the Unified
Border element in this network for all Off-Net patterns. Here is the dial plan
structure for the Unified CM SME cluster’s calling search space coming from the
leaf clusters:
For the trunks that we will be defining towards the Unified Border Element, we need
to configure the following Calling Search Space. This allows inbound calls from the
PSTN to be routed to a leaf cluster by looking up the pattern in GDPR/ILS.
Task 32: Configure Partitions in Unified CM SME
CM Administration on your Unified CM SME cluster:
Unified CM SME Username Password
1. Go to Call Routing > Class of Control > Partitions

2. Click Add New
3. Add the following partitions
Partitions
PT_GDPR
The screen should look as follows:
PT_GDPR
4. Click Save.
Task 33: Configure Calling Search Space in Unified CM SME
You must configure two calling search spaces in Unified CM SME
2. Click Add New
3. Configure this Calling Search Space with the following parameters
Name CSS_Inbound_Leaf
Selected Partitions Directory URI

PT_GDPR
4. Click Save
5. Click Add New
6. Configure the second Calling Search Space with the following parameters
Name CSS_Inbound_CUBE
Selected Partitions Global Learned E164 Numbers

PT_GDPR
7. Click Save
Now both calling search spaces should be configured on Unified CM SME.
Configure SIP Trunks on Unified CM SME
You will configure 3 total trunks on Unified CM SME - one for each of the Unified
CM Leaf Clusters and one for the Unified Border Element.
CM Administration:
Task 34: Configure SIP Trunk to Unified CM Leaf 1

2. Click Add New
3. Select SIP Trunk
4. Device Protocol SIP
5. Trunk Service Type None (Default)
6. Click Next
7. Configure the SIP Trunk with the following parameters
Device Name POD10-LEAF1-SIP-TRUNK
Device Pool Default
Calling Search Space CSS_Inbound_Leaf


8. Click Save
10. Click Reset
12. Click Close
Task 35: Configure SIP Trunk to Unified CM Leaf 2

2. Click Add New
3. Select SIP Trunk
6. Click Next
Device Name POD10-LEAF2-SIP-TRUNK
Device Pool Default

Calling Search Space CSS_Inbound_Leaf

8. Click Save
10. Click Reset
12. Click Close
Task 36: Configure SIP Trunk to Unified Border Element

2. Click Add New
3. Select SIP Trunk
6. Click Next
Device Name POD10-CUBE-SIP-TRUNK
Device Pool Default
Calling Search Space CSS_Inbound_CUBE


8. Click Save
10. Click Reset
12. Click Close
Configure Route Groups and Route Lists in Unified CM SME
In Unified CM SME we will need to configure 3 separate Route Groups and Route
Lists to point to each individual SIP trunk you just configured. Although the SIP
Route Pattern can be associated to a trunk directly, it is best practice to use route
lists and route groups.
CM Administration:
Task 37: Configure Route Group for Unified CM Leaf 1

1. Go to Call Routing > Route/Hunt > Route
Group POD10-Leaf1-RG
2. Click Add New

3. Configure the Route Group with the
following parameters
Configuration Parameter POD10-CUBE-SIP-TRUNK

POD10-LEAF1-SIP-TRUNK
Route Group Name POD10-Leaf1-RG POD10-LEAF2-SIP-TRUNK
Selected Devices POD10-LEAF1-SIP-TRUNK
4. Click Save.
Task 38: Configure Route Group for Unified CM Leaf 2
Group POD10-Leaf2-RG
2. Click Add New


Route Group Name POD10-Leaf2-RG POD10-LEAF2-SIP-TRUNK
Selected Devices POD10-LEAF2-SIP-TRUNK
4. Click Save.
Task 39: Configure Route Group for Unified Border Element

Group POD10-CUBE-RG
2. Click Add New


Route Group Name POD10-CUBE-RG POD10-LEAF2-SIP-TRUNK
Selected Devices POD10-CUBE-SIP-TRUNK
4. Click Save.
POD10-CUBE-SIP-TRUNK
POD10-CUBE-SIP-TRUNK
Task 40: Configure Route List for Unified CM Leaf 1
List
2. Click Add New POD10-Leaf1-RL
3. Configure the Route List Information with

the following parameters
POD10-Leaf1-RL POD10-Leaf1-RG
Name
Unified CM Group Default
4. Click Save
5. Click Add Route Group.
6. Once in Route List Member Information
select the Route Group POD10-Leaf1-RL POD10-Leaf1-RG
7. Click Save
8. Click Apply Config
9. Click OK on the popup.
Task 41: Configure Route List for Unified CM Leaf 2

List
2. Click Add New POD10-Leaf2-RL

Name POD10-Leaf2-RL POD10-Leaf2-RG
4. Click Save
select the Route Group POD1-Leaf2-RG POD10-Leaf2-RG
7. Click Save
Task 42: Configure Route List for Unified Border Element
List
2. Click Add New POD10-CUBE-RL

Name POD10-CUBE-RL POD10-CUBE-RG
4. Click Save
select the Route Group POD10-CUBE-RG POD10-CUBE-RG
7. Click Save
Configure SIP Route Pattern in Unified CM SME
As we have mentioned in various parts of the document, we have to configure
specific routing for the route string that is advertised by the leaf clusters. You have
already configured a SIP Route Pattern of *.ciscolive.com on the leaf clusters that
point to the Unified CM SME.
Now you have to configure Unified CM SME with two unique SIP Route Patterns.
Because ILS is already configured in the network, we can check the ILS peer
configuration page to see the different advertised route strings in the network.
In Unified CM SME if you go to Advanced Features > ILS Configuration on the
bottom of the screen is the peering process. You should see the following:
Leaf1-POD10-ciscolive leaf1-POD10.ciscolive.com
Leaf2-POD10-ciscolive leaf2-POD10.ciscolive.com
sme-POD10-ciscolive sme-POD10.ciscolive.com
To reach each of the clusters you need to configure each advertised route string.
SIP Route Patterns
Task 43: Configure SIP Route Pattern for Unified CM Leaf 1

2. Click Add New leaf1-POD10.ciscolive.com
3. Configure the SIP Route Pattern with the
PT_GDPR
Configuration Parameter POD10-Leaf1-RL
IPv4 Pattern leaf1-POD10.ciscolive.com
SIP Trunk/Route List POD10-Leaf1-RL
Task 44: Configure SIP Route Pattern for Unified CM Leaf 2
2. Click Add New leaf2-POD10.ciscolive.com
3. Configure the SIP Route Pattern with the
PT_GDPR
Configuration Parameter POD10-Leaf2-RL
IPv4 Pattern leaf2-POD10.ciscolive.com
SIP Trunk/Route List POD10-Leaf2-RL
Configure Phone Line in Unified CM Leaf 1
Now that the dial plan is setup between the three clusters, you must configure the
line of the phones such that each cluster can advertise the directory numbers into
the network. We will be utilizing soft phones for this lab by enabling Phone Mode
Jabber client.
For each directory number in Unified CM, GDPR/ILS allows you to advertise two
different kinds of advertisements: Enterprise Alternate Numbers and +E.164
Alternate Numbers. Although technically speaking you can use these two
categories to carry whatever kind of advertisement you want, the intention is that
the Enterprise Alternate Number will contain some form of global private dial plan
numbering (e.g. site-code based dialing) while the +E.164 Alternate Number will
contain the true globally reachable +E.164 number.
CM Administration:
Task 45: Configure Global Dial Plan Replication for Phone #1

In Unified Communications Manager 10.x, the administrator is presented with new
options when configuring the line. Perform the following steps to configure the line
parameters:
1. Go to Device > Phone
\+13912102001
2. Click Find
3. You should see the list of phones.
4. Click on the device CSFPOD10USER1
5. Once in the Phone Configuration, click on
Line [1]
6. The line DN has been pre-configured with CSFPOD10USER1
the +E.164 value for this device.
7. Select PT_DN164 for the Route Partition of
this line.
8. Change the Calling Search Space to
9. Click Save
10. Scroll down until you can see two fields;
Enterprise Alternate Number and +E.164
Alternate Number
11. Click on Add Enterprise Alternate Number
12. Click on Add +E.164 Alternate Number
Task 46: Configure advertisement for Enterprise Alternate Number
Now you can configure the advertisement of the directory number into the ILS
network in the Enterprise Alternate Number configuration section.
1. Under Number Mask enter 8 followed
by 7 X’s (8XXXXXXX). 82102001
2. Click Add to Local Route Partition

3. Select the Route Partition named
PT_Abbreviated_Dial
4. Click on Advertise Globally via ILS
This will advertise an enterprise Alternate Number into the network making it
possible for users to reach this phone via the abbreviated 8-digit dialed number.
The checkbox for Add to Local Route Partition is important here for several
reasons. First of all, there are no translation patterns anywhere that translate the
Enterprise Alternate Number to the Directory Number on the line. In order to
actually reach this pattern, it must be inserted into the local digit analysis engine.
You could choose to create a generic translation pattern to accomplish this,
however the better approach is just to add each alternate number directly into the
digit analysis tree by using this mechanism.
Task 47: Configure advertisement for +E.164 Alternate Number

Next, configure the +E.164 advertisement. Because the directory numbers you are
using are already in +E.164 format, there is no need to apply a mask or add to the
local partition as it already exists in the partition configured on the DN.
1. Click Advertise Globally via ILS
2. Click Save for the Directory Number +13912102001

Configure Phone Line in Unified CM Leaf 2
Next, complete the same steps for Unified CM Leaf 2. Use a Web Browser to
connect to the IP address listed below and log in to Unified CM Administration:
Task 48: Configure Global Dial Plan Replication for Phone #1

Perform the following steps to enable advertisements on your first phone.
1. Go to Device > Phone
\+13912103001
2. Click Find
3. You should see the list of phones.
4. Click on the device CSFPOD10USER2
5. Once in the Phone Configuration, click on
Line [1]
6. The line DN has been pre-configured with CSFPOD10USER2
the +E.164 value for this device.
7. Select PT_DN164 for the Route Partition of
this line.
8. Change the Calling Search Space to
9. Click Save
10. Scroll down until you can see two fields;
Enterprise Alternate Number and +E.164
Alternate Number
11. Click on Add Enterprise Alternate Number
12. Click on Add +E.164 Alternate Number
+13912103001
Task 49: Configure advertisement for Alternate Number
Now we can configure the advertisement of the directory number into the ILS
network.
1. Under Number Mask enter 8 followed by
7 X’s (8XXXXXXX). 82103001
2. Click Add to Local Route Partition

3. Select the Route Partition named
PT_Abbreviated_Dial
4. Click on Advertise Globally via ILS
This will advertise an enterprise Alternate Number into the network and add it to the
local PT_Abbreviated_Dial partition.
Task 50: Configure advertisement for +E.164 Number

Do the same for the +E.164 Alternate Number:
1. Click Advertise Globally via ILS
2. Click Save for the Directory Number +13912103001

Validate learned patterns via ILS/GDPR
Now that you have configured the Phone Lines to advertise via ILS/GDPR, you can
validate that each of the clusters has learned patterns from the other clusters. Use
a Web Browser to connect to the IP address listed below and log in to Unified CM
Administration:
You will first be looking at Leaf Cluster 2 to see if it has learned the advertisements
from Leaf 1. Remember that ILS replication takes up to 1 minute to go from one
hub to another, so Leaf 1 might not have learned the patterns from Leaf 2 yet as
you just added those advertisements to Leaf 2.
Task 51: Validate learned patterns on Leaf Cluster 2

In Unified CM 10.x, a new menu option exists under Call Routing that contains all
the learned and advertised components of Global Dial Plan Replication. This
information is also available as part of the Route Plan Report under the Call Routing
menu.
1. Go to Call Routing > Global Dial Plan Replication >
Learned Numbers
This will present the following screen after clicking Find.
+13912102001 POD10 POD10

82102002 POD10 POD10
As you can see, Leaf 2 has learned the two separate numbers from Leaf #1. The
+E164 number and the enterprise alternate number for the configured phone. You
can now test placing calls to these numbers from Leaf 2.
Feel free to look at your other clusters (Leaf Cluster 1 and Unified CM SME) to
ensure they are learning all the routes from the rest of the network.
Task 52: Place calls with Cisco Jabber Client
Now you can utilize Cisco Jabber client to test calls across the ILS/GDPR network
from cluster to cluster. Each POD of the lab has two desktop computers that have
Cisco Jabber Client 9.6 installed.
If the Jabber Client is not started on the Cisco provided laptop computer, please
start the client. The ICON is located on your desktop and looks similar to:
Once the client is started it will connect to Unified Communications Manager. Each
desktop computer is configured to speak to either Leaf 1 or Leaf 2. POD10user1 is
configured to Leaf 1 and POD10user2 is configured for Leaf2.
Once the client is started you can validate that the Jabber Client is properly
connected to the Unified Communications Manager Server by Selecting Help >
Show Connection Status
You should see the status for Softphone as connected.

Now you can place calls from one Softphone to the next.
POD10user1@
Dial Digits Phone POD10user2@
82103001 Should
82103001 Ring
POD10user1@ POD10user2@
You can also place calls by dialing 9 followed by the E.164 for US National
numbers.
POD10user1@
913912103001 Should
913912102001 Ring
Calls should complete in both directions. You can also complete the call using +
dialing. After you are done confirming all the dialing between phones is working,
you can move on to completing the PSTN dial plan and CUBE configuration.
Configure PSTN Route Patterns Leaf Cluster 1
The last step in configuring the dial plan for the leaf clusters is to configure the
static route patterns for PSTN access to send calls to the Unified CM SME cluster in
case the number is not an on-net number. You will be configuring two static route
patterns, one for NANP dialing, +1[2-9]XX[2-9]XXXXXX, and one for international
dialing, +[2-9]!.
CM Administration:
Task 53: Add US NANP static route pattern on Leaf Cluster 1

To add the first PSTN route pattern, do the following:
1. Go to Call Routing > Route Hunt > Route Pattern
2. Click Add New
3. Configure the Route Pattern with the values defined
below:
Field Value
Route Pattern \+1[2-9]XX[2-9]XXXXXX
Route Partition PT_National_Route_Patterns
Gateway/Route List POD10-RL-SME
P O D 10 -R L -S M E
4. Click Save
Task 54: Add International static route pattern on Leaf Cluster 1
Next do the following to add the international dialing pattern.
2. Click Add New
below:
Field Value
Route Pattern \+[2-9]!
Route Partition PT_Intl_Route_Patterns
4. Click Save
Configure PSTN Route Patterns Leaf Cluster 2
Repeat the same steps for Leaf Cluster 2.
CM Administration:
Task 55: Add US NANP static route pattern on Leaf Cluster 2

First add the NANP pattern
2. Click Add New
below:
Field Value
4. Click Save
Task 56: Add International static route pattern on Leaf Cluster 2
Then add the pattern for International dialing
2. Click Add New
below:
Field Value
4. Click Save
Configure PSTN Route Patterns Unified CM SME
Once the calls reach Unified CM SME, they must go out to the PSTN via the CUBE
SIP trunks. You will be configuring two static route patterns to send calls to CUBE.
CM Administration:
Task 57: Add US NANP static route pattern on Unified CM SME

Perform these steps to add the NANP route pattern.
2. Click Add New
below:
Field Value
Gateway/Route List POD10-CUBE-RL
P O D 10 -CU B E -R L
4. Click Save
Task 58: Add International static route pattern on Unified CM SME
Now add the international route pattern
2. Click Add New
below:
Field Value
Gateway/Route List POD10-CUBE-RL
Urgent Priority Selected
P O D 10 -CU B E -R L
4. Click Save
CUBE General Configuration
Now that you have configured the internal ILS network and are able to place calls
between internal phones, you need to configure the pair of Cisco Unified Border
Element (CUBE) routers that you will be utilizing as the Session Border Controllers
(SBC) to the service provider’s SIP trunk.
You will be configuring the ISR CUBEs as a redundant box-to-box system. By
configuring redundancy between two separate routers you can provide a
mechanism that allows calls to stay active in the event of an error condition such as
a power outage, hardware failure, or software failure on one of the two devices.
Because you are configuring 2 CUBEs in redundancy mode, each configuration
needs to be applied to the separate routers. There is no automatic configuration
synchronization between the two routers.
The configuration between the two routers is nearly identical with the exception of a
few minor differences, so make sure you do not just copy and paste the
configuration from one router to the other. It is probably best to have one team-
member work on one router while the other works on the second.
Task 59: CUBE General Configuration

You have already configured this router to disable trusted addresses. This new
feature in IOS 15.x is a toll-fraud prevention mechanism. In your private network
you can provide specific IP addresses that you wish to permit this device to
establish calls with. For the purpose of this lab you have disabled the feature with
the following commands:
CUBE 1 CUBE 2
(config)#voice service voip (config)#voice service voip
(conf-voi-serv)#no ip address trusted authenticate (conf-voi-serv)#no ip address trusted authenticate
Now you need to add some additional CUBE-specific configuration to the router.
First, enable sip-to-sip connections. By default, Cisco IOS does not permit a call to
both originate and terminate on a VoIP call leg; at least one party in the call must be
a POTS port. With this command, you are allowing VoIP to VoIP connections as
long as both call legs are SIP.
Enter the following commands in configuration mode on the CUBE router:
CUBE 1 CUBE 2
(conf-voi-serv)#mode border-element (conf-voi-serv)#mode border-element
(conf-voi-serv)#allow-connections sip to sip (conf-voi-serv)#allow-connections sip to sip
Next, enable address hiding. This will force the CUBE to utilize it’s own IP
addresses for each of the call legs so that the service provider does not have
visibility to your internal IP addressing.
Enter the following configuration in configuration mode on the CUBE router:
CUBE 1 CUBE 2
(conf-voi-serv)#address-hiding (conf-voi-serv)#address-hiding
Next, enable header and mid-call signaling pass-through. When CUBE receives a
SIP INVITE, SUBSCRIBE, and NOTIFY message, the header passing command
enables passing SIP headers associated with these messages to the other party in
the call.
The midcall-signaling command distinguishes between the way Unified CME and
CUBE handle signaling messages. Most SIP-to-SIP video and SIP-to-SIP re-INVITE
based supplementary services require the midcall-signaling command to be
configured before configuring other supplementary services. Supplementary
service features that are functional without configuring midcall-signaling include:
session refresh, fax, and refer-based supplementary services. The midcall-
signaling command is for SIP-to-SIP calls only.
CUBE 1 CUBE 2
(conf-voi-serv)#sip (conf-voi-serv)#sip
(conf-serv-sip)#header-passing (conf-serv-sip)#header-passing
(conf-serv-sip)#midcall-signaling passthru (conf-serv-sip)#midcall-signaling passthru
The supported codecs are configured via the voice class codec. Configure the
following on the CUBE router:
CUBE 1 CUBE 2
(config)#voice class codec 1 (config)#voice class codec 1
(config-class)#codec preference 1 g711ulaw (config-class)#codec preference 1 g711ulaw
(config-class)#codec preference 2 g729r8 (config-class)#codec preference 2 g729r8
Many customers prefer to use G.729 as the preferred codec to conserve

bandwidth over SIP trunks to service providers. Some services only accept G.711.
You can define different codec classes and apply them to the different dial-peers
based on call flow direction to handle different call types (say Fax pass-through). In
our case we will prefer G.711 but still allow G.729 so that Unified CM can negotiate
G.729 if necessary.
Task 60: Configure media inactivity

It is best practice to configure media inactivity timer to tear down calls that are not
transmitting RTP in the network. This can happen if there is a failure in the network
somewhere that leads to CUBE not being notified that the call has ended. By
detecting whether or not the CUBE has received RTP packets for a specified
number of minutes, CUBE can automatically tear down orphaned connections. Note
that IP phones still send RTP packets even if they are on Mute, so leaving a call
muted for an extended period of time will not cause the call to drop.
Perform the following configuration to enable media inactivity detection:
CUBE 1 CUBE 2
(config)#gateway (config)#gateway
(config-gateway)# media-inactivity-criteria all (config-gateway)# media-inactivity-criteria all
(config-gateway)# timer receive-rtcp 5 (config-gateway)# timer receive-rtcp 5
Last you must enable the SIP User Agent. This is a global configuration command.
CUBE 1 CUBE 2
(config)#sip-ua (config)#sip-ua
CUBE Box to Box Redundancy
This next section takes you through configuring the box-to-box redundancy
features in IOS.
Task 61: Configure redundancy between CUBEs

The first step in configuring the ISR CUBE for box-to-box redundancy is to enable
redundancy under voice service voip.
CUBE 1 CUBE 2
(conf-voi-serv)#redundancy (conf-voi-serv)#redundancy
Task 62: Configure IPC between CUBEs

ISR CUBE redundancy uses Inter-Device Protocol Communication (IPC) to maintain
state information between the CUBEs. This allows one CUBE to tell the other about
active calls so that, in the event of a failover, the other CUBE already knows what
calls were previously set up.
CUBE 1 CUBE 2
(config)#ipc zone default (config)#ipc zone default
(config-ipczone)#association 1 (config-ipczone)#association 1
(config-ipczone-assoc)#protocol sctp (config-ipczone-assoc)#protocol sctp
(config-ipc-protocol-sctp)#no shutdown (config-ipc-protocol-sctp)#no shutdown
The association command must match between the two redundant routers for the
failover to work. The protocol that we will be utilizing is SCTP (Stream Control
Transmission Protocol).
Now you can configure the local port and remote destination IP addresses. For the
purpose of this lab you will be using the internal CUBE interface to carry the IPC
communications between both CUBEs.
When configuring the IPC zone, you must define the IP address and port of the
local interface. This is the information that will tell IPC on what port he is to listen to
for communications from his peer.
Perform the following configuration on each CUBE to set up the IPC communication
local parameters.
CUBE 1 CUBE 2
(config-ipc-protocol-sctp)#local-port 5000 (config-ipc-protocol-sctp)#local-port 5000
(config-ipc-local-sctp)#local-ip 10.0.110.11 (config-ipc-local-sctp)#local-ip 10.0.110.12
Once completed, you can configure the remote association to the peer IPC. In this
lab the IP address of CUBE1 is 10.0.110.11 and CUBE2 is 10.0.110.12. For the
configuration of the local and remote ports, you must point to the opposite router.
CUBE 1 CUBE 2
(config-ipc-local-sctp)#remote-port 5000 (config-ipc-local-sctp)#remote-port 5000
(config-ipc-remote-sctp)#remote-ip 10.0.110.12 (config-ipc-remote-sctp)#remote-ip 10.0.110.11
Once completed, the configuration for IPC is done and the configuration should
look like this:
CUBE 1 CUBE 2
ipc zone default ipc zone default
association 1 association 1
no shutdown no shutdown
protocol sctp protocol sctp
local-port 5000 local-port 5000
local-ip 10.0.110.11 local-ip 10.0.110.12
remote-port 5000 remote-port 5000
remote-ip 10.0.110.12 remote-ip 10.0.110.11
Task 63: Configure track interface objects

CUBE is typically deployed using two interfaces: an interface pointing towards the
service provider, and an internal interface. When you configure CUBE box-to-box
redundancy, one possible failure scenario is that one of the two interfaces on one
of the CUBE routers might loose connectivity. In this scenario, it makes sense for
the primary function of CUBE to switchover to the standby CUBE so that call routing
can continue.
In this diagram you can see that the service provider interface for CUBE1 has gone
down (g0/1). By configuring tracking when the interface on CUBE1 goes down, the
CUBE redundancy code forces CUBE1 to reboot so that CUBE2 can take over.
Enter the following commands to turn on interface tracking.
CUBE 1 CUBE 2
(config)# track 1 interface GigabitEthernet0/0 (config)# track 1 interface GigabitEthernet0/0
line-protocol line-protocol
(config)# track 2 interface GigabitEthernet0/1 (config)# track 2 interface GigabitEthernet0/1
line-protocol line-protocol
Task 64: Configure HSRP on Inside Interfaces

For this lab setup you will be utilizing interface GigabitEthernet0/0 as the inside
interface on each CUBE. The IP address for interface GigabitEthernet0/0 is
10.0.110.11 on CUBE1 and 10.0.110.12 on CUBE2. That configuration is already
completed; please don’t modify.
Next you must configure the HSRP address for the inside interface. When
configuring HSRP with groups it’s important that both routers share the same HSRP
group so that the multicast address used to exchange HSRP keepalives matches
between the routers.
Enter the following configuration to enable HSRP on the inside interface:
CUBE 1 CUBE 2
(config)#interface GigabitEthernet0/0 (config)#interface GigabitEthernet0/0
(config-if)#standby 110 ip 10.0.110.10 (config-if)#standby 110 ip 10.0.110.10
Task 65: HSRP Tracking and Priorities

For proper functionality of CUBE, both interfaces of the same group have to be
configured with the same priority. This reason for this has to do with pre-emption.
With disparate priorities the highest priority router always pre-empts the standby.
This will cause problems for CUBE upon the return of a higher priority router after
recovering from an HA event. When using the IP address as the tiebreaker, pre-
emption doesn’t force a change in the state of HSRP.
To ensure that the same router is active for both the service provider facing and
internal interfaces, we have to make sure that the IP address is configured such that
one side always wins for both interfaces. HSRP uses the higher IP address as the
tiebreaker. In the following example you can see an example:
For the purpose of this lab, we have configured the IP addresses for you. CUBE 2
will be the highest priority. In the event of a failure of CUBE 2, CUBE 1 will take over
functionality for the network. When CUBE2 returns from it’s HA event, CUBE2 will
not preempt CUBE1 because the priorities are the same.
Task 66: Configure HSRP delay timers

You will be making a change to the delay timers for HSRP. You want to make sure
that during the reboot of a standby HSRP group router, the HSRP state doesn’t go
active before the interface has actually gone into an active/operational state.
CUBE 1 CUBE 2
(config-if)# standby delay minimum 30 reload 60 (config-if)# standby delay minimum 30 reload 60
(config-if)# standby version 2 (config-if)# standby version 2
(config-if)# bfd interval 500 min_rx 500 multiplier 3 (config-if)# bfd interval 500 min_rx 500 multiplier 3
Task 67: Configure HSRP group name

Now you are going to configure a name for this HSRP group. This will be used to tie
the HSRP group to the redundancy application. The redundancy application will use
this interface as its keepalive mechanism.
CUBE 1 CUBE 2
(config-if)# standby 110 name box2boxcube (config-if)# standby 110 name box2boxcube
Task 68: Verify configuration of HSRP on Internal Interfaces
At this point the configuration of the HSRP interfaces on the routers should be:
CUBE 1 CUBE 2
interface GigabitEthernet0/0 interface GigabitEthernet0/0
ip address 10.0.110.11 255.255.255.128 ip address 10.0.110.12 255.255.255.128
standby delay minimum 30 reload 60 standby delay minimum 30 reload 60
standby 110 ip 10.0.110.10 standby 110 ip 10.0.110.10
standby 110 name box2boxcube standby 110 name box2boxcube
You can then verify that HSRP is active and working between the two routers with
the show standby command.
CUBE 1 CUBE 2
#show standby #show standby
GigabitEthernet0/0 – Group 110 GigabitEthernet0/0 – Group 110
State is Standby State is Active
5 state changes, last state change 22:21:32 5 state changes, last state change 22:21:32
Virtual IP address is 10.0.110.10 Virtual IP address is 10.0.110.10
Active virtual MAC address is 0000.0c07.ac65 Active virtual MAC address is 0000.0c07.ac65
Local virtual MAC address is 0000.0c07.ac65 Local virtual MAC address is 0000.0c07.ac65
(v1 default) (v1 default)
Hello time 3 sec, hold time 10 sec Hello time 3 sec, hold time 10 sec
Next hello sent in 1.456 secs Next hello sent in 1.456 secs
Active router is 10.0.110.12, priority 100 Active router is local
(expires in 8.624 sec) Standby router is 10.0.110.11, priority 100
Standby router local (expires in 8.624 sec)
Priority 100 (configured 100) Priority 100 (configured 100)
Track object 2 state Up decrement 10 Track object 2 state Up decrement 10
Group name is "box2boxcube" (cfgd) Group name is "box2boxcube" (cfgd)
Note: Which router becomes the active and standby in your topology depends on
the order in which you have configured them. Don’t worry about this for now. We
will reload the router later to get everything synced up.
Task 69: Configure Service Provider HSRP Interface

Similar to the inside interface configuration, configure HSRP for the service provider
interface, GigabitEthernet0/1. The configuration should be as follows:
CUBE 1 CUBE 2
(config-if)#standby delay minimum 30 reload 60 (config-if)#standby delay minimum 30 reload 60
(config-if)#standby 210 ip 10.0.224.109 (config-if)#standby 210 ip 10.0.224.109
Task 70: Configure Redundancy Inter-device
Now you can start the process of creating the inter-dependency between the
CUBE redundancy functionality and HSRP. One of the two routers may fail
(depending on the HSRP state) – keep reading on.
CUBE 1 CUBE 2
(config)#redundancy inter-device (config)#redundancy inter-device
(config-red-interdevice)#scheme standby box2boxcube (config-red-interdevice)#scheme standby box2boxcube
The command scheme standby box2boxcube refers to the HSRP configuration

group name.
One of the two routers may show the error when you enter the scheme standby
box2boxcube command:
% Standby scheme configuration cannot be processed now group box2boxcube is not in active state
This is because the router wants the HRSP group to be active before allowing you
to enter this command. The router still takes the command even though it displays
this message.
For redundancy to function, a router reload is required. Save the configuration and
reload the router (if you already reloaded one of the two above, so it’s not
necessary to reload it again).
CUBE 1 CUBE 2
#wr #wr
Building configuration… Building configuration…
[OK] [OK]
# reload # reload
The router reload will take approximately 4 – 5 minutes. After the router has finished
reloading, you can examine the state of the application redundancy with the
command show redundancy states. The active/standby states may be reversed in
your set up.
CUBE 1 CUBE 2
#show redundancy states #show redundancy states
my state = 8 -STANDBY HOT my state = 13 -ACTIVE
peer state = 13 -ACTIVE peer state = 8 -STANDBY HOT
Hardware Mode = Duplex Unit ID = 0 Hardware Mode = Duplex Unit ID = 0
Maintenance Mode = Disabled Maintenance Mode = Disabled

Manual Swact = cannot be initiated from this the standby unit Manual Swact = enabled
Communications = Up Communications = Up
client count = 13 client count = 13

client_notification_TMR = 60000 milliseconds client_notification_TMR = 60000 milliseconds
RF debug mask = 0x0 RF debug mask = 0x0
You can now proceed to configure the CUBE SIP functions.
CUBE Server Groups
If you have been working with IOS voice configuration for years, you may be most
familiar with dial-peer configurations where a dial-peer exists with a destination
pattern for each of the Unified Communication Manager nodes that CUBE wants to
send calls to. As an example, with a cluster of Unified Communication Manager of 8
call processing nodes, you would have to configure a total of 8 dial-peers for each
pattern you want to send to Unified CM. This means if you had 3 different patterns
pointing to the cluster, you would need 24 dial-peers.
A new feature introduced in CUBE release 10.0 will significantly reduce the count of
dial-peers in a Border Element. This feature is called destination server group.
This feature is configured as a voice class function outside of the dial-peers and
then assigned to a dial peer instead of a session target pointing to an individual IP
address.
Task 71: Define internal server groups

CUBE 1 CUBE 2
(config)#voice class server-group 1 (config)#voice class server-group 1
(config-class)#ipv4 10.0.110.40 (config-class)#ipv4 10.0.110.40
While our configuration is simple in this lab, you would configure in your own
production environment the IP addresses of all the Unified Communication Manager
call processing nodes under the same server-group.
Task 72: Define external ( service provider ) server groups

You will now configure the next sever group that points towards the service
provider SBC that is part of this lab. You will configure these with a preference state
to favor a specific destination IP address.
CUBE 1 CUBE 2
(config)#voice class server-group 2 (config)#voice class server-group 2
(config-class)#ipv4 10.0.224.101 preference 1 (config-class)#ipv4 10.0.224.101 preference 1
(config-class)#ipv4 10.0.224.102 preference 2 (config-class)#ipv4 10.0.224.102 preference 2
E164 Dial Maps
In Cisco Unified Border Element release 8 and higher, a feature called E164 number
maps was introduced. This functionality makes it possible to group various E164
numbers under a single dial-peer. This can be used for both destination and
incoming called-number functions of dial-peers since the release of Unified Border
Element 10 (prior to release 10, it was only available for destination-patterns, but
not incoming called-number).
Task 73: Configure internal E164 Dial Map

CUBE 1 CUBE 2
(config)#voice class e164-pattern-map 1 (config)#voice class e164-pattern-map 1
(config-class)# e164 391210.... (config-class)# e164 391210....
Now we can configure the E164 Dial Map for PSTN destinations
Task 74: Configure service provider E164 Dial Map

CUBE 1 CUBE 2
(config)#voice class e164-pattern-map 2 (config)#voice class e164-pattern-map 2
(config-class)# e164 +1[2-9]..[2-9]...... (config-class)# e164 +1[2-9]..[2-9]......
(config-class)# e164 +[2-9]T (config-class)# e164 +[2-9]T
Dial Peer Maps are a very powerful feature that combined with server groups has
the potential to simplify a Unified Border Element configuration significantly from the
past.
CUBE Dial Peers
Task 75: Configure Dial Peers between CUBE and Unified CM SME
When configuring dial-peers with redundant CUBEs it is important that the dial-
peers match between both routers. If not, depending on which CUBE is active,
different behavior will occur.
You will first configure the dial-peer that matches numbers owned by your
enterprise and routes them to the SME cluster for further processing. SME will then
leverage GDPR/ILS to find the correct destination cluster.
Recall that you only have two number ranges that route into your site – one for each
Unified CM cluster. The service provider is routing calls to you as a 10-digit national
number. You can tell CUBE to send any calls that arrive with a called party of
391210.... to SME by configuring the following dial-peer.
CUBE 1 CUBE 2
(config)# dial-peer voice 101 voip (config)# dial-peer voice 101 voip
(config-dial-peer)# destination e164-pattern-map 1 (config-dial-peer)# destination e164-pattern-map 1
You also want to anchor calls that originate from your network to this dial-peer. To
accomplish this, you will utilize the incoming called configuration command on the
dial-peer.
Remember that every call that traverses CUBE has an inbound and outbound dial-
peer match. The inbound peer determines any settings relevant to the inbound call
leg (e.g. codecs, DTMF configuration, etc...). The outbound dial peer does the
same for the outbound call leg.
It is always a good practice with CUBE or Unified CME to ensure that calls are
always assigned (or anchored) to a configured dial-peer. If not you can run into
matching the default dial-peer, dial-peer 0, which may not have the parameters
you want to apply for that session. This is why you use the command incoming
called to catch the inbound call leg. You will repeat the same to anchor the
inbound calls from the PSTN on the second dial-peer. Another way to accomplish
the same goal is to have separate dial-peers that only contain the incoming
called and no destination pattern. Calls that originate from the enterprise will be
sent to CUBE in a globalized +E.164 format.
Configure the following dial-peer command to anchor incoming calls from SME to
this dial peer. We will now utilize the second e164 pattern map that contains both
possible PSTN destination patterns we configured under e164-pattern-map 2.
CUBE 1 CUBE 2
(config-dial-peer)# incoming called e164-pattern-map 2 (config-dial-peer)# incoming called e164-pattern-map 2
You want to make sure that for any calls matching this dial-peer the only protocol
used is SIP. The command is session protocol sipv2. You also want to force the
protocol to UDP only. UDP is the only transport supported for redundant CUBE.
CUBE 1 CUBE 2
(config-dial-peer)# session protocol sipv2 (config-dial-peer)# session protocol sipv2
(config-dial-peer)# session transport udp (config-dial-peer)# session transport udp
Next, specify the destination IP that is the target for this dial-peer. The destination
is that of SME that was configured in our server-group 1. This option in the dial-
peer configuration will NOT be visible until session protocol sipv2 is configured.
This is because the server-group feature is only available for SIP dial peers.
CUBE 1 CUBE 2
(config-dial-peer)# session server-group 1 (config-dial-peer)# session server-group 1
Two additional commands are important - the DTMF relay configuration and the
maximum connections. For the purpose of this lab we are going to keep the
maximum number of connections at 5 and will be using RFC2833 as our DTMF
transport. You will also assign the voice class codec you configured previously.
CUBE 1 CUBE 2
(config-dial-peer)# max-conn 5 (config-dial-peer)# max-conn 5
(config-dial-peer)# dtmf-relay rtp-nte (config-dial-peer)# dtmf-relay rtp-nte
(config-dial-peer)# voice-class codec 1 (config-dial-peer)# voice-class codec 1
(config-dial-peer)# no vad (config-dial-peer)# no vad
Now any calls received by CUBE from the PSTN to an internal extension will be sent
to Unified CM SME by this dial-peer.
NOTE: These DID numbers are not reachable from the PSTN as they are using a
fictitious area code, however a subsequent section will allow you to configure real
DIDs and map them to some of your phones. You will be able to place calls to the
real PSTN from your Jabber Client once the configuration is completed correctly.
Task 76: Configure redundancy bind

Now you can configure the bind between the dial-peer and the interface. There are
two commands you will be using on each dial peer. Media and signaling each are
configured with separate bind commands:
Configure the following commands on the dial-peer:
CUBE 1 CUBE 2
(config-dial-peer)# voice-class sip bind control (config-dial-peer)# voice-class sip bind control
source-interface GigabitEthernet0/0 source-interface GigabitEthernet0/0
(config-dial-peer)# voice-class sip bind media (config-dial-peer)# voice-class sip bind media
With this configuration, any calls that arrive from the Unified CM SME destined to
the PSTN will use the configuration from this dial-peer. Creating separate dial-
peers is not necessary but is a good practice to enable finer control of calls to/from
the PSTN. Examples might include control of Delayed Offer to Early Offer based on
direction. The most critical aspect to this practice is to avoid a call falling into dial-
peer 0, a default dial-peer in IOS.
The final configuration for the dial-peers between CUBE and SME is:
CUBE 1 CUBE 2
dial-peer voice 101 voip dial-peer voice 101 voip
max-conn 5 max-conn 5
destination e164-pattern-map 1 destination e164-pattern-map 1
session protocol sipv2 session protocol sipv2
session transport udp session transport udp
incoming called e164-pattern-map 2 incoming called e164-pattern-map 2
voice-class codec 1 voice-class codec 1
voice-class sip bind control source-interface voice-class sip bind control source-interface
GigabitEthernet0/0 GigabitEthernet0/0
voice-class sip bind media source-interface voice-class sip bind media source-interface
dtmf-relay rtp-nte dtmf-relay rtp-nte
no vad no vad
Task 77: Configure Dial Peer between CUBE and the Service Provider
For the PSTN side of the CUBE you will create a dial-peer. Configure the following
dial-peer for outbound calls to the PSTN from CUBE. This dial-peer is also matched
for inbound calls from the PSTN.
CUBE 1 CUBE 2
(config-dial-peer)# incoming called e164-pattern-map 1 (config-dial-peer)# incoming called e164-pattern-map 1
(config-dial-peer)# max-conn 5 (config-dial-peer)# max-conn 5
(config-dial-peer)# destination e164-pattern-map 2 (config-dial-peer)# destination e164-pattern-map 2
(config-dial-peer)# session protocol sipv2 (config-dial-peer)# session protocol sipv2
(config-dial-peer)# session transport udp (config-dial-peer)# session transport udp
(config-dial-peer)# session server-group 2 (config-dial-peer)# session server-group 2
(config-dial-peer)# dtmf-relay rtp-nte (config-dial-peer)# dtmf-relay rtp-nte
(config-dial-peer)# voice-class codec 1 (config-dial-peer)# voice-class codec 1
(config-dial-peer)# voice-class sip bind control (config-dial-peer)# voice-class sip bind control
(config-dial-peer)# voice-class sip bind media source- (config-dial-peer)# voice-class sip bind media source-
interface GigabitEthernet0/1 interface GigabitEthernet0/1
(config-dial-peer)# no vad (config-dial-peer)# no vad
At this point the dial-peer configuration should be as follows:

CUBE 1 CUBE 2
max-conn 5 max-conn 5
session server-group 1 session server-group 1
no vad no vad
! !
session server-group 2 session server-group 2
! !
After adding the dial-peers the first time, you must once again reload the routers. If
you do not reload the router at this point, CUBE will send INVITEs out using the
physical interface address instead of the virtual HRSP address. This is only
necessary the first time you configure the router. You should be able to add
additional dial-peers on the fly after this without having to reboot again.
To save the configuration and reload the routers, do the following:
CUBE 1 CUBE 2
# wr # wr
Building configuration… Building configuration…
[OK] [OK]
# reload # reload
After the router reboots, check the state of the application redundancy with the
command show redundancy states. The active/standby states may be reversed.
Generally the router you rebooted first should come up as the active CUBE.
At this point, even though you have a working configuration, you are missing a key
component. Currently the PSTN is sending 10-digit NANP numbers to CUBE, but
SME is expecting to see numbers globalized in +E.164 format. Similarly, the PSTN
will not accept numbers in +E.164 format and the numbers have to be localized to
the NANP format. As a result, in the current state, calls will fail.
This is a good opportunity to enable CCSIP message debugs on the router to see
the calls failing and determine the root cause of the failure.
Task 78: Enable CCSIP debugs on Active Cube

First verify the active ISR CUBE router in your lab. The command is
# show standby brief
One CUBE will be active the second will be standby. On the active CUBE enter the
following debug command.
# clear log
Clear logging buffer [confirm] <Press Return>
# debug ccsip messages
The routers are configured to send all messages to the log. Once you have enabled
the debugs on the router, place a call to a PSTN phone number. Use one of your
Jabber clients to dial 9 + 1 + 10 digits, for example, 919199915678. Once the call
has failed, you can view the debugs in the log with the following commands to turn
off debugging and then show the log:
# no debug all
# show log
In the logs, you should see an INVITE from your SME cluster destined to the
phone number you dialed. It will look something like this:
Jun 5 11:20:15.052: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+19199915678@10.0.110.10:5060 SIP/2.0
Via: SIP/2.0/TCP 10.0.110.40:5060;branch=z9hG4bK1a15dfea59
From: <sip:+13912022001@10.0.110.40>;tag=37~8f9b5fdf-9764-44ac-82c2-37e28db8ff1f-20316794
To: <sip:+19199915678@10.0.110.10>
Date: Tue, 05 Jun 2012 18:20:15 GMT
Call-ID: 1778df00-fce14ddf-d-2866000a@10.0.102.40
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip: 10.0.110.40:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0393797376-0000065536-0000000013-0677773322
Session-Expires: 1800
P-Asserted-Identity: <sip:+13912022001@10.0.110.40>
Remote-Party-ID: <sip:+13912022001@10.0.110.40>;party=calling;screen=yes;privacy=off
Contact: <sip:+13912022001@10.0.110.40:5060;transport=tcp>
Max-Forwards: 68
Content-Length: 0
If you do not see any debugs at all, you may have an issue further upstream. The
problem may be that your Unified CM is not sending the call to SME, or SME is not
sending the call to CUBE. Contact a lab proctor for help if you are not seeing the
INVITE.
If your dial-peer matching is configured correctly, you should then see another
INVITE sent out to one of the two PSTN SBC’s. You will then see CUBE send a 100
Trying message back to the SME cluster and receive a 100 Trying from the PSTN.
You should then see the PSTN cluster respond with an error as follows:
Jun 5 11:20:15.076: //74/1778DF000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.0.224.29:5060;branch=z9hG4bK17187
From: <sip:+13912022001@10.0.224.29>;tag=17C388-415
To: <sip:+19199915678@10.0.224.102>;tag=205030~7607a476-c715-48ae-9c26-7d7ede797628-
45449815
Date: Tue, 05 Jun 2012 18:20:15 GMT
Call-ID: EE5188D7-AE7111E1-8072B792-6968135D@10.0.224.29
CSeq: 101 INVITE
Allow-Events: presence
Reason: Q.850;cause=1
Content-Length: 0
This message indicates that the PSTN is unable to route the call to the number
provided. If you look at the INVITE that went out to the PSTN, you will see that the
call is being sent to the +E.164 address, however the PSTN is expecting an NANP-
formatted number. This normalization can be handled in several ways. You could do
it in SME or CUBE. On CUBE you can do it either as the call arrives into CUBE or as
the call is going out from CUBE. The next section goes into the localization and
normalization of numbers in CUBE.
Configure CUBE Dial Plan Normalization
Because most service providers don’t accept numbers in +E.164 format, you will
have to convert from +E.164 to NANP numbering on egress and convert from
NANP to +E.164 on ingress. CUBE can do this either as a call comes into CUBE (on
the inbound dial-peer before a destination-pattern match) or on egress (after a
destination-pattern match on the outbound dial-peer). In this lab, you will do the
translation on the outbound dial peer. The primary reason for doing this is to
prevent routing loops where CUBE sends a call from the PSTN back out to the
PSTN.
You need to normalize both the calling and called party numbers for presentation
purposes.
Task 79: Convert from +E.164 to NANP for Called Numbers to the PSTN
The first translation you are going to configure is going to convert from +E.164 to
NANP for numbers CUBE receives from SME. National numbers will just get the +
removed while international numbers will have the + removed and 011 prefixed (the
international access code for the NANP).
CUBE 1 CUBE 2
(config)# voice translation-rule 101 (config)# voice translation-rule 101
(cfg-translation-rule)# rule 1 /^\+\(1[2-9]..[2- (cfg-translation-rule)# rule 1 /^\+\(1[2-9]..[2-
9]......\)/ /\1/ 9]......\)/ /\1/
(cfg-translation-rule)# rule 2 /^\+\([2-9]\)/ (cfg-translation-rule)# rule 2 /^\+\([2-9]\)/
/011\1/ /011\1/
Let’s examine what the translation rule is doing. This rule matches a +E.164 number
and converts it to NANP format.
Task 80: Convert from +E.164 to NANP for Calling Numbers to the PSTN
You must also convert from +E.164 to NANP for the calling party number. The
PSTN expects calling party numbers to be a 10-digit national number. You will also
make a provision for an international number to go out as country-code followed by
number. This may occur if a call from an international phone is routed on net within
your enterprise and then routed out to the PSTN as a toll-bypass call.
Configure the following translation rules to transform the calling party numbers:
CUBE 1 CUBE 2
(cfg-translation-rule)# rule 1 /^\+1\([2-9]..[2- (cfg-translation-rule)# rule 1 /^\+1\([2-9]..[2-
9]......\)/ /\1/ 9]......\)/ /\1/
(cfg-translation-rule)# rule 2 /^\+\([2-9]\)/ /\1/ (cfg-translation-rule)# rule 2 /^\+\([2-9]\)/ /\1/
The difference between this translation rule and the previous is that we want the
calling user to be seen without the country code (1) for national numbers.
Task 81: Convert Called Number from NANP to +E.164 for Inbound Calls
from PSTN
You must convert the numbers arriving from the PSTN in NANP format to +E.164
before routing to SME. This will convert from a 10-digit number the service provider
is sending to +E.164 by prefixing the digits +1. You will never receive a call
destined to anything other than a national number from a US-based service
provider, so there is no need to make any provisions for international calls.
CUBE 1 CUBE 2
(cfg-translation-rule)# rule 1 /\([2-9].........\)/ (cfg-translation-rule)# rule 1 /\([2-9].........\)/
/+1\1/ /+1\1/
In this case any number that is 10 digits that starts with [2-9] will match and CUBE
will add a +1 to that.
Task 82: Convert calling number from NANP to +E.164 for inbound calls
from PSTN
For calls arriving from the PSTN, CUBE must globalize the calling party number to
+E.164 format so that features like the missed calls directory on the phone work
without requiring any editing of the phone number. SIP presents one challenge in
this regard in that it does not provide a way to distinguish between a national and
international calling party number the way that H.323 and ISDN Q.931 do. This
means that there is a potential for ambiguity in the calling party number. The safest
assumption to make is that a calling party number that is 10 digits long and starts
with the digits 2 through 9 is a national number (so it needs a prefix of +1) and any
other number is international with the country code and number, so it only needs a
prefix of +. If there happens to be a country with a 2-digit country code followed by
8-digit national number that starts with the digits 2 through 9, it will be mis-
categorized as a US number. The only way around this is if the PSTN starts
supporting the sending of numbers in +E.164 format.
Create the following translation rule to convert from NANP to +E.164 for inbound
calls from the PSTN:
CUBE 1 CUBE 2
(cfg-translation-rule)# rule 1 /\([2-9].........\)/ (cfg-translation-rule)# rule 1 /\([2-9].........\)/
/+1\1/ /+1\1/
(cfg-translation-rule)# rule 2 /\([2-9]\)/ /+\1/ (cfg-translation-rule)# rule 2 /\([2-9]\)/ /+\1/
Task 83: Configure Translation profile for inbound dial-peers

Now that you have the translations, you can configure the translation profiles that
will be applied to the dial-peers.
CUBE 1 CUBE 2
(config)# voice translation-profile inbound-add-plus (config)# voice translation-profile inbound-add-plus
(cfg-translation-profile)# translate called 201 (cfg-translation-profile)# translate called 201
(cfg-translation-profile)# translate calling 202 (cfg-translation-profile)# translate calling 202
(cfg-translation-profile)# exit (cfg-translation-profile)# exit
(config)# voice translation-profile outbound-strip- (config)# voice translation-profile outbound-strip-
plus plus
(cfg-translation-profile)# translate called 101 (cfg-translation-profile)# translate called 101
(cfg-translation-profile)# translate calling 102 (cfg-translation-profile)# translate calling 102
Task 84: Add translation profiles to dial-peers

Now apply the translation profile to the dial peers. Make sure you configure the
correct profile on the dial peers (101 is using the inbound translation profile while
the other four use the outbound profile).
CUBE 1 CUBE 2
(cfg-translation-profile)# translation-profile (cfg-translation-profile)# translation-profile
outgoing inbound-add-plus outgoing inbound-add-plus
(cfg-translation-profile)# translation-profile (cfg-translation-profile)# translation-profile
outgoing outbound-strip-plus outgoing outbound-strip-plus
Task 85: Place PSTN call from CUCM
Place a test call to make sure your PSTN dialing is now working correctly. You can
call your mobile phone or dial one of the PSTN phones located throughout the lab.
To dial a number outside of the U.S. dial 9 + 011 + country code + number
optionally terminated with the # sign.
POD10user1@ Dial Digits Phone

9[cell phone]#
9[PSTN Should
Phone] Ring
POD10user1@ Cell Phone
At this point, you should now be able to place outbound calls to the PSTN from any
of your phones and dial any phone within your network via ILS/GDPR by dialing
either 8+7 digits or by dialing as a PSTN call (which will be routed locally on-net
without actually going out to the PSTN).
CUBE DO to EO configuration
Many service providers require that the SIP INVITE that is sent to their SBC have the
SDP already included with the INVITE this is called Early Offer (EO) because the
media negotiation information is offered in the INVITE. Until recently, Unified
Communications Manager only supported Delayed Offer (DO) unless you insert a
Media Termination Point (MTP) for every call through that trunk (which also comes
with numerous limitations). This meant that the original INVITE would lack the SDP.
CUBE can act as an intermediary and force the call leg that is sent to the provider
have the SDP offer in the INVITE. When an INVITE does not contain an SDP offer,
this type of call is referred to as a Delayed Offer INVITE. If the INVITE contains SDP,
it is an Early Offer INVITE.
Unified CM will accept either an Early Offer or Delayed Offer INVITE without issue.
CUBE can take an Early Offer and send an Early Offer to the outbound leg, take a
Delayed Offer and send a Delayed Offer to the outbound leg, or take a Delayed
Offer and send an Early Offer to the outbound leg. It cannot accept an Early Offer
and send a Delayed Offer to the outbound leg, but this is not a problem as any RFC
3261 compliant device must support receiving an Early Offer, so there should never
be a case where you need to convert from EO to DO.
There are two ways to configure DO to EO conversion – at the global level or at the
dial-peer level. The global configuration is done under the voice service voip sub-
configuration, however for the purpose of this lab you will do the configuration at
the dial peer level for more control of exactly when CUBE performs DO to EO
conversion. This is the recommended way to deploy this feature.
You already have inbound and outbound dial peers to both SME and the service
provider’s SBCs. In the following configuration, you will modify the outbound dial
peers to the service provider so that CUBE always sends an Early Offer regardless
of what it receives on the inbound leg.
Task 86: Enable DO-EO on Outbound Dial Peers
What you must do is force the outbound dial-peer to send early offer only. You
must add the command voice-class sip early-offer forced to the two dial
peers that point to the service provider’s SBCs.
CUBE 1 CUBE 2
(config-dial-peer)# voice-class sip early-offer (config-dial-peer)# voice-class sip early-offer
forced forced
Task 87: Verify EO-DO Configuration

You can use SIP debugs to verify that the early offer to delayed offer configuration
is working properly. Enable SIP debugs on your active CUBE as follows:
# clear log
Clear logging buffer [confirm] <Press Return>
# debug ccsip messages
Now place another call out to the PSTN and then disable debugs and view the log
file.
# no debug all
# show log
You should see an INVITE come into CUBE without SDP like this:
Jun 5 12:50:49.144: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+19196247285@10.0.102.10:5060 SIP/2.0
Via: SIP/2.0/TCP 10.0.102.40:5060;branch=z9hG4bK3524c9c624
From: <sip:+13912022001@10.0.102.40>;tag=83~8f9b5fdf-9764-44ac-82c2-37e28db8ff1f-20316832
To: <sip:+19196247285@10.0.102.10>
Date: Tue, 05 Jun 2012 19:50:49 GMT
Call-ID: be637800-fce16319-20-2866000a@10.0.102.40
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.0.102.40:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 3194189824-0000065536-0000000032-0677773322
P-Asserted-Identity: <sip:+13912022001@10.0.102.40>
Remote-Party-ID: <sip:+13912022001@10.0.102.40>;party=calling;screen=yes;privacy=off
Contact: <sip:+13912022001@10.0.102.40:5060;transport=tcp>
Max-Forwards: 68
Content-Length: 0
Then you should see an INVITE going out to the PSTN with SDP like this:
Jun 5 12:50:49.176: //300/BE6378000000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:19196247285@10.0.224.101:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.224.29:5060;branch=z9hG4bK3C19EE
Remote-Party-ID: <sip:3912022001@10.0.224.27>;party=calling;screen=yes;privacy=off
From: <sip:3912022001@10.0.224.29>;tag=6AAE64-978
To: <sip:19196247285@10.0.224.101>
Date: Tue, 05 Jun 2012 19:50:49 GMT
Call-ID: 954B5A97-AE7E11E1-81AAB792-6968135D@10.0.224.27
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3194189824-0000065536-0000000032-0677773322
User-Agent: Cisco-SIPGateway/IOS-15.2.20120302.200531.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO,
REGISTER
CSeq: 101 INVITE
Timestamp: 1338925849
Contact: <sip:3912022001@10.0.224.29:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 67
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 279
v=0
o=CiscoSystemsSIP-GW-UserAgent 9700 8418 IN IP4 10.0.224.29
s=SIP Call
c=IN IP4 10.0.224.29
t=0 0
m=audio 16468 RTP/AVP 0 18 101
c=IN IP4 10.0.224.29
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
Enhanced Event Tracing
A new feature in Unified Border Element is event tracing for SIP messages. When
configured, event tracing makes it possible for CUBE to keep track of calls. It can
store SIP messages and CUBE internal call states. These can be kept in memory
under a controlled memory space, dumped to file or dumped to external source
such as a FTP server.
Task 88: Enable monitor event trace

The first step to enable monitor event trace is to turn on tracing for both the FSM
and MSG components of event-trace. FSM keeps internal information of CUBE call
states. These can be used by Cisco in the event of diagnosing an internal problem
with CUBE.
The MSG component of event-trace stores the different SIP messages that are
exchanged between CUBE and it’s destination peers.
CUBE 1 CUBE 2
(config)# monitor event-trace voip ccsip fsm (config)# monitor event-trace voip ccsip fsm
(config)# monitor event-trace voip ccsip msg (config)# monitor event-trace voip ccsip msg
Task 89: Disable event-trace automatic file dump

Event-trace can be configured to automatically dump completed calls to files.
These can be sent to flash, ftp, tftp or internal harddrive. For the purpose of this
lab we will disable the automatic dump functionality and keep the trace in memory
and dump the event trace based on a search criteria.
CUBE 1 CUBE 2
(config)# monitor event-trace voip ccsip dump none (config)# monitor event-trace voip ccsip dump none
Task 90: Configure event-trace memory footprint

You will now set a memory limit for event-trace in the memory of the router. In a
production environment you can expand and contract this based on the amount of
memory that exists in your router.
You will set a limit of 100 MB for the purpose of this lab.
CUBE 1 CUBE 2
(config)# monitor event-trace voip ccsip limit (config)# monitor event-trace voip ccsip limit
memory 100 memory 100
With event-trace configured we can now place calls and have them show up in
event-trace. First you need to determine what CUBE is the active CUBE in your
topology. Issue the command
# show standby
The active CUBE should be State is Active. This might be your partner’s CUBE.
Task 91: Place calls for event-monitor

Using the Jabber client place calls to the specified PSTN test number

9[cell phone]#
9[PSTN Should
Phone] Ring
Place various calls for added effect. Once done, we can look at event-monitor to
see the calls that are stored internally. The command is:
# show monitor event-trace voip ccsip history latest
The output will be similar to:

--------Cover buff----------
buffer-id = 1 ccCallId = 1030 PeerCallId = 1031
Called-Number = +1919XXXXXXX Calling-Number = +13912XXXXXX Sip-Call-Id =
8bd64100-2d414633-20-2865000a@10.0.101.40
sip_msgs: Enabled.. Total Traces logged = 14
sip_fsm: Enabled.. Total Traces logged = 32
--------------------------------
With this information you can the tell event-trace to display more information for a
call. From the command that you have issued, gleam the ccCallId field. Then you
can use that to specify the call-id to filter inside of event-trace.
# show monitor event-trace voip ccsip history filter call-id [Number] all
That will dump all the information (both FSM and MSG) for the call with the
specified call-id. You can also filter based on the calling or called number.
# show monitor event-trace voip ccsip history filter call-num [Number] all
Another functionality of event-trace is the ability to dump the contents of the

buffers to file. This functionality can be used automatically for all calls or used to
just push the contents to file upon user intervention.
Task 92: Configure dump file destination path
Event-trace keeps the information about calls in memory in the buffer we previously
specified. The information is stored while memory is available in the platform and is
cleared out last call first. You can configure the router to write files to a folder. This
can be the local flash or remote FTP or TFTP server.
While this can be done automatically for all calls, the performance hit on the
platform can be significant if the system has a high rate of Call per Second. When
you configure the destination path you don’t automatically dump for each call (that
you do separately). You specify the path such that when you tell the system to
dump the call it’s placed in the defined path and filename.
You will now configure the monitor event-trace destination configuration. Even
though we have disabled automatic file dump, we have to give CUBE the
information needed to where to place the dump files when we trigger the dump
event manually.
CUBE 1 CUBE 2
(config)# monitor event-trace voip ccsip dump-file (config)# monitor event-trace voip ccsip dump-file
flash:ciscolivetrace.log flash:ciscolivetrace.log
With this you will be able to tell the system to dump the information for a specific
call.
Task 93: Event-trace file dump

Place calls from the jabber client towards a PSTN device and hang up to complete
the call.

9[cell phone]#
9[PSTN Should
Phone] Ring
Issue the command:

# show monitor event-trace voip ccsip history latest
To get the list of calls stored in the buffer. With this each call has defined a ccCallID
field. This unique field gives you an identifier to dump the buffer content.
# monitor event-trace voip ccsip history dump filter call-id [ccCallID] pretty
When completed you should see that the router writes to flash two files. One
contains the meta-data and the second contains the trace logs. You can view these
files with the more command.
CUBE / SME OPTIONS Ping Configuration
SIP trunks are peer-to-peer links and, as such, do not normally maintain any kind of
registration so that one side can determine whether or not the peer is still available
to receive a call. Typically in the event of a failure, an attempt to send an INVITE to
a peer will fail and after some timers, the call is rerouted to another peer. This
provides redundancy, however it introduces dial delays while the caller waits for the
first call to fail.
Many SIP devices (including Unified CM, Unified CM SME, and CUBE) support
sending a type of keepalive called an out-of-dialog OPTIONS ping to the peer
device to determine whether or not the peer is still available to accept calls. For the
trunks between Unified CM SME and CUBE as well as the link between CUBE and
the Service Provider, this is the best way to ensure fast failover in the event of
failure.
OPTIONS ping works by periodically sending a SIP OPTIONS message to the peer
and expecting a response. Depending on the response (or lack thereof), CUBE will
respond by setting the dial peer in service or out of service. When a monitored
session target fails to respond (or responds with an error code), the dial-peer is
busied out. If an alternate dial-peer is configured for the same destination pattern,
the call is attempted on the next preferred dial peer, if no remaining routes are
available, CUBE rejects the call immediately which allows the upstream call agent to
attempt to reroute if it has another CUBE or gateway it can use to send the call.
The response to options ping is considered unsuccessful in the following scenarios:
Error Code Description
503 service unavailable

505 sip version not supported
no response request timeout
All other error codes, including 4XX are considered a valid response and the dial
peer is not busied out. This is because a 400-series code generally means the
device responding is up and functioning, but likely just does not support the
OPTIONS method. When a dial-peer is busied out, CUBE continues attempting to
send an OPTIONS ping and the dial-peer is set to active upon receipt of a valid
response.
When using box-to-box redundancy on CUBE, only the active CUBE will send
OPTIONS pings. The standby will show the dial-peers in the busyout state until it
becomes active.
Task 94: Configure OPTIONS ping on CUBE dial-peers

Before the release of CUBE 10.0, the options ping configuration was performed on
an individual dial-peer basis using the voice-class sip options-keepalive
command and all the relevant parameters like timers and retry counts had to be
configured on each dial-peer. This configuration is still possible if you are not using
the server-groups capability; however, when using server-groups, you must use
the new options-keepalive profile construct to enable OPTIONS ping. This profile is
then applied to each dial-peer.
To enable OPTIONS ping, first create a sip-options-keepalive voice class. You can
optionally define the up-interval and down-interval timers and retry count here as
well if you wish. For the purpose of this lab we will use the defaults.
up-interval seconds— Number of up-interval seconds allowed to pass before marking the UA as unavailable. The
range is 5-1200. The default is 60.
down-interval seconds — Number of down-interval seconds allowed to pass before marking the UA as
unavailable. The range is 5-1200. The default is 30.
retry retries — Number of retry attempts before marking the UA as unavailable. The range is 1 to 10. The default is
5 attempts.
CUBE 1 CUBE 2
(config)# voice class sip-options-keepalive 1 (config)# voice class sip-options-keepalive 1
(config-class)# description CiscoLive Options Class (config-class)# description CiscoLive Options Class
(config-class)# transport udp (config-class)# transport udp
Enable OPTIONS ping on the dial-peers facing the service provider by issuing the
following commands on the CUBE routers:
CUBE 1 CUBE 2
(config-dial-peer)# voice-class sip options- (config-dial-peer)# voice-class sip options-
keepalive profile 1 keepalive profile 1
Configure OPTIONS ping for the peers pointing to Unified CM SME as well with the
following commands:
CUBE 1 CUBE 2
(config-dial-peer)# voice-class sip options- (config-dial-peer)# voice-class sip options-
keepalive profile 1 keepalive profile 1
Task 95: Configure OPTIONS pings on Unified CM SME

To enable OPTIONS pings on the Unified CM SME cluster you must modify the SIP
profile used on the SIP trunk to CUBE. You are not allowed to modify the
configuration of the Standard SIP Profile, so you must copy the existing one and
create new one, then apply the new profile to the SIP trunk that points to CUBE.
First create the new SIP Profile:
1. Go to Device > Device Settings > SIP
Profile on the Unified CM SME Cluster
2. Click Find
3. Click on Standard SIP Profile
4. Click Copy at the top of the page
5. Change the name to SIP Profile with
OPTIONS
6. At the bottom of the page for SIP Profile is
the section for SIP Options Ping.
7. Click on Enable OPTIONS Ping to monitor
destination status for Trunks with
Service Type "None (Default)"
8. Click Save
Task 96: Add OPTIONS Ping Profile to the SIP Trunk

Finally, you must apply the profile you just created to the SIP trunk going to your
CUBE.
1. Go to Device > Trunk on the Unified CM Cluster.
2. Click Find
3. Select the SIP Trunk that goes to CUBE (POD10-CUBE-SIP-TRUNK)
4. Change the SIP Profile (not SIP Security Profile) to SIP Profile with OPTIONS.
5. Click Save
6. Click Reset
7. On the pop up window, click Reset
8. Close the popup window by clicking Close
Enabling URI Dialing
Up to now you have only dealt with dialing numeric patterns, however URI-based
dialing has become more prevalent recently, especially when dealing with video
conferencing systems and B2B connections using VCS Expressway.
Fortunately, now that you have ILS up and running throughout your network,
configuring URI dialing very easy. ILS will replicate the mapping between a URI and
a route string just as it does for GDPR numeric patterns and numbers.
In Unified CM, a line must always have a directory number. A URI becomes just
another alias of that line, similar to the way an Enterprise or +E.164 Alternate
number become an alias for the primary DN on the line.
There are two ways to associate a URI with a line. The first is to just manually
configure the URI on the directory number page. There is a section for Directory
URIs the looks like this:
Here, you assign the URI, the partition, and you can decide whether or not to
advertise the URI to other clusters via ILS.
The other way to assign a URI to a line is by using the user directory to assign a
directory URI and map that user to a primary extension. All URI’s mapped this way
are automatically placed into a partition called the ‘Directory URI’ partition that is
pre-installed. Most customers will normally use the second method because it
allows the URI to also show up in the user directories on the phone.
Let’s go through the steps of adding a URI to a user using this second method.
Task 97: Create a new End User and associate Primary Extension
First connect to leaf cluster 1 using the credentials below:
The users on this cluster have already been created for you, however the Primary
Extension mapping was broken earlier when you changed the partition of the
directory number that was configured on your phone. Let’s fix this to fix your URI
dialing.
Add an end user following these steps:
1. Go to User Management > End Users on the Unified CM Cluster.
2. Click Find
3. Click on your user
4. Scroll down to the Directory Number Associations section
5. You should see the Primary Extension is already set to \+13912102001, however you
must change it to \+13912102001 in PT_DN164
6. Click Save.
Task 98: Verify Directory URI Mapping

At this point the user’s URI should now be associated with the primary extension
that is configured for the user. To verify, follow these steps:
1. Go to Device > Phones on the Unified CM Leaf 1 Cluster.
2. Click Find
3. Select the device CSFPOD10USER1
4. Click on Line[1]
5. Scroll down to the Directory URIs section. You should see the URI you configured on the
user page now associated with this line automatically:
Notice that the Advertise Globally via ILS checkbox is automatically enabled
and you didn’t actually have to configure anything for URI dialing to work globally
other than associating the user with the directory number via the Primary
Extension.
Task 99: Check URI replication
Within a minute, this URI should replicate to the other clusters in the ILS network.
You can verify that the route has been learned on leaf cluster 2 and Unified CM
SME by looking at the route plan report.
To check that the pattern has been learned, log into your second leaf cluster and
follow these instructions:
1. Go to Call Routing > Route Plan Report on the Unified CM Leaf 2 Cluster.
2. Change the Find field to All URIs
3. Click Find
4. You should see POD10user1@ciscolive.com appear on the list with a type of Learned URI
and a route string of leaf1-POD10.ciscolive.com.
You can now place a test call using URI dialing. This call will go between clusters
via the SME cluster.
POD10user1@ Phone POD10user2@

Dial URI
POD10user2@ciscolive.com Should
POD10user2@ciscolive.com
Ring
POD10user1 POD10user2
SME Normalization Script (Modify Diversion Header)
Unified CM 8.5 introduced a new feature called “SIP Normalization and
Transparency”. This feature allows you to associate a script with a SIP trunk and
execute that script for all calls that traverse the trunk. The scripts are written in a
language called Lua (see http://www.lua.org/ for more information), which is a very
powerful and efficient language for applications such as this.
The normalization and transparency scripts allow an administrator to make
numerous modifications to SIP messages as they traverse Unified CM.
Modifications can include adding, deleting, or modifying any of the SIP headers, as
well as modifying SDP information. This feature also allows Unified CM to
transparently pass through unknown headers when interconnecting two devices
that leverage proprietary signaling.
This feature allows you to solve a variety of interoperability issues in a multi-vendor
environment as different vendors sometimes interpret various SIP RFC’s differently
or choose to implement some RFC’s and not others.
One common use for normalization scripts is to modify the SIP Diversion header.
The Diversion header is typically used to indicate the original called party for a given
call. For example, if Phone A calls Phone B and Phone B is configured to forward to
the PSTN, the calling party number should indicate Phone A’s phone number, but
list Phone B in the diversion header.
Unified CM provides a variety of mechanisms for modifying the calling and called
party numbers as a call traverses through the system, however no such mechanism
exists for modifying the redirecting number information carried in the Diversion
header. By default, Unified CM will simply present the directory number configured
on the line for the original called party.
This section will walk you through the process of adding a normalization script to
apply a mask to the diversion header.
Task 100: Add a new normalization script to SME

First you must add the script to Unified CM SME.
1. On your SME cluster go to Device > Device Settings > SIP Normalization Script.
2. Click Add New
3. Enter DiversionMask as the name
4. In the content, add the following script:
M = {}
local mask = scriptParameters.getValue("Diversion-Mask")
function M.outbound_INVITE(message)
if mask
then
message:applyNumberMask("Diversion", mask)
end
end
return M
NOTE: You can copy/paste this script from a link provided to you in the lab.
5. Click Save.
Task 101: Apply Normalization Script to CUBE SIP Trunk

Finally, you must add the newly-created normalization script to the SIP trunk that
points to the CUBE.
To associate the normalization script to the SIP trunk, do the following:
1. On your SME cluster go to Device > Trunk.
2. Click Find
3. Select the SIP trunk that points to your CUBE router (POD10-CUBE-SIP-TRUNK)
4. Scroll to the bottom of the page and in the Normalization Script menu, select the
DiversionMask script
5. In the Parameter Name box, enter Diversion-Mask (this is case-sensitive).
6. In the Parameter Value box, enter XXXXXXXXXX (10 X’s).
7. Click Save
8. Click Reset to reset the trunk
9. On the popup that appears, click Reset
10. Click Close
Translate Inbound DID to Lab Number
As mentioned earlier, the DID numbers assigned to your phones are allocated from
a non-existent area code and are therefore unreachable from the PSTN, however
we have set up several real DID numbers that are being routed to your CUBE from
the service provider. The following section will show you how to accept those
numbers and use SME to translate the numbers to two of your phones so you can
receive calls from the PSTN.
Follow these steps to allow inbound calls from the PSTN.
Task 102: Create a new Partition in SME for inbound translations

You will create a new partition on SME called InboundTranslations that will be
used as the partition for Translation Patterns that will be used to translate the PSTN
number to your internal number.
1. On your SME cluster, go to Call Routing > Class of Control > Partition.
2. Click the Add New button
3. Enter InboundTranslations for the name of the new partition and click Save.
Task 103: Create a new CSS to restrict access to Inbound Translations

You will create a new Calling Search space that will be used for the calling search
space of your translation patterns. This CSS will only have access to the GDPR-
learned patterns and not to the translations.
1. On your SME cluster, go to Call Routing > Class of Control > Calling Search Space.
2. Click the Add New button
3. Enter CSS_Only_GDPR for the name of the new CSS.
4. Select the following partitions from the Available Partitions list and click the down arrow to
add them to the Selected Partitions list.
CSS_Only_GDPR
PT_GDPR
5. Click Save.
Task 104: Add Inbound Translations partition to the Inbound PSTN CSS
You must now add the Inbound Translations partition to the CSS used by the PSTN
SIP trunk so that calls that come in from the PSTN will search through the
translations.
1. On your SME cluster, go to Call Routing > Class of Control > Calling Search Space.
2. Click Find to list all the available Calling Search Spaces.
3. Select the CSS_Inbound_CUBE CSS.
4. Select the InboundTranslations CSS from the list of Available Partitions and move it down
to the Selected Partitions.
5. Click Save.
Task 105: Create Translation Pattern to Translate PSTN number
These translation patterns will take the number delivered by the PSTN and translate
them to the private numbers we are using for the lab. This will be done at the SME
layer which acts as your centralized aggregation point for PSTN routes (both
inbound and outbound). You will create one translation pattern to point a DID to a
phone registered to Unified CM 1 and another to ring a phone registered with
Unified CME.
1. On your SME cluster, go to Call Routing > Translation Patterns.
2. Click Add New
3. Configure the Pattern, Partition, CSS, and Called Party Transform Mask as shown below:
POD Translation Partition CSS Called Party
Pattern Transformation
Mask
POD10 \+19194767718 InboundTranslations CSS_Only_GDPR +13912102001
4. De-select Provide Outside Dial Tone

5. Click Save
Repeat the same procedure for the DID that points to your second cluster phone as
well by referring to the following table. HINT: You can go to the pattern you created
in the last step, click Copy, then modify the translation and click Save instead of
creating the translation pattern from scratch.
POD Translation Partition CSS Called Party

Pattern Transformation
Mask
POD10 \+19194767719 InboundTranslations CSS_Only_GDPR +13912103001
Task 106: Add number to e164 Pattern Map

The CUBE configuration must be modified to route the new DID numbers to your
SME cluster. With the new e164 Pattern Maps, we just need to add these patterns
to the existing pattern-map
CUBE 1 CUBE 2
(config)# voice class e164-pattern-map 1 (config)# voice class e164-pattern-map 1
(config-class)# e164 919476771[89] (config-class)# e164 919476771[89]
You should now be able to reach two of your phones from the PSTN. Dial +1 (919)
476-7718 from your cell phone or one of the PSTN phones located in the lab to
reach your Unified CM phone with extension 2001 or dial +1 (919) 476-7719 to
reach your Leaf cluster 2 phone with extension 3001.
BONUS SECTION
Use Session Trace feature to view SIP call flow
Unified CM 8.5 and later provides a tracing facility that allows you to view
a message sequence diagram for SIP calls that flow through the system.
This is especially useful for diagnosing issues with Session Management
Edition.
The session trace functionality is built-in to the Real-time monitoring tool (RTMT).
RTMT is already installed on your workstation, so click the icon on your desktop.
Once launched, you will be prompted to log in. Enter the IP address of your SME
cluster for the Host IP Address. If prompted to add a certificate to the trust store,
select Accept.
You will then be prompted with a login window. Enter the SME username and
password.
After RTMT loads, you will be presented with a window to select a configuration.
Just click OK to select the Default configuration.
On the left hand pane, select the CallManager option and
you will see a Session Trace Log View section under the
CallProcess group. You can select Real Time Data to
view logs from the server or Open from Local Disk to
load files that you have saved locally. In this case, click on
Real Time Data. The tool will load and then present you
with a window where you can select the search criteria.
In the search criteria, you may specify a calling number, called number, or both.
The * is used as a wildcard. You can also specify the start time to search and the
number of minutes beyond the start time as well as the time zone. By default, the
tool will set the start time to 30 minutes before the time you launched the tool with
a duration of 30 minutes, effectively searching the last 30 minutes of calls.
To find a call you have made through your SME cluster, click the Run button. You
will see the matching calls.
To view the session trace for the call, click the call you want to view and then click
the Trace Call button at the bottom of the page. You will see the Analyze Call
Diagram window appear with the session trace.
To see the actual SIP message, click the message that appears on the diagram.
NOTE that being able to see the SIP message requires the trace level for the
CallManager service be set to Detailed (this has already been done for you). If the
trace level is not set correctly, you will see a message indicating that the tool could
not find the SIP message. The same is true if the trace files have been overwritten
for the timeframe you are looking for.
Debug SIP call on CUBE
You are now going to be user software called TranslatorX to simplify the
troubleshooting of calls on CUBE. TranslatorX is a multi-platform software that
processes log files from Unified Communications Manager to provide human
readable trace information.
Translator X is available publicly at:
http://translatorx.cisco.com/
TranslatorX can read traces from a variety of Cisco platforms including Cisco IOS
Unified Border Element debugs: specifically debug ccsip messages. You will first
work on capturing and viewing a call as it passes through the Unified Border
Element.
Task 107: Initiate debugs on Unified Border Element

On the CUBE you want to capture the debugs to logs. You always want to ensure
that all debugs go to the log file instead of console. The first reason is the reduction
of CPU load on the router. The second, and more important, reason is that there is
less chance of missing debug output.
To accomplish this you are going to configure the router to send all debugs to the
log buffer instead of console.
CUBE 1 CUBE 2
(config)# no logging console debugging (config)# no logging console debugging
(config)# logging buffered debugging (config)# logging buffered debugging
(config)# logging buffered 1000000 (config)# logging buffered 1000000
This will disable debug output to console, push all debugs to the logging buffer and
then make sure we have enough space by putting a buffer of 100,000 bytes.
Once this is ready, you can then enable debugs and capture the logs. Only the
active ISR CUBE we will run these. Let’s make sure that we are on the doing this on
the active ISR.
CUBE 1 CUBE 2
#show standby brief #show standby brief
Interface Grp Pri P State Active Interface Grp Pri P State Active
Gi0/0 101 51 Standby 10.0.110.12 Gi0/0 101 51 Active local
Gi0/1 201 51 Standby 10.0.224.108 Gi0/1 201 51 Active local
Enable the debugs on the router that says it is Active. In this case, CUBE 2 is active.
# clear log
# debug ccsip message
Once debugs are enabled, place a call towards the PSTN phone located by your
workstation or if you wish to your cell phone or other PSTN number. Once you have
established the call, please hang up the call to terminate. Once you have completed
this please issue the command:
#undebug all
Now you can copy the contents of the buffer to a file on the flash of router to copy
to your workstation.
# show log | redirect flash:debugoutput.log
Once this is completed you can copy the file from the router to the workstation.
Task 108: Copy log file from CUBE to your Cisco Live Workstation
On your computer will be an application called pscp.exe. A member of the Putty
secure client applications suite, it permits us to issue an SCP copy to the SCP
server configured on the routers. This is just a simple mechanism to be able to copy
the files of the router. You could also configure FTP to send the files to an external
source.
Putty SCP is copied on the root directory of your computer under C:\ . The
command to copy the logs of the CUBE is below. The command below is showing
the IP address of CUBE 2 (10.0.110.12). If your CUBE 1 router is the active router,
then use its IP address instead (10.0.110.11)
C:\pscp.exe -scp cladmin@10.0.110.12:/debugoutput.log c:\logs
The command will ask for the password to cladmin that is c1sco123. Once copied
the file should be located on the root directory of this computer.
Task 109: Read the log file in Translator X
We have pre-installed TranslatorX on the workstations for your usage. This
application is available in Windows and Mac OSX. Once you start the application
you will be presented with a screen similar to this:
Please select the File > Open. Select the debugoutput.log file from the c:\logs
directory. Once read, the file should look similar to the following:
You can click on each individual line on the tool to get the detailed output of the
debug. At the bottom are some default exclusions. These can be used to eliminate
messages that we would normally want to ignore like Out of Dial OPTIONS Ping
messages (the keepalives from the trunks). One very cool feature of the tool is to
provide functionality for ladder diagrams for calls. Because we only have a single
call we can just click on the Generate Diagram button at the bottom.
This will output the following:
If you have done multiple calls you can filter the trace by enabling a filter. On the
top of the application is a button named Call List. This command lets you easily
create a filter for a particular call.
You can examine the debug to see the different messages that the call generated to
complete the call to the PSTN. You can also generate more calls and copy those
logs back over to your Workstations if you wish to get additional debugs to analyze.
Detailed tracing on Unified Communications Manager
TranslatorX provides the same functionality for troubleshooting calls in Unified
Communications Manager. Unified Communications Manager provides extensive
details of calls when configured. By default Unified CM is configured for basic
tracing, although the 9.0 release actually defaults to Detailed tracing. All versions
prior to the 9.0 release default to error level. Even though your clusters are running
the 9.0 release, they were previously upgraded from the 8.6 release and as a
general rule, defaults are not modified when upgrading, therefore your first step will
be to enable detailed tracing. You will enable the tracing all three Unified
Communications Servers.
IP Address Username Password
UCM #1 10.0.110.50 Administrator c1sco123!
UCM #2 10.0.110.60 Administrator c1sco123!
SME 10.0.110.40 Administrator c1sco123!
Task 110: Navigate to Cisco Unified Serviceablity

To modify trace levels, you will need to navigate to the UCM Serviceability page.
Once that page has loaded, go to Trace > Configuration.
Trace configuration is used for many different applications and processes that are
part of Unified Communications Manager. In a clustered Unified Communications
environment you can enable traces on only particular nodes of the cluster, or you
can change the settings for every node of the cluster.
Select CM services from the pull-down of the service group and click Go.
Next, select the Cisco CallManager service and click Go.
Now you can enable tracing
Task 111: Enable detailed tracing for Call Manager Service

The screen that will be displayed can be a little daunting when first viewed as it has
so many options to select from. To simplify the process Cisco has a pull down to
set the debug Trace Level.
It is beyond the scope of this lab and document to explain all the possibilities, so
we will focus on making a single change. Fortunately, because the new default for
9.0 is Detailed tracing, just click the button at the top of the page that says Set
Default. This should set the Debug Trace Level to Detailed.
Once completed please click on Save. Repeat this process for all the three Unified
Communications Servers.
Unified Communications Manager trace collection
Now that all Unified Communications Managers are configured for detailed tracing,
you can gather logs. Before you start the process of creating of collecting traces,
you need to have some calls stored in the logs.
You can places calls as you wish. Two good scenarios are a single call to another
phone in the internal network (ONNET) and another to a phone OFFNET.
POD10user1@
82103001 Should
82103001 Ring
POD10user1@
Dial Digits Phone
91[cell phone] Should
91[Cell Phone] Ring
Once you have placed the necessary calls, do the trace collection as shown below.
Task 112: Trace collection with RTMT

Trace collection is done with the Real Time Monitoring tool that was used before. If
you still have RTMT open, please go to the File Menu and click Log Off. Connect to
Unified Communications Manager #1 with the IP address of 10.0.110.50. Once
open select Trace & Log Central.
This will provide you with a popup to select the Services/Application that you wish
to collect the files from.
Select the Cisco CallManager Service/Application. In a multi node environment

you can select All Servers to collect traces from all the nodes then Click Next.
Click Next on the next page because you don’t need to pick any other services. A
screen will be presented that provides you with the details of what files you plan to
get.
For the case of this lab tell RTMT to collect the files generated for the last hour.
Click on Relative Range and select 1 hour.
Then click on the checkbox named Uncompress Log Files. This is an important
step for this lab to only get the TXT files instead of a compressed file.
Then click on Download File Directory to select the Desktop folder for your
workstation. Then click Finish. This will start the process of file collection for this
Unified Communications Manager node. Once completed you will be able to find a
folder on your Desktop from the node you pulled the traces from.
Task 113: Read UCM trace files with TranslatorX

Now that you have the log files collected you can read them with TranslatorX. The
structure of the trace files is always going to be <CUCM Name>-<date of
collection>-cm-trace-ccm-<sdi or sdl>
TranslatorX can process SDI trace files in versions of Unified CM prior to 9.0. In the
9.0 release, the contents of the SDI and SDL traces are combined into a single SDL
trace file, so for 9.0 TranslatorX reads through the SDL traces.
In TranslatorX select File > Open Folder (not File > Open). It will look something
similar as the following:
Leave the default values and click OK. You will get a window to select the folder to
read. You can just click on the Date of the collection – you do not have to click all
the way down on the SDL folder. TranslatorX will traverse the whole directory
structure automatically. This is especially useful if you have traces from multiple
nodes in a cluster. It will read them all at the same time.
This is a very important feature. In an active Unified Communications Manager
system with detailed file traces enabled, the system can write hundreds of files. The
tool can read and analyze these in bulk and with its filtering mechanism locate
specific calls you may be looking for.
Once you have opened the folder you will have a series of messages. It should look
similar to the following:
After reading the files, Translator X presents you with every message it has read
from the files. If you have enabled CDR call records on your Unified
Communications Manager (we have enabled these for you) you can see a list of
active calls by clicking on the Call List button located on the top.
Here you can then enable a filter for a particular call. By selecting the call and
clicking on the button Generate Filter Translator X will create a filter for this call.
When you go back to the main Translator X screen you can now see a filter is
applied.
Now we can generate a quick ladder diagram for this call.
This functionality is similar to the Session Trace feature we explored earlier in

RTMT, but Translator X can provide a much more broad functionality by looking at
Unified Communication Manager traces. While Session trace is SIP-only,
TranslatorX supports a wide range of protocols. It also works with an ordinary
SDI/SDL trace while Session Trace must get its input from the output of the session
trace tool itself.
Explore some of the functionality in TranslatorX before moving on. Feel free to ask
questions of the lab proctors.
Task 114: Tracing a call end to end

Using the tools presented you can trace a call across all components of the
network. By doing a call towards the PSTN we can gather the trace logs from the
Unified Communications Manager node, the Unified CM SME Edition and the Unified
Border Element.
Do this on your own – generate a call to the PSTN, then trace that single call from
Unified CM leaf cluster to SME to CUBE.
Notes
Notes
Notes

Best SIP-CUBE LAB PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Best SIP-CUBE LAB PDF

Enviado por

Direitos autorais:

Formatos disponíveis

LTRUCC-2150

Cisco Unified CM 10.0 SIP Trunking, Session

Paul Giralt (pgiralt@cisco.com)

Configure ILS on Unified CM SME Edition .......................................... 17

Configure ILS on Unified Communications Manager Leaf 1 .................. 19

Configure ILS on Unified Communications Manager Leaf 2 .................. 21

Dial Plan for Unified CM Leaf Cluster 1 ............................................. 23

Configure Translation Patterns for Leaf Cluster 1 ............................... 29

Dial Plan for Unified CM Leaf Cluster 2 ............................................. 36

Configure Translation Patterns for Leaf Cluster 2 ............................... 41

ILS/GDPR with Centralized Unified CM SME ....................................... 47

Configure SIP Route String for Unified CM Leaf 2 .............................. 50

Configure Unified CM SME Dial Plan ................................................. 51

Configure SIP Trunks on Unified CM SME .......................................... 54

Configure Route Groups and Route Lists in Unified CM SME ............... 57

Configure SIP Route Pattern in Unified CM SME ................................. 61

Configure Phone Line in Unified CM Leaf 1 ....................................... 63

Validate learned patterns via ILS/GDPR ............................................. 67

Configure PSTN Route Patterns Leaf Cluster 1 .................................. 70

Configure PSTN Route Patterns Leaf Cluster 2 .................................. 72

Configure PSTN Route Patterns Unified CM SME ................................ 74

CUBE General Configuration ............................................................ 76

CUBE Box to Box Redundancy .......................................................... 79

CUBE Server Groups ....................................................................... 86

E164 Dial Maps ............................................................................... 87

CUBE Dial Peers ............................................................................. 88

Configure CUBE Dial Plan Normalization ............................................ 94

CUBE DO to EO configuration ........................................................... 98

Enhanced Event Tracing ................................................................ 101

CUBE / SME OPTIONS Ping Configuration ........................................ 105

Enabling URI Dialing ...................................................................... 108

SME Normalization Script (Modify Diversion Header) ........................ 111

Translate Inbound DID to Lab Number ............................................. 114

Detailed tracing on Unified Communications Manager ....................... 129

Unified Communications Manager trace collection ............................ 132

Notes ........................................................................................... 138

You can find access information to your pod on http://siplab.ciscolive.com

From an administrator’s point of view, Unified Communications Manager establishes

Included with each of these are:

The user dials 82103001 which matches route string leaf2-POD10.ciscolive.com.

Task 1: Configure Cluster ID

Task 2: Configure ILS on Unified CM SME

Task 3: Configure Cluster ID

Task 4: Configure ILS on Unified Communications Manager Leaf 1

Task 5: Configure Cluster ID

Task 6: Configure ILS on Unified Communications Manager Leaf 2

Task 7: View ILS Mesh topology

PT_LocalFeatures Would normally contain things like Call Park Numbers

PT_Abbreviated_Dial Patterns for abbreviated 8+7 digit dialing

PT_GDPR SIP Domain Patterns to reach Route Strings

PT_Local_Translation Would normally contain any local cluster translations

PT_Local_Route_Patterns +E.164 Route Patterns for reaching Local numbers

PT_National_Route_Patterns +E.164 Route Patterns for reaching National numbers

PT_Intl_Route_Patterns +E.164 Route Patterns for reaching International numbers

Let’s configure the partitions for both leaf clusters.

Task 8: Configure partitions on Leaf Cluster 1

POD10 10.0.110.50 Administrator c1sco123!

1. Go to Call Routing > Class of Control > Partition

To configure the first calling search space on cluster 1, do the following:

Global Learned E164 Numbers

Global Learned Enterprise Numbers

Global Learned E164 Numbers

Global Learned E164 Patterns