Appendix B Case Study: Troubleshooting Cisco Unified IP Phone Calls
Troubleshooting Intracluster Cisco Unified IP Phone Calls
16:02:51.031 CCMUnicastBridgeManager - Started 16:02:51.031 CCMMediaTerminationPointManager - Started 16:02:51.125 CCMMediaCoordinator(1) - started
16:02:51.125 CCMNodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started
16:02:51.234 CCMNodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started
16:02:51.390 CCMNodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started
16:02:51.406 CCMRoutePlanManager - Started, loading RouteLists 16:02:51.562 CCMRoutePlanManager - finished loading RouteLists 16:02:51.671 CCMRoutePlanManager - finished loading RouteGroups 16:02:51.671 CCMRoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCMRoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order
16:02:51.671 CCMRouteList - RouteListName=''ipwan''
16:02:51.671 CCMRouteList - RouteGroupName=''ipwan''
16:02:51.671 CCMRoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order
16:02:51.671 CCMRouteGroup - 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 CCMRouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCMRouteGroup
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 CCMNodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started
16:02:51.843 CCMProcessDb - Dn = 2XXX, Line = 0, Display = , RouteThisPattern, NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause = 16:02:51.859 CCMDigit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCMForwardManager - Started
16:02:51.984 CCMCallParkManager - Started 16:02:52.046 CCMConferenceManager - 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 CCMDeviceManager: Statically Initializing Device; DeviceName=172.16.70.226
16:02:52.250 CCMDeviceManager: 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.
Troubleshooting Guide for Cisco Unified CallManager Release 5.0(2)
|
| ||
|
|