HI all,
I have set up a queue with 2 members (A & B). 1st call is waiting
in the queue and a queue member A is ringing but don't take the call.
Member A keeps ringing. Then 2nd call is also get into the queue but
I found that queue member B doesn't ring. That's mean member B is
available to take call but somehow it can't get a call in the queue.
After that, member A takes the call of the 1st caller and member B gets ring.
Question:
-Why the 1st call will be stick the queue even there are many call behind?
-Is it a bug of the queue or just a setting of the queue to solve the problem?
5000 has 2 calls (max unlimited) in 'rrmemory' strategy (24s
holdtime), W:0, C:1, A:1, SL:100.0% within 120s
Members:
Local/2002 at sipauth (dynamic) (Not in use) has taken no calls yet
Local/2001 at sipauth (dynamic) (Unknown) has taken 1 calls (last
was 76 secs ago)
Callers:
1. SIP/2003-02cf0940 (wait: 0:47, prio: 0)
2. SIP/10.100.0.109-e4096dc0 (wait: 0:15, prio: 0)
Rilawich Ango Thursday, April 10, 2008 3:28 AM> I have set up a queue with 2 members (A & B). 1st call is waiting > in the queue and a queue member A is ringing but don't take the call. > Member A keeps ringing. Then 2nd call is also get into the queue but > I found that queue member B doesn't ring. That's mean member B is > available to take call but somehow it can't get a call in the queue. > After that, member A takes the call of the 1st caller and > member B gets ring.What version of Asterisk are you using? This is a know issue/feature with version 1.2.x In version 1.4.x, set autofill=yes in queues.conf and calls will fill in as expected. Don Pobanz
Two use-cases where autofill=no is desirable:
1) If it's important that you answer your callers in strict order (i.e.
in order to meet estimated wait time commitments etc).
2) If your queue members/agents are local channels (as local channels
are always available, so call attempts will be made regardless of who's
talking).
Kind regards,
Matt.
BJ wrote
>/ This was something I put in a long while back on 1.2 branch because we
really needed it for 1.2
> to "bug fix" the behavior, but also needed to prevent the
change in behavior for those that
> didn't want it to change.
/>/
/>/ That being the case and we're in the day and age of 1.6 branches
now, it'd be interesting to > think of what people would think of deprecating this option completely
now in /trunk in favor
> of the "autofill=yes" behavior being the only behavior
available. I cannot think of any use
> cases where the autofill=no behavior might be desirable. That being said,
I also might have
> blinders on so would be curious to here what the rest of the community
has to say about it.
/>/
/>/ BJ/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20080415/cc532d83/attachment.htm
> Two use-cases where autofill=no is desirable: > > 1) If it's important that you answer your callers in strict order (i.e. > in order to meet estimated wait time commitments etc).Not always the case. Let's look at multiple queue assignment where agents have skills (logged in) to multiple queues. AGT1: Has SkillA, SkillB, SkillC AGT2: Has SKillA SLA: 24 seconds Senario -------- Calls in Queues: Call1: SkillA - 15 seconds Call2: SkillB - 12 seconds AGT1 will become available in now() +2 seconds AGT2 will become available in now() +6 seconds ------------------------ CASE 1 (Calls in strict order): TIME=now()+2: AGT1 becomes available, CALL1 matched, time in Q now 17 seconds, assigned, SLA OK. TIME=now()+6: AGT2 becomes available, CALL2 NOT matched, not assigned, AGT2 idle, awaiting AGT1 to finish call, time in Q now 18 seconds. TIME=now()+10: AGT2 idle, CALL2 sitting in queue, SLA failed. CASE 2 (Calls not in order, system SMART enough to read into the queue and predict availability based on historical data) TIME=now()+2: AGT1 becomes available, CALL1 matches, but system knows that CALL2 is also a match and remaining agents are NOT a match. Predicted availability says call 2 will fail SLA, system assigns CALL2 to AGT2, time in Q now 14 seconds, SLA OK. TIME=now()+6: AGT2 becomes available, CALL1 matches and is assigned, time in Q now 21 seconds, SLA OK. TIME=now()+10: AGT1 on call 2, SLA OK. AGT2 on call 1, SLA OK. Now this isn't strictly the problem originally described but I'm trying to articulate where the use case as specified falls down in real-world environments. This also shows and area that Asterisk (and _many_ other switches) have not gone yet but we need to aspire to. This type of functionality is why you currently shell out the bucks for Avaya. - dbc.