Troubleshooting Guide for Cisco CallManager, Release 3.3(3) - Case Study: Troubleshooting Intercluster Phone Calls [Cisco Unified Communications Manager (CallManager)]

Table Of Contents

Case Study: Troubleshooting Intercluster Phone Calls

Sample Topology

Intercluster H.323 Communication

Call Flow Traces

Failed Call Flow

Case Study: Troubleshooting Intercluster Phone Calls

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

This appendix contains the following topics:

•Sample Topology

•Intercluster H.323 Communication

•Call Flow Traces

•Failed Call Flow

Sample Topology

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

Intercluster H.323 Communication

The Cisco IP Phone in Cluster 1 makes a call to the Cisco IP Phone in Cluster 2. Intercluster Cisco CallManager communication takes place using the H.323 Version 2 protocol. A Cisco IOS Gatekeeper also serves for admission control.

The Cisco IP Phone can connect to the Cisco CallManager via Skinny Station protocol, and the Cisco CallManager can connect with the Cisco IOS Gatekeeper by using the H.323 Registration, Admission, and Status (RAS) protocol. The admission request message (ARQ) gets sent to the Cisco IOS Gatekeeper, which sends the admission confirmed message (ACF) after making sure the intercluster call can be made using H.323 version 2 protocol. Once this happens, the audio path gets made by using the RTP protocol between Cisco IP Phones in different clusters.

Call Flow Traces

This section discusses the call flow by 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 displays on the Cisco IP Phone. The following debug output shows the called number (1001), H.225 connect, and H.245 confirm messages. The codec type is G.711 mu-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 following traces show the calling and called party number, which associates with an IP address and a hexidecimal value.
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). The disconnect, then on-hook messages, follow these traces.
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 intercluster call flow, as seen in the SDI trace. In the following traces, the Cisco IP Phone (1001) goes off hook. A TCP handle gets 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 dials the called number (2000) of the Cisco IP Phone, and the process of digit analysis tries 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 completed, and the results appear in the following traces. It is important to note that the following PotentialMatches=NoPotentialMatchesExist reference indicates that the Cisco CallManager cannot match this directory number. Finally, a reorder tone gets 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.3(3)
	Case Study: Troubleshooting Intercluster Phone Calls
Troubleshooting Guide for Cisco CallManager, Release 3.3(3) Index Preface Troubleshooting Overview Troubleshooting Tools Installation, Backup, and Restore Issues Cisco CallManager System Issues Directory Issues Device Issues Dial Plans and Routing Issues Cisco CallManager Services Issues Voice Messaging Issues Opening a Case With TAC Case Study: Troubleshooting Intracluster Phone Calls Case Study: Troubleshooting Cisco IP Phone-to-Cisco IOS Gateway Calls Case Study: Troubleshooting Intercluster Phone Calls	Download this chapter Case Study: Troubleshooting Intercluster Phone Calls Download the complete book PDF of the entire book (PDF - 2 MB) Feedback Table Of Contents Case Study: Troubleshooting Intercluster Phone Calls Sample Topology Intercluster H.323 Communication Call Flow Traces Failed Call Flow Case Study: Troubleshooting Intercluster Phone Calls The case study in this appendix examines a Cisco IP Phone that is calling another Cisco IP Phone that is located in a different cluster. This type of call is also known as an intercluster Cisco IP Phone call. This appendix contains the following topics: •Sample Topology •Intercluster H.323 Communication •Call Flow Traces •Failed Call Flow Sample Topology The following sample topology gets used in this case study. Two clusters, each having two Cisco CallManagers, and also Cisco IOS Gateways and a Cisco IOS Gatekeeper are in place. Intercluster H.323 Communication The Cisco IP Phone in Cluster 1 makes a call to the Cisco IP Phone in Cluster 2. Intercluster Cisco CallManager communication takes place using the H.323 Version 2 protocol. A Cisco IOS Gatekeeper also serves for admission control. The Cisco IP Phone can connect to the Cisco CallManager via Skinny Station protocol, and the Cisco CallManager can connect with the Cisco IOS Gatekeeper by using the H.323 Registration, Admission, and Status (RAS) protocol. The admission request message (ARQ) gets sent to the Cisco IOS Gatekeeper, which sends the admission confirmed message (ACF) after making sure the intercluster call can be made using H.323 version 2 protocol. Once this happens, the audio path gets made by using the RTP protocol between Cisco IP Phones in different clusters. Call Flow Traces This section discusses the call flow by 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 displays on the Cisco IP Phone. The following debug output shows the called number (1001), H.225 connect, and H.245 confirm messages. The codec type is G.711 mu-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 following traces show the calling and called party number, which associates with an IP address and a hexidecimal value. 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). The disconnect, then on-hook messages, follow these traces. 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 intercluster call flow, as seen in the SDI trace. In the following traces, the Cisco IP Phone (1001) goes off hook. A TCP handle gets 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 dials the called number (2000) of the Cisco IP Phone, and the process of digit analysis tries 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 completed, and the results appear in the following traces. It is important to note that the following PotentialMatches=NoPotentialMatchesExist reference indicates that the Cisco CallManager cannot match this directory number. Finally, a reorder tone gets 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