[Asterisk-Users] app_queue input needed...
David C. Troy
dave at toad.net
Sun Sep 7 12:47:11 MST 2003
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 [dave at toad.net] 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 [dave at toad.net] 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: asterisk-users-admin at lists.digium.com
> > > > [mailto:asterisk-users-admin at lists.digium.com] On Behalf Of
> > > > David C. Troy
> > > > Sent: Sunday, September 07, 2003 11:05 AM
> > > > To: asterisk-users at lists.digium.com
> > > > 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
> > > Asterisk-Users at lists.digium.com
> > > http://lists.digium.com/mailman/listinfo/asterisk-users
> > >
> >
> > _______________________________________________
> > Asterisk-Users mailing list
> > Asterisk-Users at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-users
> >
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
More information about the asterisk-users
mailing list