Unsuccessful call to the PSTN via the Cisco 5400 (H323) gateway due to incoming dial-peer 0

Good afternoon,

Today I happened to be convinced once again in practice how it is important to understand the principles of call routing in Cisco voice gateways. One of my students had the following problem: he was performing a new installation of CUCM at a customer side and then connecting the CUCM to the PSTM via the Cisco 5400 voice gateway. To begin with, he decided to test the connection to PSTN, and, therefore, call routing on the CUCM was configured. On the gateway, the minimal dial-peer configuration was performed.

However, when trying to call the PSTN, the connection was not established. Debug isdn q931 was started on the gateway to determine the reason for the call release.

Here is what the debug showed:

*Jul 30 14:01:31.837: ISDN Se7/1:15 Q931: TX -> SETUP pd = 8  callref = 0x0088
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Calling Party Number i = 0x2081, '8612301501'
                Plan:Unknown, Type:National
        Called Party Number i = 0xC0, '217770'
                Plan:Unknown, Type:Subscriber(local)
*Jul 30 14:01:31.913: ISDN Se7/1:15 Q931: RX <- CALL_PROC pd = 8  callref = 0x8088
        Channel ID i = 0xA98381
                Exclusive, Channel 1
*Jul 30 14:01:32.001: ISDN Se7/1:15 Q931: RX <- ALERTING pd = 8  callref = 0x8088
        Progress Ind i = 0x8282 - Destination address is non-ISDN
*Jul 30 14:01:32.013: ISDN Se7/1:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x0088
        Cause i = 0x80AC - Requested circuit/channel not available
*Jul 30 14:01:32.201: ISDN Se7/1:15 Q931: RX <- RELEASE pd = 8  callref = 0x8088
        Cause i = 0x80AC - Requested circuit/channel not available
*Jul 30 14:01:32.201: ISDN Se7/1:15 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x0088

The reason of the call release was Requested circuit/channel not available (typically this is indicated with Cause 44 or Cause 172). It would seem to be a typical situation when calling to a remote side thorugh E1 link that does not have all 30 time slots programmed. This is what happens if the call is released by the remote party. However, in this case, the call is declined by the Cisco gateway! (pay attention to the direction of the signal Disconnect - TX!). A quite logical question arises - why is this gateway, occupying and choosing time slot 1 for establishing a connection, suddenly reports that the channel is unavailable ???

To find out the reason for this behavior, I recommended that my student to do additional debugs - debug cch323 h225 and debug voip ccapi inout. These debugs should find out if the call manager did not reject the call, and if not, why there was a call release on the gateway. Here are some of the debugs we did:

*Jul 30 15:02:22.500: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN
*Jul 30 15:02:22.500: //-1/xxxxxxxxxxxx/H323/setup_ind: Entry

...... (truncated)

*Jul 30 15:02:22.500: //31/006CDFA50D00/H323/setup_ind: Call Manager detected
*Jul 30 15:02:22.500: //31/006CDFA50D00/H323/cch323_h225_receiver: SETUPIND_CHOSEN: src address = 10.30.25.99; dest address = 10.30.25.100
*Jul 30 15:02:22.500: //31/006CDFA50D00/H323/run_h225_sm: Received event H225_EV_SETUP_IND while at state H225_IDLE

.......(truncated)

*Jul 30 15:02:22.504: //-1/006CDFA50D00/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x65FE2A3C, Call Info(
   Calling Number=8612301501,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
   Called Number=217770(TON=Unknown, NPI=Unknown),
   Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=0, Progress Indication=NULL(0), Calling IE Present=TRUE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=31
*Jul 30 15:02:22.504: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

It can be seen that to route the call, the gateway selects the default dial-peer 0 as the inbound dial-peer! However, the 53XX, 54XX, and 58XX series of Cisco voice gateways do not set up voice calls if the default dial-peer 0 is selected. These series of the voice gateways require the use of any other inbound dial-peer than the dial-peer 0. Therefore, the gateway stopped attempting to establish a connection after sending a Setup message to the PSTN and raised a Disconnect message with Cause 172 (0x80AC).

*Jul 30 15:02:22.696: //32/006CDFA50D00/CCAPI/ccCallDisconnect:
   Cause Value=172, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=172)
*Jul 30 15:02:22.696: //32/006CDFA50D00/CCAPI/ccCallDisconnect:
   Cause Value=172, Call Entry(Responsed=TRUE, Cause Value=172)
*Jul 30 15:02:22.696: ISDN Se7/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x008F
        Cause i = 0x80AC - Requested circuit/channel not available

Dial-peer 0 was selected by the voice gateway due to dial-peers misconfiguration. In this gateway, only two dial-peers were configured:

dial-peer voice 10 pots
 trunkgroup tg_PSTN
 description TEST_OUTBOUND_214000
 translation-profile outgoing NATIONAL
 destination-pattern 21....
 forward-digits all
!
dial-peer voice 20 voip
 description TEST_INBOUND_301501
 preference 1
 destination-pattern 301501
 voice-class codec 1
 session target ipv4:10.30.25.101

The dial-peer 10 could not be selected as an inbound dial-peer, since the call came to the gateway from the CUCM, and the type of this dial-peer was pots (the calls from the CUCM requires voip dial-peers to be configured on the voice gateway). The dial-peer 20 (voip) did not satisfy any of the 3 inbound dial-peer selection rules:

- parameters incoming called-number and answer-address were not configured at all;

- the destination-pattern parameter wildcard does not match the calling number (from the debug it is clearly seen that the Calling Number is 8612301501).

To fix this problem, I recommended to configure correctly the selection of the inbound dial-peer. Inbound dial-peer selection by incoming called-number criteria  was configured here:

dial-peer voice 30 voip
 description test_from_cucm_to_pstn
 incoming called-number [2-79].....
 codec g711alaw

After that, the calls from the CUCM to the PSTN became successful.