Summary:	ASTERISK-05321: [feature request] detect if any agents are available without answering call before first answer, and reject of not.
Reporter:	Iain W. Bird (birdwes)	Labels:
Date Opened:	2005-10-18 19:22:34	Date Closed:	2011-06-07 14:02:35
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	It would be useful to detect if no agents are available either because the all the Qs are full or there are no available agents before an answer at the start of IVR menus so that a "congestion" can be delivered to force redirection back to another external provider e.g. UK 0870 hunting services or to force back to rings leading to external SIP VM on a small setup with limited bandwidth.  To do this you could have an spare unanswered Q (containing agents for all Qs in the same incoming "line") and extend the Queue directive to have a "test" option (do this whilst Ringing) that checks for avalable agents without causing the call to be answered and go to MOH.  The test would never deliver QUEUE_TIMEOUT.  From my rudimentary checks this could be done by some fairly simple mods to queue_exec and join_queue in app_queue.c
Comments:	By: Donny Kavanagh (donnyk) 2005-10-19 17:17:26 This is possible today with an agi script or two, and some imagination.  Sure its not one command, but what can you do.  What you are asking for is an extra application to ask for the status of a queue, kind of like HasVoiceMail checks a VM box. By: Iain W. Bird (birdwes) 2005-10-20 12:43:32 Hi again, It just seems to make more sense to me to extend the command so that we're not going through layers of wrappers and glue code to get the same result when 99% of the work is already in join_queue.  I have made my own working test modifications to a local copy of app_queue.c to prove it in principle.  I am quite happy to clean, comment and go through the code submission procedures if others agree that it's a good idea to include this feature OR - should it really be instead another dialplan command call QueueTest instead?  Not having been a * user very long though I don't want to tread on any toes or mess up anybody else's design ideas.   My current test code and proposal for usage is that an option letter be added to Queue, such as '?' to indicate that it's a test and result comes out in QUEUESTATUS e.g. exten => 801,1,Queue(MainQueue|t?|||200) exten => 801,2,NoOp(${QUEUESTATUS}) exten => 801,3,GotoIf($["${QUEUESTATUS}" = "FULL"]?6:4) exten => 801,4,Queue(MainQueue|t|||200) exten => 801,5,Voicemail,u9999 exten => 801,6,Congestion By: Donny Kavanagh (donnyk) 2005-10-20 12:52:45 If you feel this is a valid feature, please fax a disclaimer to digium, and post your patch here (in diff -u format).  You can find instructions for that on http://bugs.digium.com and http://www.asterisk.org .  Please be aware however that since 1.2 is in final testing before release, that your patch will be flaged as post 1.2 and will not be incorporated until the next dev branch starts up.  This will not stop you of course from making the changes locally. By: Iain W. Bird (birdwes) 2005-10-20 15:11:51 After some consideration I think it would be best to give the feature a new command name instead of adding it as an option so I will post diffs when I have reworked the proof of concept as a separate command.  I don't want to confuse users with existing dialplan scripts. How about IsQueueJoinable as a name for the command? Will wait a couple of days to do some more thorough testing and just in case anybody else wants to have a say. By: Kevin P. Fleming (kpfleming) 2005-10-31 18:08:59.000-0600 How about just modifying the Queue() application to delay doing any sort of answer until it knows the call is actually going to join the queue? By: Iain W. Bird (birdwes) 2005-11-01 06:05:15.000-0600 Hi kpflemming, The reason I changed my mind about modifying Queue was so as to make it clear to dialplan script writers that the queue is not about to be joined, and that this is a control of flow command.  It also seems to me be clearer than tinkering with "Answer/pbx_builtin_answer" functionality which to is not really part of the queue app. I've now implemented IsQueueJoinable and will continue to test it on my system for a few more days before submitting it.  My current implementation does a n+101 jump if the queue can't be joined. By: Kevin P. Fleming (kpfleming) 2005-11-01 17:24:31.000-0600 Notes: 1) In CVS HEAD and Asterisk 1.2, we are no longer adding 'priority jumping' to applications. Instead, the preferred method of letting the dialplan know what happened is by setting a result variable, which app_queue does (QUEUESTATUS). 2) There is also a minor issue of 'atomicity'. If the IsJoinable app (function?) tells you the queue is joinable, but then it becomes unjoinable before you send the caller there, you will be back to the old behavior. Having the Queue() application do it solves this problem, because it will either join the queue or return after having decided definitively that it could not join the queue. Personally I think that changing app_queue to not answer the channel until it decides it needs to is by far the preferable solution, and it doesn't even need to be an option... we should just change it. Thoughts? By: Iain W. Bird (birdwes) 2005-11-02 08:34:31.000-0600 The function at present also returns QUEUESTATUS but I can remove the priority jump if people feel that it's not required or not the right style. Regarding atomicity, yes the status of the queue may change between IsQueueJoinable() and the later Queue(), but I don't see that as being an issue.  I don't want the caller to go through IVR menus before reaching any queue if none of the queues are joinable, which is why my view is that it's not appropriate to put the functionality in the Queue() command.  If a Background() message has to be played before you find out that the queue cannot be joined then it's too late to deliver a "congestion" because the call has already been answered.  This is another reason why I think it should be separate from Queue(). By: Iain W. Bird (birdwes) 2005-11-07 18:40:40.000-0600 Hi kpfleming, I am ready to submit patches.  Who can I contact about the disclaimer.  There is an issue that needs to be resolved. By: Kevin P. Fleming (kpfleming) 2005-11-07 19:07:43.000-0600 The process is outlined in the bug posting guidelines that you can find from the main Mantis page. By: Kevin P. Fleming (kpfleming) 2005-11-15 20:50:56.000-0600 Suspended awaiting further input from the poster.