CUCM 7: Dial out to PSTN gives busy

Unanswered Question
May 31st, 2009

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (2 ratings)
Loading.
csshenoy80 Sun, 05/31/2009 - 07:09

Cisco IOS Software, 3800 Software (C3845-ADVENTERPRISEK9-M), Version 12.4(11)XJ4

, RELEASE SOFTWARE (fc2)

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

Paolo Bevilacqua Sun, 05/31/2009 - 07:33

That should not happen. Perhaps is related o something on the h.323 side, check with "debug ccapi all".

csshenoy80 Sun, 05/31/2009 - 07:44

the debug ccapi all is not supported on the cisco router. Any other config / debug which need to be checked.

csshenoy80 Sun, 05/31/2009 - 07:57

it has "debug voip ccapi", also, I am able to dial out local numbers, only international numbers are giving me busy tone.

The international numbers get dialed out using the "csim start" command.

I have checked the route patterns and they seem to be fine.

Please suggest.

Jaime Valencia Sun, 05/31/2009 - 08:50

Exactly what is telco expecting for these values:

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

Plan:Unknown, Type:Unknown

leading 00s?

no 00s but international?

00s + unknown?

00s + national?

If u don't know call your telco, many expect a combination of parameters to allow the calls

HTH

java

if this helps, please rate

csshenoy80 Sun, 05/31/2009 - 09:00

BT is the telco. As well, I have configured the DID.

The telco is sending 6 digits on the gateway. On CUCM H323 Gateway, I have configured the significant digits as 4, with CSS which has access to the IP Phone partitions, but when i dial the DID number form PSTN, I get the announcement, number not in use. As well, from q931 debug, i get the message , unallocated number.

Please suggest.

Ayodeji oladipo... Sun, 05/31/2009 - 09:35

Un allocated number is usually a CSS/partiton problem

two things

1. Check the CSS on your gateway that it has the partition of the Phones in it.

2. Post the output of your debug voip ccapi inout here..

If you are using h.323, you need to check your dial-peer config. You can post that here too and I can have a look

csshenoy80 Sun, 05/31/2009 - 10:13

The css on gw has the access to ip phone partiton.

attached is the ccapi debug for DID incoming call, in which the call failed.

I tried with translation pattern as well with all 6 digits coming form the service provider, it didn't help either.

Please suggest.

Attachment: 
Ayodeji oladipo... Sun, 05/31/2009 - 10:29

Ok..So here is your problem...

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

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)

from the debug..the number called is 222088...The debug shows that there is no dial-peer for this pattern.

You need to have two call legs. In the debug we can only see the incoming dial-peer, we did not see the outgoing dial-peer which the gateway will use to route the call to callmanager.

What is the extension of the phone you are trying to reach? is it 222088?

Can you post your sh run here?

csshenoy80 Sun, 05/31/2009 - 11:00

please find the sh run below:

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

Building configuration...

Current configuration : 2692 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname TESTRTR

!

boot-start-marker

boot-end-marker

!

card type e1 0 3

enable password ***********

!

no aaa new-model

network-clock-participate wic 3

ip cef

!

!

!

!

!

multilink bundle-name authenticated

!

isdn switch-type primary-net5

voice-card 0

codec complexity high

dspfarm

dsp services dspfarm

!

!

!

voice call disc-pi-off

!

voice service voip

allow-connections h323 to h323

h323

!

!

voice class codec 1

codec preference 1 g711ulaw

codec preference 2 g711alaw

!

!

!

voice class h323 1

h225 timeout tcp establish 3

call start fast

!

!

!

!

!

!

!

!

!

!

voice translation-rule 1

rule 1 /222080/ /8001/

rule 2 /222081/ /8002/

rule 3 /222082/ /8003/

rule 4 /222083/ /8004/

rule 5 /^\(222\)\(...\)/ /2\2/

!

!

voice translation-profile PSTN

translate called 1

!

!

!

!

!

!

username TEST

username TEST1 secret 5 **************************!

!

controller E1 0/3/0

framing NO-CRC4

pri-group timeslots 1-8,16

vlan internal allocation policy ascending

!

!

!

!

!

!

interface GigabitEthernet0/0

ip address X.X.X.X 255.255.255.0

duplex auto

speed auto

media-type rj45

no keepalive

standby 0 ip Y.Y.Y.Y

h323-gateway voip interface

h323-gateway voip bind srcaddr X.X.X.X

!

interface GigabitEthernet0/1

ip address X.X.X.X X.X.X.X

duplex auto

speed auto

media-type rj45

no keepalive

!

interface FastEthernet0/0/0

no ip address

shutdown

duplex auto

speed auto

!

interface FastEthernet0/0/1

no ip address

shutdown

duplex auto

speed auto

!

interface Serial0/3/0:15

no ip address

encapsulation hdlc

isdn switch-type primary-net5

isdn incoming-voice voice

isdn bchan-number-order ascending

no cdp enable

!

!

!

ip http server

no ip http secure-server

!

!

!

!

!

!

!

control-plane

!

!

!

voice-port 0/3/0:15

!

!

!

!

!

dial-peer voice 1 voip

preference 1

destination-pattern 8...

voice-class codec 1

session target ipv4:X.X.X.X

dtmf-relay h245-alphanumeric

no vad

!

dial-peer voice 2 voip

preference 2

destination-pattern 8...

voice-class codec 1

session target ipv4:X.X.X.X

dtmf-relay h245-alphanumeric

no vad

!

dial-peer voice 3 pots

translation-profile incoming PSTN

destination-pattern 9T

incoming called-number .

direct-inward-dial

port 0/3/0:15

!

!

!

!

line con 0

stopbits 1

line aux 0

stopbits 1

line vty 0 4

password ********

login

!

scheduler allocate 20000 1000

!

end

Ayodeji oladipo... Sun, 05/31/2009 - 11:07

Ok,

Your translation rule does not have the pattern for the dialled number.

The dialled number is 222088.

So you need a rule for 222088

csshenoy80 Sun, 05/31/2009 - 11:14

you mean rule to convert 222088 to 2088? I already have the voice translation to convert 222088 to 2088. kindly suggest.

Ayodeji oladipo... Sun, 05/31/2009 - 12:24

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 Sun, 05/31/2009 - 12:30

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 oladipo... Sun, 05/31/2009 - 14:15

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 Sun, 05/31/2009 - 14:16

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 oladipo... Sun, 05/31/2009 - 14:29

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 Sun, 05/31/2009 - 16:05

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 Sun, 05/31/2009 - 16:01

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

csshenoy80 Mon, 06/01/2009 - 11:19

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.

Actions

This Discussion