[Asterisk-Users] app_queue, fewestcalls and leastrecent logic

Discussion:

Brian West

2003-08-09 19:06:10 UTC

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

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.

_______________________________________________
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

_______________________________________________
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.

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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 think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw

_______________________________________________
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 Brian West
I think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw

_______________________________________________
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 think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw

_______________________________________________
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 think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw

_______________________________________________
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 think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw

_______________________________________________
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 think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw

_______________________________________________
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 think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw

_______________________________________________
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 think we are starting to see what type of logic people are wanting in
fewestcalls and leastrecent strategy.
bkw

_______________________________________________
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.

_______________________________________________
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

_______________________________________________
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