Summary:	ASTERISK-28369: app_queue: Member device state "invalid" when second call is ringing and hint is used
Reporter:	Boolah (boolah@mailvoid.net)	Labels:
Date Opened:	2019-04-02 07:20:32	Date Closed:	2021-02-23 13:39:41.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:	13.25.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS v7.6.1810	Attachments:	( 0) debug_log_28369 ( 1) extensions.conf ( 2) queues.conf
Description:	In a queue with a single agent who is on an active call and ringinuse=yes is set, if a second call begins ringing the queue, but before the call is answered, the next call will not be allowed to join the queue, irrespective of the joinempty setting. I've posted this issue in the community and can be found here: https://community.asterisk.org/t/unable-to-join-queue-only-on-third-call-when-second-is-ringing/79161 I've also verified that the issue exists in Asterisk version 13.23.1, 13.25.0 and 13.26.0-rc1
Comments:	By: Asterisk Team (asteriskteam) 2019-04-02 07:20:33.530-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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Joshua C. Colp (jcolp) 2019-04-08 06:19:47.338-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information In this case please attach the full configuration, including dialplan, and also the console output for your attempts. By: Boolah (boolah@mailvoid.net) 2019-04-08 08:58:28.002-0500 1.  Steps to reproduce the problem:  Have an agent (1305) logged into a queue (500) talking on an active call (1307).  A second call comes in (1306) and begins ringing the queue.  While this call is ringing the queue, a third call attempts to ring the queue (1300), but is not allowed to join the queue and this call goes to the queue fail over destination. 2.  Expected behavior:  As documented in queues.conf, since ringinuse=yes and joinempty=strict, as long as at least one agent is logged into the queue and the agent is reachable (not necessarily available, but simply reachable), any number of calls should be allowed to join the queue. 3.  Behavior encountered: The third call attempting to join a queue with a single agent who is talking on an active call (inuse), will not be allowed to join the queue if a second call is actively ringing the queue.  Moreover, setting joinempty to invalid OR unavailable OR unknown all yield the same result. The requested debug log is now attached. By: Joshua C. Colp (jcolp) 2019-04-08 09:53:32.360-0500 What is the output of "queue show" for the specific queue when the problem occurs, and does the debug log match the current queues.conf you've provided? By: Boolah (boolah@mailvoid.net) 2019-04-08 10:31:08.981-0500 The output of 'queue show 500' when the queue is idle: (Local/1305@from-queue/n from hint:1305@ext-local) (ringinuse enabled) (dynamic) (Not in use) When the agent in on the active first call: (Local/1305@from-queue/n from hint:1305@ext-local) (ringinuse enabled) (dynamic) (in call) (In use) When the second call begins ringing the queue, but before the second call is answered: (Local/1305@from-queue/n from hint:1305@ext-local) (ringinuse enabled) (dynamic) (in call) (Invalid) Note that now the queue reports the agent’s state as “Invalid”. At this point, if a third call tries to join the queue I see this in the CLI: WARNING[8445][C-00000004]: app_queue.c:8031 queue_exec: Unable to join queue '500' At this point, the variable QUEUESTATUS is set to JOINEMPTY and ABANDONED is unset. The attached debug log matches the queues.conf provided. By: Joshua C. Colp (jcolp) 2019-04-08 11:02:59.911-0500 Okay, so you're using a hint for the device state and a Local channel for dialing. What is some dialplan for that for what it looks like? I don't want to guess, as that can lead to different results. By: Boolah (boolah@mailvoid.net) 2019-04-08 11:23:15.152-0500 The dialplan is that of the standard FreePBX v13.0.195.26 queue (relevant portion attached as extensions.conf). By: Joshua C. Colp (jcolp) 2019-04-08 11:29:54.569-0500 In the future if you're using FreePBX, please state as such when filing the issue originally. By: Joshua C. Colp (jcolp) 2019-04-08 12:03:02.143-0500 How about the output of "core show hints"? That will allow me to see what is feeding that hint. As it is, that appears to be the underlying problem - the hint is changing to invalid for some reason, which then gets picked up by app_queue. By: Boolah (boolah@mailvoid.net) 2019-04-08 12:49:50.306-0500 I did manually add in one hint for the receptionist's extension which shows the status of all of the possible agents in the queue: exten => 0,hint,SIP/1305&SIP/1306,CustomPresence:0 Extension '0' just calls the queue '500': exten => 0,1,Goto(from-internal,500,1) BTW - I am not dialing '0' for any of these tests.  Moreover, if I remove the hint I manually added as well as the dialplan for extension 0, the same result occurs. Output of 'core show hints':    -= Registered Asterisk Dial Plan Hints =- _*45*X.@ext-queues  : ${DB(AMPUSER/${EXTEN  State:Unavailable     Presence:                Watchers  0 0@ext-local         : SIP/1305&SIP/1306,Cu  State:Idle            Presence:not_set         Watchers  0 _*45XXXX*XXX@ext-que: Custom:QUEUE${EXTEN:  State:Unavailable     Presence:                Watchers  0 1307@ext-local      : SIP/1307,CustomPrese  State:Idle            Presence:not_set         Watchers  0 1306@ext-local      : SIP/1306,CustomPrese  State:Idle            Presence:                Watchers  1 1305@ext-local      : SIP/1305,CustomPrese  State:Idle            Presence:not_set         Watchers  1 1304@ext-local      : SIP/1304,CustomPrese  State:Unavailable     Presence:not_set         Watchers  0 1300@ext-local      : SIP/1300,CustomPrese  State:Idle            Presence:not_set         Watchers  0 *451305*500@ext-queu: Custom:QUEUE1305*500  State:InUse           Presence:not_set         Watchers  1 _*80X.@ext-local    : ${DB(AMPUSER/${EXTEN  State:Unavailable     Presence:                Watchers  0 ---------------- - 10 hints registered By: Joshua C. Colp (jcolp) 2019-04-09 09:12:07.137-0500 So the problem seems to be due to the use of hints for device state. If a device is specified instead it works perfectly fine. By: Friendly Automation (friendly-automation) 2021-02-23 13:39:42.748-0600 Change 15427 merged by George Joseph: app_queue: Fix conversion of complex extension states into device states [https://gerrit.asterisk.org/c/asterisk/+/15427|https://gerrit.asterisk.org/c/asterisk/+/15427] By: Friendly Automation (friendly-automation) 2021-02-23 13:40:11.042-0600 Change 15397 merged by George Joseph: app_queue: Fix conversion of complex extension states into device states [https://gerrit.asterisk.org/c/asterisk/+/15397|https://gerrit.asterisk.org/c/asterisk/+/15397] By: Friendly Automation (friendly-automation) 2021-02-23 13:40:58.726-0600 Change 15428 merged by George Joseph: app_queue: Fix conversion of complex extension states into device states [https://gerrit.asterisk.org/c/asterisk/+/15428|https://gerrit.asterisk.org/c/asterisk/+/15428]