Call to PSTN rejected disconnect cause 21

[Even .]

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 .]

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 .]

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 · Accepted solution]

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 .]

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]

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]

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]

Hi Humza, 

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

[mitchell.bumgarner]

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]

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]

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.