Cisco OL-9420-01 - Manual (Page 4)

A-4
Troubleshooting Guide for Cisco Unified CallManager Release 5.0(2)
OL-9420-01
Appendix A Case Study: Troubleshooting Cisco Unified IP Phone Calls
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
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.