Asterisk queue: Unable to join queue

Asterisk Asterisk Support
1

Hi,

I have a queue which works fine in general.
However, under certain conditions some calls cannot enter the queue, and I would like to find out why.

The queue is defined like so:

[q7000]
autofill = yes
strategy = ringall
retry = 0
timeout = 20
weight = 0
wrapuptime = 0
joinempty = paused,invalid,unavailable
leavewhenempty = paused,invalid,unavailable
announce-position = no
announce-holdtime = no

In my dialplan I have the following:

same => n(requeue),NoOp(There are ${QUEUE_MEMBER(q7000,free)} free agents in q7000, ${QUEUE_MEMBER(q7000,logged)} logged, ${QUEUE_MEMBER(q7000,ready)} ready and ${QUEUE_MEMBER(q7000,count)} total accounted for before entering queue 7000)
same => n,Queue(q7000,twx,,)
same => n,NoOp(POST - There are ${QUEUE_MEMBER(q7000,free)} free agents in q7000, ${QUEUE_MEMBER(q7000,logged)} logged, ${QUEUE_MEMBER(q7000,ready)} ready and ${QUEUE_MEMBER(q7000,count)} total accounted for after leaving queue 7000)

Occasionally in my log I can see this:

pbx.c: Executing [t@custom-IVR1-am:7] NoOp("IAX2/meetbox-6880", "There are 0 free agents in q7000, 1 logged, 0 ready and 15 total accounted for before entering queue 7000") in new stack
pbx.c: Executing [t@custom-IVR1-am:8] Queue("IAX2/meetbox-6880", "q7000,twx,,") in new stack
app_queue.c: Unable to join queue 'q7000'
pbx.c: Executing [t@custom-IVR1-am:9] NoOp("IAX2/meetbox-6880", "POST - There are 0 free agents in q7000, 1 logged, 0 ready and 15 total accounted for after leaving queue 7000") in new stack

What I would like to know is why that call could not join the queue.
The NoOp output seems to indicate that there was an agent logged in (it was probably busy – on a call).
I understand that even with my joinempty and leavewhenempty settings, a call should enter the queue even if its agents are “busy” (on call), right?
If not, why?

[EDIT]
To say the truth, I’m a bit confused on how to use the joinempty and leavewhenempty settings. I want calls to enter the queue whenever there’s at least one “available” agent (ie. at least one agent is “busy”/on call, “ringing” or “not in use”). How does that translate to “joinempty”?
I also want calls to leave the queue whenever “all” agents are either paused, invalid or unavailable/off-line.

[EDIT]
I suspect that my joinempty and leavewhenempty settings seem to “work for me”, except when there are a lot of calls in the queue. Is there a max number of calls allowed per queue (I did not set maxlen)?

[EDIT]
Could it be an Asterisk bug? I have v. 18.10.0, but I haven’t seen anything in the release notes (CHANGES).
I’m getting the message

Unable to join queue

only on “high” call load (actually, not that high either… maybe around 20 calls in queue).
I know there is no maxlen limit because “show queue” gives me this header:
q7000 has X calls (max unlimited)

[EDIT]
I’ll file a bug report as soon as I update my Asterisk version because there’s definitely something wrong. I changed joinempty to yes and left leavewhenempty with
paused,invalid,unavailable and calls entered and immediately exited the queue even if there were 2 agents logged in but busy/on call (as seen with QUEUE_MEMBER).
In other words, the dialplan code:

same => n(requeue),NoOp(There are ${QUEUE_MEMBER(q7000,free)} free agents in q7000, ${QUEUE_MEMBER(q7000,logged)} logged, ${QUEUE_MEMBER(q7000,ready)} ready and ${QUEUE_MEMBER(q7000,count)} total accounted for before entering queue 7000)
same => n,Queue(q7000,twx,,)
same => n,NoOp(POST - There are ${QUEUE_MEMBER(q7000,free)} free agents in q7000, ${QUEUE_MEMBER(q7000,logged)} logged, ${QUEUE_MEMBER(q7000,ready)} ready and ${QUEUE_MEMBER(q7000,count)} total accounted for after leaving queue 7000)

led to:

pbx.c: Executing [t@custom-IVR1-am:7] NoOp("IAX2/meetbox-11955", "There are 0 free agents in q7000, 2 logged, 0 ready and 15 total accounted for before entering queue 7000") in new stack
pbx.c: Executing [t@custom-IVR1-am:8] Queue("IAX2/meetbox-11955", "q7000,twx,,") in new stack
res_musiconhold.c: Started music on hold, class 'default', on channel 'IAX2/meetbox-11955'
res_musiconhold.c: Stopped music on hold on IAX2/meetbox-11955
pbx.c: Executing [t@custom-IVR1-am:9] NoOp("IAX2/meetbox-11955", "POST - There are 0 free agents in q7000, 2 logged, 0 ready and 15 total accounted for after leaving queue 7000") in new stack

So if there are 2 logged-in members even if they’re not free, the calls should stay in the queue.

2

In case you’re wondering
${QUEUE_MEMBER(q7000,paused)}
is also 0 in the case I reported above.
It really looks like a bug now, or I’ve seriously overlooked some config option.

3

You could try turning on debug logging[1] and app_queue may tell you some of its decision making. Otherwise if you do file an issue, there is no time frame on if or when it would get looked into. I also looked through the old issue tracker and there were no open issues regarding this when we stopped using it a month ago.

And I don’t know anything further for app_queue in this area beyond the documentation.

[1] Collecting Debug Information - Asterisk Project - Asterisk Project Wiki

4

I’m pinpointing the issue here…

A DEBUG log reveals that all the operators were “paused” (when I thought they weren’t) as I see messages of this kind:

app_queue.c: Operator X is unavailable because he is paused'

So, apparently at that precise moment I have to believe that the agents are in the “paused” state.
However, the output of ${QUEUE_MEMBER(MYQUEUE,paused)} being 0 right before entering the queue and right after exiting it I don’t know what is failing to report the right state: app_queue or the QUEUE_MEMBER function.

5

There’s an inherent race condition in that. Between outputting and entering app_queue, things can change. Not saying that is the cause, but just that is always the case with querying state as such.

6

I also don’t think you can pass paused like that for a queue. It looks to be for a specific interface.

7

It’s highly unlikely there’s a race condition in my case because I’m calling QUEUE_MEMBER before and after the Queue command. Also, this doesn’t happen just once or twice - it’s apparently every time all agents are “paused”. So this leads me to think that I’m either not using QUEUE_MEMBER correctly for the “paused” agents, or there’s a bug there.
According to the docs, the “specific interface” must be specified for write operations. I only need to read the state of the members just like I’m doing with “free”, “logged”, etc.
So, according to this (I’m using Ast 18):
https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Function_QUEUE_MEMBER
I should be able to query the amount of “paused” agents within a queue by simply specifying the queue name and the “paused” option.
That doesn’t seem to work in my case as that function for that option seems to always yield 0.

8

The paused requires it for both read and write. “interface is required for all member operations.”, this is a member operation.

9

I have all sorts of agents in the queue. Their “interfaces” are all of type PJSIP/*. Sorry for the lame question, but what kind of “interface” should I pass the QUEUE_MEMBER function? Do I need to explicitly pass each queue member interface? Or maybe as PJSIP/agent1&PJSIP/agent2…etc.? I’m just making this up because the doc doesn’t clearly define what an interface is here and its format. An example would be nice.

10

An interface would be “PJSIP/agent1”. A single target in a dial string. Multiple are not supported.

11

“interface” is also not QUEUE_MEMBER specific, it’s used in the configuration[1] to refer to what I mentioned.

[1] asterisk/configs/samples/queues.conf.sample at master · asterisk/asterisk · GitHub

12

OK, I’ll try to call QUEUE_MEMBER for every single agent interface although this can be quite tedious when there are a lot of queue members or when the latter are dynamic (hence I don’t necessarily know which interface to query). Too bad QUEUE_MEMBER doesn’t “simply count” the paused members as it does for “free”, “logged”, etc. I guess there must be a technical/coding reason for this.
Anyway, I haven’t tested it yet but thanks for clarifying!

13

Generally the answer for many things is… noone has written it.

14

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