Yeah, I buy that argument, but concede that it should probably be configurable. Also the rounding up to an 5/10/15 minute announcement makes sense in this context. Let's give it some thought.
Dave ===================================================================== David C. Troy [EMAIL PROTECTED] 410-384-2500 Sales ToadNet - Want to go fast? 410-544-1329 FAX 570 Ritchie Highway, Severna Park, MD 21146-2925 www.toad.net On Sun, 7 Sep 2003, Brian West wrote: > I think the hold time needs to be announced only once when the caller is > injected into the call queue. Otherwise callers will hear hold times > shoot up if you have a few long calls. > > bkw > > On Sun, 7 Sep 2003, David C. Troy wrote: > > > > > Troy, > > > > These is all good feedback; I did my patch primarily based on my own > > needs, so YMMV. The business about the thread-locked code was related to > > the usedontmiss.com patch, not yours. Yours seems to avoid that problem, > > as does mine. > > > > I spent the last couple of hours digging deeper into this, and I > > incorporated a 'queuetimeout' (similar to what outtolunc did, but rather > > than transferring to 's,1,...' within the queue context, it just exits and > > lets the originating extension list figure out what to do with it. > > > > I agree that more control needs to be added to make a general solution; > > that will mean the addition of a few, preferably a minimal number, > > queues.conf parameters. To me, that's up to the community and to Mark. > > > > I'll post the new patch in a few minutes, after a bit more testing, but it > > seems to work very smoothly now; I figured out some stuff I didn't > > understand about the various loops in the code, and that's well commented > > now. > > > > Patch will be located here: > > http://asterisk.toad.net/app_queue.c-pos+holdtime+queuetimeout.patch > > > > Take a look at this patch and let's see what we want to do about the > > holdtime logic; at a minimum this patch cleans up and packages all that > > logic very neatly, so it then becomes a simple question of how to invoke > > it rather than the harder question of how to do it generally. > > > > Dave > > > > ===================================================================== > > David C. Troy [EMAIL PROTECTED] 410-384-2500 Sales > > ToadNet - Want to go fast? 410-544-1329 FAX > > 570 Ritchie Highway, Severna Park, MD 21146-2925 www.toad.net > > > > On Sun, 7 Sep 2003, Troy Settle wrote: > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > > > David C. Troy > > > > Sent: Sunday, September 07, 2003 11:05 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [Asterisk-Users] app_queue input needed... > > > > > > > > > > > > > > > > Brian, > > > > > > > > I just finished doing both of these mods myself. The patch > > > > is available > > > > here: > > > > > > > > http://asterisk.toad.net/app_queue.c-pos+holdtimepatch > > > > > > > > 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. > > > > > > Been tested with over 90 calls in the queue. We did not run into this > > > situation. > > > > > > > > > > > - 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. > > > > > > I see that you set this to 10 seconds actually, but even at 15, that's a > > > little crazy. IMO, announcements should be made no more often than 60 > > > seconds. Personally, I find it quite annoying when something interupts > > > the MOH 3-4 times a minute to say "your call is important to us" or "we > > > value your business" or "you are caller number 8274738, please wait." > > > > > > If you look at our code, the default is to announce every 60 seconds. > > > It doesn't matter if 1 person or 30 people in front of you drop out in > > > rapid succession (actually, we did test with 30 callers dropping at one > > > time). The next announcement will not come before 60 seconds have > > > passed. > > > > > > > > > > > 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. > > > > > > Not enough control is being offered here. At a minmum, each of the > > > following should be doable: > > > > > > - Announce without position or time > > > - Announce with time only > > > - Announce with position only > > > - Announce with position and time > > > > > > > > > > > - 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 > > > > > > I like this idea very much. > > > > > > > > > > > - Holdtime is only announced if it is 4 minutes or greater; this is > > > > arbitrary and could be rolled into a configurable queues.conf setting. > > > > > > Yes, this needs to a config option for sure. I would want announcements > > > all the way down to "less than 2 minutes." > > > > > > > > > > > > > > - 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. > > > > > > Perhaps it would be cool if you got Allison to record these. I was > > > going to have her do the ones for our patch, but John Todd volunteered > > > before I even knew that Brian had posted the patches up (which is why > > > there's also like 3 versions of the patch so far). > > > > > > > > > > > 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. > > > > > > My vote for announcing hold times, is to use a configuration varaible to > > > specify minutes and seconds, or to round up to the nearest minute (or > > > 2,3,4,5 minutes). For that matter, you could even decrease the > > > granularity based on the position and how long the wait is. > > > > > > If I'm in position 3, and the wait time is less than 1 minute, why not > > > announce the seconds? Chances are, the call will be answered right > > > after the caller hears "your estimated wait time is 38 seconds." > > > > > > On the other hand, that might be annoying to caller 10 who's got a hefty > > > 12 minute wait ahead of her, so that announcement should be "less than > > > 15 minutes." > > > > > > > > > > > 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. > > > > > > That patch was done by outtolunc, and I expect that when/if Mark tackles > > > app_queue, he'll incorporate that as well. > > > > > > > > > > > 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. > > > > > > > > > > > > -- > > > Troy Settle > > > Pulaski Networks > > > http://www.psknet.com > > > 540.994.4254 ~ 866.477.5638 > > > Pulaski Chamber 2002 Small Business Of The Year > > > > > > _______________________________________________ > > > Asterisk-Users mailing list > > > [EMAIL PROTECTED] > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > > > _______________________________________________ > > Asterisk-Users mailing list > > [EMAIL PROTECTED] > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > _______________________________________________ > Asterisk-Users mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
