Cisco Systems OL-9420-01 User Manual
APPENDIX
Case Study: Troubleshooting
Cisco Unified IP Phone Calls
This appendix contains two case studies:
• Troubleshooting Intracluster Cisco Unified IP Phone Calls
• Troubleshooting Intercluster Cisco Unified IP Phone Calls
Troubleshooting Intracluster Cisco Unified IP Phone Calls
The case study in this section discusses in detail the call flow between two Cisco Unified IP Phones
within a cluster, called an intracluster call. This case study also focuses on Cisco Unified CallManager
and Cisco Unified IP Phone initialization, registration, and keepalive processes. A detailed explanation
of an intracluster call flow follows the discussion. The explanation of the processes are explained using
the trace utilities and tools discussed in Chapter 2, “Troubleshooting Tools.”
This section contains the following topics:
B
• Sample Topology
• Cisco Unified IP Phone Initialization Process
• Cisco Unified CallManager Initialization Process
• Self-Starting Processes
• Cisco Unified CallManager Registration Process
• Cisco Unified CallManager KeepAlive Process
• Cisco Unified CallManager Intracluster Call Flow Traces
Sample Topology
Given that you have two clusters named Cluster 1 and Cluster 2, the two Cisco Unified CallManagers in
Cluster 1 are called Unified CM3 and Unified CM4, while the two Cisco Unified CallManagers in
Cluster 2 are called Unified CM1 and Unified CM2.
The traces collected for this case study come from Unified CM1, which is located in Cluster 2, as shown
in Figure B-1. The basis for the call flow are the two Cisco Unified IP Phones in Cluster 2. The IP
addresses of these two Cisco IP Phones are 172.16.70.230 (directory number 1000) and 172.16.70.231
(directory number 1001), respectively.
OL-9420-01
Troubleshooting Guide for Cisco Unified CallManager Release 5.0(2)
B-1
Troubleshooting Intracluster Cisco Unified IP Phone Calls
Figure B-1 Sample Topology of Intracluster Cisco IP Phone-to-Cisco IP Phone Calls
Appendix B Case Study: Troubleshooting Cisco Unified IP Phone Calls
IOS Gatekeeper
IP IP
Unified
CM3
172.16.70.245 172.16.70.243
Cluster 1
Zone 1
= T1/PRI
= T1/CAS
= RAS
Unified
CM4
172.16.70.241
172.16.70.255
IP WAN
Cisco Unified IP Phone Initialization Process
The following procedure explains in detail the Cisco Unified IP Phone initialization (or boot up)
process.
PSTN
IP IP
Unified
CM1
172.16.70.228 172.16.70.229
Cluster 2
Unified
CM2
Zone 2
141754
Procedure
Step 1 If you have set the appropriate options in DHCP server (such as Option 066 or Option 150), the
Cisco Unified IP Phone sends a request, at initialization to the DHCP server to get an IP address,
Domain Name System (DNS) server address, and TFTP server name or address. It also gets a default
gateway address if you have set these options in the DHCP server (Option 003).
Step 2 If a DNS name of the TFTP sever is sent by DHCP, you need a DNS server IP address to map the name
to an IP address. Bypass this step if the DHCP server sends the IP address of the TFTP server. In this
case study, the DHCP server sent the IP address of TFTP because DNS was not configured.
Step 3 If a TFTP server name is not included in the DHCP reply, the Cisco IP Phone uses the default server
name.
Step 4 The configuration file (.cnf) file gets retrieved from the TFTP server. All .cnf files have the name
SEP<mac_address>.cnf. If this is the first time the phone is registering with the
Cisco Unified CallManager, a default file, SEPdefault.cnf, gets downloaded to the
Cisco Unified IP Phone. In this case study, the first Cisco Unified IP Phone uses the IP address
172.16.70.230 (its MAC address is SEP0010EB001720), and the second Cisco Unified IP Phone uses
the IP address 172.16.70.231 (its MAC address is SEP003094C26105).
Step 5 All .cnf files include the IP address(es) for the primary and secondary Cisco Unified CallManager(s).
The Cisco Unified IP Phone uses this IP address to contact the primary Cisco Unified CallManager and
to register.
B-2
Troubleshooting Guide for Cisco Unified CallManager Release 5.0(2)
OL-9420-01
Appendix B Case Study: Troubleshooting Cisco Unified IP Phone Calls
Troubleshooting Intracluster Cisco Unified IP Phone Calls
Step 6 Once the Cisco Unified IP Phone connects and registers with Cisco Unified CallManager, the
Cisco Unified CallManager tells the Cisco Unified IP Phone which executable version (called a load ID)
to run. If the specified version does not match the executing version on the Cisco Unified IP Phone, the
Cisco Unified IP Phone will request the new executable from the TFTP server and reset automatically.
Cisco Unified CallManager Initialization Process
This section explains the initialization process of Cisco Unified CallManager with the help of traces that
are captured from Unified CM1 (identified by the IP address 172.16.70.228). As described previously,
SDI traces provide a very effective troubleshooting tool because they detail every packet sent between
endpoints.
This section describes the events that occur when Cisco Unified CallManager is initialized.
Understanding how to read traces will help you to properly troubleshoot the various
Cisco Unified CallManager processes and the effect of those processes on services such as conferencing
and call forwarding.
The following messages from the Cisco Unified CallManager SDI trace utility show the initialization
process on one of the Cisco Unified CallManagers, in this case, Unified CM1.
• The first message indicates that Cisco Unified CallManager started its initialization process.
• The second message indicates that Cisco Unified CallManager read the default database values (for
this case, it is the primary or publisher database).
• The third message indicates Cisco Unified CallManager received the various messages on TCP port
8002.
• The fourth message shows that, after receiving to these messages, Cisco Unified CallManager added
a second Cisco Unified CallManager to its list: Unified CM2 (172.16.70.229).
• The fifth message indicates that Cisco Unified CallManager has started and is running
Cisco Unified CallManager version 3.1(1).
16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CCMDatabase
Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen
Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229]
16:02:51.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager
Version=<3.1(1)> started
Self-Starting Processes
Once Cisco Unified CallManager is up and running, it starts several other processes within itself. Some
of these processes follow, including MulticastPoint Manager, UnicastBridge Manager, digit analysis,
and route list. You will find the messages described during these processes very useful when you are
troubleshooting a problem related to the features in Cisco Unified CallManager.
For example, assume that the route lists are not functioning and are unusable. To troubleshoot this
problem, you would monitor these traces to determine whether the Cisco Unified CallManager has
started RoutePlanManager and if it is trying to load the RouteLists. The sample configuration below
shows that RouteListName=''ipwan'' and RouteGroupName=''ipwan'' are loading and starting.
16:02:51.031 CCM|MulicastPointManager - Started
OL-9420-01
Troubleshooting Guide for Cisco Unified CallManager Release 5.0(2)
B-3
Troubleshooting Intracluster Cisco Unified IP Phone Calls
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:51.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager
started
16:02:51.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager
started
16:02:51.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis
started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection
Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection
Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''
The following trace shows the RouteGroup adding the device 172.16.70.245, which is Unified CM3
located in Cluster 1 and is considered an H.323 device. In this case, the RouteGroup is created to route
calls to Unified CM3 in Cluster 1 with Cisco IOS Gatekeeper permission. If a problem occurs while
routing the call to a Cisco Unified IP Phone located in Cluster 1, the following messages would help you
find the cause of the problem.
16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts
Appendix B Case Study: Troubleshooting Cisco Unified IP Phone Calls
Part of the initialization process shows that Cisco Unified CallManager is adding "Dns" (Directory
Numbers). By reviewing these messages, you can determine whether the Cisco Unified CallManager has
read the directory number from the database.
16:02:51.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control
started
16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = ,
RouteThisPattern, NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause =
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started
In the following traces, the Device Manager in Cisco Unified CallManager statically initializes two
devices. The device with IP address 172.17.70.226 represents a gatekeeper, and the device with IP
address 172.17.70.245 gets another Cisco Unified CallManager in a different cluster. That
Cisco Unified CallManager gets registered as an H.323 Gateway with this Cisco Unified CallManager.
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.245
Cisco Unified CallManager Registration Process
Another important part of the SDI trace involves the registration process. When a device is powered up,
it gets information via DHCP, connects to the TFTP server for its .cnf file, and then connects to the
Cisco Unified CallManager that is specified in the .cnf file. The device could be an MGCP gateway, a
Skinny gateway, or a Cisco Unified IP Phone. Therefore, you need to be able to discover whether devices
have successfully registered on the Cisco network.
B-4
Troubleshooting Guide for Cisco Unified CallManager Release 5.0(2)
OL-9420-01
Loading...