Duplicate Calls, Call Not Answered

[phonehome]

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

[Sean Lynch]

Check the Agent Detail report for the agent resource and see if these calls are generating a reason code (32763) for "Ring No Answer".
-Sean

[phonehome]

No, it is set to Call Not Answered.

Edit: I looked in our reason codes. It is in fact 32763.

[Sean Lynch]

Review that in the System Admin Guide and Reporting Admin Guide... It is being recorded as a Ring No Answer, from the perspective that the agent is not answering.
Hope this helps,
Sean

[phonehome]

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.

[Sean Lynch]

If it does not turn out to be something in the delivery of telephony/calling (as , garthman1 suggests) check your script and see if you are distributing the call to multiple CSQ's (such as a primary and secondary scenario) and whether or not you have the agent(s) skilled for both.
-Sean

[Sean Lynch]

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

[garthman1]

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. 

[Will Pettit]

Hi, long shot, but did you ever solve this?