Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Call to PSTN rejected disconnect cause 21

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

2 ACCEPTED SOLUTIONS

Accepted Solutions
Cisco Employee

Call to PSTN rejected disconnect cause 21

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

Cisco Employee

Call to PSTN rejected disconnect cause 21

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

35 REPLIES
VIP Super Bronze

Call to PSTN rejected disconnect cause 21

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Call to PSTN rejected disconnect cause 21

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

VIP Super Bronze

Call to PSTN rejected disconnect cause 21

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Re: Call to PSTN rejected disconnect cause 21

Please find debug and sh run file in the attachment

calling number 53319

called number 7088808781851

Thanks,

Even

Call to PSTN rejected disconnect cause 21

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.
VIP Super Bronze

Call to PSTN rejected disconnect cause 21

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Re: Call to PSTN rejected disconnect cause 21

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

Call to PSTN rejected disconnect cause 21

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"

Call to PSTN rejected disconnect cause 21

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.
VIP Super Bronze

Call to PSTN rejected disconnect cause 21

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 "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Call to PSTN rejected disconnect cause 21

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

Call to PSTN rejected disconnect cause 21

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

Please rate helpful answers!

Call to PSTN rejected disconnect cause 21

Please check this box.

//Suresh Please rate all the useful posts.
New Member

Call to PSTN rejected disconnect cause 21

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

Call to PSTN rejected disconnect cause 21

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.
New Member

Call to PSTN rejected disconnect cause 21

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

New Member

Call to PSTN rejected disconnect cause 21

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

Call to PSTN rejected disconnect cause 21

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
New Member

Call to PSTN rejected disconnect cause 21

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

New Member

Call to PSTN rejected disconnect cause 21

Hi all,

any advice about this issue?

Thanks,

Even

Cisco Employee

Call to PSTN rejected disconnect cause 21

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

Call to PSTN rejected disconnect cause 21

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
New Member

Call to PSTN rejected disconnect cause 21

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

Call to PSTN rejected disconnect cause 21

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
New Member

Re: Call to PSTN rejected disconnect cause 21

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

Cisco Employee

Call to PSTN rejected disconnect cause 21

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

New Member

Re: Call to PSTN rejected disconnect cause 21

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

New Member

Call to PSTN rejected disconnect cause 21

Hi all,

any update?

Thanks,

Even

Cisco Employee

Call to PSTN rejected disconnect cause 21

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

6853
Views
49
Helpful
35
Replies