AGENTDIRECT and INGROUP Priority Random Order Problem

[geilt]

Here is my issue...VICI Install as described in my signature.

I have 1 Ingroup (Sales) Priority 0 and Agent Direct Priority 99

4 Calls Come in: 3 to Sales and 1 to Agent Direct for a user.

My agent is in PAUSE waiting for a notification that there is a callback to their number in the queue.

The Agent goes ready.

Most of the time, but not ALL of the time...the Sales calls come in before the agent direct, causing the agent to panic as they hangup and waste the lead.

Often times, the agent has to take and hangup on all 3 calls until they get their Agent Direct, which is why they were in Pause waiting for this call to come in.

The same happens when a fronter tries to transfer to the agent direct. If there is Sales calls in queue, the agent will have to take and hangup on each one until the agent direct call back finally pops up.

What is going on here? Is there no way to prioritize an Agent's Direct calls guaranteed? Or is there some kind of race condition going on? Am I missing some setting?

We have tried by turning OFF and ON any BLOCK settings, as well as turning OFF and ON the No Delay Call Route in different permutations of the settings and nothing can guarantee that I will get the AGENTDIRECT first.

Using a separate campaign to log out of the main and log in for agent direct callbacks is not an option for us.

Even if no one can help, can someone at least point me toward the script and / or log that is responsible for distributing the calls in queue in vicidial_auto_calls. I am very familiar with how all the database tables work just not sure which script is making the decision making, it doesn't appear to be the Inbound script as that just queues if up if no one is available.

[mflorell]

I just checked our ticketing system and don't see anything from you guys recently.

If you send in an email<support@vicidial.com> with a dump of the affected campaign and in-groups settings, I'll see if I can replicate this issue locally today.

Also, if you have the screenlog.0 output where this is happening(after hours if possible) that would also be very helpful.

[mflorell]

We were able to test for this yesterday and, it is a bug!

We've added a code to fix this in svn/trunk, please upgrade to the latest revision and test again.

Thank you very much for reporting it!