Agent goes not ready after non-acd transfer

[Phil Bradley]

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?

[brian1mcc]

Hi,

Is the Automatic Available setting in Resources set to enabled?

Regards,

Brian

[Phil Bradley]

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.

[JEck]

Any resolution to the issue?  I'm having the same issue with a customer.

Thanks

[Phil Bradley]

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.

[edguidry]

Having similar issues.   Was there a resolution?   thanks, edide

[davidblair]

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

[Phil Bradley]

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!

[davidblair]

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.