IVR Breakout in Queue Causes Newer Calls to Be Connected First

When calls are in queue and an older call is in breakout IVR, a newer call will be connected to an agent. This behavior is annoying a client and I was hoping someone had a work-around.

Here is the trace that shows the older call (00398) being played IVR while newer call (00399) gets connected. (I have many)

[2019-10-01 14:19:38] VERBOSE[25060][C-00000399] pbx.c: Executing [[email protected]:53] Queue("SIP/TSI01-in-00000337", "101,t,,,360,,,subQueueAlert,s,1,0,") in new stack
[2019-10-01 14:19:38] VERBOSE[25060][C-00000399] res_musiconhold.c: Started music on hold, class 'hold', on channel 'SIP/TSI01-in-00000337'
[2019-10-01 14:20:36] VERBOSE[24190][C-00000398] res_musiconhold.c: Stopped music on hold on SIP/TSI01-in-00000336
[2019-10-01 14:20:36] VERBOSE[24190][C-00000398] app_queue.c: Playing periodic announcement
[2019-10-01 14:20:36] VERBOSE[24190][C-00000398] file.c: <SIP/TSI01-in-00000336> Playing 'custom/TSI_OnHold.slin' (language 'en')
[2019-10-01 14:20:49] VERBOSE[26600][C-00000399] pbx.c: Executing [[email protected]:1] Set("Local/[email protected];2", "QAGENT=2925") in new stack
[2019-10-01 14:20:49] VERBOSE[25060][C-00000399] app_queue.c: Called Local/[email protected]/n
[2019-10-01 14:20:49] VERBOSE[25060][C-00000399] app_queue.c:     -- LazyMembers debugging - Numbusies: 0, Nummems: 1
[2019-10-01 14:20:49] VERBOSE[26600][C-00000399] pbx.c: Executing [[email protected]:2] Set("Local/[email protected];2", "__FROMQ=true") in new stack
[2019-10-01 14:20:49] VERBOSE[26600][C-00000399] pbx.c: Executing [[email protected]:3] GotoIf("Local/[email protected];2", "0?hangup") in new stack
[2019-10-01 14:20:49] VERBOSE[26600][C-00000399] pbx.c: Executing [[email protected]:4] GotoIf("Local/[email protected];2", "1?101,1:hangup") in new stack

So is this a bug, a miss-configuration or just the way it works? Any workarounds? (The breakout IVR has VM and other options, so I can’t just use pre-recorded messages in MOH.)


Is auto fill enabled? If so, try disabling it.

Also, you can try the below

Thanks @PitzKey. Autofill is disabled. Did you ever find out what file that was? I grepped for it in /etc/asterisk and got nothing.

I think this is mainly just how it works. In Asterisk Queues, the calls pick agents, rather than the agents picking calls. There is a little bit of logic to stop low priority queues overriding high priority ones, but, as many calls as there are free agents will be competing for the available agents, and if one is playing comfort messages, it will not be actively looking for an agent.

If by IVR, you really mean just playing “your call is important to us, please wait”, you can record a special musiconhold track that embeds those messages.

(I can’t remember what it does with two equal priority queues that share the same agents, but I suspect that it may not reduce the number of calls from the top of the queues that are actually looking for agents, so calls further down the queue may end up getting an agent. Normally this isn’t too much of an issue, unless multiple agents come free in the same second, as there will rarely be more than one agent free when queues are heavily loaded.)

There needs to be more to the debug then a half dozen lines. We need to see the call that is in the queue and then the breakout IVR selection/options and the call behind this call. If the playback is causing the next caller to be sent to the agent there might be a problem.

No there doesn’t. This is simple enough for anyone to replicate/verify. Posting here is not posting a bug report.

The lines he posted shows it pulled call 398 out of the queue to play the periodic message and while 398 was still out, it sent call 399 to an agent.

But if a full debug is required, the app_queues.c has lots of debug to prove this is a bug.

core set debug 4 is enough verbosity to see all of the app_queue debug messages. FreePBX logs debug to full by default.

app_queues.c has two main loops. one for the “head caller” and one for callers 2+. Both loops call say_periodic_announcement. So with debug on, it should be simple to have the OP post something that will prove where the callers were.

No, I didn’t.

Maybe someone with a little more experience would be able to tell.

@BlazeStudios I could add more debug but I’m not clear on why it is needed. The fact is that 398 was pulled out of the queue for the IVR, and while it was being played 399 went to an agent. I promise 398 was the first caller. So my question is this behavior a bug, a miss-configuration or just the way it works? If there is some configuration option to NOT have the breakout IVR played to the oldest call (or calls?) in the queue I would really like to find it.

There is no pulling from the queue when the message is played. It’s a recording that is being played back just like any of the other recordings. Until the caller actually selects an option that is available to them they are in the queue. If they ignore the recording and don’t press 1 for voicemail or 2 for a callback then their position and status is the queue is unchanged. When they opt to press 1 or 2 that is when they are sent to the IVR context and taken out of the queue.

How many callers where in the queue when this happened? Does this happen with every caller that gets the periodic playback message? So if caller 4 gets the playback does caller 5 jump to position 4 or 3? Are they sent directly to an agent? Or does this only happen with callers in position 1 and 2?

Actually the cause of this problem of calls coming out of the queue LIFO instead of FIFO was an error in globals_custom.conf detailed in this post:

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.