Queue overflow on DID removes transfer option (v20 Update 7)

[kwit]

Hi 3CX experts,

(I'm sadly definitely not one of them)

We’re seeing a very specific issue in 3CX v20 Update 7 (build 1080) with multi-queue call flows:


Setup 1 (main trunk number):

Main trunk > Queue 1 > Queue 2 (after 15s if unanswered) > Queue 3 (after 30s if unanswered) > Voicemail

• Transfer works from a call picked up at any stage.

Setup 2 (support DID):

DID > Queue 1 > Queue 2 (after 15s if unanswered) > Queue 3 (after 30s if unanswered) > Voicemail

• Transfer works if the call is picked up in Queue 1.
• Transfer does NOT work if the call is picked up in Queue 2 or Queue 3.

Observations:

• Both queue setups look identical in configuration.
• The only difference is main trunk number vs DID.
• Agents can still answer the call, but options to transfer or park disappear in overflow queues when using a DID.

Questions:

• Has anyone else experienced DID > Queue > Queue breaking transfers in v20 Update 7 after calls have been answered?
• Are there recommended best practices for multi-tier queue routing that preserve transfer/park functionality?

Thanks!

kwit

 

[KyriacosS_3CX]

Hello,

Has this been checked in verbose and anything relevant spotted in the logs?

Main number, the queue is defined in the trunk config as the default destination, or is that DID also assigned via the queue config?

Please let us know exactly what you are doing, step by step, so we can see exactly. Some screenshots might help.

 

[Abe-C]

Same build broke calls rolling to queue for me. Zero issues before the update and after all calls that should roll to queue get dropped.
No changes were made in 3CX configuration prior to issue other than the update. Completely removed the queue and added but same issue. All calls rolled over are abandoned.
Logs examples show:

Call from "RENO ,NV" <sip:[email protected];user=phone>;tag=1c53945669 to <sip:[email protected];user=phone> has been dropped as it was not acknowledged in time. Please verify configuration and ensure there are no connectivity issues.

Call from "TEXAS" <sip:[email protected];user=phone>;tag=1c779584837 to <sip:[email protected];user=phone> has been dropped as it was not acknowledged in time. Please verify configuration and ensure there are no connectivity issues.
Error 50029:
This is also known as ACK (Acknowledge) not received. It is a SIP method that depends on an ACK to keep the call active. If an ACK is not received, the call will drop. Acks not received happen because of

1. Firewall without port forwarding
2. Wrong port forwarding configured
3. Dynamic IP

None of these factors is the case. No changes and all worked on previous build. On-prem server.

 

[kwit]

Hi there, thanks for the speedy reply!

Nothing obvious spotted in the logs but we're continuing to test and monitor.

Setup 1 (main trunk number):

The Default Route for the trunk config (below) is set to the main queue.


Under DID Numbers for the trunk, the trunk number is not listed (I assume by design).

Main trunk line Queue 1 (below) does have the same trunk number listed under the Assigned DID number(s) field:


Queue 2:



Transfers are fine from here once picked up.


Setup 2 (support DID):

Onto the support queues, where things are misbehaving:

Queue 1:



Queue 2:



Picking up from here and trying to transfer doesn't work.

Thanks!

 

[KyriacosS_3CX]

Hello,

How is the transfer attempted - what app/device etc? Do you press transfer and nothing happens? Does the call drop, do they not get the transfer option?

Are the members in these queues the same, same department, same roles and permissions?

Opening a ticket might be the fastest way to drill down to this, right now we are just trying to guess at both the issue and the config behind it.

 

[KyriacosS_3CX]

Same build broke calls rolling to queue for me. Zero issues before the update and after all calls that should roll to queue get dropped.
No changes were made in 3CX configuration prior to issue other than the update. Completely removed the queue and added but same issue. All calls rolled over are abandoned.
Logs examples show:

Call from "RENO ,NV" <sip:[email protected];user=phone>;tag=1c53945669 to <sip:[email protected];user=phone> has been dropped as it was not acknowledged in time. Please verify configuration and ensure there are no connectivity issues.

Call from "TEXAS" <sip:[email protected];user=phone>;tag=1c779584837 to <sip:[email protected];user=phone> has been dropped as it was not acknowledged in time. Please verify configuration and ensure there are no connectivity issues.
Error 50029:
This is also known as ACK (Acknowledge) not received. It is a SIP method that depends on an ACK to keep the call active. If an ACK is not received, the call will drop. Acks not received happen because of

1. Firewall without port forwarding
2. Wrong port forwarding configured
3. Dynamic IP

None of these factors is the case. No changes and all worked on previous build. On-prem server.

This does not seem related. Perhaps start a separate thread, if you have not done so, where more specific questions can be asked.

I would also recommend to check logs in Verbose mode, as additional details that mind point to a solution can often be found there.