Summary:	ASTERISK-02572: Patch to modify queue message system
Reporter:	Chris A. Icide (cicide)	Labels:
Date Opened:	2004-10-08 22:31:49	Date Closed:	2011-06-07 14:10:36
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_queue.patch
Description:	This patch makes the following changes: When there are no callers in a queue, with agents available, the agents are polled before any messages are played. Two messages have been added, message 1 and message 2.  These messages are played in order as defined by the variables: announce-message-1 announce-message-2 in the queue.conf file, these can be defined per queue.  If message 1 is set to 0, neither message will be played.  If message 1 is not 0 and message 2 is zero only message 1 will play.  If both are non-zero, both will play. The message 1 variable defines the amount of time from start of the queue before the message will play, and the amount of time once message one has played, that it will play again, either after itself or if message 2 is set, after message 2.  The message 2 variable defines the amount of time in seconds that message 2 will play after message 1. If at any time the position announcement is less than 10 seconds away, the next scheduled message will play after the position announcement, not before. Also in the config file, the two variables: queue-message-1 = <sound file location> queue-message-2 = <sound file location> Please pardon any poor coding.  I have never written c code before (besides an attempt in 1996 or so to learn from a manual, which I never had time for).  I just took a look at the app_queue.c file, and made an attempt.  Anyone who wants to clean up the patch, I more than welcome it.
Comments:	By: Brian Roy (chuji) 2004-10-09 07:14:53 Can you transfer out during one of the messages? That would really help me out a lot. That way, I can have a message saying, "Thank you for continuing to hold, if you prefer to leave a message, please press X now. Otherwise, your call will be answered in the order it was received.". -Chuji By: Olle Johansson (oej) 2004-10-11 13:20:50 Please read bug guidelines. You need to add the diff as a *file*, not include it in the actual bug report. Also, you need to confirm that you've sent in a disclaimer to digium. By: Chris A. Icide (cicide) 2004-10-12 22:10:27 Chuji: I am submitting the patch as is.  I will take a look and see if I can change the code to accept a keypress while either the position, hold time, or message announcements are playing, but I cannot promise anything - see my c programming disclaimer above. By: Chris A. Icide (cicide) 2004-10-12 22:17:29 Disclaimer sent to Digium via fax By: Kevin P. Fleming (kpfleming) 2004-10-12 23:41:57 I had posted a patch to accomplish _part_ of what this patch does, but this patch has more functionality. However, I think the implementation of it (syntax wise), could be better. How about something like this (in queues.conf): queue-message => message1,60 queue-message => message2,90 queue-message => message3,45 The file could list any number of messages, to be played in the order they are found in the queues.conf file. The second parameter would be a time specification, like what this patch already does. This would replace all current queue messages played to the caller during their "hold time" _except_ the position announcement, unless we want to make a "magic" message file name that actually causes the position announcement to be played. Comments? By: Chris A. Icide (cicide) 2004-10-13 13:30:56 There are two other things I would like to add to this as well as making the configuration implementation better.  Specifically if a context exists for leaving the queue if a caller presses a button, then we should accept and act on a pressed button during the streaming of messages.  The queue system does not currently do that. As for making the changes, like I said above, I'm not a c coder, so please feel free to modify the patch as needed. By: twisted (twisted) 2004-10-27 17:08:54 What's the status here? By: Chris A. Icide (cicide) 2004-10-27 20:12:04 I have the patch in operation in 2 locations with no issues. kpfleming made a good suggestion above, however, I don't think I have the combination of time and skill to implement his suggestion at this time. edited on: 10-27-04 20:33 By: Kevin P. Fleming (kpfleming) 2004-11-01 17:20:50.000-0600 I am working on this right now, will have a new patch (lightly tested) in the next couple of hours. By: Russell Bryant (russell) 2004-11-09 00:47:59.000-0600 Also, how will this patch handle an empty path? It would be nice if the user didn't put anything, it wouldn't play the message. By: Kevin P. Fleming (kpfleming) 2004-11-09 08:37:38.000-0600 The delay in posting this patch is due to a problem getting the new system to be able to fully emulate the old one... Since there are some interested parties here, I'll post what the issue is and get your opinions. As it stands today in CVS HEAD, the admin can specify that the position announcement never be played, be played once only, or be played periodically. In addition, if the "periodically" option is selected, in actual fact the announcement might be played more often than specified, because the code will play the announcement every time the caller moves down in the queue (nearer the head), but no more often than 30 seconds (by default). My new configuration works like this (as an example): queue-message => POSITION,60,once queue-message => POSITION,0 queue-message => HOLDTIME,0 queue-message => queue-thanks,60 This configuration would play the position announcement immediately upon entry to the queue, then drop that message from the list. After a 60 second delay, the position announcement would be played again. After that, the caller's expected hold time would be played. Immediately following, the "thanks" message would be played. Since the end of the list has been reached, the code will go back to the top of the list after a 60 second delay. Seeing as the first message was removed from the list, this means the position/hodltime/thanks loop will continue every 60 seconds. The message list could, of course, be much longer and with a variety of delays between messages. What won't happen, though, is any "shortcut" of the delay when the caller changes position in the queue. With this arrangement, the behavior is deterministic, and not dependent on any outside influence (except for the passage of time). What are your thoughts about this issue? As I see it, the current documentation doesn't explicitly state that this "early" position announcing will be done, so I could make a case for changing that behavior without it being a regression. On the other hand, lack of documentation doesn't mean that users aren't expecting it to continue that way... but I can't find a simple way to extend this new syntax to support the existing behavior. Comments? By: Mark Spencer (markster) 2004-11-16 23:57:35.000-0600 I don't really think we need to announce more often than what's listed regardless of the queue.  Therefore if that behavior changes in CVS head I think i'm okay with that. By: Kevin P. Fleming (kpfleming) 2004-11-17 07:28:11.000-0600 OK, then based on Mark's statement that this behavior change is acceptable (and will be documented in the patch, of course), I'll clean up the patch and get it posted here in the next day or so. By: brc007 (brc007) 2004-11-30 02:18:55.000-0600 kpfleming, Have you had a chance to get the patch you mentioned ready? Thanks, --Housekeeping By: Kevin P. Fleming (kpfleming) 2004-11-30 09:28:52.000-0600 Yes, it's nearly ready to be posted. I will do so tomorrow, after I get a little more time to test it out. For the benefit of the lurkers, I'll document how it works here, because I've expanded its scope quite a bit since the last time I posted here. There is a new configuration file, queue-messages.conf. A sample format is: [globals] youarenext => ... [foobar] position => 0              ; seconds to delay message => queue-thanks,0  ; file name, seconds to delay holdtime => 15,60          ; rounding seconds, seconds to delay Each item can be suffixed with "once", to have it skipped after its first use for any given caller. There can be an unlimited number of named message lists (scripts) in queue-messages.conf. In queues.conf, each queue can now have: messages => foobar This specifies the default message list to be played to callers in that queue. If this is specified, then use of announce-frequency, announce-holdtime, announce-round-seconds, or any of the queue-* items (to specify sound file names) for that queue will generate a warning and be ignored. If the "messages" parameter is _not_ specified for a queue, an internal message list is created from the existing defaults and specified parameters, so the patch is totally backwards compatible (except for the issue previously mentioned in this bug). Finally, the Queue() application can now react to a QUEUE_MESSAGES channel variable; if this is set to the name of a message list from queue-messages.conf when the Queue() app is called, the caller will be played that message list, not the one specified as the default for that queue. This allows different message lists to be played to different callers, even in the same queue. By: brc007 (brc007) 2004-12-07 21:36:36.000-0600 Reminder sent to kpfleming *poke*... Any updates? Thanks, this sounds like a great patch! --Housekeeping edited on: 12-07-04 22:44 By: Kevin P. Fleming (kpfleming) 2004-12-07 21:40:40.000-0600 No worries, I don't mind being poked. I have the patch working reasonably well here, but am debugging some memory leak issues. I'll know more in a few hours. By: brc007 (brc007) 2004-12-07 22:45:07.000-0600 Great! Thanks for the update :) By: twisted (twisted) 2004-12-18 19:56:40.000-0600 cicide, kpflemming requested close of this bug until a later date, I will not allow this to happen without your approval, since you are the origional poster.  Please make a decision and post here.  Thanks! By: Kevin P. Fleming (kpfleming) 2004-12-18 20:03:05.000-0600 The patch I have been working on to provide a new queue message management system will not be posted as part of this bug; it's too big and complicated to make it work with app_queue as it stands right now. My inhouse version of app_queue has a vast number of improvements (code cleanup and optimization, not new features), and I don't want all of them to appear in a "messages" patch, since none of them are really related to that. Instead, I will begin posting patches to bring CVS app_queue closer in line with my inhouse version; once that is complete (hopefully), then the new message management system will be a much easier merge (and the patch will be far easier to understand and read). By: Olle Johansson (oej) 2004-12-27 12:27:05.000-0600 Where are we with this bug - should it stay open, does it apply to current cvs? By: twisted (twisted) 2005-01-01 22:31:43.000-0600 Closing, since poster failed to respond.  kpfleming is handling this, and already submitted a bunch of patches to cvs regarding app_queue.