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 ???
*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:
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
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.
Спасибо за статью!
Такая же ситуация была у меня при схеме CUCM7-Gatekeeper-Cisco2821(VGW). Добавил входящий dial-peer voip и все заработало!