CUCM 7: Dial out to PSTN gives busy

[csshenoy80]

Hi

I am configuring H323 GW with CUCM7. Have the required gateway configuration with dial-peer pots:

dial-peer voice 100 pots

destination-patter 9T

direct-inward-dial

Port 0/1/0:15

Also have the Route pattern configured for international 9.00!.

The isdn q931 gives the below message:

*May 31 11:47:09.336: ISDN Se0/1/0:15 Q931: Applying typeplan for sw-type 0x12 i

s 0x0 0x0, Calling num 0XXXXXXXXXXX

*May 31 11:47:09.340: ISDN Se0/1/0:15 Q931: Applying typeplan for sw-type 0x12 i

s 0x0 0x0, Called num 00YYYYYYYYYYYYY

*May 31 11:47:09.340: ISDN Se0/1/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0136

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 = 0x0081, '0xxxxxxxxxx'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '00yyyyyyyyyyyyy'

Plan:Unknown, Type:Unknown

*May 31 11:47:09.524: ISDN Se0/1/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0x

8136

Channel ID i = 0xA98381

Exclusive, Channel 1

Progress Ind i = 0x8288 - In-band info or appropriate now available

*May 31 11:47:09.552: ISDN Se0/1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0

x0136

Cause i = 0x80AC - Requested circuit/channel not available

*May 31 11:47:09.700: ISDN Se0/1/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x81

36

*May 31 11:47:09.704: ISDN Se0/1/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref =

0x0136

Kindly suggest.

[Ayodeji Okanlawon]

Your xlue is a bit awkward and thats why its noit matching on the dialled number.

Try and configure rule for /222088/ /2088/

specifically and then test again or change the the rule 222... to be the first rule.

[csshenoy80]

ok, let me try this out. As well, we would need to have a translation rule on ccm to convert 222088 to 2088?

Would it be a better idea to ask the ISP to send 4digits instead of 6?

Kindly suggest.

[Ayodeji Okanlawon]

You can set significant digits on CCM to 4.

That way CCM will strip 222088 down to 2088. But you will need to change your dial-peer to 222... instead of 2...

[paolo bevilacqua]

I don't think this has to do with telco or translation rules.

Router is disconneting the call without apparent reason and without eany error from telco:

*May 31 11:47:09.552: ISDN Se0/1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0

x0136

Cause i = 0x80AC - Requested circuit/channel not available

I'm not sure why this happens but it should be a CCM issue.

[Ayodeji Okanlawon]

Paolo,

did you go through this debug..

*May 31 17:53:44.091: //-1/D136EACF803C/CCAPI/cc_api_display_ie_subfields:

cc_api_call_setup_ind_common:

cisco-username=

----- ccCallInfo IE subfields -----

cisco-ani=

cisco-anitype=0

cisco-aniplan=0

cisco-anipi=0

cisco-anisi=0

dest=222088

cisco-desttype=0

cisco-destplan=1

cisco-rdie=FFFFFFFF

cisco-rdn=

cisco-rdntype=-1

cisco-rdnplan=-1

cisco-rdnpi=-1

cisco-rdnsi=-1

cisco-redirectreason=-1 fwd_final_type =0

final_redirectNumber =

hunt_group_timeout =0

*May 31 17:53:44.091: //-1/D136EACF803C/CCAPI/cc_api_call_setup_ind_common:

Interface=0x68742DF8, Call Info(

Calling Number=,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Scree

ned, Presentation=Allowed),

Called Number=222088(TON=Unknown, NPI=ISDN),

Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFl

ag=TRUE,

Incoming Dial-peer=3, Progress Indication=NULL(0), Calling IE Present=FALSE,

Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALS

E), Call Id=-1

*May 31 17:53:44.091: //-1/D136EACF803C/CCAPI/ccCheckClipClir:

In: Calling Number=(TON=Unknown, NPI=Unknown, Screening=Not Screened, Present

ation=Allowed)

*May 31 17:53:44.095: //-1/D136EACF803C/CCAPI/ccCheckClipClir:

Out: Calling Number=(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presen

tation=Allowed)

*May 31 17:53:44.095: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

*May 31 17:53:44.095: :cc_get_feature_vsa malloc success

*May 31 17:53:44.095: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

*May 31 17:53:44.095: cc_get_feature_vsa count is 1

*May 31 17:53:44.095: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

*May 31 17:53:44.095: :FEATURE_VSA attributes are: feature_name:0,fearture_time:

1752068072,feature_id:136

*May 31 17:53:44.095: //136/D136EACF803C/CCAPI/cc_api_call_setup_ind_common:

Set Up Event Sent;

Call Info(Calling Number=(TON=Unknown, NPI=Unknown, Screening=Not Screened, P

resentation=Allowed),

Called Number=222088(TON=Unknown, NPI=ISDN))

*May 31 17:53:44.095: //136/D136EACF803C/CCAPI/cc_process_call_setup_ind:

Event=0x686F6B18

*May 31 17:53:44.095: //136/D136EACF803C/CCAPI/ccCallSetContext:

Context=0x68C05D4C

*May 31 17:53:44.095: //136/D136EACF803C/CCAPI/cc_process_call_setup_ind:

>>>>CCAPI handed cid 136 with tag 3 to app "_ManagedAppProcess_Default"

*May 31 17:53:44.095: //136/D136EACF803C/CCAPI/ccCallProceeding:

Progress Indication=NULL(0)

*May 31 17:53:44.099: //136/D136EACF803C/CCAPI/ccCallDisconnect:

Cause Value=1, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Ca

use=0)

*May 31 17:53:44.099: //136/D136EACF803C/CCAPI/ccCallDisconnect:

Cause Value=1, Call Entry(Responsed=TRUE, Cause Value=1)

*May 31 17:53:44.099: //136/D136EACF803C/CCAPI/cc_api_get_transfer_info:

Transfer Number Is Null

*May 31 17:53:44.279: //136/D136EACF803C/CCAPI/cc_api_call_disconnect_done:

Disposition=0, Interface=0x68742DF8, Tag=0x0, Call Id=136,

Call Entry(Disconnect Cause=1, Voice Class Cause Code=0, Retry Count=0)

*May 31 17:53:44.279: //136/D136EACF803C/CCAPI/cc_api_call_disconnect_done:

Call Disconnect Event Sent

*May 31 17:53:44.279: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

*May 31 17:53:44.279: :cc_free_feature_vsa freeing 686E6FE0

*May 31 17:53:44.279: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

*May 31 17:53:44.279: vsacount in free is 0

The cause code is

May 31 17:53:44.279: //136/D136EACF803C/CCAPI/cc_api_call_disconnect_done:

Disposition=0, Interface=0x68742DF8, Tag=0x0, Call Id=136,

Call Entry(Disconnect Cause=1, Voice Class Cause Code=0, Retry Count=0)

*May 31 17:53:44.279: //136/D136EACF803C/CCAPI/cc_api_call_disconnect_done:

Call Disconnect Event Sent

The debug output shows that the number called is not been translated hence the VG does not have a dial-peer to route the call to CCM. So its not even CCM, its the gateway....

[paolo bevilacqua]

I did not go trough the debug.

The initial q.931 debusg shows an outgoing call, for which the outgoing pots DP is OK.

So, the OP should clarify if he has problems for incoming, outgoing or both calls.

And should then produce the combined output of debug q931 and ccapi, to correlate events.

[paolo bevilacqua]

In my experience, 00 (or 011 in NA) followed by contry code and number, plan/type unknown, is always accepted for international calls.

[csshenoy80]

I found out the issue, it was a route pattern issue as well as the dial-peer config. Made changes on Route pattern to have the discard digits - Predot and on dial-peer pots, made the destination pattern as .T instead of 9T. This solved the outgoing international call issue.

With regard to the Incoming DID call, I created a new dial-peer voip for the path from voice gateway to call manager for the pattern 2..., its working fine now with the same old translation pattern.

Thank you guys for all the help.