Summary:	ASTERISK-03731: [PATCH] Allow user to exit out of the position announcement with a keypress
Reporter:	Ted Cabeen (secabeen)	Labels:
Date Opened:	2005-03-21 14:49:54.000-0600	Date Closed:	2008-01-15 15:34:40.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_queue_interrupt_announce_cvs.patch
Description:	This patch makes it possible to press the single-digit extensions defined by the context argument in queues.conf during the position announcement as well as during MOH.  Any keypress will end the position announcement (like in the Background application) and compare the key pressed to the context defined for the queue. I also have a Stable branch patch for this feature.  If you want it, let me know. ****** ADDITIONAL INFORMATION ****** Disclaimer not on file.  Will be sent if necessary.
Comments:	By: Mark Spencer (markster) 2005-03-21 15:16:40.000-0600 We would definitely need a disclaimer for this, thanks! By: Ted Cabeen (secabeen) 2005-03-21 16:18:37.000-0600 Just faxed through the disclaimer. By: Brian West (bkw918) 2005-03-23 23:53:32.000-0600 Doesn't app_queue do this already? /b By: Kevin P. Fleming (kpfleming) 2005-03-24 00:01:30.000-0600 No, it doesn't. You can exit during moh or ringing using the defined exit keys (from the context), but not during the position announcements. By: Kevin P. Fleming (kpfleming) 2005-03-24 00:15:33.000-0600 There is a logical problem with this patch that needs to be addressed: as it's written right now, if the caller presses any key at all during the position announcement, the playback will be interrrupted. However, if that key is not a valid 'exit key' for that queue, then the moh/ringing will just immediately restart. I think the best solution for this is to pass the qe pointer all the way down into play_file(), so that it can call valid_exit() on the result of ast_waitstream(). If ast_waitstream() returns a >0 value that is not a valid exit key, then it should just be called again until it returns 0. If it _does_ return a valid exit key, then play_file() can return that to say_position(), which will then process it appropriately. However... play_file() is also used to play prompts/messages to the agent channel, where there is no 'qe' pointer. That may necessitate making a new version of play_file() called play_file_to_caller() that does the steps above. By: Ted Cabeen (secabeen) 2005-03-24 12:00:09.000-0600 Right.  Here, that's alright with us, as we use that to allow the caller to skip the message on later calls.  Since calls can't be handed to agents during the position announcement, this is useful with long position announcements.  Passing the qe all the way down means that there isn't a way for the caller to expedite his opportunity to go to a queue member.   In fact, if we passed the qe all the way down and restarted the position announcement if an non-recognized key was pressed, a malicious caller could DOS the queue by pressing the button on every message, thus preventing themselves from ever being passed to a queue member and holding everybody else in the queue up behind him.  That's not really good either. By: Kevin P. Fleming (kpfleming) 2005-03-24 12:58:50.000-0600 No, I'm not suggesting that you start the position announcement over on an invalid key, just don't stop it. In other words, inside play_file(), instead of just  res = ast_waitstream(chan, AST_DIGIT_ANY); it would be something like:  while (!res) {    res = ast_waitstream(chan, AST_DIGIT_ANY);    if (!valid_exit(qe, res))      res = 0;  } That way, the stream keeps playing even if invalid keys are hit. If a valid key is hit, then the announcement stops. The issue with not being able to deliver a caller to an agent while the announcement is playing is entirely separate; certainly most callers are not going to have any clue at all that stopping the announcement increases their chances of being answered, and if you tell them that during the announcement, you'd be better off to just eliminate the announcement :-) It would be possible to solve this problem by having the position announcement be played to the channel via a separate thread, so that the main thread could "grab" an agent and wait until the announcement finishes playing to connect the caller, but then the agent would be left 'hanging' while that happened, so I don't think that would be a good solution. By: Ted Cabeen (secabeen) 2005-03-24 13:31:33.000-0600 Ahhh.  Yeah, that would work well.   Ideally, you would be able to pass a caller to an agent if one became available during the position announcement (interrupting the position announcement to do so), but that would be a more substantial rewrite of the position announcement code than what we're discussing here.  Your solution looks good. By: Kevin P. Fleming (kpfleming) 2005-03-31 15:12:20.000-0600 Any updates? Have you tried implementing my proposed solution? By: Ted Cabeen (secabeen) 2005-04-04 17:46:05 Not yet.  I'll try to get to it this week. By: Michael Jerris (mikej) 2005-05-02 08:12:43 secabeen:  any updates on this? By: Kevin P. Fleming (kpfleming) 2005-05-15 01:38:04 I committed this to CVS HEAD with the mods to avoid exiting if the pressed key is not a valid exit key (it will still interrupt the message playing when the key is pressed, though). Thanks! By: Digium Subversion (svnbot) 2008-01-15 15:34:40.000-0600 Repository: asterisk Revision: 5673 U   trunk/apps/app_queue.c ------------------------------------------------------------------------ r5673 | kpfleming | 2008-01-15 15:34:39 -0600 (Tue, 15 Jan 2008) | 2 lines allow caller to exit during position announcement by pressing valid exit key (bug ASTERISK-3731, with mods) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5673