Troubleshooting CUCM Volume 1 The Essentials

Troubleshooting CUCM - Volume I:
The Essentials
Tips and Insights
Compiled by the Stack8 Managed and Professional Services Teams
www.stack8.com info@stack8.com
Table of Contents
Troubleshooting CUCM Volume I - Tips and Insights
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Troubleshooting Cisco Phone Registration Issues in Cisco Unified . . . . . . . . . 4

Communications Manager CUCM
- Solution 1 - Delete Trust Lists
- Solution 2 - No Network Connectivity
- Solution 3 - Validate File Downloadability

New Practices for CUCM Dial Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- Global Dial Plan Replication (GDPR) and Intercluster Lookup Service (ILS)
- Enterprise Alternate Numbers
- +E.164 Alternate Numbers
- YMMV (Your Mileage May Vary)

Using LUA Script to Allow SIP-Based Phones to Dial from the CUCM Corporate
Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Diagnosing the Dial Plan - Partitions & Calling Search Space . . . . . . . . . . . .17
- Partitions
- Calling Search Space
- Sample problem and solution

About Stack8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
If you require any help with the many features and functionalities of
CUCM please contact us: info@stack8.com
Introduction
Cisco Unified Communications Manager (CUCM) is an IP-based communications system

integrating voice, video, data, and mobility products and other applications. It enables more
effective, secure communications and can transform the way in which we communicate.
But CUCM can also be challenging. Thats why weve created this guide to help you get the
most out of this tool.
For Volume I we have compiled these Tips and Insights based upon the most frequent and
challenging issues facing our clients. Further guides will focus on specific issues associated
with CUCM.
If you would like any further Tips and Insights on CUCM, or if you require any assistance,
please feel free to contact us at: info@stack8.com
We look forward to hearing from you
3 Troubleshooting CUCM Volume I www.stack8.com

Troubleshooting Cisco Phone Registration
Issues in Cisco Unified Communications
Manager CUCM
Your company is a Cisco Unified Communications environment, and you are having issues
with registering phones to your environment. You verify the configuration on the Cisco Unified
Communications Manager CUCM, and everything seems okay, what are the possible issues preventing
registration? How can I diagnose the problem?
Problem
Your Cisco phone is not registering to Cisco Unified Communications Manager CUCM.
We will explore three possible solutions to troubleshoot to identify and resolve the issue.
Solution 1 - Delete Trust Lists
This first solution outlines one of the most common problems when introducing new devices to your
Cisco Unified Communications Manager environment. Typically, this occurs with pre-used phones
who retained the information of the previous CUCM.
Step 1. Unlock the phone and delete the CTL and ITL files.
Navigate to the security settings on your phone; the location can vary depending on the phone

Issues in CUCM
model. Certain models will have a reset security settings, others will require you to navigate to
the CTL & ITL files manually.
Use **# to unlock your phone and delete the CTL & ITL files.
Step 2. Verify that the phone has registered.

Once youve deleted the security settings, the phone should restart. Verify if it registers.
Solution 2 - No Network Connectivity
Step 1. Verification of connectivity via packet capture

You can take a packet capture by one of two methods, either by using span PC port functionality
of the phone or by configuring the same functionality on the switch.

Issues in CUCM
Packet Captures can be difficult to read when there is a lot going on, narrow it down the fields as much
as possible with the following filters in Wireshark:
ip.addr eq and ip.addr eq
Step 2. Validate 2-way connectivity

The next thing to do is validate that there is two-way communication between the Cisco Unified
Communications Manager and the phone. If there is none, then we can confirm there is no network
connectivity.
If there were no network connectivity, you would see traffic originating from your phones IP address
only, not the CUCM (first column is the originator).
Solution 3 - Validate File Downloadability
Finally, well want to see is that the phone is able to download its files.
Step 1. Verify that .cnf are being downloaded

.cnf files contain the phone configuration, in the below capture we see the GET sent by phone on
line 4, we then see the transaction is completed successfully on line 13.
Step 2. Verify that .tlv file is being downloaded

.tlv files contain the security information which allows the phone to trust the CUCM, we see the
GET on line 1, and in this case, the Cisco Unified Communications Manager CUCM returns 404
Not Found.

Issues in CUCM
Step 3. Investigate resolution options below

If you are not able to download any files from the Cisco Unified Communications Manager CUCM,
always ensure that TFTP is permitted on your network, you can also attempt to reboot the TFTP
service on CUCM; this will only affect phones which are in the registering process.
If the phone isnt finding the .cnf file, it is possible that there is a typo in the device name of the call
manager.
If the phone isnt finding the .tlv file, it is possible that there is a problem with the TVS service, this
service much like the TFTP service will only affect phones which are attempting to register to the
call manager. If this is the case, the issue is always widespread and may require the server to be
rebooted.
Useful Insights - Phone Traces
Reading traces is an unpopular way of diagnosing problems. However, it can quickly become your go-
to technique if you work on it. Dont ever be afraid to collect logs, whether it be endpoint or server logs,
if you have a good idea of what you want to find, you may be able to get it without fully understanding
the log file.
The logs we will need for this are the console logs from the phone; we should take the latest one in
this case, I will take /FS/cache/log85.log:

Issues in CUCM
So, once were in the log file, if youre familiar with log files, you can parse through these manually.
Alternatively, we can search for keywords which will point us in the right direction. For instance, search
for CTL This will bring you to all of the lines involving certificates.
And in this case, we can see that there is an error The call manager isnt in the phones trust list. This
is why the phone is being rejected from the Cisco Unified Communications Manager.
With the help of these steps, you should be in good shape to diagnose the issue behind why your
phone is not registering to your CUCM. If you find yourself needing to troubleshoot this type of other
types of issues regularly, then call logs will quickly become your best friend.

New Practices for CUCM Dial Plans
Traditionally, enterprise dial plans for organizations running Cisco Unified Communications Manager
(CUCM) were structured in a simple fashion. Each user would get assigned with an internal extension
(aka Directory Number), usually 4 to 6 digits long. Users would also get assigned with an externally
reachable phone number (aka DID, or Direct Inward Dial).
In many cases, to simplify the assignment of internal and external numbers, UC engineers would use
the last digits of the DID as the internal extension. As such, a user with DID 555-123-4567 would have
the 4567 directory number. In this scenario, incoming PSTN call routing is simple: a single rule in the
ingress PSTN voice gateway allows for the translation of a whole DID block to its matching internal
directory numbers, (ex. 555-123-XXXX matches Directory Numbers XXXX).
In geographies where DID numbers are more expensive, only a select group of users, usually executives,
receive DIDs. Other users would need be reached by calling the main office number, before being
transferred to the right internal extension by way of a receptionist or automated attendant. As such, it
is not rare to see dial plans where users internal directory numbers do not match any digits from their
assigned DIDs we dub this as non-matching DIDs in this post. In such a case, incoming PSTN call
routing rules are a bit more complex: one routing rule must be defined for each DID, mapping each
of them to an internal directory number. This is usually achieved by defining an explicit Translation
Pattern in CUCM for each DID (ex. 555-123-4567 matches Directory Number 7654).

In recent years, enterprise dial plans have grown more complex, due to the changing nature of
technology and the evolving realities of todays businesses:
Phone systems are now more centralized, often supporting users in multiple geographies within
the same environment.
Companies are now more geographically distributed, which often implies the need for many
distributed phone systems to all be linked together to form a global unified communications
footprint.
E.164 numbers are now officially recognized globally as the standard for phone number
representations (ex. +1-514-940-1480), and phone systems need to know how to handle this type
of numbers.
All of these factors have contributed to the creation of new features within CUCM to help businesses
simplify their enterprise dial plans. Although these features have been around since CUCM 10.0, we
have yet to see many organizations taking advantage of these new enhancements. In the past few
weeks, however, the Stack8 team came across two customers who do utilize these functionalities to
simplify their dial plan we hope more organizations will follow their footsteps after reading this blog
post.
Global Dial Plan Replication (GDPR) and Intercluster Lookup Service (ILS)
In multi-cluster organizations, it is usually a good practice to keep calls between end-users of different
systems on-net, rather than using the PSTN. This keeps PSTN usage down as well as reduces toll
fees, in addition to allowing for more advanced functionalities such as video.
In such a deployment, complex sets of dialing rules would have typically been implemented manually
by UC engineers, allowing for proper translation and routing of calls between clusters. Moreover,
failover rules would have also been manually added to each cluster, in order to account for situations
where bandwidth is insufficient, inter-cluster trunks are down, etc. In situations where toll-bypass, or
Tail End Hop Off (TEHO), is required for routing PSTN calls to the least cost gateway, the quantity of
dialing rules again multiply to daunting numbers.
With GDPR, these manual dialing rules mostly disappear. Rather, systems will dynamically advertise
local numbers, or patterns, to their peer systems using ILS. These advertised patterns will be tagged
with a unique location attribute which identifies the cluster from which this pattern originates.
For internal dialing (or on-net calls), Enterprise Alternate Numbers and E.164 Alternate are set to be

advertised by ILS, such that any user within the organization dialing an internal extension or a DID
belonging to the organization will remain on-net. In case of a failure for this call to remain on-net, an
additional parameter of the Directory Number allows the cluster to advertise the Enterprise Alternate
Number or the E.164 Alternate Number as a PSTN failover number. In our example, a failed on-net
call would fall back to the PSTN using a routable E.164 number no additional configurations required!
For external dialing, local dialing rules will be advertised by each ILS peer, thus creating a dynamic
set of toll-bypass rules that can be used by any cluster within the ILS network. In the example below,
a pattern for local calls to San Jose (US) is created on the US cluster which, once advertised to peer
clusters through ILS, will enable users from any peer cluster to make PSTN calls to San Jose through
the US cluster.
Enterprise Alternate Numbers
This new parameter, found in the Directory Number configuration page, allows for the creation of an
alternate number, or alias, to be directly tied to said Directory Number. This alternate number can be
injected in a local Route Partition, and/or can be advertised via GDPR and ILS.
In multi-site organizations, Directory Numbers usually consist of a Site Prefix, followed by the users
unique identifier. As an example, a user with directory number 501234 (or 50-1234 for better legibility)
would correspond to a user in site 50, with a unique ID of 1234.

Expanding the scope of this example to a multi-cluster environment, the Enterprise Alternate Number
feature can be easily used to dynamically replicate Directory Numbers to peer clusters via GDPR and
ILS.
With the above empty mask, the Directory Number also becomes the Enterprise Alternate Number.
With the Advertise Globally via ILS option checked, the alternate number will be dynamically replicated
to peer clusters, thus enabling inter-cluster calling with very little effort.
+E.164 Alternate Numbers
Although CUCM has supported E.164 Directory Numbers for quite a while, some UC applications,
especially from third-party manufacturers, do not always handle these well. As such, most UC engineers
still shy away from using E.164 numbers as Directory Numbers. The E.164 Alternate Number feature
was created to help with these issues.
In a nutshell, this feature allows for an E.164 number to be tied to an internal Directory Number. This
effectively allows for a Directory Number to have a double identity.

In the above example, the users DID is directly tied to its Directory Number using the E.164 Alternate
Number. This number is also injected in a Local Route Partition containing all internal directory
numbers, thus making sure that all calls to DIDs that are attached to this same system remain internal,
rather than trombone through the PSTN. Alternatively, users with non-matching DIDs can also
explicitly configure their E.164 DID using this same feature, only this time without using wildcards (ex.
+15559874321 rather than using Xs as above). Another benefit is that this concept now eliminates the
need for DID translation rules at the ingress voice gateway or CUCM level, which is especially useful for
organizations with non-matching DIDs.
In addition, in multi-cluster environments with global enterprise dial plans, it is usually recommended
to advertise E.164 numbers through GDPR and ILS this is easily achieved by checking the appropriate
box in this same section. As was the case with the Enterprise Alternate Number, this feature greatly
reduces the effort required to have all DIDs of the local cluster dynamically replicated with all other
clusters in the organizations, thus keeping calls to the organizations DIDs on-net rather than using
the PSTN and incurring toll charges.
YMMV (Your Mileage May Vary)
Dial plan architecture is definitely not an exact science. Different organizations have different realities,
both business and technical, which may require different approaches to design the proper dial plan to
achieve the desired result. At the very least, the examples above should help illustrate how Enterprise
Alternate Numbers, E.164 Alternate Numbers, and Global Dial Plan Replication can provide easier
solutions than more traditional approaches.
Although these features are meant to simplify global dial plans, implementing Global Dial Plan
Replication, Enterprise Alternate Numbers or E.164 Alternate Numbers can sometimes require quite
a bit of heavy lifting. Should you require assistance with dial plan architecture or implementation, our
Cisco UC experts are available to help!

Using LUA Script to Allow SIP-Based Phones
to Dial from the CUCM Corporate Directory
If you sync your Cisco Unified Communications Manager (CUCM) to an enterprise directory, such as
Microsoft Active Directory, and the phone format is entered in a fancy human-friendly way, users
with SIP-based phones will have some issues to dial.
In my last case with a customer, the phone number format in the corporate directory had been
formatted as follows: +1 514-940-1480 x5661.
From SCCP phones and Jabber, this string is interpreted, and the resulting number is respectively
+151494014805661 or +1514940148095661 (note the extra 9 digit between the main number and
the extension).
With SIP-based phones, there is no parsing before the call is initiated with CUCM. At the time of
writing, it is still unclear whether this is a bug or is in-line with the RFC.
Given the elusive answers provided by TAC on this matter, I decided to leverage the SIP Normalization
feature of CUCM to workaround this situation and achieve my goal of allowing SIP-based phones to
dial numbers from within the CUCM Corporate Directory.

Below is a typical INVITE sent by the phone when dialing +1 514-940-1480 x5661 from the Corporate
Directory in CUCM.
Spaces are replaced by %20, hyphens and the letter x are sent as-is. Obviously, there is no way in
CUCM to create a translation pattern which would match this string.
INVITE sip:+1%20514-940-1480%20x5661@cucm.acme.com SIP/2.0

Via: SIP/2.0/TCP 10.10.10.10:50291;branch=z9hG4bK7673093f
From: Test phone <sip:2890@cucm.acme.com>;tag=00a289fbb820000f2624e8cf-1f9deb31
To: <sip:+1%20514-940-1480%20x5661@cucm.acme.com>
Call-ID: 00a289fb-b8200004-5f91f053-241493e7@10.10.10.10
Max-Forwards: 70
With the help of a LUA script applied on a SIP Profile, which is in turn applied to the SIP-based phones,
we have a resulting INVITE looking like this:
INVITE sip:+151494014805661@cucm.acme.com SIP/2.0

Via: SIP/2.0/TCP 10.10.10.10:50291;branch=z9hG4bK7673093f
From: Test phone <sip:2890@cucm.acme.com>;tag=00a289fbb820000f2624e8cf-1f9deb31
To: <sip:+151494014805661@cucm.acme.com>
Call-ID: 00a289fb-b8200004-5f91f053-241493e7@10.10.10.10
Max-Forwards: 70
As you can see, the number is now routable by CUCM. The LUA script I have developed to remove the
unwanted characters can be found below. You can be as fancy as you want with adapting this script
to your particular needs.
M={}
function M.inbound_INVITE(msg)
--[[ Extract data from SIP INVITE --]]
local to = msg:getHeader(To)
local method, ruri, ver = msg:getRequestLine()
--[[ Isolate both side of @ in variables --]]

local to_left_side, to_right_side = string.match(to, <sip:(.*)@(.*))
local ruri_left_side, ruri_right_side = string.match(ruri, sip:(.*)@(.*))

--[[ Search and replace for To Header and Request URI --]]
to_left_side = string.gsub(to_left_side , %%20, )
to_left_side = string.gsub(to_left_side , -, )
to_left_side = string.gsub(to_left_side , x, )
ruri_left_side = string.gsub(ruri_left_side , %%20, )
ruri_left_side = string.gsub(ruri_left_side , -, )
ruri_left_side = string.gsub(ruri_left_side , x, )
--[[ If the left side of @ contain only numbers and begin OR not begin
with +, then update the To Header and Request URI --]]
if string.find(to_left_side, ^+?%d*$) then
msg:modifyHeader(To, <sip: .. to_left_side .. @ .. to_right_side)
end
if string.find(ruri_left_side, ^+?%d*$) then

msg:setRequestUri(sip: .. ruri_left_side .. @ .. ruri_right_side)
end
end
return M

Diagnosing the Dial Plan - Partitions &
Calling Search Space
Diagnosing problems in your Cisco unified communications dial plan can be difficult as there are a large
variety of ways in which it can be broken and generally, to identify these, a solid base understanding
of the underlying features is required. With that said, lets look at the base of your UC dial plan and a
few problems that could arise at this level.
At its base, Cisco Unified Communications Manager (CUCM) is built upon Partitions and Calling Search
Spaces. We need to understand how these interact before we can hope to solve any issues with our
dial plan.
Partitions
Partitions are used to logically segregate directory numbers in your system. Every Directory Number,
Route Pattern, and Translation have an associated partition.
17
Troubleshooting CUCM Volume I www.stack8.com
Calling Search Spaces (CSS) are used to determine which partitions a given device can dial. If a device
is not configured with a Calling Search Space and/or its Calling Search Space does not contain any
partitions, said device would not be able to make any calls.

When a new call is made, the line and device CSS are combined in that order, and a pattern is matched
in the following order:
Most specific match with priority.

Most specific match without priority.
If equal, Partition order in the CSS.
Problem:
You have a new user who complains they are not able to dial certain extensions.
Steps:
Go to the device configuration of User A

Validate that the device is configured with a Calling Search Space
Check the Partition associated to User Bs directory number
Resolution:
Validate that the Partition of User Bs directory number is configured in Device As Calling Search Space
If the line appears with multiple entries in the Route Plan Report, that could be the source of our issue.
Check to see if the Calling Search Space of User As device contains multiple of these partitions.
Problem:
User complains that when they call a specific number, there is a significant delay before the phone
starts ringing.
Resolution:
Validate if there is another pattern with equal or greater priority for which the pattern is longer than
the users, but the initial digits are the same.
In this case, CUCM would then wait for more digits to see if it matches the longer extension -- this
delay is referred to as the interdigit timeout. Either set the users pattern to priority or delete the
other pattern.
Example:
User: 4553
Problematic pattern: 45531

Tip: Dialed Number Analyzer is a good tool for diagnosing these types of issues.
Connecting to DNA: https://<<cucmipaddress>>/dna
This tool allows you to simulate the logical path which a call will take from a given device.

About Stack8
Stack8 is a new breed of Cisco Solutions Partner. The founders, former Cisco guys, created the com-
pany to provide Cisco Solutions that adapt to each customers reality. Our focus is on how people
use Cisco technologies and ensuring they get the most out of it.
We are positioned as the human 8th layer of the OSI Stack, the
layer that bridges business operations and process with
technology.
Stack8 is built on three pillars, each born out of the prevailing problems our customers face today:
Professional Services: the how - getting you set up quickly and painlessly
Managed Services: the help an always live extension of your team
Software Solutions: the tools - improving and optimizing your operations
As a Cisco Solutions Partner, we love Cisco and its incredible

networking, unified communications solutions; but we know that the complexities that exist in all
stages of the technology lifecycle are the real hindrance that prevents customers from achieving
their goals. We realize that the only way for us to help our clients is to provide services and solutions
rallied around taking that
complexity out. We work hard every day to make Cisco easy.
Founded in 2010, Stack8 Technologies is an independent, privately held company based in Montre-
al, Canada.
For more information please visit: www.stack8.com
If you require any help with the many features and functionalities of
CUCM please contact us: info@stack8.com

Corporate Headquarters: 1550 Rue Metcalfe #500, Montral, QC H3A 1X6, Canada
General Inquiries: info@stack8.com Tel: +1-514-940-1480 Toll-free: +1-514-940-1480
Sales Inquiries: info@stack8.com Tel: +1-514-940-1600 Toll-free: +1-844-940-1600

Troubleshooting CUCM Volume 1 The Essentials

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Troubleshooting CUCM Volume 1 The Essentials

Încărcat de

Drepturi de autor:

Formate disponibile

Troubleshooting CUCM - Volume I:

Troubleshooting CUCM Volume I - Tips and Insights

Troubleshooting Cisco Phone Registration Issues in Cisco Unified . . . . . . . . . 4

Cisco Unified Communications Manager (CUCM) is an IP-based communications system

We look forward to hearing from you

3 Troubleshooting CUCM Volume I www.stack8.com

Solution 1 - Delete Trust Lists

4 Troubleshooting CUCM Volume I www.stack8.com

Step 2. Verify that the phone has registered.

Solution 2 - No Network Connectivity

Step 1. Verification of connectivity via packet capture

5 Troubleshooting CUCM Volume I www.stack8.com

ip.addr eq and ip.addr eq

Step 2. Validate 2-way connectivity

Solution 3 - Validate File Downloadability

Step 1. Verify that .cnf are being downloaded

Step 2. Verify that .tlv file is being downloaded

6 Troubleshooting CUCM Volume I www.stack8.com

Step 3. Investigate resolution options below

Useful Insights - Phone Traces

7 Troubleshooting CUCM Volume I www.stack8.com

8 Troubleshooting CUCM Volume I www.stack8.com

9 Troubleshooting CUCM Volume I www.stack8.com

10 Troubleshooting CUCM Volume I www.stack8.com

Enterprise Alternate Numbers

11 Troubleshooting CUCM Volume I www.stack8.com

+E.164 Alternate Numbers

12 Troubleshooting CUCM Volume I www.stack8.com

YMMV (Your Mileage May Vary)

13 Troubleshooting CUCM Volume I www.stack8.com

14 Troubleshooting CUCM Volume I www.stack8.com

INVITE sip:+1%20514-940-1480%20x5661@cucm.acme.com SIP/2.0

INVITE sip:+151494014805661@cucm.acme.com SIP/2.0

--[[ Isolate both side of @ in variables --]]

15 Troubleshooting CUCM Volume I www.stack8.com

if string.find(ruri_left_side, ^+?%d*$) then

16 Troubleshooting CUCM Volume I www.stack8.com

Calling Search Space

18 Troubleshooting CUCM Volume I www.stack8.com

Most specific match with priority.

Go to the device configuration of User A

Problematic pattern: 45531

19 Troubleshooting CUCM Volume I www.stack8.com

Connecting to DNA: https://<<cucmipaddress>>/dna

20 Troubleshooting CUCM Volume I www.stack8.com

As a Cisco Solutions Partner, we love Cisco and its incredible

For more information please visit: www.stack8.com

21 Troubleshooting CUCM Volume I www.stack8.com

S-ar putea să vă placă și