Solved: Re: Call to PSTN rejected disconnect cause 21 - Page 3

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

Even . · ‎10-04-2013

Hi Jagpreet,

Thanks for the response.

When this issue happen, the endpoint (gateway) was not down and working well, i don't know why there is no TCP session to the gateway..

There are 12 servers in this cluster. 1 server as pubs, 6 servers as subs (handle call processing), 5 servers as moh&tftp.

i can't find working call's trace on that day when this issue happened, but i attached today's working call's trace (after call manager service restart) but with different calling number that has same css and partition (53319 instead of 54132).

Thanks,

Even

Even . · ‎10-06-2013

Hi Jagpreet and all,

any update? or do i need to open TAC case to ensure this issue is a bug on cucm 8.6.2 SU3 ?

Thanks,

Even

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

Even . · ‎10-07-2013

Dear Jagpreet,

Thank you very much for your big help. I appreciate it very much.

Now i will open a TAC case to make sure it is a bug issue.

Dear All,

Thank you very much for your attention and help.

Thanks,

Even

sandip.khandekar · ‎11-27-2017

Hi

we have configured h323 gatway.

when i call 3175 Ip Phone to other pstn 61871111 is working but another number 61871321 1324 etc and 63200192 is not going .

Humza Khan · ‎11-12-2015

Hi Ayodeji,

These commands works for me, thank for sharing.

https://supportforums.cisco.com/discussion/12691686/pri-call-forwarding-issue

Above disccusion issue resolved by these trusted list commands.

Thank you so much.

Regards,

HK

Ayodeji Okanlawon · ‎11-12-2015

Hi Humza,

Glad it helped you. You didn't rate the post though. Please give it some stars :)

Please rate all useful posts

mitchell.bumgarner · ‎06-28-2018

This was extremely helpful! I was trying to test a gateway that is still technically being used by an older 8.6.2 cluster, so I simply added a dial peer. However, all others were H.323, and this was one of the few SIP connected gateways on the 8.6.2 cluster. All others were H.323 so when I was sending generic SIP messages, calls went through fine without changing too much. However, on this single SIP gateway, no matter what I would send to the gateway I would get Fast Busy, because the IP trust list. Great catch, Ayodeji! Thank you!

If this is helpful to someone else, one thing that should have pointed it out to me sooner would have been the "debug voice ccapi" output. See Below:

*Jun 28 22:24:24.800: //811585/CE919D800000/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 811585 with tag 100 to app "_ManagedAppProcess_TOLLFRAUD_APP"
*Jun 28 22:24:24.800: //811585/CE919D800000/CCAPI/ccCallDisconnect:
Cause Value=21, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

The "_ManagedAppProcess_TOLLFRAUD_APP" seems to indicate that it matched Toll Fraud. It didn't click in my head until Ayodeji stated that above. Thanks again!

AbidKhan34652 · ‎01-14-2021

Hi All,

i want to link EXT no with Mobile No,

For Example: From any IP Phone i Dial #Extension (#1001) and it should ring on Cell Phone no.

Thanks.

Roger Kallberg · ‎01-14-2021

Word of advice. Please post your question in a new post instead of asking a completely none related question on an old post that's also is marked as answered. Your chances of getting help would be much bigger then.

What you ask about is called Mobile Connect or Single Number Reach (SNR). Do a search for this on the community or on your favorite search engine and you surely will find plenty of information.