CFD v20 - Add extensions into queues

Julian Kelly

Gold Partner
Advanced Certified
Joined
Aug 5, 2024
Messages
3
Reaction score
1
Evening all,

We are currently trying to implement a CFD in which if a queue reaches 2+ calls it automatically logs a user extension into the queue to assist with the calls and then once it drops below this threshold to automatically log them out.

I have found https://www.3cx.com/community/threads/3cx-cfd-call-queue-v18.83380/#post-388493 which is more or less what we want to achieve, but mirroring the settings does not work, the odd thing is the less than 2 calls condition works and if i reverse it logs the user in and out as required but as soon as i put the "greater than 2" condition in calls to the CFD just drop out.

Any one come across this? Did anything change between v18 and 20 when it comes to the "Get Queue Status"?

Thanks.

Julian
 
In order to understand why the call is being dropped, enable verbose logs in 3CX, then reproduce the issue, and check the 3CXCallFlow.log file. That will give you some pointers.
 
  • Like
Reactions: Julian Kelly
In order to understand why the call is being dropped, enable verbose logs in 3CX, then reproduce the issue, and check the 3CXCallFlow.log file. That will give you some pointers.
Thanks Ernesto, been using 3CX for quite a long time now but very rarely had to touch CFD, that log once pulled out of the support package showed me exactly what was going on. Tweaked the condition and now working as intended. Thanks mate, owe you a beer.
 
Glad you managed to solve it! Where should I pick up that beer? xD
 
I think we need to at least mention some cautions associated with this approach. First, there is no feasible way to ensure this CFD application is automatically started after a 3CX reboot, so you will need to have a very detailed checklist that is followed religiously to ensure someone remembers to dial the extension of the CFD after a reboot.

Second, my guess is that you are poking an API in a loop to check the number of people waiting in the designated queue? Hopefully you put a pause in your loop to ensure you do not burn through resources as this application runs continuously.

Your idea is good -- dynamically logging overflow agents into a queue based on the queue demands, and then logging them out again when the demands fall below a second threshold (min and max). This is an idea I have been floating in the forums for more than a decade, but as yet I have not found anyone able to help with funding the project. This approach is vastly better than using rollover queues that result in lots of reported abandoned calls as well as callers potentially losing their place in the queue. Rollover queues really mess with queue reports and identifying "real" abandoned calls.

Let me take this opportunity to ask again... anyone want to help fund building a commercial-quality solution? The requirements and design have been sitting in my brain for years. Ready when you are!
 
  • Like
Reactions: EmmettsIT
We use the shamelessly cheap trick of first sending the call to the call script which manipulates the queue and only then does the queue receive the call. The queue is never called directly. Of course this only works if the calls are exclusively controllable - i.e for external calls.
 
  • Like
Reactions: EmmettsIT

Forum statistics

Threads
112,149
Messages
590,964
Members
165,170
Latest member
SupportRock