| Summary: | ASTERISK-18945: Review and refine the 'ignorebusy' option in app_queue | ||||||
| Reporter: | Leif Madsen (lmadsen) | Labels: | |||||
| Date Opened: | 2011-11-30 17:01:54.000-0600 | Date Closed: | 2013-04-25 12:03:44 | ||||
| Priority: | Major | Regression? | Yes | ||||
| Status: | Closed/Complete | Components: | Applications/app_queue | ||||
| Versions: | 1.8.7.1 10.0.0 | Frequency of Occurrence | |||||
| Related Issues: |
| ||||||
| Environment: | Attachments: | ||||||
| Description: | After reviewing ASTERISK-18754 with Mark Michelson, it became evident that the 'ignorebusy' option appears to be interfering with some operations in app_queue, and that it needs to be better reviewed and likely better documented. Per IRC: <leifmadsen> putnopvut: I know you probably don't really remember, but is there a reason why when you have strategy=ringall in app_queue that ringinuse=yes isn't applicable? <leifmadsen> I'm talking about the note in app_queue.c on line 2923 (Asterisk 10 branch) <leifmadsen> this is in relation to: https://issues.asterisk.org/jira/browse/ASTERISK-18754 <putnopvut> I think you may be reading too much into that comment. The function tries to determine if any members are available to answer the call. When ringall is used, then as soon as there is at least one available member, then that answers the question that "yes, there are indeed members to call." It appears in that function that if ringinuse is set to "yes" for the queue, then we should consider the member to be available. Now, <putnopvut> the fact that the calls are not delivered to the busy extension likely has to do with some later logic which extensions to call. I'll have a look at the ring_entry and ring_one functions to see if there is anything there that looks suspicious. <putnopvut> leifmadsen: okay, possible reason found. Do you have any idea what the "ignorebusy" option is? <leifmadsen> well, I didn't see it in queues.conf -- but I did notice it as an option to Queue() <putnopvut> It appears that for dynamic realtime members, if a specific value for "ignorebusy" is not provided, it is assumed to be enabled. This doesn't appear to be the case for static members. <putnopvut> That *may* be what's causing this to happen, because the ring_entry function will not ring a busy member if either the ringinuse is set to "no" or if the member has ignorebusy set to true. <putnopvut> You'd probably want to look in the queues.conf.sample file for more info on it. <infobot> leifmadsen meant: funny enough, queues.conf.sample does not include 'ignorebusy' <putnopvut> leifmadsen: it does for me, in that it is mentioned, but an example usage is not shown. <putnopvut> It appears to be a per-member setting of ringinuse. <putnopvut> So in other words, if you have ringinuse set to yes for the queue, you can set ignorebusy for a specific member in order to have that one skipped. <leifmadsen> what about when you use dynamic members set from the CLI? <putnopvut> Let me check about that. <leifmadsen> wonder if that is available from a function or AddQueueMember() <leifmadsen> does not show in the documentation <putnopvut> It appears that you cannot set that via AddQueueMember() <putnopvut> leifmadsen: it appears that irroot added the ignorebusy option in rev 325483 <leifmadsen> hmmm, ok I'm going to have to ask him to better document it <putnopvut> Along with a few other things. <putnopvut> And I'm correct about what ignorebusy does, btw. <leifmadsen> putnopvut: it sounds like it should be enabled for static peers too <leifmadsen> not sure why it is enabled for one type of peer but not another <putnopvut> Yeah, and I'm not even sure if it's possible to set it on static members. <putnopvut> Like even using queues.conf <leifmadsen> this seems like a regression to me <putnopvut> Yeah, it's very inconsistent. You can only set the option for dynamic realtime peers, and it's on by default for them but no other types. <putnopvut> Oh, AND the ignorebusy option does not persist with persistent members. | ||||||
| Comments: | By: Rusty Newton (rnewton) 2013-04-25 12:03:44.674-0500 Fixed by ASTERISK-19536 | ||||||