Troubleshooting Guide for Cisco CallManager, Release 3.1(1) - Troubleshooting Inter-Cluster Calls [Cisco Unified Communications Manager (CallManager)]

Table Of Contents

Troubleshooting Inter-Cluster Calls

Sample Topology

Inter-Cluster H.323 Communication

Call Flow Traces

Failed Call Flow

Troubleshooting Inter-Cluster Calls

The case study in this appendix examines a Cisco IP Phone calling another Cisco IP Phone located in a different cluster. This type of call is also known as an inter-cluster Cisco IP Phone call.

This appendix contains the following topics:

•Sample Topology

•Inter-Cluster H.323 Communication

•Call Flow Traces

•Failed Call Flow

Sample Topology

The following is the sample topology used in this case study. There are two clusters, each having two Cisco CallManagers. There are also Cisco IOS Gateways and a Cisco IOS Gatekeeper in place.

Inter-Cluster H.323 Communication

The Cisco IP Phone in Cluster 1 is making a call to the Cisco IP Phone in Cluster 2. Inter-cluster Cisco CallManager communication takes place using the H.323 Version 2 protocol. There is also a Cisco IOS Gatekeeper for admission control.

The Cisco IP Phone can talk to the Cisco CallManager via Skinny Station protocol, and the Cisco CallManager can talk with the Cisco IOS Gatekeeper using the H.323 Remote Access Server (RAS) protocol. The admission request message (ARQ) is sent to the Cisco IOS Gatekeeper, which sends the admission confirmed message (ACF) after making sure the inter-cluster call can be made using H.323 version 2 protocol. Once this happens, the audio path is made using the RTP protocol between Cisco IP Phones in different clusters.

Call Flow Traces

This section discusses the call flow using SDI trace examples captured in the CCM000000000 file. The traces discussed in this case study focus only on the call flow itself.

In this call flow, a Cisco IP Phone (2002) located in Cluster 2 is calling a Cisco IP Phone (1001) located in Cluster 1. Remember that you can follow a device through the trace by looking at the TCP handle value, time stamp, or name of the device. The TCP handle value for the device remains the same until the device is rebooted or goes offline.

In the following traces, the Cisco IP Phone (2002) has gone off-hook. The trace shows the unique messages, TCP handle, and the calling number, which is displayed on the Cisco IP Phone. The called number (1001), H.225 connect, and H.245 confirm messages can be seen in the following debug output. The codec type is G.711 µ-law.
16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= 
H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06 
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=,  
CallingParty=2002, CalledPartyName=1001, CalledParty=1001, 
tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel 
tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - 
StationOpenReceiveChannelAckID tcpHandle=0x1c64310, Status=0, 
IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, 
port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, 
port = 29626
The calling and called party number, which is associated with an IP address and a hexidecimal value, can be seen in the following traces.
16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission 
tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) 
The following traces show the packet sizes and the MAC address of the Cisco IP Phone (2002). These traces are followed by the disconnect, then on-hook messages.
RemoteRtpPortNumber: 29626 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link 
to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel 
tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission 
tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:16.531 CCM|In  Message -- H225ReleaseCompleteMsg -- Protocol= 
H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90 
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06 
16:06:16.531 CCM|Locations:Orig=1 BW=64	Dest=0 BW=-1 (-1 implies 
infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession 
sending disconnect to (64,2) and remove connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all 
disconnect replies, forwarding a reply for party1(16777219) and 
party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing 
MediaManager(2) from connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID 
tcpHandle=0x1c64310
Failed Call Flow

The following section describes an unsuccessful inter-cluster call flow, as seen in the SDI trace. In the traces below, the Cisco IP Phone (1001) has gone off-hook. A TCP handle is assigned to the Cisco IP Phone.
16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText 
tcpHandle=0x4fbbc30, Display= 1001        
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line 
instance=1 lampMode=LampOn tcpHandle=0x4fbbc30
In the following traces, the user is dialing the called number (2000) of the Cisco IP Phone, and the process of digit analysis is trying to match the number.
16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="")
16:05:33.484 CCM|Digit analysis: 
potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="2")
16:05:35.921 CCM|Digit 
analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="20")
16:05:36.437 CCM|Digit 
analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="200")
16:05:36.656 CCM|Digit 
analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="2000")
The digit analysis has now been completed and the results are shown in the following traces. It is important to note that the PotentialMatches=NoPotentialMatchesExist reference below indicates that the Cisco CallManager is unable to match this directory number. Finally a reorder tone is sent to the calling party (1001), which is followed by an on-hook message.
16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo 
CallingPartyName=1001,  CallingParty=1001, CalledPartyName=, 
CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone 
tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID 
tcpHandle=0x4fbbc30

	Troubleshooting Guide for Cisco CallManager, Release 3.1(1)
	Troubleshooting Inter-Cluster Calls
Troubleshooting Guide for Cisco CallManager, Release 3.1(1) Index Preface Overview Troubleshooting and Monitoring Tools and Utilities Diagnosing Cisco CallManager Problems Troubleshooting Intra-Cluster Phone Calls Troubleshooting Cisco IP Phone-to-Cisco IOS Gateway Calls Troubleshooting Inter-Cluster Calls Call Detail and Call Management Records Glossary	Download this chapter Troubleshooting Inter-Cluster Calls Download the complete book A PDF Version of Entire Book (PDF - 1 MB) Feedback Table Of Contents Troubleshooting Inter-Cluster Calls Sample Topology Inter-Cluster H.323 Communication Call Flow Traces Failed Call Flow Troubleshooting Inter-Cluster Calls The case study in this appendix examines a Cisco IP Phone calling another Cisco IP Phone located in a different cluster. This type of call is also known as an inter-cluster Cisco IP Phone call. This appendix contains the following topics: •Sample Topology •Inter-Cluster H.323 Communication •Call Flow Traces •Failed Call Flow Sample Topology The following is the sample topology used in this case study. There are two clusters, each having two Cisco CallManagers. There are also Cisco IOS Gateways and a Cisco IOS Gatekeeper in place. Inter-Cluster H.323 Communication The Cisco IP Phone in Cluster 1 is making a call to the Cisco IP Phone in Cluster 2. Inter-cluster Cisco CallManager communication takes place using the H.323 Version 2 protocol. There is also a Cisco IOS Gatekeeper for admission control. The Cisco IP Phone can talk to the Cisco CallManager via Skinny Station protocol, and the Cisco CallManager can talk with the Cisco IOS Gatekeeper using the H.323 Remote Access Server (RAS) protocol. The admission request message (ARQ) is sent to the Cisco IOS Gatekeeper, which sends the admission confirmed message (ACF) after making sure the inter-cluster call can be made using H.323 version 2 protocol. Once this happens, the audio path is made using the RTP protocol between Cisco IP Phones in different clusters. Call Flow Traces This section discusses the call flow using SDI trace examples captured in the CCM000000000 file. The traces discussed in this case study focus only on the call flow itself. In this call flow, a Cisco IP Phone (2002) located in Cluster 2 is calling a Cisco IP Phone (1001) located in Cluster 1. Remember that you can follow a device through the trace by looking at the TCP handle value, time stamp, or name of the device. The TCP handle value for the device remains the same until the device is rebooted or goes offline. In the following traces, the Cisco IP Phone (2002) has gone off-hook. The trace shows the unique messages, TCP handle, and the calling number, which is displayed on the Cisco IP Phone. The called number (1001), H.225 connect, and H.245 confirm messages can be seen in the following debug output. The codec type is G.711 µ-law. 16:06:13.921 CCM\|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310 16:06:13.953 CCM\|Out Message -- H225ConnectMsg -- Protocol= H225Protocol 16:06:13.953 CCM\|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06 16:06:13.953 CCM\|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310 16:06:14.015 CCM\|H245Interface(2) OLC indication chan number = 2 16:06:14.015 CCM\|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231) 16:06:14.015 CCM\|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k 16:06:14.062 CCM\|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310, Status=0, IpAddr=0xe74610ac, Port=20444, PartyID=2 16:06:14.062 CCM\|H245Interface(2) paths established ip = e74610ac, port = 20444 16:06:14.187 CCM\|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626 The calling and called party number, which is associated with an IP address and a hexidecimal value, can be seen in the following traces. 16:06:14.187 CCM\|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231) 16:06:14.187 CCM\|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) The following traces show the packet sizes and the MAC address of the Cisco IP Phone (2002). These traces are followed by the disconnect, then on-hook messages. RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k 16:06:16.515 CCM\| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1 16:06:16.515 CCM\|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231) 16:06:16.515 CCM\|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231) 16:06:16.531 CCM\|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol 16:06:16.531 CCM\|Ie - Q931CauseIe -- IEData= 08 02 80 90 16:06:16.531 CCM\|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06 16:06:16.531 CCM\|Locations:Orig=1 BW=64 Dest=0 BW=-1 (-1 implies infinite bw available) 16:06:16.531 CCM\|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to (64,2) and remove connection from list 16:06:16.531 CCM\|MediaManager - wait_AuDisconnectReply - received all disconnect replies, forwarding a reply for party1(16777219) and party2(16777220) 16:06:16.531 CCM\|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2) from connection list 16:06:16.734 CCM\|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310 Failed Call Flow The following section describes an unsuccessful inter-cluster call flow, as seen in the SDI trace. In the traces below, the Cisco IP Phone (1001) has gone off-hook. A TCP handle is assigned to the Cisco IP Phone. 16:05:33.468 CCM\|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30 16:05:33.468 CCM\|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001 16:05:33.484 CCM\|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn tcpHandle=0x4fbbc30 In the following traces, the user is dialing the called number (2000) of the Cisco IP Phone, and the process of digit analysis is trying to match the number. 16:05:33.484 CCM\|Digit analysis: match(fqcn="", cn="1001", pss="", dd="") 16:05:33.484 CCM\|Digit analysis: potentialMatches=PotentialMatchesExist 16:05:35.921 CCM\|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2") 16:05:35.921 CCM\|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist 16:05:36.437 CCM\|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20") 16:05:36.437 CCM\|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist 16:05:36.656 CCM\|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200") 16:05:36.656 CCM\|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist 16:05:36.812 CCM\|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000") The digit analysis has now been completed and the results are shown in the following traces. It is important to note that the PotentialMatches=NoPotentialMatchesExist reference below indicates that the Cisco CallManager is unable to match this directory number. Finally a reorder tone is sent to the calling party (1001), which is followed by an on-hook message. 16:05:36.812 CCM\|Digit analysis: analysis results 16:05:36.812 CCM\|\|PretransformCallingPartyNumber=1001 \|CallingPartyNumber=1001 \|DialingPattern=2XXX \|DialingRoutePatternRegularExpression=(2XXX) \|PotentialMatches=NoPotentialMatchesExist \|CollectedDigits=2000 16:05:36.828 CCM\|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, CalledPartyName=, CalledParty=2000, tcpHandle=0x4fbbc30 16:05:36.828 CCM\|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30 16:05:37.953 CCM\|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks