|Summary:||ASTERISK-08870: [patch] calls in queue are blocked untill it is first call in queue|
|Reporter:||Peng Yong (ppyy)||Labels:|
|Date Opened:||2007-02-25 02:12:11.000-0600||Date Closed:||2007-08-24 14:26:36|
|Environment:||Attachments:||( 0) autofill.1.2.new|
( 1) autofill.diff1
( 2) autofill.diff3
( 3) autofill.diff6
|Description:||we are running a busy call center now. we find many call are waiting even when the agent are free.|
we check the code, find all calls in queue are runing wait_our_turn() untill it is first call in the queue. asterisk recheck it every one second (ast_waitfordigit(qe->chan, RECHECK * 1000))&ASTERISK-11713;
a call is not removed from queue before it is bridged. so all callers 2 through maxlen are waiting if:
agent are not answer the first call
playing announce to caller
can we make some change to remove the blocking?
|Comments:||By: mboenke (mboenke) 2007-02-28 02:11:38.000-0600|
We are facing the same problems, at least the one with the uninterrtupable announcements. Do you have set autofill=yes in queus.conf?
By: Joshua C. Colp (jcolp) 2007-03-05 14:48:21.000-0600
Can you please confirm as previous note mentioned: are you using autofill? if not if you set it to yes does the queue then perform as you want?
By: Peng Yong (ppyy) 2007-03-06 07:49:30.000-0600
i enabled autofill ,and find following bug in 1.4 and trunk:
1. avl is not caculated, and the following log information always print "0 available members".
ast_log(LOG_DEBUG, "Even though there are %d available members, the strategy is ringall so only the head call is allowed in\n", avl);
2. the paused members should not be included in avl members.
3. the avl is not correctly caculated. the waiting calls will not be removed from queue, but the device state is "in use" when it is called even if it is no conncted. here is a issue:
call1 and call2 come into the queue which has to free members, member1, member2.
and call1 will ring member1 as sooon as it come into the queue. if the member not accept call1, the call2 will wait in the queue:
call1, avl = 2, idx = 0
call2, avl = 1, idx = 1
member1 is "in use" when it ring, so avl is 1. and call2 will wait.
and after 15 second, call1 time out, then call2 ring member2, and call1 will ring member1 also:
call2, avl = 2, idx = 1, ring member2
call1, avl = 1, idx = 0, ring member1
the member should be considered available if it is not connected.
here is a patch for trunk and 1.4
By: BJ Weschke (bweschke) 2007-03-06 12:18:22.000-0600
I really only agree with point #2. We should not include paused members as "available". However, this patch doesn't accommodate the member status variable which takes into account interfaces that have gone "not idle / available" for reasons other than a call for that specific queue. You need to accommodate for this and for this reason, the patch fails.
By: Peng Yong (ppyy) 2007-03-06 22:46:19.000-0600
here is a new patch.
for point #1, it is correct in my first patch, it should not always print "0 available members" in log.
for point #3 i add a variable dialing to queue entry.
ringing members are not included in avl members, and now dialing queue entry are also not included in idx.
By: BJ Weschke (bweschke) 2007-03-08 12:53:44.000-0600
ppyy: your 2nd patch is OK, save for, when you set dialing back to 0, it doesn't look like you have the qe->parent mutex locked at that point in execution and you probably should. change that and it's good to go as far as I'm concerned.
By: Peng Yong (ppyy) 2007-03-08 18:21:06.000-0600
add lock to qe->parent, new patch uploaded
By: Peng Yong (ppyy) 2007-03-08 18:35:14.000-0600
backport autofill function to asterisk-1.2
By: pkempgen (pkempgen) 2007-03-29 10:01:34
Just a small thing:
ast_log(LOG_DEBUG, "It's our turn (%s), index %d, avariable %d.\n", qe->chan->name, idx, avl);
ast_log(LOG_DEBUG, "It's not our turn (%s), index %d, avariable %d\n", qe->chan->name, idx, avl);
By: Serge Vecher (serge-v) 2007-03-29 10:13:15
yeah, also is it "avariable" or "available"
By: Peng Yong (ppyy) 2007-03-29 10:14:39
thks for pkempgen. new patch uploaded
By: Serge Vecher (serge-v) 2007-03-29 10:24:43
pkemgen: have you tested the patch; if so, what are your results? We need test reports to make decision on whether the patch can go in or not.
By: pkempgen (pkempgen) 2007-03-29 12:31:51
autofill.diff6 works with 1.4.2 but I have not tested the
patch in a busy environment.
s/are we dailing/are we dialing/ :)
What I'd really like app_queue to do is ring the members even
while announcements are being played and if a member answers
stop playing the announcement. That might be a seperate issue
By: Wolfgang Pichler (wuwu) 2007-03-29 13:34:21
i have applied this patch to asterisk version 1.2.4 (yeah - pretty old - but working stable) because we did have had the same problem. I've testet it on a backup system - worked fine. Now it is running on our production system for nearly 1 week without any problems. At primetime the system does around 30 concurrent calls, which will come in in about 1-2 minutes...
On weekends the call volume will go up to around 70 concurrent calls entering in 1-2 minutes - so - then i will know if it really works ;-)
This patch did saved my day - before the patch we did have had massive problems because of agents not taking a call - so all other calls were not going through to next free agent...
Thanks for the patch
By: Serge Vecher (serge-v) 2007-03-29 13:59:05
remarking issue for 1.2.x as it need to be fixed there first.
By: Peng Yong (ppyy) 2007-04-06 08:57:52
did somebody else test it?
By: BJ Weschke (bweschke) 2007-04-06 08:59:59
This patch cannot be applied to 1.2 because it's new functionality there. autofill was never added to 1.2. It's 1.4+ functionality I think.
By: Peng Yong (ppyy) 2007-04-06 09:17:59
autofill.diff6 is bug fix for 1.4. and autofill.1.2.new is feature back port to 1.2.
i think autofill can be also seemed as a bug fix for 1.2 :)
it's a bug for asterisk without autofill, if calls in queue are blocked.
By: BJ Weschke (bweschke) 2007-04-06 09:19:26
I'm personally in agreement with you, but this was discussed, and it was deemed a new "feature" in 1.2 that wouldn't go in.
By: Peng Yong (ppyy) 2007-04-16 13:26:50
we runing this feature (1.2) for 40 days, no problem.
any one have some feed back?
By: Ronald Chan (loloski) 2007-04-26 13:38:59
yes, i'm running this too with no problem at all. 1.2 branch
By: Ronald Chan (loloski) 2007-04-30 05:25:42
If this could not commit on 1.2 because it was a feature, then how about in 1.4 or SVN trunk? thanks ppyy for the patch
By: BJ Weschke (bweschke) 2007-08-24 14:26:33
This is a relevant patch against 1.2 but it's a new feature going in to 1.2 (which we don't do) when the functionality is already correct and working as expected in 1.4