Solved: Call to PSTN rejected disconnect cause 21

Even . · ‎09-27-2013

Hi all,

I got some problem here.

I have two call manager cluster (version 6.1.4 and 8.6.2 SU3), both of them connected to a H323 gateway (router 3845 iOS version 12.4.22). When I call to PSTN from 6.1.4 cluster, it works fine, but when I call to PSTN from 8.6.2 cluster, the call is rejected. then I debug the router and got disconnect cause 21.

disconnect cause 21 :

Call Rejected.

Indicates that the equipment sending this cause does not wish to accept this call, alth9ough it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. May also be generated by the network, indicating that the call was cleared due to a supplementary service constraint.

The route pattern and other configuration at both cluster are the same.

Do you guys have any idea about this problem?

Thanks,

Even

Jagpreet Barmi · ‎10-02-2013

Hi Even,

Looking at the the symptoms (call not hitting the gateway and restart of the CM service resolves the issue), you might be hitting the following defect.

CSCtq10477 : Route Group Members being skipped and reporting as device down

In order to confirm, please provide the call manager traces for a failed call.

Alternatively, you can also check if you recieve alerts for "RouteListExhausted" with "Reason=41" in RTMT.

HTH

Jagpreet Singh Barmi

View solution in original post

Jagpreet Barmi · ‎10-06-2013

Hi Even,

I checked the working set of logs after the service restart and could see the call to route out from the first member in the route list using route group (4f333393-6e79-b477-c09a-b7351fa1bc95) which was considered DOWN earlier.

Digit analysis.

16:26:47.775 |Digit analysis: match(pi="2", fqcn="02129946319", cn="53319",plv="5", pss="PT_CTN:PT_Internal_JVO:PT_Internal_KLO:PT_Internal_SMO:PT_Internal_SMO_DRI_PBX:PT_Internal_SMO_RBI_PBX:PT_Internal_SMO_DMI_PBX:PT_PSTN_JVO_JAK:PT_TEHO_DRJ_PB:PT_TEHO_SLK_PB:PT_TEHO_BPN_PB:PT_TEHO_DRI_PB:PT_TEHO_RBI_PB:PT_TEHO_STN_PB:PT_TEHO_MNS_PB:PT_TEHO_DMI_PB:PT_TEHO_DRJ_CB:PT_TEHO_SLK_CB:PT_TEHO_BPN_CB:PT_TEHO_DRI_CB:PT_TEHO_RBI_CB:PT_TEHO_STN_CB:PT_TEHO_MNS_CB:PT_TEHO_DMI_CB:PT_Service_IBU:PT_Service_JVO:PT_Service_JVO_JAK:PT_Emergency_JVO_JAK:PT_Service_MWI:PT_Block_TollPremium:PT_Dummy", TodFilteredPss="PT_CTN:PT_Internal_JVO:PT_Internal_KLO:PT_Internal_SMO:PT_Internal_SMO_DRI_PBX:PT_Internal_SMO_RBI_PBX:PT_Internal_SMO_DMI_PBX:PT_PSTN_JVO_JAK:PT_TEHO_DRJ_PB:PT_TEHO_SLK_PB:PT_TEHO_BPN_PB:PT_TEHO_DRI_PB:PT_TEHO_RBI_PB:PT_TEHO_STN_PB:PT_TEHO_MNS_PB:PT_TEHO_DMI_PB:PT_TEHO_DRJ_CB:PT_TEHO_SLK_CB:PT_TEHO_BPN_CB:PT_TEHO_DRI_CB:PT_TEHO_RBI_CB:PT_TEHO_STN_CB:PT_TEHO_MNS_CB:PT_TEHO_DMI_CB:PT_Service_IBU:PT_Service_JVO:PT_Service_JVO_JAK:PT_Emergency_JVO_JAK:PT_Service_MWI:PT_Block_TollPremium:PT_Dummy", dd="7088808781851",dac="0")|2,100,13,1222.808^146.44.223.202^SEP001EBE918FD1

16:26:47.775 ||PretransformCallingPartyNumber=53319

|CallingPartyNumber=53319

|DialingPartition=PT_PSTN_JVO_JAK

|DialingPattern=7.!

|FullyQualifiedCalledPartyNumber=7088808781851

Route list selected is RL_CB_nonlocal_PSTN_JAK

16:26:47.776 |RouteListControl::idle_CcSetupReq - RouteList(RL_CB_nonlocal_PSTN_JAK), RouteListCdrc::create CI = 36027531 BRANCH = 0 mIsEmccHunt=0|2,100,13,1222.808^146.44.223.202^SEP001EBE918FD1

16:26:47.777 |RoutePlanServer::updateStartingIndex - RouteGroupName(4f333393-6e79-b477-c09a-b7351fa1bc95)|*^*^*

16:26:47.777 |RouteListCdrc::null0_CcSetupReq - Selecting a device.|2,100,13,1222.808^146.44.223.202^SEP001EBE918FD1

16:26:47.777 |SMDMSharedData::findLocalDevice - Name=146.44.254.68 Key=18b5c56f-8251-dd93-6816-49d2d6128fdb isActvie=1 Pid=(2,183,12) found|2,100,13,1222.808^146.44.223.202^SEP001EBE918FD1

16:26:47.777 |RouteListCdrc::select_facility_DmPidRes: Execute a route action.|2,100,13,1222.808^146.44.223.202^SEP001EBE918FD1

16:26:47.777 |RouteListCdrc::routeAction -- current device name=18b5c56f-8251-dd93-6816-49d2d6128fdb, idle or available |2,100,13,1222.808^146.44.223.202^SEP001EBE918FD1

Also, I could see a TCP session being established and the H323 messages were exchanged.

16:26:47.779 |H225Cdpc::requestConnect_TcpStartSessionRes(691, 36027531): TcpStartSessionRes from H225Handler=13|2,100,13,1295.2^*^*

16:26:47.779 |H225Cdpc::handleCcSetupReq(691, 36027531): H225Setup sent to IP=146.44.254.68|2,100,13,1222.808^146.44.223.202^SEP001EBE918FD1

16:26:47.780 |value H323-UserInformation ::= |*^*^*

16:26:47.780 |SPROCRas - {

h323-uu-pdu

{

h323-message-body setup :

{

protocolIdentifier { 0 0 8 2250 0 5 },

sourceAddress

{

h323-ID : {"Helmi Muzammil - 53319", ...}

},

sourceInfo

{

Looking at the symptoms, I believe that we are hitting the defect. However, the reason code doesn't match. You can open a TAC case to get a confirmation.

NOTE: As you pointed out earlier that we are dealing with multiple issues, the TCP session not establishing even with the other end point status as available could be because of something else and analysis of the SDL Traces may provide additional inputs about it.

HTH,

Jagpreet Singh Barmi

View solution in original post

Ayodeji Okanlawon · ‎09-27-2013

This is likely because you dont have the ip address of CUCM8.6 defined in the destination-pattern of your dial-peer..

To solve this please configure this on your gateway and add the ip address of the cucm in your trust list

example below..

conf t

voice service voip

 ip address trusted list
  ipv4 203.0.113.100 255.255.255.255
  ipv4 192.0.2.0 255.255.255.0

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Even . · ‎09-27-2013

Hi Aokanlawon,

Thanks for reply.

The command is not available in the iOS version 12.4.(22)T5.

As i know, that command available in iOS version 15.1(2)T and later

Thanks,

Even

Ayodeji Okanlawon · ‎09-27-2013

Can you please send the ff:

debug voip ccapi inout

sh run

please include calling and called number

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Even . · ‎09-27-2013

Please find debug and sh run file in the attachment

calling number 53319

called number 7088808781851

Thanks,

Even

Suresh Subramanian · ‎09-27-2013

Hi Even,

it seems the call is rejected at out leg by provider. please check with them why they are not accepting the call.

also, it would be good if you provide the debugs for a working call originating from cucm 6.

debug isdn q931 & debug voip ccapi inout for both working & nonworking calls would be helpful.

//Suresh Please rate all the useful posts.

Ayodeji Okanlawon · ‎09-27-2013

Hi,

The call is been disconnected from your Telco. The call is routed using dial-peer 11...and call id 11778 indicates that is the far end that is disconnecting the call...

Sep 27 15:44:36.668 WIB: //11778/80F77D080200/CCAPI/cc_api_call_disconnected:

Cause Value=21, Interface=0x699200BC, Call Id=11778

Sep 27 15:44:36.668 WIB: //11778/80F77D080200/CCAPI/cc_api_call_disconnected:

Call Entry(Responsed=TRUE, Cause Value=21, Retry Count=0)

I suggest you turn on debug isdn q931 to see the isdn negotiation and check why your telco is rejecting the call..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Even . · ‎09-27-2013

Hi Suresh and Aokanlawon,

Thanks for the responses.

But why is it working fine if the call to PSTN come out from cucm 6, and not from cucm 8?

Please find debug voice ccapi inout and isdn q931 for both working & nonworking calls from both cluster.

Regards,

Even

Carlo Poggiarelli · ‎09-27-2013

Hi Even.

I saw in the log that in worknig case you send a 02129946319 and in non working case you are sending only the extension number 53319

Maybe that's the reason why your provider is rejecting the call

In the CUCM Route patter set a calling party trnasform mask as 02129946XXX

HTH

Regards

Carlo

Please rate all helpful posts

"The more you help the more you learn"

Please rate all helpful posts "The more you help the more you learn"

Suresh Subramanian · ‎09-27-2013

Yes Carlo, you are right.

Non Working Call

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

Sep 27 19:18:18.842 WIB: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x012D

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Progress Ind i = 0x8183 - Origination address is non-ISDN

Calling Party Number i = 0x2181, '53319'

Plan:ISDN, Type:National

Called Party Number i = 0x80, '088808781851'

Plan:Unknown, Type:Unknown

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

Working Call

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

Sep 27 19:25:06.324 WIB: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x012E

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Progress Ind i = 0x8183 - Origination address is non-ISDN

Calling Party Number i = 0x2181, '02129946319'

Plan:ISDN, Type:National

Called Party Number i = 0x80, '088808781851'

Plan:Unknown, Type:Unknown

>> the only difference is calling number.

//Suresh Please rate all the useful posts.

Ayodeji Okanlawon · ‎09-27-2013

As everyone has suggested, looks like your telco is rejecting the call due to wron caller ID..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Even . · ‎09-27-2013

Hi all,

Thanks for the response.

In my cucm configuration, my directory number has external phone mask, and in the route pattern -> route list, i had set "use calling party external phone number mask" to "On", so it will use mask from my directory number.

but why the calling number that sent to router still my internal directory number (in this case 53319)?

Is there anything wrong with my configuration above?

Thanks,

Even

Amine Nouasri · ‎09-27-2013

Check Use Calling Party's External Phone Number Mask on the route pattern.

Please rate helpful answers!

Suresh Subramanian · ‎09-27-2013

Please check this box.

//Suresh Please rate all the useful posts.

Even . · ‎09-29-2013

Hi Amine and Suresh,

sorry for late reply.

I don't think "Use Calling Party's External Phone Number Mask" on the route pattern need to be checked, because i have turn it on in the route list detail configuration (Route Group) in the fourth pic above.

i don't set "Use Calling Party's External Phone Number Mask" on the route pattern, because on that pattern, i assigned a route list that contains two route group, one route group's "Use Calling Party's External Phone Number Mask" i set to on, and the others i set it to off, because on the second route group, i using "calling party transform mask" field, so i can't turn it on in the route pattern section.

by the way, i haven't change any configuration but now it working well with existing configuration, i just try to restart the call manager service, i don't know how this can happen? because before this issue, the call to PSTN working well, then suddenly this problem occur without modification in the configuration before, but then again, now it suddenly working well. is there anyone who ever experience this problem before? and what is the cause of this problem?

Regards,

Even