Summary:ASTERISK-00211: [patch] Announce callers position in queue every x seconds / service level reporting / queue timeouts / hold time estimation
Reporter:Brian West (bkw918)Labels:
Date Opened:2003-09-03 10:54:05Date Closed:2008-01-15 14:46:58.000-0600
Versions:Frequency of
Environment:Attachments:( 0) app_queue_patch_1_07.tar
( 1) app_queue_patch_1_07a.tar
Description:This patch will announce the callers postition in the call queue every x seconds set by announcefreq in queues.conf or set to 0 to disable it.
Comments:By: Brian West (bkw918) 2003-09-03 10:55:06

These two files needed:


"You are caller number"


"waiting to speak with a representative"

edited on: 09-03-03 10:36

By: John Todd (jtodd) 2003-09-03 12:37:27

I've added these words to the list of words to go to Allison shortly.

By: Brian West (bkw918) 2003-09-03 14:39:13

now I think i'm done with the patching for now.. any more changes will be done after v3 of this patch is put in cvs.  

Per queue config options:
announce-message = filename ie "You are caller number"
announce-continue = filename "waiting to speak to a representative."
announce-position = yes|no do you wish to announce position
announce-frequency = how many seconds between anouncements 0 disables all anouncements

if announce-position is set to no and announce-frequency is is higer than 0 it will play announce-continue only.  You could just put a message that says "Your call is very important to us please hold for the next available representative"

PS mad propz to gunk for his assistance with this patch! :P

By: gunk (gunk) 2003-09-03 15:02:10

Isn't it amazing what 2 idiots can come up with when they stick their heads together?

To clarify the config options, I'm attaching a diff for queues.conf.sample

By: davetroy (davetroy) 2003-09-07 10:49:33

I uploaded my version of a set of similar modifications -- it is in pos+holdtimepatch.txt.  I don't want to confuse the issue, but rather suggest that we work towards a common approach for these modifications.  This version has the advantage of packaging up all the media (moh stop/start, playfile) into functions and standardizes the logic for holdtime/position announcement in say_position().  Believe there is some merit to that;  perhaps we can merge these two trees together before things get too weird.

Now we need to have the ability to fail out of a queue after X many timeout/retry cycles and/or seconds, which I am working on as well.  Suggestions appreciated...

By: davetroy (davetroy) 2003-09-07 10:57:43

I think my upload got htmlized; here is a direct link:

Here are some notes which were posted to the mailing list.



I just finished doing both of these mods myself.  The patch is available


You might take a look and see if it helps you at all.  I make no claims
that mine is a definitive version;  I just did it to suit my own needs.

A couple of things you might want to watch out for with your own coding:

- someone had posted a similar patch in June (from pbx.usedontmiss.com)
from which I borrowed some ideas, however, this version made the mistake
of announcing queue position from inside a thread-locked code section,
which will interrupt music-on-hold for all callers while their positions
are announced.  My version does the announcements outside of the
thread-lock.  See end of leave_queue.

- If you are caller #4 and callers #3 and #2 leave in rapid succession,
you'll be trying to announce position to caller #4 twice, quickly,
possibly interleaving your announcements.  To solve this problem, no
announcement is made if a position announcement was last made within the
last 15 seconds.  See the first couple of lines of say_position.

My version operates along these lines:

- To turn on position/holdtime announcements, just define
'announcetimeout' in queues.conf; position/holdtime announcements will be
made at that interval.

- The guts of the operation is in say_position and get_avg_holdtime;
changes to the rest of the code have been minimized.

- No position/holdtime announcement is made if the caller is the only
caller in the queue when they enter the queue.

- A special 'you're next' announcement is played when position == 1

- Holdtime is only announced if it is 4 minutes or greater; this is
arbitrary and could be rolled into a configurable queues.conf setting.

- You need to add the following files to /var/lib/asterisk/sounds:

  YouAreNext   "You are now first in line; your call will be next"
  ThereAre     "There are currently..."
  CallsWaiting "Calls Waiting"
  AvgHoldTime  "The approximate average hold time is currently..."
  Minutes      "Minutes"
  ThankYou     "Thank you for your patience"

It would be cool if we could get Mark to have Allison record these files
for distribution with the package, once this family of features is
committed to app_queue.

I like the idea of rounding up to "under 5, under 10, under 15"
announcements as well, as it would sound less cheesy and be better at
setting realistic, but not exact, holdtime expectations.

I also want to see the ability to fail out of a queue (perhaps defined in
terms of X number of retry/timeout cycles) and will be working on this
today some.

Seems like there are several people working on this family of problems
(pos/holdtime/fail out) and it might make sense for us to work together
some and standardize our approach.  Otherwise we're going to end up with 5
versions of app_queue.


edited on: 09-07-03 10:44

By: davetroy (davetroy) 2003-09-07 15:03:08

After some more work I've got a much better patch to post:

This cleans up a bunch of the position announcement logic and code placement and makes more sense overall.  I also added the queue timeout facility (queuetimeout in queues.conf) discussed previously.  This is a little bit different from what was done in outtolunc's patch in Bug ASTERISK-192, but is the same basic idea.  I think it's a tad cleaner; thanks to him for showing exactly where to put the logic.

From here playing with the hold time logic/config parameters should be straightforward.  Play with it and let's see if we can't agree on a common approach.

By: Mark Spencer (markster) 2003-09-07 18:29:14

Looking good.  I'm not sure this defition of average hold time makes the most sense.  Presumably the average hold time has something to do with the average amount of time that callers have had to wait for the duration of their time, not the average in the queue, where adding new people would actually *reduce* the average hold time...

By: Brian West (bkw918) 2003-09-07 19:27:30

  Thats the reason gunk and I didn't add the average wait times into the patch we did because 1. Its hard to calculate.  2. how can it be correctly calculated.

Also now that I think about it qe->pos +1 would be the callers true position.


By: davetroy (davetroy) 2003-09-07 20:41:44

Agree that calculating an accurate hold time estimate based only on people presently in the queue is difficult/impossible.  More likely you really do want something like a rolling window, such as John Todd suggested, which is a bit more sophisticated and would have to be maintained over the course of time; though there are instances where it might not make much sense either.

A busy period could push your rolling window time up to 30 minutes, but you might only have two calls in the queue, and the first call might only have a 1 min hold time.  Telling the user that they have a 30 min est hold time seems sort of silly in this case, so some logic has to be be built around when to dismiss/correct a rolling window estimate.  How do the commercial ACD apps do this today?  Anybody know?  I'm sure there's a statistical method we could use to yield this.

I could see adding 'avgholdtime' as a queue property and maintaining that over the course of the day; that's probably the place to do it.  Meantime the version I posted gives some at least a number to work with that, I think, gets more accurate as the person stays on the call longer.  My primary motivation was to give a number -- any number.  Time now to figure out how to make it as correct as possible.

Brian, I guess you're saying qe->pos+1 is the true position because you have to count the call that is currently being serviced by the agent?

By: Brian West (bkw918) 2003-09-07 20:47:00

yes qe->pos+1 because you have to count the call being serviced.

By: davetroy (davetroy) 2003-09-07 20:53:41

Not sure that's relevant if you have N agents; does position then become qe->pos+N?  I'm looking at it from the perspective of the number of calls waiting to be serviced, I guess;  1 is next, 2 is second to next, etc.

By: davetroy (davetroy) 2003-09-09 08:20:56

OK, I think I have something even better now.  My dad designed an electronic altimeter in the 80's that used a smoothing algorithm to keep the altitude needle from fluctuating wildly.  It's essentially a recursive boxcar (moving window) filter that enables you to store one filtered value; old values get logarithmically divided out, and new values get incorporated in.  You can change the weighting of new vs. old by changing the filter's coefficient.  The whole thing can be done with shifts, adds, and subtracts, so it's lightweight and elegant.

That said, this allows us to store our queue holdtime as a single queue property, obviating the need for an array, and giving us an easy way to read and update hold time.

A patch implementing this approach is here:

To better understand the filter's behavior, I put together a graph and spreadsheet to model it:

I am running this now and it seems to work quite well.

I decided that there is no better indicator of holdtime than filtered historical data, so I am no longer making any attempt to analyze the current queue members' hold times.  Their hold times will get incorporated in as they are answered.

I decided to include abandoned calls in the holdtime calculations; when a call is abandoned their holdtime is calculated into the queue holdtime.  I am debating whether this is a good idea.

Because we are now storing an aggregate, per-queue holdtime value, this is easy to display and read.  I added it to the 'show queues' output, in a non-obtrusive and compatible way.

Comments welcome; I think we're getting close on this stuff...

By: davetroy (davetroy) 2003-09-09 11:27:11

I made a couple of small fixes and also added a counter for completed/abandoned calls per queue; see show queues output.

Get a new copy of patch from link above.

By: gunk (gunk) 2003-09-09 11:56:13


I'm kinda liking where you're going with this.  Would you mind incorporating the configuration variables that bkw and myself came up with in our patch?  Also, I don't know that I like 'announcetimeout,' as it's not setting a timeout, it's a setting for 'how often.'

Configuration options should include (at a minimum):

announce-frequency=seconds   (default 60)
announce-position=0|1|no|yes (default yes)
announce-message=sound       (you are caller #)
announce-continue=sound      (please continue to hold)
queue-timeout=seconds (not cycles)

As an alternative, the queue-timeout could be moved to the application call, which is more in keeping with the way other applications work.


By: davetroy (davetroy) 2003-09-09 16:59:57

Gunk -- was thinking about adding in the config settings you used just as a way of trying to tie this all closer together.

I had some thoughts that maybe we should consider before we do that though:

- one of the ACD bugs makes the statement that * queuing doesn't use standard ACD terminology; seems like that would be easy to fix, and that maybe now would be a good time to make those changes.  Thoughts?

- I agree that 'announce-frequency' and 'announce-XXX' are better than 'announcetimeout';  I used that because that was apparently Mark's original name for this and it was in the code

- That said, I dislike that we are using the word 'announce' at all as its first use was for the announcement of the queue-name to the member; maybe something like 'sayholdtime' and 'sayposition' would be better?

- I like the idea of moving the timeout to the app call; that was what I had intuitively thought would work initially.  I think I'll do that.

John -- you mentioned getting Allison to record some soundfiles.  How does that work?  I would prefer something in her voice so that it matches the say_number voice.  Certainly it could be overridden with other files, but right now these are the sounds that are needed:

queue-youarenext "Your call is now first in line and will be answered by the next available representative."
queue-thereare "There are currently"
queue-callswaiting "Calls waiting to speak with a representative."
queue-holdtime "The estimated hold time is currently"
queue-minutes "Minutes"
queue-thankyou "Thank you for your patience."

If we could get these recorded and included in the cvs along with this patch, I think that'd be a first step at something really first class.

Someone else offered some thoughts on including a directory of advertising/message sound files that can be played based on a frequency setting.  I like this idea too but haven't done anything with it yet because I wanted to get the position/holdtime stuff figured out first.  Any special thoughts on this?

As per my msg to the mailing list today, I also think it'd be good to start on some logging of queue events that can be used for management purposes, and will probably start on that soon too.

edited on: 09-09-03 16:43

By: John Todd (jtodd) 2003-09-13 19:18:08

There seem to be two separate patches discussed here.  Maybe three.

So do you all have consensus on what, exactly, needs to be added to CVS? There are a whole slew of comments, files, and URL's above in this note.  What I'd like to do is get a "yea" or "nay" from davetroy, gunk, and bkw on a final list of patches and then a pointer to that list of patches so Mark doesn't have to scan through the whole list of stuff above.  Please have tested the patches throughly before final submission - I'd like to see tests from all three of you, since these are somewhat of a pain in the butt to reproduce a "real" test environment unless you run a call center, which I assume all three of you have access to.

I will send the messages above in davetroy's note to Allison in the next "run" of stuff I have her do.  Is that a "final" list of queue announcements?  If not, please submit to me via email as well as putting into the notes here, since I get way too much mail from the bugtracker to read it all in detail.

By: John Todd (jtodd) 2003-09-13 19:20:03

Here is what I have from various people in my "to-allison" file that has to deal with queues:

You are caller number
You are currently caller number
in the queue.
in the line.
waiting to speak with a representative

queue-youarenext "Your call is now first in line and will be answered by the next available representative."  
queue-thereare "There are currently"  
queue-callswaiting "Calls waiting to speak with a representative."
queue-holdtime "The estimated hold time is currently"  
queue-minutes "Minutes"  
queue-thankyou "Thank you for your patience."

By: davetroy (davetroy) 2003-09-14 12:52:49

I've been running my latest version (http://asterisk.toad.net/app_queue.c-recursiveboxcar.patch) in a busy call center for the last week and it's totally solid.  It has these features:

- Position announcement
- Hold time calculation and announcement
- Queue fail-out timer parameter
- Abandoned and Completed call counters

I propose that Allison record these files:

queue-youarenext "Your call is now first in line and will be answered by the next available representative."
queue-thereare "There are currently"
queue-callswaiting "Calls waiting to speak with a representative."
queue-holdtime "The estimated hold time is currently"
queue-minutes "Minutes"
queue-thankyou "Thank you for your patience."

Meantime, I will finish up incorporating the parameters gunk has described, more or less as follows:

announce-frequency=seconds (default 60)
announce-position=no|yes (default yes)
announce-eta=no|yes|once (default yes)

I do not see any reason to specify the sound files as parameters if we are going to get Allison-ized versions to use; they can be swapped out with other files easily enough and are well labeled.

The queue-timeout parameter has been moved to the application call itself as described by gunk.  I see no reason to commit a less comprehensive patch to CVS if the additional features are good to go.  I am planning to add several other features to app_queue, including event logging, and I am going to base that work on my current patched version.  Forking in a different direction will impede the addition of features to app_queue, so I would suggest that bkw, gunk, and I come to agreement about a single patch that meets our needs.


By: Brian West (bkw918) 2003-09-14 13:10:03

David you have the right idea and you are headed the direction gunk and I want to go.  I will test your patch later this week.  We can get allison to record the files via thevoice.digium.com.  

By: Brian West (bkw918) 2003-09-14 13:11:17

Also noticed that the filenames are mixed case.  To follow the rest of * they should be lowercase. :)

By: davetroy (davetroy) 2003-09-14 13:31:28

Brian -- see my later post, I am moving to the 'queue-filename' format in lowercase and will incorporate the new proposed filenames in the final version.

By: gunk (gunk) 2003-09-14 16:00:14


We wanted to be able to specify the sound file in the config so that you could have different messages in different queues.

By: davetroy (davetroy) 2003-09-14 17:03:59

That makes some sense, but all the messages, no matter which queue, are going to say essentially the same thing: "there are currently x calls", "you're first in line", etc.  I think it makes the most sense to have Allison record these basic files because they need to integrate with ast_say_number which is in her voice already.  Clearly these files could be specified via options, but there are *6* files which would need to be added as configurable options, and I think adding that overcomplicates the configuration with little reward.  All you're going to get by changing the files is files that don't integrate with the position/holdtime numeric announcements.

I think that to do per-queue customizable, additional messaging, it makes more sense to specify an 'advertising' directory (which of course doesn't have to contain just advertising files but could be any sort of sounds you want to play) on a per-queue basis and have those files played at a certain interval.  Someone else started down this path and it's where I think I'd like to head with it.  Add an 'advertdirectory' and a 'advertfrequency' timer and you're good to go.

If there are additional things you want to play at the user per-queue, they can be done via Playback in the dial plan before you get into the queue.  I'm not opposed to your suggestion per-se, but can't identify a situation where it's really necessary.  Open to suggestions on this.

By: Brian West (bkw918) 2003-09-14 18:16:36

Well if I don't wanna announce the callers wait nor their position but an advert it would be a good option.

By: davetroy (davetroy) 2003-09-14 21:44:14

Agreed, that's why these options have been contemplated:
announce-frequency=seconds (default 60)
announce-position=no|yes (default yes)
announce-eta=no|yes|once (default yes)

There's no need to specify up to 6 different sound files to accomplish this goal.

By: ben_au (ben_au) 2003-10-28 05:48:30.000-0600

I've been using the recursiveboxcar_patch.txt for a few days and impressed the socks of my boss. So thanks to everyone for their work.

I do have a couple of things to ask though...
The hold time that is announced, should that go down as the caller gets closer to the front of the queue?

And... Here is an example I ran into yesterday that suggests that specifying the queue messages would be a good thing:
We're an ISP and we were having problems with our network. I changed the ThankYou sound file to let callers know about the problem, this is great for the support queue, but I'd prefer callers in the sales queue wanting to sign up didn't hear about our problems! *grin*

By: John Todd (jtodd) 2003-11-04 15:04:59.000-0600

OK, look, let me ask again: WHAT PATCHES SHOULD BE APPLIED HERE?  All of them?  Some of them?  Are there conflicting patches in this list of files attached to this bug?  Please do NOT include URLs as patch locations, that confuses everything. When we're doing patch runs, we don't have time to read every single comment made in the ticket.  A summary list of files, all included on the ticket, and a "Yes, I have tested the above files and they work for me" is what we're looking for.  Is this ready or not?  Brian, you have "app_queue.c.diff_v3_use_this_one.txt" and then we also see some of dave's patches in there.  I see some sound files, but not all of them as are described elsewhere in the ticket.  Are these patches complimentary? Do they have different features?  If so, then make new tickets for each in the future, but let's get this one sorted out. Someone please update this ticket with clear, concise instructions for Mark to patch the main CVS branch with these multiple patches.

By: mbetel (mbetel) 2003-11-06 02:58:21.000-0600

my problem too.... too many different versions of patches here...the busy error was because of a wrong version of the applied patch!

I am now using the http://asterisk.toad.net/app_queue.c-recursiveboxcar.patch with dutch prompts in a 5 agent helpdesk environment. And YES I HAVE TESTED THE ABOVE PATCH AND IT WORKS FINE FOR ME!

As far as I am concerned this is the one to incorporate into CVS

- Position announcement
- Hold time calculation and announcement
- Queue fail-out timer parameter
- Abandoned and Completed call counters

- the diff for queues.conf (but I can upload one)
- the 5 queue-xxx.gsm prompts in Allisons voice

By: davetroy (davetroy) 2003-11-08 10:13:10.000-0600

I apologize for not following up with this sooner; been on travel and busy with other things.  Also wanted to give people a few weeks to try the recursive filter and completed/abandoned counters, which I have been using now for 2 months with no problems.

I will work on this today and have a completed final patch against current cvs for both config and app_queue.c by tonight or tomorrow.

By: davetroy (davetroy) 2003-11-08 12:51:56.000-0600

OK, the tarball app_queue_patch.tar should be considered final and implements most changes discussed to date; it is an update to the recursiveboxcar patch that several folks are using.

It includes the following files:

Ideally the sound files should be replaced with ones in Allison's voice, as she sounds a lot sexier than I do.

Note the change of 'announcetimeout' to 'announce-frequency' -- here are the relevant docs from the queues.conf.sample file:

; How often to announce queue position and/or estimated holdtime to caller (0=off)
;announce-frequency = 90
; Should we include estimated hold time in position announcements?
; Either yes, no, or only once; hold time will not be announced if <1 minute
;announce-holdtime = yes|no|once
; Use these sound files in making position/holdtime announcements.  The
; defaults are as listed below -- change only if you need to.
;queue-youarenext = "queue-youarenext"          ("You are now first in line.")
;queue-thereare = "queue-thereare"              ("There are")
;queue-callswaiting = "queue-callswaiting"      ("calls waiting.")
;queue-holdtime = "queue-holdtime"              ("The current est. holdtime is")
;queue-minutes = "queue-minutes"                ("minutes.")
;queue-thankyou = "queue-thankyou"              ("Thank you for your patience.")
; Note that a timeout to fail out of a queue may be passed as part of application call
; from extensions.conf:
; Queue(queuename|[options]|[optionalurl]|[announceoverride]|[timeout])
; example: Queue(dave|t|||45)

John, let's go ahead and put this patch into CVS.  Thanks.

edited on: 11-08-03 12:58

By: John Todd (jtodd) 2003-11-08 13:03:04.000-0600

Dave - I think I have most of these sound files already in place at http://www.loligo.com/asterisk/sounds/   - dig around in there and you should find all of them.  Look at the .txt file for actual sayings.

By: davetroy (davetroy) 2003-11-08 13:39:24.000-0600

John, I found the right files and incorporated them.  allison.tar (it chopped off the rest of the name I gave it) is the same as app_queue_patch.tar and should now be considered the latest release candidate.  Thanks for getting those done!

By: yamez (yamez) 2003-11-09 01:36:08.000-0600

I am testing the patch now two thing to note first davetroy did not edit the "show application queue" to show the new timeout option, and second the time out does not seem to work:

   -- Executing Queue("SIP/6152214215-92ce", "nocnq|tT|||3") in new stack
   -- Started music on hold, class 'nocq', on SIP/6152214215-92ce
   -- Called 3846
   -- SIP/3846-f3c1 is ringing
   -- Nobody picked up in 15000 ms
   -- Called 3846
   -- SIP/3846-fd8d is ringing
   -- Nobody picked up in 15000 ms
   -- Called 3846
   -- SIP/3846-f00f is ringing
   -- Nobody picked up in 15000 ms
   -- Called 3846

Is the timeout in minutes or seconds ?

By: davetroy (davetroy) 2003-11-09 09:48:42.000-0600

Yamez, use the new app_queue_patch_1_03.tar patch.  There was a bug in the queue parameter initialization which was tromping on the timeout value which has been fixed.  I thought the 'show application queue' msg had been updated but you are right it was not, so that's fixed too.

Some details on how the queue timeouts are performed.  Callers 2 through n, (the 'tail' of the queue) are processed in a separate loop from the head queue entry.  Entries in the tail are timed out after exactly 'queuetimeout' seconds -- as you would expect.

The head queue entry is actively trying to ring somebody and is checked to be timed out after every queues.conf 'timeout' and 'retry' cycle, but not while those are happening.

So, if:
queues.conf->timeout = 45
queues.conf->retry = 15

Callers 2 through n (tail) will be failed out after 30 seconds.
Head caller will ring queuemembers for 45 seconds, then timeout because 45>30.

And if Queue(dave|t|||50) then:

Callers 2 through n (tail) will be failed out after 50 seconds.
Head caller will ring queuemembers for 45 seconds, won't timeout because 45<50, then wait for 15 seconds, THEN timeout because 60>50.

All this is just a complicated way of saying that the timeout won't override the timeout/retry cycle values for the head caller.

Thanks for checking this out so we can get this finished up.

edited on: 11-09-03 10:08

By: yamez (yamez) 2003-11-09 17:43:33.000-0600

I have tested app_queue_patch_1_03.tar patch and it works great, the timeout works
and the "show application Queue" look good.  This patch looks like the real deal.

By: davetroy (davetroy) 2003-11-14 12:55:11.000-0600


Added the ability to turn on Asterisk's monitor capability from within app_queue;  if it is enabled before running app_queue, you end up recording people sitting on MOH, and even if they abandon the call.

This starts recording only when the call is answered by an agent, and can be configured using a simple directive in queues.conf.  Here is the documentation from the modified queues.conf.sample file:

; Calls may be recorded using Asterisk's monitor resource
; This can be enabled from within the Queue application, starting recording
; when the call is actually picked up; thus, only successful calls are
; recorded, and you are not recording while people are listening to MOH.
; To enable monitoring, simply specify "monitor-format";  it will be disabled
; otherwise.
; monitor-format = gsm|wav|wav49

Change is fairly simple and as such should be rather robust.  Have done limited testing here; encourage feedback and believe this should be ready to include in CVS.

By: Paul Cadach (pcadach) 2003-11-16 11:21:19.000-0600

I think saying caller's position immediately after joining to the queue is not good option. If queue have free operators it's just unneeded delay before call is handled. May be make this configurable?

Also, I think recording filename format must be configurable too.

And, IMHO channel's state must be supported everywhere when possible to notify queue handler about having free representatives to pass call immediately, without long delays (support is required at least for chan_agent). May be this feature will require some new callbacks to pass notifications for "interested" parts like app_queue...

By: mbetel (mbetel) 2003-11-17 04:36:06.000-0600

I have added a servicelevel statistic to app_queue_patch_104. This will tell the percentage of call answered within a settable amount of seconds and gives a quick indication on how well the ACD queue is doing. Most callcenters I know strive to answer 80% of the calls within 20 seconds.
The amount of seconds can be set by specifiying
in queues.conf

The patch containing the complete 104 patch from dave + my sl additions can be found here as app_queue_with_sl.patch

edited on: 11-17-03 04:31

By: davetroy (davetroy) 2003-11-23 11:40:42.000-0600


Incorporates M. Betel's "servicelevel" patch and cleans up a couple of initializations in that code.

Added display of completed/abandoned/holdtime/servicelevel info to QueueStatus manager output, plus some other small changes/updates to manager output.

Changed monitoring to use call's 'uniqueid' as recording filename.

By: Brian West (bkw918) 2003-11-23 12:27:17.000-0600

Dave which files can be removed?  I'm trying to cut confusion here so I need to remove the ones that aren't valid anymore.


By: davetroy (davetroy) 2003-11-24 11:16:09.000-0600

I'd say everything prior to version 1_06 has been deprecated...

By: tclark (tclark) 2003-11-24 12:14:36.000-0600

This patch does not apply against current cvs
This is the reject file
*** 1156,1166 ****
               if (!res) {
                       for (;;) {
                               res = try_calling(&qe, options, announceoverride, url);
                               if (res)
                               res = wait_a_bit(&qe);
                               if (res < 0) {
                                       if (option_verbose > 2) {
                                               ast_verbose(VERBOSE_PREFIX_3 "User disconnected when they almost made it\n");
                                               res = -1;
--- 1327,1363 ----
               if (!res) {
                       for (;;) {
+                               /* This is the wait loop for the head caller*/
+                               /* To exit, they may get their call answered; */
+                               /* they may dial a digit from the queue context; */
+                               /* or, they may may timeout. */
+                               /* Leave if we have exceeded our timeout */
+                                 if (qe.queuetimeout && ( (time(NULL) - qe.start) >= qe.queuetimeout) ) {
+                                       res = 1;
+                                       break;
+                                 }
+                               /* Make a position announcement, if enabled */
+                                 if (qe.parent->announcefrequency)
+                                       say_position(&qe);
+                               /* Try calling all queue members for 'timeout' seconds */
                               res = try_calling(&qe, options, announceoverride, url);
                               if (res)

By: Matteo Brancaleoni (mbrancaleoni) 2003-11-25 04:56:44.000-0600

the reject is dued to the new 'n' option in app_queue. using a previuos version works ok.

By: Matteo Brancaleoni (mbrancaleoni) 2003-12-04 13:16:26.000-0600

tested and works ok for me (using in production now).
btw, must be updated to apply to current cvs , is to say to the app_queue where mark added the 'n' option

By: davetroy (davetroy) 2003-12-24 10:48:59.000-0600


Incorporates the new 'n' option added to recent cvs builds.  Otherwise identical; everything else should be deprecated.  Should be good to go.  Happy holidays, folks!

By: gus (gus) 2004-01-05 11:17:46.000-0600

If a call hangs up meanwhile it's in the queue (between retry cycles), the app sends an Invite and Cancel to the first free SIP Agent.
Trace is needed?

By: clark (clark) 2004-01-08 19:51:30.000-0600

Will this patch be committed to CVS?

By: davetroy (davetroy) 2004-01-09 13:40:04.000-0600

gus: I am not sure what you are saying, exactly, but this patch doesn't affect the underlying queue functionality with respect to agents.  If there is a problem there, it in theory is a problem with app_queue and not this patch.  If you have reason to believe otherwise, please say so.

clark: Malcolm contacted me today looking for a disclaimer, so I think that means it's headed into cvs.

By: gus (gus) 2004-01-09 15:58:01.000-0600

Dave: In a first place, congratulations for this patch. And ok, I will do some tests in another machine without a patch.


By: zoa (zoa) 2004-01-09 19:47:14.000-0600

Am i the only one thinking of a temporary app_queue2 with these patches and anthms patches applied until anthms new Q application is ready ?

These things provide great functionality.

Could somebody close bug 0000195 and make a link from that bug to this one ?
(So that we don't have multiple bugs that are in fact the same?)

By: kenalker (kenalker) 2004-01-11 20:41:34.000-0600

I would like to suggest some logging that would be very helpful to a call center manager.

How about incorporating code that will create a log entry to a log file (or database) the amount of wait time that a caller is quoted when entering the queue, and then creating another log entry when the caller makes it through the queue which records the *actual* time spent in the queue?

If the person doesn't make it through the queue (ie. hangs up), a log entry should be made indicating how long the caller had waited when the caller hung up.

There should be a way to differentiate (in the log) a call terminated by the caller, versus a call picked up by and agent.

edited on: 01-11-04 20:38

By: gus (gus) 2004-01-11 20:55:49.000-0600

kenalker: I won't agree with that... those funcionalities could be made with manager API. Using this api you will have that information and much more.
In my opinion, isn't good idea to make more complex this app.

By: ltropiano (ltropiano) 2004-01-11 20:57:28.000-0600

It would be nice if instead of MOH when someone is waiting for agents to answer they can get a "ringing" while in the queue for the next agent (as an option to Queue) ...

By: kenalker (kenalker) 2004-01-11 21:14:55.000-0600

Reminder sent to gus

Gus, I don't know how to email you directly so I'm using the "send a reminder" feature of the bug tracker.  I'm totally new to * and bug tracker, so please forgive me.

My direct email is ken@impulse.net, for a response.  I'm going this off-line so as not to clutter the bug tracker.

I have not used the "monitor" api to which you refered.  Would monitor automatically be able to do what I've decribed in my request?  I assume code would still have to be put directly into the queue program in order for the information (queue time at entry and exit) to be available for the monitor app.  Am I correct, or do I not understand the monitor app at all?

If I am correct, then it seems I need to mention this feature request both in this bug report and add a feature request to the monitor app bug section (although, that doesn't seem to exist in the bug tool drop-down for projects).


By: gus (gus) 2004-01-11 21:22:42.000-0600

kenalker: Ok, I will contact to you off list, but I think that is good to review the real needs for this app.

By: gunk (gunk) 2004-01-12 07:34:08.000-0600

GUYS!  Take this to a mailing list please!  This is NOT a bulletin board or a chatroom.  This is for reporting and monitoring bugs, not for chatting or troubleshooting.

Admins: I'm stupid!  I don't see any method for removing myself from monitoring this bug.  I do not wish to receive any further email from this particular bug.


By: ben_au (ben_au) 2004-02-04 20:03:55.000-0600


This hasn't been added to the CVS yet? I just tried to patch the lastest CVS and it doesn't apply!

By: shad (shad) 2004-02-14 14:23:16.000-0600

Reminder sent to bkw918

I'm trying to apply this patch to the 0.7.2 zip release and it fails. Could you please advise? I need this for a busy call center which I'm trying to commision by the end of the week.

Do I need to downgrade to an earlier version of Asterisk ? if so which version?

Thanks for your consideration.

edited on: 02-14-04 13:08

By: Brian West (bkw918) 2004-02-15 02:26:40.000-0600

I did not write the current verison of this patch Dave Troy did.  Posting your notes and questions here in the bug notes is usually plenty to get the attention of the person who did write it.


By: gbdrbob (gbdrbob) 2004-02-16 18:55:54.000-0600

This patch won't apply to app_queue in * versions over 0.7.1 so download or cvs checkout that version if you want to use it. The changes between 0.7.1 and stable 1.0 branch don't look to be that major, see -


If anyone wants to adapt the code so it will patch to 1.0 stable, I (and many others I'm sure) would be very grateful. Then it could perhaps be included as an add on (cvs admins?).

edited on: 02-16-04 17:46

By: ben_au (ben_au) 2004-02-16 20:38:08.000-0600

I know this isn't a chatroom, but... my boss said I can offer cash to someone who can make this work, if that'll speed things up.

My e-mail address is ben@team.dcsi.net.au let me know if you can help!

While I'm offering cash, would it be difficult add an option so the caller hears ringing, instead of hold music Queue(queuename|r)

By: zoa (zoa) 2004-02-17 04:57:14.000-0600

ben_au, i suggest you better offer cash to the new anthm & tclark project.

By: gus (gus) 2004-02-17 10:17:02.000-0600

Are you saying that this project is dead? The problems were not solved, and if this is truth, this bug must be closed.
Which is the number of the project that you mention?

By: menger (menger) 2004-02-24 22:27:34.000-0600

I have uploaded a new version of the patch which from my testing seems to work with the latest CVS release. I don't have the facilities to test it well so please test it and let me know if you have any issues. All I did was patch it manually.

I also fixed the config file patch to not put quotation (") marks around the filenames as it will not work out of the box with them.

By: menger (menger) 2004-03-04 00:56:22.000-0600

Reminder sent to bkw918

is this patch ever going to make it into cvs or is it dead?

By: Brian West (bkw918) 2004-03-04 00:59:23.000-0600

Please read the notes.  I didn't write this patch.

By: zoa (zoa) 2004-03-04 04:14:19.000-0600

could everybody that is using this patch say if you think its good (or better than the non patched acd) ?

i'd like to see this get into the cvs as it has less deadlocks...

By: Mark Spencer (markster) 2004-03-04 10:07:42.000-0600

If you guys are happy with this, and we have the prompts made, then I'm happy to put this patch in cvs head.

By: dimi (dimi) 2004-03-09 08:10:55.000-0600

Thanks menger i used your patch in stable brach 0.7.2 and works fine but i found two problem:
- I set Language but when it say number of queue return in english
- Sometimes if more the one add to the queue calls say wrong number of queue dont remove the old one that hangup while waiting to connect.
Thanks for your good work

By: dimi (dimi) 2004-03-09 08:35:21.000-0600

Sorry... For the first problem about Language i have discovery that is "bug" in say.c ...
Im sorry for my bad report..
There are a Bug open at number "0001097" to fix say.c

edited on: 03-09-04 07:26

By: jesses (jesses) 2004-03-12 17:15:32.000-0600

Trying to patch the most current CVS of version asterisk-0.7.2

patching file /usr/src/asterisk/apps/app_queue.c
Hunk #4 FAILED at 97.
Hunk ASTERISK-12 FAILED at 1312.
Hunk ASTERISK-13 succeeded at 1364 (offset 3 lines).
Hunk ASTERISK-14 succeeded at 1389 with fuzz 1 (offset 3 lines).
Hunk ASTERISK-15 succeeded at 1413 (offset 6 lines).
Hunk ASTERISK-16 succeeded at 1488 (offset 6 lines).
Hunk ASTERISK-17 succeeded at 1550 (offset 6 lines).
Hunk ASTERISK-18 succeeded at 1631 (offset 6 lines).
Hunk ASTERISK-19 succeeded at 1663 (offset 6 lines).
Hunk ASTERISK-20 succeeded at 1752 (offset 9 lines).
Hunk ASTERISK-21 succeeded at 1763 (offset 9 lines).
2 out of 25 hunks FAILED -- saving rejects to file /usr/src/asterisk/apps/app_queue.c.rej

By: menger (menger) 2004-03-12 18:37:53.000-0600

jesses: which version of the patch are you using? Are you using the stable or the development branch?

By: menger (menger) 2004-03-12 18:39:55.000-0600

markster: i am happy with this patch. It has been well tested by alot of people even though they don't seem to be as active on this patch now. Maybe it might be a good idea to move this to the head branch.

By: jesses (jesses) 2004-03-12 19:05:07.000-0600

I used the development patch  app_queue_patch_1_07a.tar, with todays CVS. If I take the app_queue.c file from the CVS that was put out on the same day as the patch, the patch goes in fine, but when I try to call the queue, I dont hear any announcements and I see this in my logs-

Mar 12 15:49:02 WARNING[917526]: File "queue-youarenext" does not exist in any format
Mar 12 15:49:02 WARNING[917526]: Unable to open "queue-youarenext" (format ULAW): No such file or directory
Mar 12 15:49:02 WARNING[917526]: File "queue-thankyou" does not exist in any format
Mar 12 15:49:02 WARNING[917526]: Unable to open "queue-thankyou" (format ULAW): No such file or directory

I am sure that the files are in the right place, I have no idea why it will not find it

By: jesses (jesses) 2004-03-12 19:11:48.000-0600

Nevermind, the queue.conf file had quotes around the filenames for some reason. Removing fixed it. I agree with earlier comments that sound filenames as an option should be removed. I'm proof that it causes more problems then it solves

edited on: 03-12-04 22:38

By: menger (menger) 2004-03-13 00:43:17.000-0600

jesses: yeah. I had that issue and fixed it in the queue.conf patch inside 1_07a.

By: Mark Spencer (markster) 2004-03-13 01:07:50.000-0600

I've merged this into CVS.  If there are any bugs related to this, please open a *new* tracking ticket since this one is sooooo long.

By: Digium Subversion (svnbot) 2008-01-15 14:46:58.000-0600

Repository: asterisk
Revision: 2415

U   trunk/CHANGES
U   trunk/Makefile
U   trunk/apps/app_queue.c
U   trunk/configs/queues.conf.sample
A   trunk/sounds/queue-callswaiting.gsm
A   trunk/sounds/queue-holdtime.gsm
A   trunk/sounds/queue-minutes.gsm
A   trunk/sounds/queue-thankyou.gsm
A   trunk/sounds/queue-thereare.gsm
A   trunk/sounds/queue-youarenext.gsm
U   trunk/sounds.txt

r2415 | markster | 2008-01-15 14:46:58 -0600 (Tue, 15 Jan 2008) | 2 lines

Merge queue changes from Bug ASTERISK-211