The case study described in Appendix 11, "Case Study: Troubleshooting Cisco Unified IP Phone Calls," describes the call flow for an intracluster call. The case study in this appendix examines a Cisco Unified IP Phone that is calling through a Cisco IOS Gateway to a phone that connects through a local PBX or on the Public Switched Telephone Network (PSTN). Conceptually, when the call reaches the Cisco IOS Gateway, the gateway will forward the call to either a phone that is connected to an FXS port or to the PBX. If the call is forwarded to the PBX, it could terminate to a phone that is connected to a local PBX, or the PBX forwards it over the PSTN, and the call will terminate somewhere on the PSTN.

In this call flow, a Cisco Unified IP Phone (directory number 1001) that is located in cluster 2 calls a phone (directory number 3333) that is located somewhere on the PSTN. 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 off line.

In the following traces, the Cisco Unified IP Phone (1001) went off hook. The trace shows the unique messages, TCP handle, and the calling number, which displays on the Cisco Unified IP Phone. No called number displays at this point, because the user did not try to dial any digits.

In the following traces, the user dials the DN 3333, one digit at a time. The number 3333 specifies the destination number of the phone, which is located somewhere on the PSTN network. The digit analysis process of the Cisco Unified Communications Manager currently active analyzes the digits to discover where the call needs to get routed. Appendix 11, "Case Study: Troubleshooting Cisco Unified IP Phone Calls," provides a more detailed explanation of the digit analysis

In the following traces, the digit analysis completed, calling and called party are matched, and the information was parsed.

|CallingPartyNumber=1001

|DialingPattern=3333

|DialingRoutePatternRegularExpression=(3333)

|PretransformDigitString=3333

|PretransformPositionalMatchList=3333

|CollectedDigits=3333

|PositionalMatchList=3333

In the following traces, the number 0 indicates the originating location, and the number 1 indicates the destination location. BW = -1 determines the bandwidth of the originating location. The value -1 implies that the bandwidth is infinite. The bandwidth gets considered as infinite because the call originated from a Cisco Unified IP Phone that is located in a LAN environment. BW = 64 determines the bandwidth of the destination location. The call destination specifies a phone that is located in a PSTN, and the codec type that is used specifies G.711 (64 Kbps).

The following traces show the calling and called party information. In this example, the calling party name and number remain the same because the administrator did not configure a display name, such as John Smith.

The following trace shows that the H.323 code initialized and is sending an H.225 setup message. You can also see the traditional HDLC SAPI messages, the IP address of the called side in hexidecimal, and the port numbers.

The following trace shows the calling and called party information as well as the H.225 alerting message. The trace also shows is the mapping of a Cisco Unified IP Phone hexidecimal value to the IP address. The IP address of the Cisco Unified IP Phone (1001) specifies 172.16.70.231.

After the H.225 alert message get sent, H.323 initializes H.245. The following trace shows the calling and called party information, and the H.245 messages. The TCP handle value remains the same as before, which indicates that this is the continuation of the same call.

The following message shows that an on-hook message from the Cisco Unified IP Phone (1001) is being received. As soon as an on-hook message is received, the H.225 and Skinny Station device disconnection messages get sent, and the entire H.225 message displays. This final message indicates that the call terminated.

Debug Messages and Show Commands on the Cisco IOS Gatekeeper

The "Call Flow Traces" section covers the Cisco Unified Communications Manager SDI trace in detail. In the topology for this case study, the debug ras command turned on in the Cisco IOS Gatekeeper.

The following debug messages show that the Cisco IOS Gatekeeper is receiving the admission request (ARQ) for the Cisco Unified Communications Manager (172.16.70.228), followed by other successful Remote Access Server (RAS) messages. Finally, the Cisco IOS Gatekeeper sends an admission confirmed (ACF) message to the Cisco Unified Communications Manager.

The following debug messages show that the Cisco IOS Gatekeeper received a disengage request (DRQ) from the Cisco Unified Communications Manager (172.16.70.228), and the Cisco IOS Gatekeeper sent a disengage confirmed (DCF) to the Cisco Unified Communications Manager.

The command show gatekeeper endpoints on the Cisco IOS Gatekeeper shows that all four Cisco Unified Communications Managers are registered with the Cisco IOS Gatekeeper. In the topology for this case study, four Cisco Unified Communications Managers exist, two in each cluster. This Cisco IOS Gatekeeper includes two zones, and each zone includes two Cisco Unified Communications Managers.

R2514-1#show gatekeeper endpoints

GATEKEEPER ENDPOINT REGISTRATION

===================================

CallSignalAddr Port RASSignalAddr Port Zone Name Type

--------------- ----- --------------- ----- --------- ----

172.16.70.228 2 172.16.70.228 1493 gka.cisco.com VOIP-GW

H323-ID: ac1046e4->ac1046f5

172.16.70.229 2 172.16.70.229 3923 gka.cisco.com VOIP-GW

H323-ID: ac1046e5->ac1046f5

172.16.70.245 1 172.16.70.245 1041 gkb.cisco.com VOIP-GW

H323-ID: ac1046f5->ac1046e4

172.16.70.243 1 172.16.70.243 2043 gkb.cisco.com VOIP-GW

H323-ID: ac1046f5->ac1046e4

Total number of active registrations = 4

Debug Messages and Show Commands on the Cisco IOS Gateway

The "Debug Messages and Show Commands on the Cisco IOS Gatekeeper" section discusses the Cisco IOS Gatekeeper show commands and debug outputs were discussed in detail. This section focuses on the debug output and show commands on the Cisco IOS Gateway. In the topology for this case study, calls go through the Cisco IOS Gateways. The Cisco IOS Gateway interfaces to the PSTN or PBX with either T1/CAS or T1/PRI interfaces. The following example shows debug output of commands such as debug voip ccapi inout, debug H225 events, and debug H225 asn1.

In the following debug output, the Cisco IOS Gateway accepts the TCP connection request from Cisco Unified Communications Manager (172.16.70.228) on port 2328 for H.225.

*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].

*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

The following debug output shows that the H.225 data is coming from the Cisco Unified Communications Manager on this TCP session. The protocolIdentifier, which indicates the H.323 version that is being used, displays in this debug output. The following debug shows that H.323 version 2 is being used. The example also shows the called and calling party numbers.

The following debug output shows Call Control Application Programming Interface (CCAPi). Call Control APi indicates an incoming call. You can also see called and calling party information in the following output. CCAPi matches the dial peer 0, which specifies the default dial peer. It matches dial peer 0 because the CCAPi could not find any other dial peer for the calling number, so it uses the default dial peer.

In this packet, Cisco IOS also sends the H.245 address and port number to Cisco Unified Communications Manager. Sometimes, the Cisco IOS Gateway will send the unreachable address, which could cause either no audio or one-way audio.

Cisco IOS Gateway with T1/PRI Interface

As explained earlier, two types of calls go through the Cisco IOS Gateways: the Cisco IOS Gateway interfaces to the PSTN or PBX with either T1/CAS or T1/PRI interfaces. The following example shows the debug outputs when the Cisco IOS Gateways use T1/PRI interface.

The debug isdn q931 command on the Cisco IOS Gateway got turned on, which enables Q.931, a Layer Three signaling protocol for D-channel in the ISDN environment. Each time that a call is placed out of the T1/PRI interface, a setup packet must get sent. The setup packet always includes (protocol descriptor) pd = 8, and it generates a random hexidecimal value for the callref. The callref tracks the call. For example, if two calls are placed, the callref value can determine the call for which the RX (received) message is intended. Bearer capability 0x8890 means a 64-Kbps data call. If it were a 0x8890218F, it would represent a 56-Kbps data call and 0x8090A3 if it is a voice call. In the debug following output, the bearer capability specifies 0x8090A3, which applies for voice. The example shows called and calling party numbers.

The callref uses a different value for the first digit (to differentiate between TX and RX), and the second value stays the same (SETUP had a 0 for the last digit and CONNECT_ACK also has a 0). The router completely depends upon the PSTN or PBX to assign a Bearer channel (B-channel). If the PSTN or PBX does not assign a channel to the router, the call will not get routed. In this case, a CONNECT message that is received from the switch includes the same reference number as was received for ALERTING (0x800B). Finally, you can see the exchange of the DISCONNECT message followed by RELEASE and RELEASE _COMP messages as the call disconnects. A cause ID for the call rejection follows RELEASE_COMP messages. The cause ID represents a hexidecimal value. Find the meaning of the cause by decoding the hexidecimal value and follow up with your provider.

Cisco IOS Gateway with T1/CAS Interface

Two types of calls go through the Cisco IOS Gateways: the Cisco IOS Gateway interface to the PSTN or PBX with either T1/CAS or T1/PRI interfaces. The following debug outputs occur when the Cisco IOS Gateways has T1/CAS interface. The debug cas on the Cisco IOS Gateway was turned on.

The following debug message shows that the Cisco IOS Gateway is sending an off-hook signal to the switch.

Apr 5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111)

The following debug message indicates that the switch is sending wink after receiving the loop closure signal from the Cisco IOS Gateway.

Apr 5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

Apr 5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

The following debug message indicates that the Cisco IOS Gateway is going off hook.

Apr 5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

The following output shows the show call active voice brief on the Cisco IOS Gateway when the call is in progress. The output also shows the called and calling party number and other useful information.