Discussion:
app_queue, fewestcalls and leastrecent logic
(too old to reply)
Brian West
2003-08-09 19:06:10 UTC
Permalink
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.

fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.

Next new caller would ring fewestcalls agent first then start roundrobin.

What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.

leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.

Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.

Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.

Example:
queue timeout = 20
agent autologoff = 60

The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.

Unless i'm wrong here.

Please post your input on these options and how you would like them to see
them function function.

Thanks,
Brian
CWIS Internet Services
Simon Woodhead
2003-08-09 19:30:14 UTC
Permalink
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 as the fallback rather than
roundrobin.

- it would also be good to have no fall-back at all but to stay in
fewestcalls / leastrecent mode such that if the no. 1 in the league of
fewestcalls / leastrecent calls doesn't answer, it goes on to no. 2, then 3
etc. etc.

The second one may actually be how you see roundrobin working as I'm a
little confused as to how it actually works in queue scenarios. I've only
ever used for passing unanswered calls to a specific extensions to other
members of the workgroup. In a queue scenario, what order does it rotate?
Will the same person always be the first and the order thereafter always the
same?

W

----- Original Message -----
From: "Brian West" <***@bkw.org>
To: <asterisk-***@lists.digium.com>
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.

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.

fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.

Next new caller would ring fewestcalls agent first then start roundrobin.

What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.

leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.

Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.

Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.

Example:
queue timeout = 20
agent autologoff = 60

The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.

Unless i'm wrong here.

Please post your input on these options and how you would like them to see
them function function.

Thanks,
Brian
CWIS Internet Services
Brian West
2003-08-09 19:48:57 UTC
Permalink
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 will
start roundrobin(ie or hunting as you might see it) if the agent doesn't
answer. Fourth call would start back at 1001. I think I seen app_circular
somewhere.

And yes I agree it should be a fallback options or just create diffrent
variations of the current fewestcalls and leastrecent like fewestcallsrr
and leastrecentrr, but that doesn't address the fact that if agent 1001
and 1002 are logged in you don't want agent 1001 ringing forever over and
over while agent 1002 sits idle. If no agents answer it should try
something else or have the option to try something else.


bkw
Post by Simon Woodhead
Hiya,
First off, thanks to everyone involved in app_queue. Its a great addition to
an already great system.
- the fallback method should be optional if at all possible, so it can be
set up for, say, fewest calls with ring all as the fallback rather than
roundrobin.
- it would also be good to have no fall-back at all but to stay in
fewestcalls / leastrecent mode such that if the no. 1 in the league of
fewestcalls / leastrecent calls doesn't answer, it goes on to no. 2, then 3
etc. etc.
The second one may actually be how you see roundrobin working as I'm a
little confused as to how it actually works in queue scenarios. I've only
ever used for passing unanswered calls to a specific extensions to other
members of the workgroup. In a queue scenario, what order does it rotate?
Will the same person always be the first and the order thereafter always the
same?
W
----- Original Message -----
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.
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Simon Woodhead
2003-08-09 20:05:13 UTC
Permalink
Hi Brian,

Thanks for the explanation.

In my second scenario, agent 1002 wouldn't be sat idle as the call would
rotate around all them (like round robin) but in the order they stand in the
league of fewestcalls / least recent calls. They'd all ring but the order
would change according to activity. This'd need to be coupled with your
auto-logout logic though as the fewestcalls / least recent has potential to
always ring first and go unanswered which could delay calls in going to live
and active agents.

W

----- Original Message -----
From: "Brian West" <***@bkw.org>
To: <asterisk-***@lists.digium.com>
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 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 will
start roundrobin(ie or hunting as you might see it) if the agent doesn't
answer. Fourth call would start back at 1001. I think I seen app_circular
somewhere.

And yes I agree it should be a fallback options or just create diffrent
variations of the current fewestcalls and leastrecent like fewestcallsrr
and leastrecentrr, but that doesn't address the fact that if agent 1001
and 1002 are logged in you don't want agent 1001 ringing forever over and
over while agent 1002 sits idle. If no agents answer it should try
something else or have the option to try something else.


bkw
Post by Simon Woodhead
Hiya,
First off, thanks to everyone involved in app_queue. Its a great addition to
an already great system.
- the fallback method should be optional if at all possible, so it can be
set up for, say, fewest calls with ring all as the fallback rather than
roundrobin.
- it would also be good to have no fall-back at all but to stay in
fewestcalls / leastrecent mode such that if the no. 1 in the league of
fewestcalls / leastrecent calls doesn't answer, it goes on to no. 2, then 3
etc. etc.
The second one may actually be how you see roundrobin working as I'm a
little confused as to how it actually works in queue scenarios. I've only
ever used for passing unanswered calls to a specific extensions to other
members of the workgroup. In a queue scenario, what order does it rotate?
Will the same person always be the first and the order thereafter always the
same?
W
----- Original Message -----
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.
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Paul Cheng
2003-08-09 19:55:22 UTC
Permalink
Hi,

We have our * box configured to receive inbound SIP calls from FWD and
enter into an autoattendant where someone can enter an extension
directly.

However, the inbound DTMF is not being correctly detected in most
cases. Entering 8050 results in a correct detection, but enter 9003
results in only 90 being detected. Entering 700 results in 70 being
detected. 799=79, etc.

It appears that repeated digits do not get detected. 8750 works, but
999 results in only 9 being detected.

Has anyone else experienced this problem? We are using X-lite as the
client on the FWD side to test.
Uriel Carrasquilla
2003-08-09 20:40:58 UTC
Permalink
For some reason my Voice-mail is not sending E-mails with the voice
attachment anymore.
It just stopped working.
any suggestions on how to debug?
Simon Woodhead
2003-08-09 20:01:57 UTC
Permalink
Hi Uriel,

Forgive me if you've already done this, but have you checked disk space on
the mailserver? Its caught me before and might save you hours debugging
something that isn't broke.

W

----- Original Message -----
From: "Uriel Carrasquilla" <***@adelphia.net>
To: <asterisk-***@lists.digium.com>
Sent: Saturday, August 09, 2003 9:40 PM
Subject: RE: [Asterisk-Users] E-mail (still version 1) is not being
Delivered


For some reason my Voice-mail is not sending E-mails with the voice
attachment anymore.
It just stopped working.
any suggestions on how to debug?
Jamie Neil
2003-08-09 22:32:18 UTC
Permalink
Post by Paul Cheng
Hi,
We have our * box configured to receive inbound SIP calls from FWD and
enter into an autoattendant where someone can enter an extension
directly.
However, the inbound DTMF is not being correctly detected in most
cases. Entering 8050 results in a correct detection, but enter 9003
results in only 90 being detected. Entering 700 results in 70 being
detected. 799=79, etc.
It appears that repeated digits do not get detected. 8750 works, but
999 results in only 9 being detected.
Has anyone else experienced this problem? We are using X-lite as the
client on the FWD side to test.
This is a problem that we have had with X-Lite which I heard was due to the
RFC2833 DTMF frames not being correctly formatted (I may be wrong on this -
I am not a SIP authority by any means).

In-band detection works ok, but then you are limited to G711.

I sent a packet trace (as requested) to someone at Xten demonstrating the
problem, but have heard nothing since. I read somewhere that they had fixed
this on the latest build (1050), however that's the one I've been having the
problems with!

Jamie
Uriel Carrasquilla
2003-08-10 16:17:32 UTC
Permalink
W:
checked the disk space and there is plenty of room
What sequence did you follow for debugging?
where does * put the E-mails before transmitting?
URiel

-----Original Message-----
From: asterisk-users-***@lists.digium.com
[mailto:asterisk-users-***@lists.digium.com]On Behalf Of Simon
Woodhead
Sent: Saturday, August 09, 2003 4:02 PM
To: asterisk-***@lists.digium.com
Subject: Re: [Asterisk-Users] E-mail (still version 1) is not being
Delivered


Hi Uriel,

Forgive me if you've already done this, but have you checked disk space on
the mailserver? Its caught me before and might save you hours debugging
something that isn't broke.

W

----- Original Message -----
From: "Uriel Carrasquilla" <***@adelphia.net>
To: <asterisk-***@lists.digium.com>
Sent: Saturday, August 09, 2003 9:40 PM
Subject: RE: [Asterisk-Users] E-mail (still version 1) is not being
Delivered


For some reason my Voice-mail is not sending E-mails with the voice
attachment anymore.
It just stopped working.
any suggestions on how to debug?
Richard Lyman
2003-08-10 18:56:59 UTC
Permalink
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 most recent
attempt would be on the bottom '1057174447' (below is an example)

-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447

that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Brian West
2003-08-10 21:06:01 UTC
Permalink
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)

I'm sure better autologoff logic as per my first email would be a great
idea also.

bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Richard Lyman
2003-08-10 22:08:57 UTC
Permalink
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Brian West
2003-08-10 22:45:06 UTC
Permalink
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.

bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Brian West
2003-08-11 15:27:17 UTC
Permalink
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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Jim Friedeck
2003-08-11 15:37:22 UTC
Permalink
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.

Jim Friedeck

------------------------------------------
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Brian West
2003-08-11 15:44:36 UTC
Permalink
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
Post by Jim Friedeck
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.
Jim Friedeck
------------------------------------------
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Jim Friedeck
2003-08-11 16:07:34 UTC
Permalink
Very good. We need leastrecent before deployment. Just a basic sorting
of 'leastrecent-ness' should work for us. For now, anyway.

Jim

-----------------------------------
Post by Brian West
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
Post by Jim Friedeck
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.
Jim Friedeck
------------------------------------------
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Richard Lyman
2003-08-12 06:29:24 UTC
Permalink
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>
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Brian West
2003-08-12 11:06:00 UTC
Permalink
But how do you translate inhouse to logic for app_queue. :P
Post by Richard Lyman
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>
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Richard Lyman
2003-08-12 14:24:32 UTC
Permalink
translation: manager gets off thier fat ass and actually talks to
agentA regarding 'INHOUSE' policies, and how it will effect the agents
employment!

<G>
Post by Brian West
But how do you translate inhouse to logic for app_queue. :P
Post by Richard Lyman
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>
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Brian West
2003-08-12 15:32:45 UTC
Permalink
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
Post by Richard Lyman
translation: manager gets off thier fat ass and actually talks to
agentA regarding 'INHOUSE' policies, and how it will effect the agents
employment!
<G>
Post by Brian West
But how do you translate inhouse to logic for app_queue. :P
Post by Richard Lyman
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>
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Richard Lyman
2003-08-12 20:24:55 UTC
Permalink
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 that agrees with
me. <G>
Post by Brian West
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
Post by Richard Lyman
translation: manager gets off thier fat ass and actually talks to
agentA regarding 'INHOUSE' policies, and how it will effect the agents
employment!
<G>
Post by Brian West
But how do you translate inhouse to logic for app_queue. :P
Post by Richard Lyman
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>
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Brian West
2003-08-12 22:24:18 UTC
Permalink
I see. :P
Post by Richard Lyman
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 that agrees with
me. <G>
Post by Brian West
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
Post by Richard Lyman
translation: manager gets off thier fat ass and actually talks to
agentA regarding 'INHOUSE' policies, and how it will effect the agents
employment!
<G>
Post by Brian West
But how do you translate inhouse to logic for app_queue. :P
Post by Richard Lyman
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>
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Richard Lyman
2003-08-10 22:16:05 UTC
Permalink
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 the 'target'
agent (the one at the top is busy / logged off / in wrapup / some other
'not viable agent' trigger... it simply goes to the next in the list, if
somehow ALL the agents got looped over, let the 'retry' code (which is
there) kick in and start all over.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Adam Goryachev
2003-08-11 09:44:47 UTC
Permalink
Post by Brian West
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!
Post by Brian West
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.
IMHO, leastrecent and fewestcalls should order the 'queue' based on those
parameters. The members of the queue should be called in that order. (Of
course, the priority parameter should be respected first though).

Now, roundrobin should work by always ordering the members in the same
order, but the next interface it tries is always one after the previous one
it tried.

We should also have a type of 'ordered' or similar, which is like roundrobin
but always starts from the same spot. (eg, always call the receptionist
first, then overflow to the accounts person, and then the marketing person
etc...
Post by Brian West
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
This sounds very nice, but perhaps there should also be some sort of
indicator to the user that they have been logged off. If you forget to
logoff before you go to the toilet, you come back, and start doing 'stuff'
while you wait for some calls to arrive and don't realise you have been
logged off.

Some options:

a) Send them an email when they are auto-logged off (a lot of 'agents' may
not have an email account)
b) Send them a voicemail when they are auto-logged off (might have MWI which
provides a visual indicator that you have been logged off)
c) Don't actually log them off, just ignore their extension for a
configurable amount of time. This might even re-act similar to qmail's
logarithmic back-off retry times. ie, suspend for 10 minutes, then retry,
suspend for 30 minutes, retry, suspend for 1 hour, etc... (need a way to log
back on tho)
d) Should also log to cdr when someone is auto-logged off, this way
reporting will show that agent 232 is lazy and never answers the phone,
resulting in always being logged off ....

Other people with more experience in a call centre might have other ideas on
notification methods...

Regards,
Adam
Linus Surguy
2003-08-11 10:02:45 UTC
Permalink
Hi all,

We're using an older version of *, built a couple of months ago and before
we go through all the hassle of updating source files and checking latest
dependancies on other kernels etc, I'd like to know if the following is a
known fault:

We're running a PSTN to FWD gateway in the UK and just whilst I was looking
at something else I noticed a call come in which caused Asterisk to simply
halt, terminating all processes.

I've got a SIP trace of the call, which is quoted below. Any ideas?


voip-gw1:/etc/asterisk # asterisk
voip-gw1:/etc/asterisk # asterisk -rvvv
== Parsing '/etc/asterisk/asterisk.conf': Found
Asterisk 0.4.0, Copyright (C) 1999-2001 Linux Support Services, Inc.
Written by Mark Spencer <***@linux-support.net>
=========================================================================
Connected to Asterisk 0.4.0
currently running on voip-gw1 (pid = 31349)
-- Remote UNIX connection
voip-gw1*CLI> sip debug
SIP Debugging Enabled
voip-gw1*CLI> iax2 no debug
IAX2 Debugging Disabled
-- B-channel 1 successfully restarted on span 1
-- B-channel 2 successfully restarted on span 1
-- B-channel 3 successfully restarted on span 1
-- B-channel 4 successfully restarted on span 1
-- B-channel 5 successfully restarted on span 1
-- B-channel 6 successfully restarted on span 1
-- B-channel 7 successfully restarted on span 1
-- B-channel 8 successfully restarted on span 1
-- B-channel 9 successfully restarted on span 1
-- B-channel 10 successfully restarted on span 1
-- B-channel 11 successfully restarted on span 1
-- B-channel 12 successfully restarted on span 1
-- B-channel 13 successfully restarted on span 1
-- B-channel 14 successfully restarted on span 1
-- B-channel 15 successfully restarted on span 1
-- B-channel 17 successfully restarted on span 1
-- B-channel 18 successfully restarted on span 1
-- B-channel 19 successfully restarted on span 1
-- B-channel 20 successfully restarted on span 1
-- B-channel 21 successfully restarted on span 1
-- B-channel 22 successfully restarted on span 1
-- B-channel 23 successfully restarted on span 1
-- B-channel 24 successfully restarted on span 1
-- B-channel 25 successfully restarted on span 1
-- B-channel 26 successfully restarted on span 1
-- B-channel 27 successfully restarted on span 1
-- B-channel 28 successfully restarted on span 1
-- B-channel 29 successfully restarted on span 1
-- B-channel 30 successfully restarted on span 1
-- B-channel 31 successfully restarted on span 1
-- Executing Dial("Zap/3-1", "Sip/***@fwd.pulver.com") in new stack
-- Accepting call from '1189000000' to '099138269' on channel 3, span 1
Interface is eth0
IP Address is 213.166.5.129
We're at 213.166.5.129 port 2738
Answering with preferred capability 8
Answering with preferred capability 4
Answering with preferred capability 2
Answering with non-codec capability 1
10 headers, 11 lines
Reliably Transmitting:
INVITE sip:***@192.246.69.223 SIP/2.0
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
From: "1189000000" <sip:***@213.166.5.129>;tag=as5770a04f
To: <sip:***@192.246.69.223>
Contact: <sip:***@213.166.5.129>
Call-ID: ***@213.166.5.129
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Content-Type: application/sdp
Content-Length: 237

v=0
o=root 31365 31365 IN IP4 213.166.5.129
s=session
c=IN IP4 213.166.5.129
t=0 0
m=audio 2738 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
(no NAT) to 192.246.69.223:5060
-- Called ***@fwd.pulver.com
Sip read: LI>
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
From: "1189000000" <sip:***@213.166.5.129>;tag=as5770a04f
To: <sip:***@192.246.69.223>
Call-ID: ***@213.166.5.129
CSeq: 102 INVITE
Server: Free World Dialup (0.8.11pre31 (i386/linux))
Content-Length: 0


8 headers, 0 lines
Sip read: LI>
SIP/2.0 302 MovedTemporarily
Via: SIP/2.0/UDP 213.166.5.129;branch=z9hG4bK3f7299f7
Call-ID: ***@213.166.5.129
From: <sip:***@213.166.5.129>;tag=as5770a04f
To: edc-soft <sip:***@192.246.69.223>;tag=16f2d190
CSeq: 102 INVITE
Contact: <sip:***@81.103.138.84:5062>;q=1.000
User-Agent: Ahead SIPPS IP Phone Version 2.0.42.13
Content-Length: 0


9 headers, 0 lines
-- Got SIP response 302 "MovedTemporarily" back from 192.246.69.223
Transmitting:
ACK sip:***@192.246.69.223 SIP/2.0
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
From: "1189000000" <sip:***@213.166.5.129>;tag=as5770a04f
To: <sip:***@192.246.69.223>;tag=16f2d190
Contact: <sip:***@213.166.5.129>
Call-ID: ***@213.166.5.129
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0

(no NAT) to 192.246.69.223:5060
-- Now forwarding Zap/3-1 to '***@default' (thanks to
SIP/fwd.pulver.com-c473)
voip-gw1*CLI>
Disconnected from Asterisk server
voip-gw1:/etc/asterisk #
Jeremy McNamara
2003-08-11 13:53:11 UTC
Permalink
what hassles? cvs update


Jeremy McNamara
Post by Linus Surguy
Hi all,
We're using an older version of *, built a couple of months ago and before
we go through all the hassle of updating source files and checking latest
dependancies on other kernels etc, I'd like to know if the following is a
We're running a PSTN to FWD gateway in the UK and just whilst I was looking
at something else I noticed a call come in which caused Asterisk to simply
halt, terminating all processes.
I've got a SIP trace of the call, which is quoted below. Any ideas?
voip-gw1:/etc/asterisk # asterisk
voip-gw1:/etc/asterisk # asterisk -rvvv
== Parsing '/etc/asterisk/asterisk.conf': Found
Asterisk 0.4.0, Copyright (C) 1999-2001 Linux Support Services, Inc.
=========================================================================
Connected to Asterisk 0.4.0
currently running on voip-gw1 (pid = 31349)
-- Remote UNIX connection
voip-gw1*CLI> sip debug
SIP Debugging Enabled
voip-gw1*CLI> iax2 no debug
IAX2 Debugging Disabled
-- B-channel 1 successfully restarted on span 1
-- B-channel 2 successfully restarted on span 1
-- B-channel 3 successfully restarted on span 1
-- B-channel 4 successfully restarted on span 1
-- B-channel 5 successfully restarted on span 1
-- B-channel 6 successfully restarted on span 1
-- B-channel 7 successfully restarted on span 1
-- B-channel 8 successfully restarted on span 1
-- B-channel 9 successfully restarted on span 1
-- B-channel 10 successfully restarted on span 1
-- B-channel 11 successfully restarted on span 1
-- B-channel 12 successfully restarted on span 1
-- B-channel 13 successfully restarted on span 1
-- B-channel 14 successfully restarted on span 1
-- B-channel 15 successfully restarted on span 1
-- B-channel 17 successfully restarted on span 1
-- B-channel 18 successfully restarted on span 1
-- B-channel 19 successfully restarted on span 1
-- B-channel 20 successfully restarted on span 1
-- B-channel 21 successfully restarted on span 1
-- B-channel 22 successfully restarted on span 1
-- B-channel 23 successfully restarted on span 1
-- B-channel 24 successfully restarted on span 1
-- B-channel 25 successfully restarted on span 1
-- B-channel 26 successfully restarted on span 1
-- B-channel 27 successfully restarted on span 1
-- B-channel 28 successfully restarted on span 1
-- B-channel 29 successfully restarted on span 1
-- B-channel 30 successfully restarted on span 1
-- B-channel 31 successfully restarted on span 1
-- Accepting call from '1189000000' to '099138269' on channel 3, span 1
Interface is eth0
IP Address is 213.166.5.129
We're at 213.166.5.129 port 2738
Answering with preferred capability 8
Answering with preferred capability 4
Answering with preferred capability 2
Answering with non-codec capability 1
10 headers, 11 lines
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Content-Type: application/sdp
Content-Length: 237
v=0
o=root 31365 31365 IN IP4 213.166.5.129
s=session
c=IN IP4 213.166.5.129
t=0 0
m=audio 2738 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
(no NAT) to 192.246.69.223:5060
Sip read: LI>
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
CSeq: 102 INVITE
Server: Free World Dialup (0.8.11pre31 (i386/linux))
Content-Length: 0
8 headers, 0 lines
Sip read: LI>
SIP/2.0 302 MovedTemporarily
Via: SIP/2.0/UDP 213.166.5.129;branch=z9hG4bK3f7299f7
CSeq: 102 INVITE
User-Agent: Ahead SIPPS IP Phone Version 2.0.42.13
Content-Length: 0
9 headers, 0 lines
-- Got SIP response 302 "MovedTemporarily" back from 192.246.69.223
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0
(no NAT) to 192.246.69.223:5060
SIP/fwd.pulver.com-c473)
voip-gw1*CLI>
Disconnected from Asterisk server
voip-gw1:/etc/asterisk #
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Linus Surguy
2003-08-11 14:01:58 UTC
Permalink
Haha. Last time I discovered my libc or something wasnt quite there so I
couldnt compile chan_enum or something, so I didnt bother and carried on
with the older version (only from a couple of months back)

Linus

----- Original Message -----
From: "Jeremy McNamara" <***@nufone.net>
To: <asterisk-***@lists.digium.com>
Sent: Monday, August 11, 2003 2:53 PM
Subject: Re: [Asterisk-Users] Known problem?
Post by Jeremy McNamara
what hassles? cvs update
Jeremy McNamara
Post by Linus Surguy
Hi all,
We're using an older version of *, built a couple of months ago and before
we go through all the hassle of updating source files and checking latest
dependancies on other kernels etc, I'd like to know if the following is a
We're running a PSTN to FWD gateway in the UK and just whilst I was looking
at something else I noticed a call come in which caused Asterisk to simply
halt, terminating all processes.
I've got a SIP trace of the call, which is quoted below. Any ideas?
voip-gw1:/etc/asterisk # asterisk
voip-gw1:/etc/asterisk # asterisk -rvvv
== Parsing '/etc/asterisk/asterisk.conf': Found
Asterisk 0.4.0, Copyright (C) 1999-2001 Linux Support Services, Inc.
=========================================================================
Connected to Asterisk 0.4.0
currently running on voip-gw1 (pid = 31349)
-- Remote UNIX connection
voip-gw1*CLI> sip debug
SIP Debugging Enabled
voip-gw1*CLI> iax2 no debug
IAX2 Debugging Disabled
-- B-channel 1 successfully restarted on span 1
-- B-channel 2 successfully restarted on span 1
-- B-channel 3 successfully restarted on span 1
-- B-channel 4 successfully restarted on span 1
-- B-channel 5 successfully restarted on span 1
-- B-channel 6 successfully restarted on span 1
-- B-channel 7 successfully restarted on span 1
-- B-channel 8 successfully restarted on span 1
-- B-channel 9 successfully restarted on span 1
-- B-channel 10 successfully restarted on span 1
-- B-channel 11 successfully restarted on span 1
-- B-channel 12 successfully restarted on span 1
-- B-channel 13 successfully restarted on span 1
-- B-channel 14 successfully restarted on span 1
-- B-channel 15 successfully restarted on span 1
-- B-channel 17 successfully restarted on span 1
-- B-channel 18 successfully restarted on span 1
-- B-channel 19 successfully restarted on span 1
-- B-channel 20 successfully restarted on span 1
-- B-channel 21 successfully restarted on span 1
-- B-channel 22 successfully restarted on span 1
-- B-channel 23 successfully restarted on span 1
-- B-channel 24 successfully restarted on span 1
-- B-channel 25 successfully restarted on span 1
-- B-channel 26 successfully restarted on span 1
-- B-channel 27 successfully restarted on span 1
-- B-channel 28 successfully restarted on span 1
-- B-channel 29 successfully restarted on span 1
-- B-channel 30 successfully restarted on span 1
-- B-channel 31 successfully restarted on span 1
-- Accepting call from '1189000000' to '099138269' on channel 3, span 1
Interface is eth0
IP Address is 213.166.5.129
We're at 213.166.5.129 port 2738
Answering with preferred capability 8
Answering with preferred capability 4
Answering with preferred capability 2
Answering with non-codec capability 1
10 headers, 11 lines
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Content-Type: application/sdp
Content-Length: 237
v=0
o=root 31365 31365 IN IP4 213.166.5.129
s=session
c=IN IP4 213.166.5.129
t=0 0
m=audio 2738 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
(no NAT) to 192.246.69.223:5060
Sip read: LI>
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
CSeq: 102 INVITE
Server: Free World Dialup (0.8.11pre31 (i386/linux))
Content-Length: 0
8 headers, 0 lines
Sip read: LI>
SIP/2.0 302 MovedTemporarily
Via: SIP/2.0/UDP 213.166.5.129;branch=z9hG4bK3f7299f7
CSeq: 102 INVITE
User-Agent: Ahead SIPPS IP Phone Version 2.0.42.13
Content-Length: 0
9 headers, 0 lines
-- Got SIP response 302 "MovedTemporarily" back from 192.246.69.223
Via: SIP/2.0/UDP 213.166.5.129:5060;branch=z9hG4bK3f7299f7
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0
(no NAT) to 192.246.69.223:5060
SIP/fwd.pulver.com-c473)
voip-gw1*CLI>
Disconnected from Asterisk server
voip-gw1:/etc/asterisk #
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Nathan Littlepage
2003-08-11 15:32:27 UTC
Permalink
Use erlang calculations to decide which is most idle.
Post by Uriel Carrasquilla
-----Original Message-----
Sent: Monday, August 11, 2003 10:27 AM
Subject: Re: [Asterisk-Users] app_queue, fewestcalls and
leastrecent logic
"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
Post by Brian West
I think we are starting to see what type of logic people
are wanting in
Post by Brian West
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
i disagree, instead of thinking 'fallback' how about
'order' the agents
Post by Brian West
Post by Richard Lyman
(by effecting the 'metric') so you 'target' the agent you
want first
Post by Brian West
Post by Richard Lyman
then if fail they go right to the next one in the 'ordered' list.
Post by Brian West
leastrecent suffers the same fait as fewestcalls onlying
ringing the
Post by Brian West
Post by Richard Lyman
Post by Brian West
leastrecent agent over and over endlessly. It should
have a fallback
Post by Brian West
Post by Richard Lyman
Post by Brian West
option.
roundrobin with leastrecent first
roundrobin with fewestcalls first
I would like to see a roundrobin with leastbusy first option.
(just because you have taken less call or leastrecent
doesn't mean you
Post by Brian West
Post by Richard Lyman
Post by Brian West
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email
would be a great
Post by Brian West
Post by Richard Lyman
Post by Brian West
idea also.
bkw
Post by Richard Lyman
well if you ask me, the leastrecent part would work if
you reversed the
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
logic on the metric.
my other last_used mod would do a time_t on that agent
the last time it
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
was 'tried' (ast_request'd) then (i was using arrays)
qsort so that (new
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
agents) '0' would be on top, and the agent that got the
most recent
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
attempt would be on the bottom '1057174447' (below is
an example)
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always
working with a full stack of agents.
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
First of all I would like to thank Mark for getting
roundrobin to go
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
roundrobin. Good job.
Now we have some options here for leastrecent and
fewestcalls strategy. It
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
needs some work on the logic and Mark recommend that I
ask the list and
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
get some input before he makes any changes to it.
fewestcalls from what I have seen would always ring
the agent with the
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
fewestcalls first then go into roundrobin if that
agent didn't answer.
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
Next new caller would ring fewestcalls agent first
then start roundrobin.
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
What do you think should happen in fewestcalls? Right
now it just rings
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
the agent with the fewestcalls over and over with
current app_queue logic.
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
leastrecent from what I have been looking at will ring
the agent that has
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
least recently take a call first then if they don't
answer go into
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
roundrobin. Then the next new call coming from queue
would first go to
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
the leastrecent first then try every agent in
roundrobin till answered
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
then starting over again. New caller from queue hits
leastrecent agent
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
first.
Same thing happens in leastrecent strategy. The
leastrecent agent will
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options.
But that also might
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
need some work. I don't want to log off an agent for
not answering the
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
phone only once. So here is how I would like to see
autologoff work.
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times
in a row to get
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
logged off. As it stands now they did not answer just
once and get logged
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
off. Thus allow for an employee to use the excuse for
not working when
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you
would like them to see
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Mark Spencer
2003-08-11 19:02:29 UTC
Permalink
It would if the user was *busy* not if they don't answer.

Mark
Post by Brian West
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
Post by Jim Friedeck
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.
Jim Friedeck
------------------------------------------
Post by Brian West
"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
Post by Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
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.
Post by Brian West
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 have taken less call or leastrecent doesn't mean you
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a great
idea also.
bkw
Post by Richard Lyman
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 most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a full stack of agents.
Post by Brian West
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.
fewestcalls from what I have seen would always ring the agent with the
fewestcalls first then go into roundrobin if that agent didn't answer.
Next new caller would ring fewestcalls agent first then start roundrobin.
What do you think should happen in fewestcalls? Right now it just rings
the agent with the fewestcalls over and over with current app_queue logic.
leastrecent from what I have been looking at will ring the agent that has
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first go to
the leastrecent first then try every agent in roundrobin till answered
then starting over again. New caller from queue hits leastrecent agent
first.
Same thing happens in leastrecent strategy. The leastrecent agent will
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also might
need some work. I don't want to log off an agent for not answering the
phone only once. So here is how I would like to see autologoff work.
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to get
logged off. As it stands now they did not answer just once and get logged
off. Thus allow for an employee to use the excuse for not working when
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like them to see
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
McAughan, Matt
2003-08-12 12:30:54 UTC
Permalink
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.

Now if your an agent that gets the 5 minute calls well then your just the
lucky one. Or someone needs to tell your friends to stop calling! If your
taking 3 hour calls someone needs to teach the agent how to wrap things up
and close the sell, or again tell your friends to stop calling! ;)

But with longest idle at least everyone gets an equal amount of "off the
phone" time, not an equal amount of "on the phone" time.

-----Original Message-----
From: Richard Lyman
To: asterisk-***@lists.digium.com
Sent: 8/12/03 1:29 AM
Subject: Re: [Asterisk-Users] app_queue, fewestcalls and leastrecent logic

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>
Post by Brian West
"I'd think dumping calls on most-idle would be fairly straightforward,
but
Post by Brian West
could be skewed if agentA is on a 40 minute call, agentB has a bunch of
5
Post by Brian West
minute calls"
So total call time should be counted in the logic somewhere.
bkw
Post by Brian West
I think we are starting to see what type of logic people are wanting
in
Post by Brian West
Post by Brian West
fewestcalls and leastrecent strategy.
bkw
Post by Richard Lyman
i disagree, instead of thinking 'fallback' how about 'order' the
agents
Post by Brian West
Post by Brian West
Post by Richard Lyman
(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.
Post by Brian West
leastrecent suffers the same fait as fewestcalls onlying ringing the
leastrecent agent over and over endlessly. It should have a
fallback
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
option.
roundrobin with leastrecent first
roundrobin with fewestcalls first
I would like to see a roundrobin with leastbusy first option.
(just because you have taken less call or leastrecent doesn't mean
you
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
haven't been a busy agent!)
I'm sure better autologoff logic as per my first email would be a
great
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
idea also.
bkw
Post by Richard Lyman
well if you ask me, the leastrecent part would work if you reversed
the
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
logic on the metric.
my other last_used mod would do a time_t on that agent the last
time it
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
was 'tried' (ast_request'd) then (i was using arrays) qsort so that
(new
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
agents) '0' would be on top, and the agent that got the most recent
attempt would be on the bottom '1057174447' (below is an example)
-- sorted agent array: 317 last_used: 0
-- sorted agent array: 318 last_used: 0
-- sorted agent array: 319 last_used: 0
-- sorted agent array: 300 last_used: 1057174447
that way, (for leastrecent anyway), you are always working with a
full stack of agents.
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
First of all I would like to thank Mark for getting roundrobin to
go
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
roundrobin. Good job.
Now we have some options here for leastrecent and fewestcalls
strategy. It
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
needs some work on the logic and Mark recommend that I ask the
list and
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
get some input before he makes any changes to it.
fewestcalls from what I have seen would always ring the agent with
the
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
fewestcalls first then go into roundrobin if that agent didn't
answer.
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
Next new caller would ring fewestcalls agent first then start
roundrobin.
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
What do you think should happen in fewestcalls? Right now it just
rings
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
the agent with the fewestcalls over and over with current
app_queue logic.
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
leastrecent from what I have been looking at will ring the agent
that has
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
least recently take a call first then if they don't answer go into
roundrobin. Then the next new call coming from queue would first
go to
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
the leastrecent first then try every agent in roundrobin till
answered
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
then starting over again. New caller from queue hits leastrecent
agent
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
first.
Same thing happens in leastrecent strategy. The leastrecent agent
will
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
ring over and over with current app_queue logic.
Now some of you might recommend autologoff options. But that also
might
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
need some work. I don't want to log off an agent for not
answering the
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
phone only once. So here is how I would like to see autologoff
work.
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
queue timeout = 20
agent autologoff = 60
The agent would have to not answer their phone 3 times in a row to
get
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
logged off. As it stands now they did not answer just once and
get logged
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
off. Thus allow for an employee to use the excuse for not working
when
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
they should be logged in and taking calls.
Unless i'm wrong here.
Please post your input on these options and how you would like
them to see
Post by Brian West
Post by Brian West
Post by Richard Lyman
Post by Brian West
Post by Richard Lyman
Post by Brian West
them function function.
Thanks,
Brian
CWIS Internet Services
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users
Loading...