04-21-2020 08:58 AM - edited 04-21-2020 09:00 AM
We are using UCCX v11.6.2.10000-38.
We are seeing an issue where an agent either has a call ring once then stop, or they get a missed call without ringing. What happens next is the agent is either presented with the same call normally, or a different agent is presented with the call.
In the detailed call CSQ agent report, we see duplicate call IDs, as shown below. All of these duplicates will show one call with 10 second ring time and zero talk time, and the other one is the actual call. Sometimes the same agent will get both the duplicate and the actual call, sometimes it will be different agents.
Node ID - Session ID - Sequence No | Call Start Time | Call End Time | Contact Disposition | Queue Time | Agent Name | Ring Time | Talk Time | Work Time |
1-22000033133-0 | 4/20/2020 9:15 | 4/20/2020 9:29 | 2 | 0:03:00 | agent 1 | 0:00:10 | 0:00:00 | 0:00:00 |
1-22000033133-0 | 4/20/2020 9:15 | 4/20/2020 9:29 | 2 | 0:03:00 | agent 2 | 0:00:02 | 0:07:28 | 0:00:32 |
If we then look at the agent state detail report, we see the agent with the zero talk time call went into reserved state for 11 seconds, but then went into not ready for several minutes. In the meantime, the other agent answers the call normally.
If the same agent gets both calls, the agent will go into reserved for 11 seconds, then not ready for a few seconds, then back to ready and finally presented with the same call again.
What is going on here?
Thanks
04-21-2020 10:12 AM
04-21-2020 10:50 AM - edited 04-21-2020 11:30 AM
No, it is set to Call Not Answered.
Edit: I looked in our reason codes. It is in fact 32763.
04-22-2020 10:53 AM
04-22-2020 11:15 AM
Not sure what you're getting at here. Regardless of the reason code, the call is ringing either twice to the same agent or to two agents at the same time.
04-22-2020 01:08 PM
04-22-2020 01:18 PM
So here was where I was going with this...
Check your system parameters for Agent State after Ring No Answer:
...in my experience, I've seen a lot of people try to change this from default, and the agent who RNA's keeps getting the call, until another agent becomes available. This doesn't work well. Put it back to default, if it has been changed. Train the agents to go 'Not Ready' when they need to leave their station or stop taking calls.
-Sean
04-22-2020 12:46 PM
Hi, did it ever work? Any changes for example, is jabber associated with the problem devices? From the symptoms it seems like jtapi messaging out of sequence, QOS, or other network issue. Something easy to try is to re-associate the devices with RMUSER for a fresh start on the phones; after that wireshark.
09-08-2023 12:41 AM
Hi, long shot, but did you ever solve this?
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