[Home]

Summary:ASTERISK-03739: [patch] Detailed dialplan result from Queue() application
Reporter:Kevin P. Fleming (kpfleming)Labels:
Date Opened:2005-03-22 11:43:06.000-0600Date Closed:2005-04-04 02:32:13
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) queue_detailed_status_rev3.diff.txt
Description:This patch adds detailed status results from the Queue application when the caller either cannot enter the queue or if they leave the queue for various reasons.

It also slightly changes the behavior of the 'joinempty' and 'leavewhenempty' options; previously, these options treated the queue as 'empty' if it had no members, the members were all invalid (according to their channel drivers) or the members were all unreachable (according to their channel drivers). However, many applications want to be able to treat 'no members' and 'all members unreachable' separately for call routing purposes, so this patch separates those two states.

It sets the QUEUESTATUS variable on exit, to one of the following values:

FULL - the queue is full
TIMEOUT - the caller timed out of the queue
JOINEMPTY - the queue has no members and 'joinempty' is not turned on
JOINUNAVAIL - the queue has no reachablemembers and 'joinunavailable' is not turned on
LEAVEEMPTY - the caller was in the queue, but all the members left the queue and 'leavewhenempty' is turned on
LEAVEUNAVAIL - the caller was in the queue, but all the members became unreachable and 'leavewhenunavailable' is turned on


****** ADDITIONAL INFORMATION ******

Disclaimer is on file.
Comments:By: Mark Spencer (markster) 2005-03-22 13:37:46.000-0600

Does this change the default behavior if joinwhenempty / leavewhenempty is enabled?  Most people have reported it as a bug that having a queue with agents nog logged on (but in the queue) was not treated as empty.  Perhaps we can just have an option like "joinwhenempty=reallyempty" or something so that it's just another value for the existing options rather than adding additional options -- this takes care of backwards compatibility as well.
By: Mark Spencer (markster) 2005-03-22 13:38:02.000-0600

Also, the variables should be listed in README.variables, too.
By: Michael Jerris (mikej) 2005-03-22 14:28:52.000-0600

I just have to say that this feature rocks!
By: Kevin P. Fleming (kpfleming) 2005-03-22 14:30:54.000-0600

Based on my reading of agent_devicestate (which is very hard to follow), I don't understand why that's not working right now. Currently, app_queue will treat a queue as 'empty' if it has no members, or if all the members are AST_DEVICE_INVALID or AST_DEVICE_UNAVAILABLE. chan_agent returns AST_DEVICE_UNAVAILABLE for agents that are not logged in, so that _should_ be working correctly nw.

However, this patch would allow the user to be able to tell the difference between the agents being not present at all vs. them being not logged in. Nobody that I have talked to about this had any worries about treating 'joinempty' differently than it is handled today, but I could easily modify the patch to automatically enable 'joinunavailable' if 'joinempty' is turned on and 'joinunavailable' is not specified.
By: Mark Spencer (markster) 2005-03-22 18:07:58.000-0600

joinempty today is the union of your proposed new joinempty and joinunavailable right?
By: Mark Spencer (markster) 2005-03-22 18:08:18.000-0600

How about joinempty=strict / leaveempty=strict
By: Kevin P. Fleming (kpfleming) 2005-03-22 18:25:13.000-0600

Yes, joinempty today is the union of the new version.

I don't mind making joinempty (and leavewhenempty) multi-valued, as long as we can keep the distinct result codes in QUEUESTATUS. Having them be two separate values,  though, allows the user the maximum flexibility (even though one of the possible combinations doesn't really make any sense).

So, there are two choices on the table:

1) leave the options separate, and automatically set the 'unavailable' options to the same value as the 'empty' options if they are not specified

2) combine the options, with the possible values being 'no', 'yes' and 'strict'

Pick what you like and I'll update the patch.
By: Mark Spencer (markster) 2005-03-23 23:39:35.000-0600

My vote is for #2, fewer options, no unusual side effects (the setting of one without the other)
By: Kevin P. Fleming (kpfleming) 2005-03-24 00:00:15.000-0600

OK, will do.
By: Mark Spencer (markster) 2005-03-26 01:27:57.000-0600

*poke*
By: Kevin P. Fleming (kpfleming) 2005-03-26 19:13:42.000-0600

Sorry, I was out of town for a couple of days. Will post an update tonight (MST, not EST!).
By: Kevin P. Fleming (kpfleming) 2005-03-28 11:30:10.000-0600

OK, new version uploaded with the requested config change made.

Unfortunately I had already merged this work with some other app_queue cleanup work, so this patch now includes more changes (but no functional differences). They are:

- The use of the 'flags' structure from utils.h is removed, in favor of using C bitfields (someone needed to provide an example conversion, so here is one). I also eliminated unnecessary flag definitions (see the next item). This makes the code easier to read and makes the use of multi-valued flags much clearer (which is why I went this direction, since 'joinempty' now has three possible values).

- try_calling used to process the options string once for each member it was calling, even though it did not change. Then, it used the options to set flags in flags structure in the localuser structure, so that it could pull them back unchanged when wait_for_answer completed. Finally, it translated the 'tThH' options into internal flags, only to later to translate them into ast_bridge_config flags. All of this is now done one time per batch of member calls, without extra translation/passing.

- The "Can't change device with no technology" message is eliminated, since app_queue is not the cause of this (nor is the user) and it causes unnecessary support questions.

- Code reformatting in various places and comment rewording

- Removal of pointless "PHM ..." comments as per coding guidelines
By: Kevin P. Fleming (kpfleming) 2005-03-28 11:34:19.000-0600

rev3, with README.variables updated (doh!)
By: Mark Spencer (markster) 2005-03-28 14:57:05.000-0600

Added to CVS, but I don't *generally* support the use of bitfields versus flags due to the ease of copying of flags, but in this case it wasn't important.
By: Russell Bryant (russell) 2005-04-04 02:32:13

not included in 1.0