well if you ask me, the leastrecent part would work if you reversed the
logic on the metric.
my other last_used mod would do a time_t on that agent the last time it
was 'tried' (ast_request'd) then (i was using arrays) qsort so that (new
agents) '0' would be on top, and the agent that got the
First of all I would like to thank Mark for getting roundrobin to go
roundrobin. Good job.
Exactly, the whole queue system seems significantly better than it was not
so long ago. Thank very much!
Now we have some options here for leastrecent and fewestcalls strategy. It
needs some work on
I was speaking in a logic related to real call routing and queueing. In
House policy can be built on top of your call strategy. What we are
needing is input on logic only ..
bkw
On Tue, 12 Aug 2003, Richard Lyman wrote:
translation: manager gets off thier fat ass and actually talks to
I see. :P
On Tue, 12 Aug 2003, Richard Lyman wrote:
my point was your logic regarding 'calculating magic/metric' for
extremely long call times shouldn't be part of the 'logic' it
SHOULD be 'inhouse' policy where the mgr gives agentA a nice long
chat about how to sell/service the client more
Ok just had my boss point something out:
I'd think dumping calls on most-idle would be fairly straightforward, but
could be skewed if agentA is on a 40 minute call, agentB has a bunch of 5
minute calls
So total call time should be counted in the logic somewhere.
bkw
On Sun, 10 Aug 2003, Brian
]
Sent: Saturday, August 09, 2003 8:48 PM
Subject: Re: [Asterisk-Users] app_queue, fewestcalls and leastrecent logic
Well their are a few diffrent ways to do a roundrobin type setup. One I
didn't mention is circular.
Circular is like this.
You have Agents 1001,1002 and 1003
First calls hits
Very good. We need leastrecent before deployment. Just a basic sorting
of 'leastrecent-ness' should work for us. For now, anyway.
Jim
---
Brian West wrote:
It just rings the fewestcalls or leastrecent over and over.. it doesn't
hunt one bit right now. Thats
ok and what happens when agentA in on a 3 hour call? once again i think
this type of 'senario' should be covered by 'in house' policy.. not some
super queue tweek G
Brian West wrote:
Ok just had my boss point something out:
I'd think dumping calls on most-idle would be fairly straightforward,
Well their are a few diffrent ways to do a roundrobin type setup. One I
didn't mention is circular.
Circular is like this.
You have Agents 1001,1002 and 1003
First calls hits 1001... second call hits 1002 even if 1001 isn't busy.
Third call hits 1003 even if 1001 and 1002 are not busy. Now it
In our original spec for Digium, leastrecent was specifically 'agent who
answered a call longest ago for that queue'. (not a direct quote) It
would then go to the next agent in order of 'longest go'. Has this
changed? Does it immediatly go roundrobin by agent number or agent load
order?
translation: manager gets off thier fat ass and actually talks to
agentA regarding 'INHOUSE' policies, and how it will effect the agents
employment!
G
Brian West wrote:
But how do you translate inhouse to logic for app_queue. :P
On Mon, 11 Aug 2003, Richard Lyman wrote:
ok and what
Use erlang calculations to decide which is most idle.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian West
Sent: Monday, August 11, 2003 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [Asterisk-Users] app_queue, fewestcalls and
leastrecent
my point was your logic regarding 'calculating magic/metric' for
extremely long call times shouldn't be part of the 'logic' it
SHOULD be 'inhouse' policy where the mgr gives agentA a nice long
chat about how to sell/service the client more effectively.
i know there is at least one other out there
Title: RE: [Asterisk-Users] app_queue, fewestcalls and leastrecent logic
Most idle or longest idle should have nothing to do with how long your last call was, or total call time. Longest idle is supposed to be the agent who has been sitting there the longest since the last call was taken
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
On Sun, 10 Aug 2003, Richard Lyman wrote:
i disagree, instead of thinking 'fallback' how about 'order' the agents
(by effecting the 'metric') so you 'target' the agent you want
It would if the user was *busy* not if they don't answer.
Mark
On Mon, 11 Aug 2003, Brian West wrote:
It just rings the fewestcalls or leastrecent over and over.. it doesn't
hunt one bit right now. Thats why I posted to the list so Mark could get
an idea of what people would like to see
and just so we are on the same page.. i wasn't talking about
'roundrobin' on that last reply...
roundrobin will always favor whoever is at the 'front' of the list.
the metric logic, needs to (in my small mind) 'order' the agents in a
'if this method, they are ordered this way' aspect. so if
i disagree, instead of thinking 'fallback' how about 'order' the agents
(by effecting the 'metric') so you 'target' the agent you want first
then if fail they go right to the next one in the 'ordered' list.
Brian West wrote:
leastrecent suffers the same fait as fewestcalls onlying ringing the
Hiya,
First off, thanks to everyone involved in app_queue. Its a great addition to
an already great system.
For my two penneth (or cents!), I think the following would be good:
- the fallback method should be optional if at all possible, so it can be
set up for, say, fewest calls with ring all
19 matches
Mail list logo
