Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
POD10
Table of Contents
Introduction to Lab ............................................................................ 7
Prerequisites .................................................................................... 9
Lab Diagram ................................................................................... 10
Lab Overview ................................................................................. 11
Before You Begin ............................................................................ 12
ILS/GDPR Overview ......................................................................... 13
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
Configure SIP trunk and Route List to SME in Leaf Cluster 2 ............... 44
37:
38:
39:
40:
41:
42:
Configure
Configure
Configure
Configure
Configure
Configure
Route
Route
Route
Route
Route
Route
Task 43: Configure SIP Route Pattern for Unified CM Leaf 1 ........................................... 61
Task 44: Configure SIP Route Pattern for Unified CM Leaf 2 ........................................... 62
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
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
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
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
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
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
Task 75: Configure Dial Peers between CUBE and Unified CM SME ............................... 88
79:
80:
81:
82:
83:
84:
85:
Convert from +E.164 to NANP for Called Numbers to the PSTN ....................... 94
Convert from +E.164 to NANP for Calling Numbers to the PSTN ...................... 94
Convert Called Number from NANP to +E.164 for Inbound Calls from PSTN .... 95
Convert calling number from NANP to +E.164 for inbound calls from PSTN ..... 95
Configure Translation profile for inbound dial-peers ......................................... 96
Add translation profiles to dial-peers ................................................................ 96
Place PSTN call from CUCM ............................................................................. 97
88:
89:
90:
91:
92:
93:
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
102:
103:
104:
105:
106:
Use Session Trace feature to view SIP call flow ............................... 120
Debug SIP call on CUBE ................................................................ 124
Introduction to Lab
Enterprises and service providers are increasingly moving from traditional TDMbased 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 Ciscos 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 RFCs 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 URIs 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 URIs 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, URIs 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:
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 startupconfiguration.
Lab Diagram
Your lab network contains the following products:
Cisco
Cisco
Cisco
Cisco
Unified
Unified
Unified
Jabber
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.10
10.0.110.1
2
10.0.110.40
10.0.110.5
0
10.0.110.6
0
Lab Overview
There are several high-level tasks you will complete in this lab:
1.
2.
3.
4.
5.
6.
7.
Configure ILS/GDPR
Configure Dial Plan and Session Management Edition
Configure Trunks and Route String routing
Configure static PSTN routes
Configure CUBE and High Availability
Enable URI Dialing
Bonus Troubleshooting section
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, lets 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. URIs 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.
Advertisements
ILS/GDPR provides 4 separate buckets containing patterns that are shared across
the network.
1.
2.
3.
4.
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.
2014 Cisco Systems, Inc. All rights reserved
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.
leaf2-POD10.ciscolive.com
10.0.110.60
Match:82103001
82103001
Dials:82103001
SME CM IP
Username
Password
10.0.110.40
Administrator
c1sco123!
sme-POD10-ciscolive
The ILS configuration section is found in the Advanced Features menu on Unified
CM:
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
CUCM Leaf 1
Username
Password
10.0.110.50
Administrator
c1sco123!
leaf1-POD10-ciscolive
leaf1-POD10.ciscolive.com
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.
CUCM Leaf1
Username
Password
10.0.110.60
Administrator
c1sco123!
leaf2-POD10-ciscolive
leaf2-POD10.ciscolive.com
For this cluster, you want to peer it with the Unified CM SME cluster you previously
2014 Cisco Systems, Inc. All rights reserved
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.
POD10
P OD 10
POD10
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.
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
2014 Cisco Systems, Inc. All rights reserved
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
PT_LocalFeatures
PT_Abbreviated_Dial
PT_GDPR
PT_Local_Translation
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
PT_National_Route_Patterns
PT_Intl_Route_Patterns
CUCM Leaf1
Username
Password
10.0.110.50
Administrator
c1sco123!
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.
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.
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
PT_Local_Translation
PT_Global_Translation
5. Click Save
CSS_COR_CiscoLive_National
PT_DN164
Global Learned E164 Numbers
Global Learned E164 Patterns
Global Learned Enterprise Numbers
Global Learned Enterprise Patterns
PT_GDPR
PT_National_Route_Patterns
4. Click Save
CSS_COR_CiscoLive_International
PT_DN164
Global Learned E164 Numbers
Global Learned E164 Patterns
Global Learned Enterprise Numbers
Global Learned Enterprise Patterns
PT_GDPR
PT_Intl_Route_Patterns
5. Click Save
CSS_Inbound_ILS
PT_DN164
PT_Abbreviated_Dial
Directory URI
4. Click Save
CUCM Leaf1
Username
Password
10.0.110.50
Administrator
c1sco123!
Field
Value
Translation Pattern
9.1[2-9]XX[2-9]XXXXXX
Partition
PT_Global_Translation
CSS_COR_CiscoLive_National
Discard Digits
PreDot
Value
Translation Pattern
9011.!#
Partition
PT_Global_Translation
CSS_COR_CiscoLive_International
Discard Digits
PreDot Trailing #
Value
Translation Pattern
9011.!
Partition
PT_Global_Translation
CSS_COR_CiscoLive_International
Discard Digits
PreDot
CUCM Leaf1
Username
Password
10.0.110.50
Administrator
c1sco123!
8.
9.
10.
11.
12.
Parameter
Configuration
Device Name
POD10-SME-SIP-TRUNK
Device Pool
Default
CSS_Inbound_ILS
Destination
10.0.110.40
SIP Profile
Click Save
Click OK on the popup
Click Reset.
On the Reset popup click Reset
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.
POD10-SME-SIP-TRUNK
4.
5.
6.
7.
8.
Configuration
Parameter
Name
POD10-RL-SME
Default
Click Save
Click on Add Route Group
Select the route group POD10-RG-SME-[NON-QSIG]
Click Save
Click OK
The screen for the Route List should look like this:
POD10-RL-SME
POD10-RG-SME
POD10-RG-SME
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
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
Follow these steps to add the partitions to the second leaf cluster:
CUCM Leaf1
Username
Password
10.0.110.60
Administrator
c1sco123!
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 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
CSS_COR_CiscoLive_National
CSS_COR_CiscoLive_International
CSS_Inbound_ILS
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
PT_Local_Translation
PT_Global_Translation
5. Click Save
CSS_COR_CiscoLive_National
PT_DN164
Global Learned E164 Numbers
Global Learned E164 Patterns
Global Learned Enterprise Numbers
Global Learned Enterprise Patterns
PT_GDPR
PT_National_Route_Patterns
5. Click Save
CSS_COR_CiscoLive_Local
Global Learned E164 Numbers
Global Learned E164 Patterns
Global Learned Enterprise Numbers
Global Learned Enterprise Patterns
PT_GDPR
PT_Intl_Route_Patterns
6. Click Save
CSS_Inbound_ILS
PT_DN164
PT_Abbreviated_Dial
Directory URI
CUCM Leaf1
Username
Password
10.0.110.60
Administrator
c1sco123!
Value
Translation Pattern
9.1[2-9]XX[2-9]XXXXXX
Partition
PT_Global_Translation
CSS_COR_CiscoLive_National
Discard Digits
PreDot
Value
Translation Pattern
9011.!#
Partition
PT_Global_Translation
CSS_COR_CiscoLive_International
Discard Digits
PreDot Trailing #
Value
Translation Pattern
9011.!
Partition
PT_Global_Translation
CSS_COR_CiscoLive_International
Discard Digits
PreDot
CUCM Leaf1
Username
Password
10.0.110.60
Administrator
c1sco123!
4.
5.
6.
7.
Parameter
Configuration
Device Name
POD10-SME-SIP-TRUNK
Device Pool
Default
CSS_Inbound_ILS
Destination
10.0.110.40
SIP Profile
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.
POD10-SME-SIP-TRUNK
4.
5.
6.
7.
Configuration
Parameter
Name
POD10-RL-SME
Default
Click Save
Click on Add Route Group
Select the route group POD10-RG-SME-[NON-QSIG]
Click Save
The screen for the Route List should look like this:
POD10-RL-SME
POD10-RG-SME
POD10-RG-SME
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
organizations 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 leaf2POD10.ciscolive.com pointing to Cluster 2. The following diagram shows this call
flow:
m
co
ive
ol
isc
2- 0. c
af
le D1
PO
om
.c
c
*.
e.
liv
o
isc
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.
CUCM Leaf 1
Username
Password
10.0.110.50
Administrator
c1sco123!
Parameter
Configuration
IPV4 Pattern
*.ciscolive.com
Route Partition
PT_GDPR
POD10-RL-SME
4. Click Save
POD10-RL-SME
CUCM Leaf 2
Username
Password
10.0.110.60
Administrator
c1sco123!
Parameter
Configuration
IPV4 Pattern
*.ciscolive.com
Route Partition
PT_GDPR
POD10-RL-SME
4. Click Save
POD10-RL-SME
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.
Unified CM SME
Username
Password
10.0.110.40
Administrator
c1sco123!
Partitions
PT_GDPR
PT_National_Route_Patterns
PT_Intl_Route_Patterns
PT_GDPR
PT_National_Route_Patterns
PT_Intl_Route_Patterns
4. Click Save.
Parameter
Configuration
Name
CSS_Inbound_Leaf
Selected Partitions
Directory URI
Global Learned E164 Numbers
Global Learned E164 Patterns
Global Learned Enterprise Numbers
Global Learned Enterprise Patterns
PT_GDPR
PT_National_Route_Patterns
PT_Intl_Route_Patterns
4. Click Save
5. Click Add New
6. Configure the second Calling Search Space with the following parameters
Parameter
Configuration
Name
CSS_Inbound_CUBE
Selected Partitions
Global Learned
Global Learned
Global Learned
Global Learned
PT_GDPR
E164 Numbers
E164 Patterns
Enterprise Numbers
Enterprise Patterns
7. Click Save
Unified CM SME
Username
Password
10.0.110.40
Administrator
c1sco123!
6. Click Next
7. Configure the SIP Trunk with the following parameters
8.
9.
10.
11.
12.
Parameter
Configuration
Device Name
POD10-LEAF1-SIP-TRUNK
Device Pool
Default
CSS_Inbound_Leaf
Destination
10.0.110.50
SIP Profile
Click Save
Click OK on the popup
Click Reset
On the Reset popup click Reset
Click Close
6. Click Next
7. Configure the SIP Trunk with the following parameters
8.
9.
10.
11.
12.
Parameter
Configuration
Device Name
POD10-LEAF2-SIP-TRUNK
Device Pool
Default
CSS_Inbound_Leaf
Destination
10.0.110.60
SIP Profile
Click Save
Click OK on the popup
Click Reset
On the Reset popup click Reset
Click Close
6. Click Next
8.
9.
10.
11.
12.
Parameter
Configuration
Device Name
POD10-CUBE-SIP-TRUNK
Device Pool
Default
CSS_Inbound_CUBE
Destination
10.0.110.10
SIP Profile
Click Save
Click OK on the popup
Click Reset
On the Reset popup click Reset
Click Close
Unified CM SME
Username
Password
10.0.110.40
Administrator
c1sco123!
4.
Configuration
Parameter
POD10-Leaf1-RG
Selected Devices
POD10-LEAF1-SIP-TRUNK
POD10-Leaf1-RG
POD10-CUBE-SIP-TRUNK
POD10-LEAF1-SIP-TRUNK
POD10-LEAF2-SIP-TRUNK
Click Save.
POD10-LEAF1-SIP-TRUNK
POD10-LEAF1-SIP-TRUNK
4.
Configuration
Parameter
POD10-Leaf2-RG
Selected Devices
POD10-LEAF2-SIP-TRUNK
POD10-Leaf2-RG
POD10-CUBE-SIP-TRUNK
POD10-LEAF1-SIP-TRUNK
POD10-LEAF2-SIP-TRUNK
Click Save.
POD10-LEAF2-SIP-TRUNK
POD10-LEAF2-SIP-TRUNK
4.
Configuration
Parameter
POD10-CUBE-RG
Selected Devices
POD10-CUBE-SIP-TRUNK
POD10-CUBE-RG
POD10-CUBE-SIP-TRUNK
POD10-LEAF1-SIP-TRUNK
POD10-LEAF2-SIP-TRUNK
Click Save.
POD10-CUBE-SIP-TRUNK
POD10-CUBE-SIP-TRUNK
4.
5.
6.
7.
8.
9.
Configuration
Parameter
Name
POD10-Leaf1-RL
Unified CM Group
Default
Click Save
Click Add Route Group.
Once in Route List Member Information
select the Route Group POD10-Leaf1-RL
Click Save
Click Apply Config
Click OK on the popup.
POD10-Leaf1-RL
POD10-Leaf1-RG
POD10-Leaf1-RG
4.
5.
6.
7.
8.
9.
Configuration
Parameter
Name
POD10-Leaf2-RL
Unified CM Group
Default
Click Save
Click Add Route Group.
Once in Route List Member Information
select the Route Group POD1-Leaf2-RG
Click Save
Click Apply Config
Click OK on the popup.
POD10-Leaf2-RL
POD10-Leaf2-RG
POD10-Leaf2-RG
4.
5.
6.
7.
8.
9.
Configuration
Parameter
Name
POD10-CUBE-RL
Unified CM Group
Default
Click Save
Click Add Route Group.
Once in Route List Member Information
select the Route Group POD10-CUBE-RG
Click Save
Click Apply Config
Click OK on the popup.
POD10-CUBE-RL
POD10-CUBE-RG
POD10-CUBE-RG
leaf1-POD10.ciscolive.com
Leaf1-POD10-ciscolive
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
leaf1-POD10.ciscolive.com
leaf2-POD10.ciscolive.com
Parameter
IPv4 Pattern
leaf1-POD10.ciscolive.com
Route Partition
PT_GDPR
POD10-Leaf1-RL
leaf1-POD10.ciscolive.com
PT_GDPR
POD10-Leaf1-RL
Parameter
IPv4 Pattern
leaf2-POD10.ciscolive.com
Route Partition
PT_GDPR
POD10-Leaf2-RL
leaf2-POD10.ciscolive.com
PT_GDPR
POD10-Leaf2-RL
CUCM Leaf 1
Username
Password
10.0.110.50
Administrator
c1sco123!
\+13912102001
CSFPOD10USER1
82102001
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.
Click
Click
Click
Click
+13912102001
CUCM Leaf 2
Username
Password
10.0.110.60
Administrator
c1sco123!
\+13912103001
CSFPOD10USER2
+13912103001
82103001
This will advertise an enterprise Alternate Number into the network and add it to the
local PT_Abbreviated_Dial partition.
Click
Click
Click
Click
+13912103001
CUCM Leaf 2
Username
Password
10.0.110.60
Administrator
c1sco123!
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.
+13912102001
82102002
POD10
POD10
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.
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
82103001
Dial Digits
82103001
Phone
Should
Ring
POD10user1@
POD10user2@
POD10user2@
You can also place calls by dialing 9 followed by the E.164 for US National
numbers.
POD10user1@
913912103001
Dial Digits
913912102001
POD10user1@
Phone
Should
Ring
POD10user2@
POD10user2@
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.
CUCM Leaf 1
Username
Password
10.0.110.50
Administrator
c1sco123!
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
Field
Value
Route Pattern
\+[2-9]!
Route Partition
PT_Intl_Route_Patterns
Gateway/Route List
POD10-RL-SME
P O D 10 -R L -S M E
4. Click Save
CUCM Leaf 2
Username
Password
10.0.110.60
Administrator
c1sco123!
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
Field
Value
Route Pattern
\+[2-9]!
Route Partition
PT_Intl_Route_Patterns
Gateway/Route List
POD10-RL-SME
P O D 10 -R L -S M E
4. Click Save
CUCM Leaf 1
Username
Password
10.0.110.40
Administrator
c1sco123!
Field
Value
Route Pattern
\+1[2-9]XX[2-9]XXXXXX
Route Partition
PT_National_Route_Patterns
Gateway/Route List
POD10-CUBE-RL
P O D 10 -CU B E -R L
4. Click Save
Field
Value
Route Pattern
\+[2-9]!
Route Partition
PT_Intl_Route_Patterns
Gateway/Route List
POD10-CUBE-RL
Urgent Priority
Selected
P O D 10 -CU B E -R L
4. Click Save
CUBE 2
(config)#voice service voip
(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.
CUBE 2
(config)#voice service voip
(conf-voi-serv)#mode border-element
(conf-voi-serv)#allow-connections sip to sip
Next, enable address hiding. This will force the CUBE to utilize its 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
(config)#voice service voip
(conf-voi-serv)#address-hiding
CUBE 2
(config)#voice service voip
(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 midcallsignaling command is for SIP-to-SIP calls only.
CUBE 1
(config)#voice service voip
(conf-voi-serv)#sip
(conf-serv-sip)#header-passing
(conf-serv-sip)#midcall-signaling passthru
CUBE 2
(config)#voice service voip
(conf-voi-serv)#sip
(conf-serv-sip)#header-passing
(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
(config)#voice class codec 1
(config-class)#codec preference 1 g711ulaw
(config-class)#codec preference 2 g729r8
CUBE 2
(config)#voice class codec 1
(config-class)#codec preference 1 g711ulaw
(config-class)#codec preference 2 g729r8
our case we will prefer G.711 but still allow G.729 so that Unified CM can negotiate
G.729 if necessary.
CUBE 2
(config)#gateway
(config-gateway)# media-inactivity-criteria all
(config-gateway)# timer receive-rtcp 5
Last you must enable the SIP User Agent. This is a global configuration command.
CUBE 1
(config)#sip-ua
CUBE 2
(config)#sip-ua
CUBE 2
(config)#voice service voip
(conf-voi-serv)#redundancy
CUBE 2
(config)#ipc zone default
(config-ipczone)#association 1
(config-ipczone-assoc)#protocol sctp
(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 zone default
(config-ipczone)#association 1
(config-ipczone-assoc)#protocol sctp
(config-ipc-protocol-sctp)#local-port 5000
(config-ipc-local-sctp)#local-ip 10.0.110.11
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
(config)#ipc zone default
(config-ipczone)#association 1
(config-ipczone-assoc)#protocol sctp
(config-ipc-local-sctp)#remote-port 5000
(config-ipc-remote-sctp)#remote-ip 10.0.110.12
CUBE 2
(config)#ipc zone default
(config-ipczone)#association 1
(config-ipczone-assoc)#protocol sctp
(config-ipc-local-sctp)#remote-port 5000
(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
ipc zone default
association 1
no shutdown
protocol sctp
local-port 5000
local-ip 10.0.110.11
remote-port 5000
remote-ip 10.0.110.12
CUBE 2
ipc zone default
association 1
no shutdown
protocol sctp
local-port 5000
local-ip 10.0.110.12
remote-port 5000
remote-ip 10.0.110.11
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
(config)# track 1 interface GigabitEthernet0/0
line-protocol
(config)# track 2 interface GigabitEthernet0/1
line-protocol
CUBE 2
(config)# track 1 interface GigabitEthernet0/0
line-protocol
(config)# track 2 interface GigabitEthernet0/1
line-protocol
CUBE 2
(config)#interface GigabitEthernet0/0
(config-if)#standby 110 ip 10.0.110.10
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 its HA event, CUBE2 will
not preempt CUBE1 because the priorities are the same.
CUBE 2
(config)#interface GigabitEthernet0/0
(config-if)# standby delay minimum 30 reload 60
(config-if)# standby version 2
(config-if)# bfd interval 500 min_rx 500 multiplier 3
CUBE 2
(config)#interface GigabitEthernet0/0
(config-if)# standby 110 name box2boxcube
CUBE 2
interface GigabitEthernet0/0
ip address 10.0.110.12 255.255.255.128
standby delay minimum 30 reload 60
standby 110 ip 10.0.110.10
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
#show standby
GigabitEthernet0/0 Group 110
State is Standby
5 state changes, last state change 22:21:32
Virtual IP address is 10.0.110.10
Active virtual MAC address is 0000.0c07.ac65
Local virtual MAC address is 0000.0c07.ac65
(v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.456 secs
Active router is 10.0.110.12, priority 100
(expires in 8.624 sec)
Standby router local
Priority 100 (configured 100)
Track object 2 state Up decrement 10
Group name is "box2boxcube" (cfgd)
CUBE 2
#show standby
GigabitEthernet0/0 Group 110
State is Active
5 state changes, last state change 22:21:32
Virtual IP address is 10.0.110.10
Active virtual MAC address is 0000.0c07.ac65
Local virtual MAC address is 0000.0c07.ac65
(v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.456 secs
Active router is local
Standby router is 10.0.110.11, priority 100
(expires in 8.624 sec)
Priority 100 (configured 100)
Track object 2 state Up decrement 10
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. Dont worry about this for now. We
will reload the router later to get everything synced up.
CUBE 2
(config)#interface GigabitEthernet0/1
(config-if)#standby delay minimum 30 reload 60
(config-if)#standby 210 ip 10.0.224.109
CUBE 2
(config)#redundancy inter-device
(config-red-interdevice)#scheme standby box2boxcube
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 its not
necessary to reload it again).
CUBE 1
#wr
Building configuration
[OK]
# reload
CUBE 2
#wr
Building configuration
[OK]
# 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
client count = 13
client_notification_TMR = 60000 milliseconds
RF debug mask = 0x0
client count = 13
client_notification_TMR = 60000 milliseconds
RF debug mask = 0x0
Unit ID = 0
CUBE 2
(config)#voice class server-group 1
(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.
CUBE 2
(config)#voice class server-group 2
(config-class)#ipv4 10.0.224.101 preference 1
(config-class)#ipv4 10.0.224.102 preference 2
CUBE 2
(config)#voice class e164-pattern-map 1
(config-class)# e164 391210....
Now we can configure the E164 Dial Map for PSTN destinations
CUBE 2
(config)#voice class e164-pattern-map 2
(config-class)# e164 +1[2-9]..[2-9]......
(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.
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
(config)# dial-peer voice 101 voip
(config-dial-peer)# destination e164-pattern-map 1
CUBE 2
(config)# dial-peer voice 101 voip
(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 dialpeer 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
2014 Cisco Systems, Inc. All rights reserved
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
(config)# dial-peer voice 101 voip
(config-dial-peer)# incoming called e164-pattern-map 2
CUBE 2
(config)# dial-peer voice 101 voip
(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
(config)# dial-peer voice 101 voip
(config-dial-peer)# session protocol sipv2
(config-dial-peer)# session transport udp
CUBE 2
(config)# dial-peer voice 101 voip
(config-dial-peer)# session protocol sipv2
(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 dialpeer 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
(config)# dial-peer voice 101 voip
(config-dial-peer)# session server-group 1
CUBE 2
(config)# dial-peer voice 101 voip
(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
(config)# dial-peer
(config-dial-peer)#
(config-dial-peer)#
(config-dial-peer)#
(config-dial-peer)#
CUBE 2
(config)# dial-peer
(config-dial-peer)#
(config-dial-peer)#
(config-dial-peer)#
(config-dial-peer)#
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.
CUBE 2
(config)# dial-peer voice 101 voip
(config-dial-peer)# voice-class sip bind control
source-interface GigabitEthernet0/0
(config-dial-peer)# voice-class sip bind media
source-interface GigabitEthernet0/0
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 dialpeers 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 dialpeer 0, a default dial-peer in IOS.
The final configuration for the dial-peers between CUBE and SME is:
CUBE 1
dial-peer voice 101 voip
max-conn 5
destination e164-pattern-map 1
session protocol sipv2
session transport udp
incoming called e164-pattern-map 2
voice-class codec 1
voice-class sip bind control source-interface
GigabitEthernet0/0
voice-class sip bind media source-interface
GigabitEthernet0/0
dtmf-relay rtp-nte
no vad
CUBE 2
dial-peer voice 101 voip
max-conn 5
destination e164-pattern-map 1
session protocol sipv2
session transport udp
incoming called e164-pattern-map 2
voice-class codec 1
voice-class sip bind control source-interface
GigabitEthernet0/0
voice-class sip bind media source-interface
GigabitEthernet0/0
dtmf-relay rtp-nte
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
(config)# dial-peer voice 201 voip
(config-dial-peer)# incoming called e164-pattern-map 1
(config-dial-peer)# max-conn 5
(config-dial-peer)# destination e164-pattern-map 2
(config-dial-peer)# session protocol sipv2
(config-dial-peer)# session transport udp
(config-dial-peer)# session server-group 2
(config-dial-peer)# dtmf-relay rtp-nte
(config-dial-peer)# voice-class codec 1
(config-dial-peer)# voice-class sip bind control
source-interface GigabitEthernet0/1
(config-dial-peer)# voice-class sip bind media sourceinterface GigabitEthernet0/1
(config-dial-peer)# no vad
CUBE 2
(config)# dial-peer voice 201 voip
(config-dial-peer)# incoming called e164-pattern-map 1
(config-dial-peer)# max-conn 5
(config-dial-peer)# destination e164-pattern-map 2
(config-dial-peer)# session protocol sipv2
(config-dial-peer)# session transport udp
(config-dial-peer)# session server-group 2
(config-dial-peer)# dtmf-relay rtp-nte
(config-dial-peer)# voice-class codec 1
(config-dial-peer)# voice-class sip bind control
source-interface GigabitEthernet0/1
(config-dial-peer)# voice-class sip bind media sourceinterface GigabitEthernet0/1
(config-dial-peer)# no vad
CUBE 2
dial-peer voice 101 voip
max-conn 5
session protocol sipv2
session transport udp
session server-group 1
destination e164-pattern-map 1
incoming called e164-pattern-map 2
voice-class codec 1
voice-class sip bind control source-interface
GigabitEthernet0/0
voice-class sip bind media source-interface
GigabitEthernet0/0
dtmf-relay rtp-nte
no vad
!
dial-peer voice 201 voip
session protocol sipv2
session transport udp
session server-group 2
destination e164-pattern-map 2
incoming called e164-pattern-map 1
voice-class codec 1
voice-class sip bind control source-interface
GigabitEthernet0/1
voice-class sip bind media source-interface
GigabitEthernet0/1
dtmf-relay rtp-nte
!
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:
2014 Cisco Systems, Inc. All rights reserved
CUBE 1
CUBE 2
# wr
Building configuration
[OK]
# reload
# wr
Building configuration
[OK]
# 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.
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]
# debug ccsip messages
<Press Return>
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
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 SBCs. 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-7d7ede79762845449815
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 NANPformatted 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.
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
(config)# voice translation-rule 101
(cfg-translation-rule)# rule 1 /^\+\(1[2-9]..[29]......\)/ /\1/
(cfg-translation-rule)# rule 2 /^\+\([2-9]\)/
/011\1/
CUBE 2
(config)# voice translation-rule 101
(cfg-translation-rule)# rule 1 /^\+\(1[2-9]..[29]......\)/ /\1/
(cfg-translation-rule)# rule 2 /^\+\([2-9]\)/
/011\1/
Lets 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:
2014 Cisco Systems, Inc. All rights reserved
CUBE 1
(config)# voice translation-rule 102
(cfg-translation-rule)# rule 1 /^\+1\([2-9]..[29]......\)/ /\1/
(cfg-translation-rule)# rule 2 /^\+\([2-9]\)/ /\1/
CUBE 2
(config)# voice translation-rule 102
(cfg-translation-rule)# rule 1 /^\+1\([2-9]..[29]......\)/ /\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
(config)# voice translation-rule 201
(cfg-translation-rule)# rule 1 /\([2-9].........\)/
/+1\1/
CUBE 2
(config)# voice translation-rule 201
(cfg-translation-rule)# rule 1 /\([2-9].........\)/
/+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 miscategorized 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
(config)# voice translation-rule 202
(cfg-translation-rule)# rule 1 /\([2-9].........\)/
/+1\1/
(cfg-translation-rule)# rule 2 /\([2-9]\)/ /+\1/
CUBE 2
(config)# voice translation-rule 202
(cfg-translation-rule)# rule 1 /\([2-9].........\)/
/+1\1/
(cfg-translation-rule)# rule 2 /\([2-9]\)/ /+\1/
CUBE 2
(config)# voice translation-profile inbound-add-plus
(cfg-translation-profile)# translate called 201
(cfg-translation-profile)# translate calling 202
(cfg-translation-profile)# exit
(config)# voice translation-profile outbound-stripplus
(cfg-translation-profile)# translate called 101
(cfg-translation-profile)# translate calling 102
CUBE 2
(config)# dial-peer voice 101 voip
(cfg-translation-profile)# translation-profile
outgoing inbound-add-plus
(config)# dial-peer voice 201 voip
(cfg-translation-profile)# translation-profile
outgoing outbound-strip-plus
9[cell phone]#
POD10user1@
Dial Digits
9[PSTN
Phone]
Phone
Should
Ring
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 subconfiguration, 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
providers 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.
CUBE 2
<Press Return>
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
Session-Expires: 1800
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:
CUBE 2
(config)# monitor event-trace voip ccsip fsm
(config)# monitor event-trace voip ccsip msg
CUBE 2
(config)# monitor event-trace voip ccsip dump none
CUBE 1
CUBE 2
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 partners CUBE.
9[cell phone]#
POD10user1@
Dial Digits
9[PSTN
Phone]
Phone
Should
Ring
Cell Phone
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
Sip-Call-Id =
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
CUBE 2
With this you will be able to tell the system to dump the information for a specific
call.
9[cell phone]#
POD10user1@
Dial Digits
9[PSTN
Phone]
Phone
Should
Ring
Cell Phone
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.
Description
503
service unavailable
505
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.
CUBE 1
(config)# voice class sip-options-keepalive 1
(config-class)# description CiscoLive Options Class
(config-class)# transport udp
CUBE 2
(config)# voice class sip-options-keepalive 1
(config-class)# description CiscoLive Options Class
(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
(config)# dial-peer voice 201 voip
(config-dial-peer)# voice-class sip optionskeepalive profile 1
CUBE 2
(config)# dial-peer voice 201 voip
(config-dial-peer)# voice-class sip optionskeepalive profile 1
Configure OPTIONS ping for the peers pointing to Unified CM SME as well with the
following commands:
CUBE 1
(config)# dial-peer voice 101 voip
(config-dial-peer)# voice-class sip optionskeepalive profile 1
CUBE 2
(config)# dial-peer voice 101 voip
(config-dial-peer)# voice-class sip optionskeepalive profile 1
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 URIs 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.
Lets 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:
POD10
CUCM Leaf 1
Username
Password
10.0.110.50
Administrator
c1sco123!
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. Lets fix this to fix your URI
dialing.
Add an end user following these steps:
1.
2.
3.
4.
5.
Notice that the Advertise Globally via ILS checkbox is automatically enabled
and you didnt actually have to configure anything for URI dialing to work globally
other than associating the user with the directory number via the Primary
Extension.
Go to Call Routing > Route Plan Report on the Unified CM Leaf 2 Cluster.
Change the Find field to All URIs
Click Find
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@
POD10user2@ciscolive.com
Dial URI
POD10user2@ciscolive.com
POD10user1
Phone
Should
Ring
POD10user2@
POD10user2
On your SME cluster go to Device > Device Settings > SIP Normalization Script.
Click Add New
Enter DiversionMask as the name
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.
7.
8.
9.
10.
Click Save
Click Reset to reset the trunk
On the popup that appears, click Reset
Click Close
On your SME cluster, go to Call Routing > Class of Control > Calling Search Space.
Click the Add New button
Enter CSS_Only_GDPR for the name of the new CSS.
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
Global Learned E164 Numbers
Global Learned E164 Patterns
Global Learned Enterprise Numbers
Global Learned Enterprise Patterns
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.
2.
3.
4.
On your SME cluster, go to Call Routing > Class of Control > Calling Search Space.
Click Find to list all the available Calling Search Spaces.
Select the CSS_Inbound_CUBE CSS.
Select the InboundTranslations CSS from the list of Available Partitions and move it down
to the Selected Partitions.
5. Click Save.
Translation
Pattern
Partition
CSS
Called Party
Transformation
Mask
POD10
\+19194767718
InboundTranslations
CSS_Only_GDPR
+13912102001
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
Pattern
Partition
CSS
Called Party
Transformation
Mask
POD10
\+19194767719
InboundTranslations
CSS_Only_GDPR
+13912103001
CUBE 2
(config)# voice class e164-pattern-map 1
(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
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.
CUBE 2
(config)# no logging console debugging
(config)# logging buffered debugging
(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. Lets make sure that we are on the doing this on
the active ISR.
CUBE 1
#show standby brief
Interface
Grp Pri P State
Active
Gi0/0
101 51
Standby 10.0.110.12
Gi0/1
201 51
Standby 10.0.224.108
CUBE 2
#show standby brief
Interface
Grp Pri P State
Gi0/0
101 51
Active
Gi0/1
201 51
Active
Active
local
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.
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.
10.0.110.50
Administrator
c1sco123!
UCM #2
10.0.110.60
Administrator
c1sco123!
SME
10.0.110.40
Administrator
c1sco123!
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.
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
2014 Cisco Systems, Inc. All rights reserved
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.
82103001
Dial Digits
82103001
Phone
Should
Ring
POD10user1@
POD10user1@
91[cell phone]
POD10user2@
POD10user2@
Dial Digits
91[Cell Phone]
POD10user1@
Phone
Should
Ring
Cell Phone
Once you have placed the necessary calls, do the trace collection as shown below.
This will provide you with a popup to select the Services/Application that you wish
to collect the files from.
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.
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.
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.
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.
Notes
Notes
Notes