Solved: Call to PSTN rejected disconnect cause 21 - Page 2

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

Suresh Subramanian · ‎09-29-2013

have you turned on the mask on 'RG_BPN_PSTN' as well?

There are some known issue with RL & its subscription manager in CUCM 8.x and 9.x. that might have caused the issue, I suspect.

Try resetting the RL in case if the issue reoccurs please.

//Suresh Please rate all the useful posts.

Even . · ‎09-30-2013

Yes, i turn on the mask on "RG_BPN_PSTN" as well, and i filled the field "calling party transform mask".

i have tried to reset the RL and call manager service when this problem occured on friday, but the problem still not solved that time, and then i leave it at weekend and try about this problem again today, and it's working well.

i don't know what happen, is this a bug of CM 8.x and 9.x or what?

Thanks,

Even

Even . · ‎09-30-2013

Hi all,

I encountered similar problem just now, i think this problem is about route list issue that told by Suresh before.

The problem is when i call to PSTN, the call manager doesn't throw the call to the voice gateway (there is no log when i debug the router), so the call return fast busy. and i solved it by restart the call manager service on the server that the route list was registered to.

i don't think it is an effective way to always restart service everytime when this problem occurs. it is the second time this problem occurs in a week.

is there any workaround to resolve this issue?

Thanks for your advice.

Thanks,

Even

Nishant Savalia · ‎09-30-2013

Hi Even,

This issue comes when CUCM is unable to select gateway from Route List and the most probable reason is that CUCM doesn't find any gateway under RL due to RL in hung state (though RL will show in registered state).

If you could have taken trace at this time from CUCM then you can see that CUCM will select proper dial-pattern, RL and then will release the call by saying that no device found in RL.

For this issue, instead of restarting call manager services every time you can do following thing:-

1). Create one dummy RG and assosciate that RG to existing RL.

2). Remove original RG from exising RL and save it.

3). Restart RL and again add old RG to same RL.

Regards,

Nishant Savalia

Regards, Nishant Savalia

Even . · ‎09-30-2013

Hi Nishant,

Thanks for the advice.

May i know, what is the root cause of this issue? what is the effect of doing that thing (creating dummy RG and so on)? is it can resolve completely this issue, so i musn't restart call manager service everytime?

fyi, i have 55 route list in my call manager, do i need to do that thing at all of my route list?

Thanks,

Even

Even . · ‎10-02-2013

Hi all,

any advice about this issue?

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

Nishant Savalia · ‎10-02-2013

Hi Even,

The root cause of this issue is difficult to identify unless we can see anything in logs. But may be it's database issue.

How often you are facing this issue? Are you facing this issue for all the RL?

You can create dummy RG and so on if you have issue with 1 or 2 RL issue so that you don't have to restart call manager service but if you have 55 RL and this issue happens with every RL then so far the better solution will be to restart call manager service.

But before that you can do one thing if you have issue with all the RL, like reset all the gateways and RL.

Regards,

Nishant Savalia

Regards, Nishant Savalia

Even . · ‎10-02-2013

Hi Nishant,

Thanks for the info.

when this happen for the first time, all CM database status was in good state (2), but there was an error on Unified CM ONCONFIG.CCM and Unified CM Rhosts at two servers as attached. is it the cause of the problem?

after i restart all the servers, the Unified CM Rhosts is in good state, but the Unified CM ONCONFIG.CCM still error.

i have this issue three times in last 4 days, i don't know if this happen to all of the route list, but yesterday, it was happen in two route list.

i need your advice and suggestion.

Thanks,

Even

Nishant Savalia · ‎10-02-2013

Can you please share that file Rhosts and ONCONFIG.CCM?

Also, please check any of the alerts for "RouteListExhausted" with "Reason=41" in RTMT as mentioned by Jagpreet in last 4 days.

Also check for any kind of fluctuation logs for gateways.

Regards,

Nishant Savalia

Regards, Nishant Savalia

Even . · ‎10-03-2013

Hi Jagpreet and Nishant,

Thanks for the response and info.

in three times that this issue occur, the symptoms are different for each other:

1. first issue, the call hit the gateway, but rejected (cause = 21), from the troubleshooting process, we found that because the external phone number mask was not sent to the gateway (internal extension number was sent instead of masking number), so the call rejected by the provider. solved by restarting RL and CM service.

2. second issue, the call was not hit the gateway at all, solved by restarting RL and CM service.

3. third issue, the call was sent to the second gateway (backup gateway) in the route group instead of the first gateway (RG algorithm top down) and i think the problem solved itself.

i found some error that Jagpreet mention before (RouteListExhausted). You can see the error on some calls, one of them at 15:29 with calling number 54132 and called number 7088808781851

Please find attached trace log file and database file.

any advice?

Thanks,

Even

Jagpreet Barmi · ‎10-03-2013

Even,

I could not find the trace logs attached to your previous post.

If you are referring to the post dated Sep 27, it only contains debugs from the gateway. However, I am looking for the corresponding call manager traces for a failed call when you experienced the issue.

It seems that one of the primary route group stopped routing the call and the call is routed through the other route group in the same route list.

As you mentioned that other groups are configured with "Use Calling Party's External Phone Number Mask" set to Off, the setup was sent with a 5 digit calling number and the provider rejected the call.

If that is the case, I would like to see the reason why the primary route group was unable to process the call.

Also, please mention the reason associated with the RouteListExhausted Alert that you received.

HTH,

Jagpreet Singh Barmi

Even . · ‎10-03-2013

Hi Jagpreet,

Sorry, i forgot to attach the file on the post before. now i already attach the file at that post.

other groups are configured with "Use Calling Party's External Phone Number Mask" set to Off, but i filled the

"calling party transform mask" field, so the call that using that groups will use pre-defined transform mask in that field (not using calling party external phone number mask), so i think this shouldn't be an issue.

The reason for RouteListExhausted is vary for each call, there are three kind of reason, 44 (no circuit channel available), 42 (switching eq congestion), 21 (call rejected)

Thanks,

Even

Even . · ‎10-04-2013

Hi all,

any update?

Thanks,

Even

Jagpreet Barmi · ‎10-04-2013

Hi Even,

There were 3 calls in the trace file that you shared and the behavior was similar in all of them (except the reason code difference for the call failure)

Digit Analysis:

15:29:47.722 |Digit analysis: match(pi="2", fqcn="02157984132", cn="54132",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_SLK:PT_Emergency_JVO_SLK: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_SLK:PT_Emergency_JVO_SLK:PT_Service_MWI:PT_Block_TollPremium:PT_Dummy", dd="7088808781851",dac="0")|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.722 |Digit analysis: analysis results|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.722 ||PretransformCallingPartyNumber=54132

|CallingPartyNumber=54132

|DialingPartition=PT_PSTN_JVO_JAK

|DialingPattern=7.!

|FullyQualifiedCalledPartyNumber=7088808781851

Route list selected is RL_CB_nonlocal_PSTN_JAK which contains two RouteGroups and 4 devices.

The first two devices are considered DOWN (the first RouteGroup) making the entire group down.

15:29:47.724 |RouteListCdrc::null0_CcSetupReq - gets a next group while 2 groups remain. mAttemptPreemptionCurrentRouteFlag = 0|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RouteListCdrc::algorithmCategorization -- CDRC_SERIAL_DISTRIBUTION type=2|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RoutePlanServer::updateStartingIndex - RouteGroupName(4f333393-6e79-b477-c09a-b7351fa1bc95)|*^*^*

15:29:47.724 |RouteListCdrc::whichAction -- DOWN (Current Group) = 1|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RouteListCdrc::routeAction -- current device name=18b5c56f-8251-dd93-6816-49d2d6128fdb, down|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RouteListCdrc::executeRouteAction: SKIP_TO_NEXT_MEMBER|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RouteListCdrc::whichAction -- DOWN (Current Group) = 1|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RouteListCdrc::routeAction -- current device name=04c58b56-2fd2-581c-0861-3ecad08a0cf3, down|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RouteListCdrc::executeRouteAction: SKIP_TO_NEXT_MEMBER|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

So, the call is tried to route from the members of the second route group (namely 146.44.253.69 and 146.44.253.68) which are considered available by CUCM but the call is still rejected.

15:29:47.724 |RouteListCdrc::null0_CcSetupReq - gets a next group while 1 groups remain. mAttemptPreemptionCurrentRouteFlag = 1|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RouteListCdrc::algorithmCategorization -- CDRC_SERIAL_DISTRIBUTION type=2|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.724 |RoutePlanServer::updateStartingIndex - RouteGroupName(6a7b9eb0-4111-a8da-c233-ed5cdda10590)|*^*^*

Name=146.44.253.69 isActive=1 isDualMode=0 Protocol=H.225

15:29:47.725 |RouteListCdrc::routeAction -- current device name=00852359-921c-914d-1bb1-71de2d6bceb7, idle or available |2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.725 |RouteListCdrc::distributeCall ccSetupReq CI=49357427 BRANCH=0|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.725 |RouteListCdrc::executeRouteAction: EXTEND_CALL_TO_CURRENT_MEMBER -- Success|2,100,13,2815.3854^146.44.223.200^SEP0008308B3822

15:29:47.977 |RouteListCdrc::checkQ931CauseCode - configuration is empty|9,100,13,671.4^146.44.253.69^*

15:29:47.978 |RouteListCdrc::null0_CcSetupReq - Selecting a device.|9,100,13,671.4^146.44.253.69^*

15:29:47.978 |SMDMSharedData::findRemoteDeviceAny - Key=2d53b1aa-1b27-4c29-d6f8-5e08c1b3ef68 found in RemoteDeviceInfo hashmap - PID(s)=3 Name=146.44.253.68 isActive=1 isDualMode=0 Protocol=H.225

15:29:47.978 |RouteListCdrc::routeAction -- current device name=2d53b1aa-1b27-4c29-d6f8-5e08c1b3ef68, idle or available |9,100,13,671.4^146.44.253.69^*

15:29:47.978 |RouteListCdrc::distributeCall ccSetupReq CI=49357427 BRANCH=0|9,100,13,671.4^146.44.253.69^*

15:29:47.978 |RouteListCdrc::executeRouteAction: EXTEND_CALL_TO_CURRENT_MEMBER -- Success|9,100,13,671.4^146.44.253.69^*

15:29:54.525 |RouteListCdrc::null0_CcSetupReq - Terminating a call after the RouteListCdrc cannot find any more device.|9,100,13,672.6^146.44.253.68^*

15:29:54.525 |RouteListCdrc::terminateCall - No more Routes in RouteListName = RL_CB_nonlocal_PSTN_JAK. Rejecting the call|9,100,13,672.6^146.44.253.68^*

15:29:54.525 |RouteListCdrc::terminateCall - Sending CcRejInd, with the cause code (42), to RouteListControl because all devices are busy/stopped.

Now, I did not see any H323 message or the TCP session getting established for the H323 gateway in the second route group.

Please check the status of the endpoints in the route group 1. Also, let me know the number of servers in the cluster as we might be missing some singaling in this trace file.

If possible, collect the traces for a working call after the cm service restart to identity the exact difference.

Regards,

Jagpreet Singh Barmi