Summary:	ASTERISK-22958: app_queue members state interface has issues when using a hint through an included context
Reporter:	Jaco Kroon (jkroon)	Labels:
Date Opened:	2013-12-10 08:17:52.000-0600	Date Closed:	2018-01-02 08:30:32.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:	11.6.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) queue_ext_state.txt
Description:	Whenever members are not idle when app_queue reloads then the state goes into a bad state whereby calls will never be sent to those members.  I've also seen cases where the state will simply stop updating completely, at the moment: gabriel ~ # asterisk -rx "queue show uls-queue-support" uls-queue-support has 0 calls (max unlimited) in 'leastrecent' strategy (0s holdtime, 0s talktime), W:10, C:0, A:0, SL:0.0% within 60s   Members:      X109/Conrad (Local/109@xdial from hint:109@hints) with penalty 20 (ringinuse disabled) (Not in use) has taken no calls yet      X105/Adriaan (Local/105@xdial from hint:105@hints) with penalty 20 (ringinuse disabled) (Not in use) has taken no calls yet      X104/ULS Pieter (Local/104@xdial from hint:104@hints) with penalty 30 (ringinuse disabled) (Not in use) has taken no calls yet      X103/ULS Kevin (Local/103@xdial from hint:103@hints) with penalty 100 (ringinuse disabled) (Not in use) has taken no calls yet      X102/Jaco Kroon (Local/102@xdial from hint:102@hints) with penalty 200 (ringinuse disabled) (Not in use) has taken no calls yet      X111/Nadine (Local/111@xdial from hint:111@hints) with penalty 10 (ringinuse disabled) (Not in use) has taken no calls yet   No Callers Even though I (X102) is currently on the phone.  The hint, according to the dialplan is: [ Included context 'hints-uls' created by 'pbx_config' ]  '102' =>          hint: SIP/102                                 [pbx_config] The fact that it's an included context seems to be what's throwing it off.  Thus on reload I'm guessing a slightly more intelligent mechanism needs to be used to set state_exten, or alternatively the state should not be duplicated into the member structure.
Comments:	By: Rusty Newton (rnewton) 2013-12-12 18:48:59.648-0600 Have you tested with hints not in an included context to see if that does factor into it? By: Jaco Kroon (jkroon) 2013-12-13 02:06:53.280-0600 I have now, and that does indeed fix it.  I've adjusted my code to compensate for this when generating the config, but I still think this should either be documented at least, or preferably fixed.  I'll leave it in your hands, since my use-case now works I have no further interest in this. By: Rusty Newton (rnewton) 2013-12-16 17:44:26.823-0600 If there is strange behavior here, then it would be nice to either fix it, or if anything have it documented as you said. I'm a bit confused on the original problem description. I attempted reproduction, setting up queue members with local channels and their state interfaces derived from the hints in an included context. After configuration, I made a call into the queue, answered it from one of the queue members and then reloaded app_queue.so while idle. I tried this several times and couldn't get any of the members to go into a strange or bad state. I tried with both types of includes. A confusing aspect is that regardless of doing a "include =>" or a "#include", dialplan show does not show the context as an "Included context". Can you describe your dialplan configuration for this machine and what type of include you used? If you don't expect reproduction to be possible, I'll just close this out as a another app_queue mystery! By: Jaco Kroon (jkroon) 2013-12-18 12:27:08.459-0600 Try this in dialplan: [hints] include => subhints [subhints] exten => 123,hint,SIP/123 Then in queues.conf: member => SIP/123,10,Whatever,hint:123@hints If I'm correct then the "state" for the member will always be exactly what it was when the reload occurred, so if the hint was "idle" at time of reload, it will remain idle, even if the member is on the phone, if the member was busy it would remain busy even when the member goes idle. If you change the member definition to: member => SIP/123,10,Whatever,hint:123@subhints Then it should all work. By: Rusty Newton (rnewton) 2013-12-30 17:19:02.381-0600 I was unable to reproduce the issue with symptoms as described, but I was able to reproduce what is likely the same root issue, but with a different symptom. I tested in SVN-branch-11-r404457 With an app_queue member configured with a state interface as described by you; the queue member's state (as shown in "queue show <queuename>" ) will not reflect the extension state of the hint when it is referenced through an included context. With my case the queue member appears to always remain as "Not in use" and never changes regardless of a reload or not. When I set the state interface to a hint that was not inside an included context, it functioned as expected. Attaching queue_ext_state.txt which shows the behavior while 6001 is on an outbound call in both scenarios. The same behavior happened with inbound calls, and even when swapping the SIP/6001 member for a local channel. As for my reproduction it just looks like app_queue fails to get state when the state interface is an included hint. I never really tested with reloads of the module as I couldn't get state to work with an included hint state interface at all. Still looks like a bug, or at least something that should be documented. By: Jaco Kroon (jkroon) 2014-01-01 10:30:42.874-0600 Rusty, I think you've got it (You are absolutely correct that it does not work at all), if you're on a call *whilst* the reload happens, you should not that it goes into a non-"Not in use" state and stay there.  Would be very nice if it can be fixed, but I don't think it's critical.  Just document that the hint should not be in an included context from the referenced context.  In other words, if the hint is really 123@bar, and bar is included from foo you should still use 123@bar and not 123@foo. Thanks for your efforts. By: Joshua C. Colp (jcolp) 2017-12-19 07:15:18.108-0600 Have you tried this under Asterisk 13 at all, or just 11? By: Asterisk Team (asteriskteam) 2018-01-02 08:30:32.039-0600 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines