[Home]

Summary:ASTERISK-28060: Queue answered out of order
Reporter:Michael Gaudette (bluefox)Labels:
Date Opened:2018-09-18 09:06:11Date Closed:2018-09-19 14:44:13
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:13.22.0 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Centos7 kept updated Using certified-13.21-cert2 - but that wasnt in the dropdown of choicesAttachments:
Description:not quite 100% reproducible, but happens often. might be a feature not a bug but I can't find any documentation on feature if it is one. If feature, please point out documentation on how to disable (or any info)

The queue system seems to remember old calls, and takes this into account when deciding who to serve first.

Way to reproduce*:
Call a queue from phone A first - wait a few seconds
Call same queue from Phone B
While both calls are waiting, hangup phone A - phone B becomes "longuest waiting"
Call back from phone A
"queue-show" CLI command shows phone B as longuest waiting
Have an agent answer queue call - phone A is served first, not phone B as would be expected

*to reproduce, make sure to "clear" memory of older calls by first using both phones to make a queue call and answer them normally.

Comments:By: Asterisk Team (asteriskteam) 2018-09-18 09:06:12.028-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Chris Savinovich (csavinovich) 2018-09-18 18:13:50.085-0500

We are going to need a copy of your queue configuration file, all info on the extensions, and your device configurations.  CLI monitor logs with debug and verbose on would help.   I couldn't reproduce it in my environment, and it could just be that your queue is configured (or got its answer method changed at some point)  to pick up calls in a priority other than by longest wait time.
CS

By: Michael Gaudette (bluefox) 2018-09-19 09:24:24.021-0500

Right now it's a 100% reproducible, but I fear it might start working fine soon. Reloading the queue module does not fix anything.

I'm attempting to give as  much info as possible without giving away passwords and codes. One thing I would like to know is how would I have set  up pickup priority differently than "longuest waiting"? I don't know where this setting might be (or the documentation on it) but that could certainly be the issue. I believed the only algorithm was longuest waiting.

As for the info - I made a test queue just for this, keeping it simple with just one agent and two calls at once:
Here is how I call the queue:
{noformat}
exten => _X!,n,Queue(${instance_name},I${ringing},,,${timeout},,,queue-moh-reset,s,1)
{noformat}
Here is how it showed up in my CLI, once variablews were defined in the dialplan
{noformat}
Queue("SIP/CALLINGPHONE-00097b13", "test-hardcoded,I,,,600,,,queue-moh-reset,s,1") in new stack
{noformat}


Here is the queue.conf snippet:
{noformat}
[test-hardcoded]
;musiconhold=classical
strategy=ringall
timeout=10
retry=10
wrapuptime=2
ringinuse = no
;maxlen = 0
;periodic-announce = thank-you-message
;periodic-announce-frequency = 10
;announce-frequency = 60
announce-holdtime = no
member => SIP/AGENTA
{noformat}

Here was the exact behavior:
Dialing from phone A (some internal SIP phone), the queue started ringing immediately, and the callerID showed CALLER_A
Dialing from phone B (some other internal SIP phone) a couple of seconds after, the queue kept on ringing with callerid CALLER_A until the end of the 10 sec timeout, but immediately after the 10 seconds timeout, WITHOUT regard to the 10 retry delay, the agent phone started ringing with CALLER_B as callerID, and afterwards kept on ringing with the  correct 10 secs timeout and 10 retry delay, but trying to connect CALLERB for the rest of the queue attempts even if CALLERA had been waiting a longer time.



As you mentionned reasonably, it may be a wrong config but I am not aware of having ever wanted to change this, and I haven't found on the asterisk 1.13 docs how I would change this even if I wanted to.
By: Michael Gaudette (bluefox) 2018-09-19 11:54:55.835-0500

Added note: here is my queue.log file (only a very basic relevant snippet)
{noformat}
1537375673|pbx3-1537375673.977560|test-hardcoded|NONE|ENTERQUEUE||705|1
1537375676|pbx3-1537375676.977563|test-hardcoded|NONE|ENTERQUEUE||200|1
1537375683|pbx3-1537375673.977560|test-hardcoded|SIP/AGENTA|RINGNOANSWER|10000
1537375693|pbx3-1537375676.977563|test-hardcoded|SIP/AGENTA|RINGNOANSWER|10000
1537375699|pbx3-1537375676.977563|test-hardcoded|NONE|ABANDON|1|1|23
1537375701|pbx3-1537375673.977560|test-hardcoded|NONE|ABANDON|1|1|28
{noformat}

What to look at: call pbx3-1537375676.977563 has a RINGNOANSWER to AGENTA, but it really shouldnt since its the second call coming in and the first call wasnt answered before.
By: Michael Gaudette (bluefox) 2018-09-19 14:36:18.479-0500

Please close issue - a typo occured in my call to the Queue app, which made this behavior possible

Sorry about this, and thank you for the attempt to help
By: Michael Gaudette (bluefox) 2018-09-19 14:44:13.589-0500

User error
By: Chris Savinovich (csavinovich) 2018-09-19 14:47:42.411-0500

What was the typo?  I found it was you were using an "I" as the Queue command options parameter instead of perhaps "R"?
By: Michael Gaudette (bluefox) 2018-09-20 07:00:32.144-0500

Not a typo per say, but I understood the last options as being gobsub, exten, priority. Which isnt th case at all, so I was pushing everyone to priority 1.