cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1338
Views
0
Helpful
4
Replies

Call did not go to available resource

Bill Brown
Level 1
Level 1

                Cisco Unified CM Administration System version: 7.1.5.31900-3     (Cisco Unified CCX Premium)

                Cisco Application Administration - 7.0(1)SR05_Build504

Problem:

     Call does not go to an available resource when queued.

1 out of about 2000 calls seems to do this.  Since we get 3000 or more calls this has been showing up more lately.

Call sets in a queue and agents are available,  call will loop through the script, supposedly going in queues and not be answered.


Current work around:

In the Select Resource, under queued, I wait a second and grab the reporting statistic on available resources in that queue.

If I see this is 1, and the call exits the select resource after my delay, I route the call to a hunt group.  Unfortunately this loses the calls identity and time in queue.  The operator has to reidentify the call to the system and place it back in the queues.

I've delayed the call 5 seconds before queueing, I wait 2 seconds before accepting and all types of work arounds, but this still appears to happen.

If you have had something similar, please offer me a way around this.  I'm positive that this is not the script, but an issue with configuration on the servers.

4 Replies 4

Graham Old
Level 7
Level 7

Are you running into this bug: CSCsw64328

UCCX: Call stays in queue when Engine fails to allocate resource
Symptom:

A call will remain in queue indefinitely  and will not be delivered to available agents. This call will appear in  the Real Time Reporting tool.

Conditions:

This occurs when there is a mismatch in Agent states and AvailableResourceList within the UCCX Engine.

Workaround:

Restart UCCX Engine.

Further Problem Description:
When the Engine attempts to allocate a resource who's state is mismatched, the following error will appear in the logs:

%MIVR-SS_RM-7-UNK:Agent agent1.allocateRsrc(17482622)
%MIVR-SS_RM-3-ERROR_ALLOCATING_RESOURCE:An  error has occurred while allocating this resource: Module Name=RM  component,A specific description for a trace=rsrc''s state is  UNAVAILABLE

Since the Engine believes it has already allocated a  resource for this call, it will leave the call in queue indefinitely,  regardless of agents becoming available to accept the call

1st Found-In

5.0(2)

Fixed-In

8.5(0.95000.4)

8.0(2.11002.2)

8.0(2.20000.1)

Graham

I ran into this issue a few times as well. Using version 7.0(1)SR05_Build504. After TAC initially pointed me to the same doc above, they then came back with an Engineering Special (ES) for 7.0(1)SR05 that addresses this.

Release Notes:

Defect fixed in UCCX 7.0(1) sr5 es08

CSCtf17185 - UCCX: Engine does not recognize JTAPI cause code for 486 Busy Here

CSCtf72525 - UCCX: Calls get stuck in Received when CallCtlConnFailed received

CSCsw22313 - Bad Database connection causes calls to fail

CSCte31488 - Some reports fail to open when Filtered by Skill name

CSCsw64328 - UCCX: Call stays in queue when Engine fails to allocate resource

CSCsy71045 - INVALID_MUTEX_OWNER Message Displayed in MADM logs

Still have yet to apply the patch, but am curious has anyone with 7.0(1) applied this patch and if so, did it resolve the bug?

Hi,

We have the same issue but this is rarely. The first time occurrence is last October 2013 then it recurs this month only February 2014.

Upon checking the MIVR logs we didn't found this error:

%MIVR-SS_RM-3-ERROR_ALLOCATING_RESOURCE:An  error has occurred while allocating this resource: Module Name=RM  component,A specific description for a trace=rsrc''s state is  UNAVAILABLE

We have done the workaround of restarting UCCX Engine and the issue resolve the issue.

We are still running the UCCX old version [7.0(1)SR05_Build504]. May we know if we need to upgrade this?

Thanks and best regards,

RJ

Hi Ralph,

I ended up applying the ES08 patch to our UCCX nodes a while ago, bringing us to 7.0(1)SR05ES08_Build080, and it resolved the issue. It was a pretty straight-forward process.

Cheers,

Frank