Queue Ring Time not working correctly

[TekToneIT]

Hey Everyone,

We have a strange issue with one of our queues not honoring the set ring time. This department has two queues, and all agents are members of both queues. The queue is using Round Robin mode, and is supposed to ring the chosen agent for 5 minutes, and then if the call is unanswered, it should be routed to a different queue that rings all available agents.

Both the "Ring Time" and "Maximum queue wait time" are set to 300 seconds for the queue. However, after exactly 120 seconds of ringing the first agent, the call is transferred to a different agent while staying in the same queue. This behavior repeats until the call has been in the queue for the allotted 300 seconds (and the 3rd agent's phone has been ringing for 60 seconds) before transferring to the queue specified in the "Destination if no answer" setting for the initial queue.

If I decrease the ring time to less than 120 seconds, the system honors the request properly and transfers the call the the next agent at the specified time. I've verified that the "No answer timeout" for the agents in the queue is set to 300 seconds for their individual user/extension (even though this shouldn't apply to queue calls), and that office hours are properly configured. I also couldn't find anything in the parameters that is set to 120 seconds that might be limiting the ring time (MAXNOANSWERTIMEOUT and BMCALLTOUT are both set to 300).

To recap, here is the expected call flow vs the actual behavior (assuming no one answers the call at any point)
Expected Behavior:
- Call comes into queue 1
- Agent chosen by the polling strategy (Round Robin) rings for 300 seconds
- Call is routed to queue 2

Actual Behavior:
- Call comes into queue 1
- Agent chosen by the polling strategy (Round Robin) rings for 120 seconds
- Call is routed to a second agent and rings for 120 seconds
- Call is routed to a third agent and rings for 60 seconds
- Call is routed to queue 2.

I'm at a loss here, and hoping someone can shed some light on what we are seeing. Is there a hard coded limit on ring time in Round Robin mode that isn't documented? Screenshots of queue config and user Call Forwarding setting are attached.

3CX Professional
Self Hosted (Debian)
Version 20.0 Update 3 (Build 806 Release)

Thanks!

 

[SnakeRiverWebDevelopment]

Question 1, Why would you set ring time for 300 seconds only to have it max out at 300 seconds?
This would never go to another agent.
Question 2, Why set the user to forward after 300 seconds?
Wouldn't it be better to ring for 30 seconds, then go to another agent with max time set to 300 seconds?
If I called and had to wait for 5 minutes, every time I called just for someone to pick up, I would simply hang up and call someone else.

 

[TekToneIT]

Question 1, Why would you set ring time for 300 seconds only to have it max out at 300 seconds?
This would never go to another agent.
Question 2, Why set the user to forward after 300 seconds?
Wouldn't it be better to ring for 30 seconds, then go to another agent with max time set to 300 seconds?
If I called and had to wait for 5 minutes, every time I called just for someone to pick up, I would simply hang up and call someone else.

To give a little background, these queues are for entry level tech support and the average wait time is about 20 minutes. Quite frankly, the queue was designed like this to help ensure that all of the agents were receiving an equal amount of calls, and to clearly log who isn't answering the phone when they should be. The initial queue time of 300 seconds was selected to make sure that the agent still had sufficient time to answer the call if they had stepped away from their desk for a minute, and the idea was very specifically to keep the calls from going to another agent for a minimum of 300 seconds.

I'm well aware that this is attempting to solve a personnel issue with a technical workaround, which I'm not crazy about, but that decision was made above my head and it just fell to my team to implement. That being said, I don't see any reason that this shouldn't work.

 

[SnakeRiverWebDevelopment]

I see,
If your average wait time is 20 minutes and you are trying to allow time for an agent to pickup, if the ring time is 300 seconds that is 60 rings, if the agent does not pickup by that amount of time something is wrong. My thought would be to set max wait time to 1800 seconds, 30 minutes, and have it ring to agents 45 seconds than go to the next, if the agent is available 7-8 phone rings should be enough to pick up the call, once all agents are on a call it would forward to a different queue or other, Just an idea.

 

[TekToneIT]

I see,
If your average wait time is 20 minutes and you are trying to allow time for an agent to pickup, if the ring time is 300 seconds that is 60 rings, if the agent does not pickup by that amount of time something is wrong. My thought would be to set max wait time to 1800 seconds, 30 minutes, and have it ring to agents 45 seconds than go to the next, if the agent is available 7-8 phone rings should be enough to pick up the call, once all agents are on a call it would forward to a different queue or other, Just an idea.

Initially I had suggested something very similar to what you proposed, however our leadership team is absolutely set on wanting the calls to ring the first agent for a full 300 seconds before being transferred to the second queue that rings all agents.

If there is a limitation on Round Robin that makes this impossible, obviously they will have to come up with a different plan, but they will expect me to provide documentation of that limitation. I fully agree that this is far from an ideal way to set up a queue, but my hands are tied unless I can prove it isn't possible to do what they want. Ignoring our bizarre use case, I can't find any reason why this configuration shouldn't work from a technical perspective.

 

[SY]

Queue waits for specified polling timeout but if agent (or its device) does not agree and rejects the polling call, queue goes to the next agent.

 

[TekToneIT]

Queue waits for specified polling timeout but if agent (or its device) does not agree and rejects the polling call, queue goes to the next agent.

That certainly sounds like what is happening. Do you have any idea what could be causing the polling call to get rejected at exactly 120 seconds, even if the agent is set to available and does not touch their device while the call is ringing? Or is there any logging available that we can use to determine if this is what is happening, and what exactly is causing the rejection?

Agents usually do have the panel open on the web app, but mostly they just use that to log in and out of the queues, and they answer the calls from their desk phone. We are using Yealink T4x series phones, and I have looked through all the settings on those, but couldn't find anything that looked like a possible culprit.

 

[TekToneIT]

We have now tried using different polling strategies with this queue, and all have the same result: the call is forwarded to the next agent after 120 seconds instead of the 300 seconds specified in the polling interval.

@SY can you or someone else at 3CX please confirm is this is the intended behavior of the call queues in v20? If not, how do we view if there is something causing the polling call to be rejected at 120 seconds? None of the call logs seem to show why a call was routed to a different agent, just that it was.