[Asterisk-Users] app_queue input needed...
David C. Troy
dave at toad.net
Sun Sep 7 12:08:54 MST 2003
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
>
More information about the asterisk-users
mailing list