12-15-2011 05:45 AM - edited 03-14-2019 09:03 AM
Hello all,
I have noticed that agents in one of my CSQ groups are going to the not ready state after receiving a non-acd call and not returning to the ready state automatically. I am running IPPA with all of my agents and my UCCX version is 8.5 SU2. When I look at the reports the status show the agent went "not ready" with a code of 32761 which is normal according the the CAD 8.5 guide. However, the agent does not return to the ready state without manually changing their state back to ready. This behaviour occurs for all agents that are a memeber of only one of my CSQ groups. I have three CSQ's setup and this only happens on one of the three groups. The other two groups automatically go back to the ready state. Has anyone else ran into this issue?
12-15-2011 06:39 AM
Hi,
Is the Automatic Available setting in Resources set to enabled?
Regards,
Brian
12-15-2011 07:21 AM
Yes, I do have automatic enabled for all the resources in this group. I should also mention that this only occurs on a non-acd call that gets transferred. If the non-acd call gets answered by the agent and the agent hangs up and not transfered, then it automatically changes them back to the ready state.
12-15-2011 08:10 AM
Any resolution to the issue? I'm having the same issue with a customer.
Thanks
12-15-2011 09:50 AM
No resolution yet. Since this is only happening to one of the three CSQ groups I am going to restart the box during off-peak hours to see if that resolves the issue. Otherwise if I dont get any other suggestions here then I will open a TAC case and post the results back here.
01-10-2012 01:32 PM
Having similar issues. Was there a resolution? thanks, edide
01-30-2012 11:25 AM
Same scenario here but with only one agent.
Non-ACD call was received because someone "call forwarded all" their phone to her extension. She takes the call (going into 32761 not-ready) then transfers it off to an application trigger and she stays in not-ready instead of snapping back to ready state.
Just started to investigate, so if someone else has more info, it would be appreciated!
DB
01-30-2012 11:30 AM
Hello All. I did get this issue resolved and it was caused by the DN not being unique in call manager. I had setup the contact center dn for presence and apparently this is not supported. After contacting Cisco they told me that the contact center DN must be unique (not show up more than once in calll manager).
Hope this helps!
02-08-2012 05:52 AM
Ours was a little different. We don't have any shared lines so I had to open a TAC case.
TAC matched our issue to the following bug ID: CSCtw59458
The fix is coming in 8.5.1 SU3 which is tentatively scheduled for April '12.
They said they had a workaround available involving manually replacing a file on the server, but I'll just wait.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide