First of all I would like to thank Mark for getting roundrobin to go
roundrobin. Good job.
Now we have some options here for leastrecent and fewestcalls strategy. It
needs some work on the logic and Mark recommend that I ask the list and
get some input before he makes any changes to it.
fewestca
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
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
Brian West wrote:
Ok just had my boss point something out:
"I'd think dumping calls on most-idle would be fairly straightforward,
translation: manager gets off thier fat ass and actually talks to
agentA regarding 'INHOUSE' policies, and how it will effect the agents
employment!
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 happen
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? Thanks.
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 why
MAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 h
But how do you translate inhouse to logic for app_queue. :P
On Mon, 11 Aug 2003, Richard Lyman wrote:
> 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
>
> Brian West wrote:
>
>
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_queu
quot; <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, August 09, 2003 8:06 PM
> Subject: [Asterisk-Users] app_queue, fewestcalls and leastrecent logic
>
>
> First of all I would like to thank Mark for getting roundrobin to go
> roundrobin. Good job.
>
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
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 mo
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
> age
> 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 o
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 before he fixes fewestcalls and
leastrecent logic.
bkw
On Mon, 11 Aug 2003, Jim Friedeck wrote:
> In our orig
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 m
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 f
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
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 th
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 b
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
l
leastrecent suffers the same fait as fewestcalls onlying ringing the
leastrecent agent over and over endlessly. It should have a fallback
option.
roundrobin with leastrecent first
roundrobin with fewestcalls first
I would like to see a roundrobin with leastbusy first option.
(just because you ha
ys be the first and the order thereafter always the
same?
W
- Original Message -
From: "Brian West" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 09, 2003 8:06 PM
Subject: [Asterisk-Users] app_queue, fewestcalls and leastrecent logic
First
23 matches
Mail list logo
