BUG for routing calls in queue

[CosNeoX]

3CX version: Version 20.0 Update 6 (Build 724 Release)
Self Hosted on Linux machine with official 3CX ISO.


Hello all.

Since yesterday, we are experiencing a very weird behaviour on our 3CX instance.
We have a queue with 20 agents. The queue is configured like this:


While the Maximum queue wait time is set to 180 seconds (3 minutes), we have sometimes callers who are stuck in the queue for more than 3 minutes (sometimes more than 5 minutes).
The worst thing is that we actually have available agents when this happens (connected, logged in the queue, status set to available). We experiment this weird behavior for some calls, and then it goes back to normal behaviour. Before acting weird again later. Feels like a routing issue or someting.

Has anyone already experienced this?
What could be the root cause of it?

Thanks for your help!

David

 

[KyriacosS_3CX]

Hello,

Do any agents have also ring my mobile or any forwarding on their extensions?

Best,
KS.

 

[CosNeoX]

Hello,

Do any agents have also ring my mobile or any forwarding on their extensions?

Best,
KS.

Hello.

No. No forwarding or anything set to mobile phone (all the agents only use the webapp).

 

[paulodagraca]

Hi CosNeoX,

Do you have any Call Data of the calls where this does happen?
If you post it here, please take any personal information out, we just need to see the 'flow' of the call.
Or try to check it yourself to see, if the call did really stick for more than 180 sec. or overflow and came back ???

Paulo

 

[lancerichards]

Hi @CosNeoX

Typically, your Ring Time and your Max Time will be different so that polling can be done as calls end.

Ring Time 30 Seconds would retry any agents already on a call every 30 seconds within your Maximum queue wait time of 180.

You will then see one poll in the logs for each time it tries to call an agent who is logged in but not on a call.

I hope that helps you.

Best,
Lance

 

[CosNeoX]

Hi CosNeoX,

Do you have any Call Data of the calls where this does happen?
If you post it here, please take any personal information out, we just need to see the 'flow' of the call.
Or try to check it yourself to see, if the call did really stick for more than 180 sec. or overflow and came back ???

Paulo

Hi Paulo!
Will check the logs for more details (didn't see anything yesterday) and will post the results here. Thanks!

 

[CosNeoX]

Hi @CosNeoX

Typically, your Ring Time and your Max Time will be different so that polling can be done as calls end.

Ring Time 30 Seconds would retry any agents already on a call every 30 seconds within your Maximum queue wait time of 180.

You will then see one poll in the logs for each time it tries to call an agent who is logged in but not on a call.

I hope that helps you.

Best,
Lance

Hi Lance!
Thanks for your answer.
Does it make any difference, even when Polling Strategy is set to Ring All?

 

[lancerichards]

Hi Lance!
Thanks for your answer.
Does it make any difference, even when Polling Strategy is set to Ring All?

Yes, think of it this way.

The max wait time is the depth of a queue.
Example: There is a queue of people lining up. The maximum time you will wait in the queue before the "next action" is 180 seconds.

The ring time is the time it rings, and the time it will retry to ring an agent.
Example: There are 3 people serving customers. There are 10 people in the queue waiting to be served. Every 30 seconds it will look for any agents available and then put someone from the queue to an available agent.

If your Ring Time is 180, and your queue depth is 180, then it will not try to put someone from the queue back to the agent as there is no opportunity to re-poll an agent to check their availability.


I hope that clarifies it for you.

Best
Lance

 

[CosNeoX]

Yes, think of it this way.

The max wait time is the depth of a queue.
Example: There is a queue of people lining up. The maximum time you will wait in the queue before the "next action" is 180 seconds.

The ring time is the time it rings, and the time it will retry to ring an agent.
Example: There are 3 people serving customers. There are 10 people in the queue waiting to be served. Every 30 seconds it will look for any agents available and then put someone from the queue to an available agent.

If your Ring Time is 180, and your queue depth is 180, then it will not try to put someone from the queue back to the agent as there is no opportunity to re-poll an agent to check their availability.


I hope that clarifies it for you.

Best
Lance

Lance,

thanks for the detailed explanation. Actually it makes sense.
I will change the ring time.

 

[CosNeoX]

I changed the Ring Time on the queue but still experiencing the same issue.
Here is below an example of a call stuck in the queue for more than 3 minutes, and not ringing on any agent:

 

[KyriacosS_3CX]

Hello,

Can we get the rest of the log lines for that call perhaps?

Best.

 

[KyriacosS_3CX]

Hello,

This is because the queue after it's expired is set to ring an Extension, not to a Voicemail directly. The extensions ringing time (before it is answered by the user or goes to the extension's voicemail) is counted in the Queue talk time, as during this period the queue is trying to make that extra call, and only sends the user over after that call is answered by the user or their voicemail.

Below is a call to a queue with a timeout of 20s, forwarding to an extension, with 20s timeout as well, before it goes to voicemail:




By following the call ID we can see the 21s Ringing on the extension is part of the queue's 41 Talking.

The new reports do tell the whole story.

Best,
KS.

 

[CosNeoX]

Hello,

This is because the queue after it's expired is set to ring an Extension, not to a Voicemail directly. The extensions ringing time (before it is answered by the user or goes to the extension's voicemail) is counted in the Queue talk time, as during this period the queue is trying to make that extra call, and only sends the user over after that call is answered by the user or their voicemail.

Below is a call to a queue with a timeout of 20s, forwarding to an extension, with 20s timeout as well, before it goes to voicemail:

View attachment 48571


By following the call ID we can see the 21s Ringing on the extension is part of the queue's 41 Talking.

The new reports do tell the whole story.

Best,
KS.

@KyriacosS_3CX : thanks for your answer and example.
But in our case, the Queue it not set to ring an extension when expired, but directly a Voicemail (please see the screenshot below):



For the call I mentioned before, here is the screenshot of the full call log:

 

[KyriacosS_3CX]

Hi,

If you point a DID to that voicemail and call in, does it pick up immediately?

 

[CosNeoX]

Hi,

If you point a DID to that voicemail and call in, does it pick up immediately?

Yes. Just assigned a DID and made a call. It goes directly to VoiceMail.

 

[KyriacosS_3CX]

I would say ideally we need to see a debug log of this happening. My suspicion would be on a setting for a specific agent, whereby the intermittent nature of the issue is based on their current status, but without more data, it's just a suspicion.

 

[CosNeoX]

I would say ideally we need to see a debug log of this happening. My suspicion would be on a setting for a specific agent, whereby the intermittent nature of the issue is based on their current status, but without more data, it's just a suspicion.

I just put the Activity Log in Verbose mode in order to analyse it.
As soon as I get more infos, I'll post here.
Thanks!

 

[KyriacosS_3CX]

Please do not post the debug log etc in the public forum. PM if needed.

 

[CosNeoX]

Please do not post the debug log etc in the public forum. PM if needed.

No no! Won't put any sensitive data here!
But thanks for remembering that!

 

[CosNeoX]

My suspicion would be on a setting for a specific agent

I checked every agent configuration.
The only different thing I found on one agent was Custom Status Message in Call Forwarding, using custom icons. Don't know if it could be an issue with encoding or something like that.
I removed it and now waiting for the issue to happen again.