[asterisk-bugs] [JIRA] (ASTERISK-28060) Queue answered out of order

[Michael Gaudette (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=244876#comment-244876 ] 

Michael Gaudette commented on ASTERISK-28060:
---------------------------------------------

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:
exten => _X!,n,Queue(${instance_name},I${ringing},,,${timeout},,,queue-moh-reset,s,1)
Here is how it showed up in my CLI, once variablews were defined in the dialplan
Queue("SIP/CALLINGPHONE-00097b13", "test-hardcoded,I,,,600,,,queue-moh-reset,s,1") in new stack


Here is the queue.conf snippet:
[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

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.

> Queue answered out of order
> ---------------------------
>
>                 Key: ASTERISK-28060
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28060
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 13.22.0
>         Environment: Centos7 kept updated
> Using certified-13.21-cert2 - but that wasnt in the dropdown of choices
>            Reporter: Michael Gaudette
>            Assignee: Michael Gaudette
>            Severity: Critical
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)