Scenario#43 – CUCM 9.1(2) RL/RG Reject Issue

Few weeks back I came across a issue for a customer who are on CUCM 9.12() cluster.

The issue was outbound calls not reaching either of the MGCP gateways from a Translation pattern even though both gateways were registered fine with Call manager.

I checked the E1s and MGCP status and all was OK. The Route List was reset as well but had no joy. I also did a Reset on MGCP quite few times but had no luck.

During test calls I found this in CCM logs:

93958336.006 |18:10:05.348 |AppInfo  |RouteListCdrc::null0_CcSetupReq – Selecting a device.

93958336.007 |18:10:05.348 |AppInfo  |RouteListCdrc::selectDevices — mTemporaryDeviceInfoList.size = 1.

93958336.008 |18:10:05.348 |AppInfo  |RouteListCdrc::null0_CcSetupReq: Execute a route action.

93958336.009 |18:10:05.348 |AppInfo  |RouteListCdrc::algorithmCategorization — CDRC_SERIAL_DISTRIBUTION type=1

93958336.010 |18:10:05.348 |AppInfo  |RouteListCdrc::whichAction — DOWN (Current Group) = 1

93958336.011 |18:10:05.348 |AppInfo  |RouteListCdrc::routeAction — current device name=a75fd367-37e5-e702-9336-505837d6fc48, down

93958336.012 |18:10:05.348 |AppInfo  |RouteListCdrc::executeRouteAction: SKIP_TO_NEXT_MEMBER

93958336.013 |18:10:05.348 |AppInfo  |RouteListCdrc::skipToNextMember

.

.

.

93958337.005 |18:10:05.348 |AppInfo  |RouteListCdrc::algorithmCategorization — CDRC_SERIAL_DISTRIBUTION type=1

93958337.006 |18:10:05.348 |AppInfo  |RouteListCdrc::whichAction — DOWN (Current Group) = 1

93958337.007 |18:10:05.348 |AppInfo  |RouteListCdrc::routeAction — current device name=64b7ded7-1c4b-87c4-dbde-dd931577cd99, down

93958337.008 |18:10:05.348 |AppInfo  |RouteListCdrc::executeRouteAction: SKIP_TO_NEXT_MEMBER

93958337.009 |18:10:05.348 |AppInfo  |RouteListCdrc::skipToNextMember

.

.

.

93958338.001 |18:10:05.348 |AppInfo  |RouteListCdrc::null0_CcSetupReq check vipr call mViprReroute=0 mViprAlreadyAttempt=0 CI=35154630 BRANCH=0

93958338.002 |18:10:05.348 |AppInfo  |RouteListCdrc::null0_CcSetupReq – Terminating a call after the RouteListCdrc cannot find any more device.

93958338.003 |18:10:05.348 |AppInfo  |RouteListCdrc::terminateCall – No more Routes in RouteListName = RL_LIP.  Rejecting the call

93958338.004 |18:10:05.348 |AppInfo  |RouteListCdrc::terminateCall – Sending CcRejInd, with the cause code (41), to RouteListControl because all devices are busy/stopped.

93958338.005 |18:10:05.348 |AppInfo  |GenAlarm: AlarmName = RouteListExhausted, subFac = CALLMANAGERKeyParam = , severity = 4, AlarmMsg = RouteListName : RL_LIP, Reason=41,

.

#

This shows the problem. For some reason both gateways appeared to be either stopped or busy to Call manager even though they were available with full 30 channels.

I searched for bugs but could not find any for CUCM 9.1(2) and RL problem. Tried to change order of E1s in RG but that did not help as well.

The issue was only resolved when I went for a cluster reboot. It seems like the Provisioning service sometimes is not updated properly and get stuck.

Just today I found that Cisco has in fact added this as a bug (Feb 7^th) on their Bug Toolkit. Even though they mention Reset of RL/RG will resolve the issue, it did not for me.

This is just a heads up for you guys if you come across similar issue for a 9.1(2) cluster. You may try resetting RL/RG but cluster reboot will definitely resolve the issue.

Bug Id is CSCum85086 -Outbound calls through RL failing, RG members reported as down