asterisk users - Sep 2004 - Queue and Agent functionality

I've seen alot of posts lately on Queue and Agent functionality, and
alot of hacks to make them do different things that most call center
managers want.

In the sake of doing this one time, I'd like to develop a single list
of request so we can consolidate a feature request for the Queue/Agent
system.

Here are the ones that I run into the most:

1.  Queue should know the status of agents assigned to a queue and act
accordingly.

 Here are a couple examples of the problem.  

A queue has no agents logged in and handling the queue, a call comes
in for the queue, the call remains in the queue until either an agent
logs in, or the queue reaches it's timeout.  What it should do is
immediately time out setting priority +101.  Normal timeout (caller in
busy queue with agents active) should exit with priority set +1.

A Queue has active agents in a prioritized fashion.  Agent 1 is
priority 1, 2 is 2, 3 is 3, and 4 is 4.  Agent 1 needs to make an
outbound call as does agent 2.  Both are now 'busy'.  The Queue still
attempts to call agent 1, gets 'busy' back from the sip device (i've
only tried this with sip), and then the system appears to wait for
something like 7-8 seconds before trying the next agent in line.

2. The queue system should allow a set of messages to be played at
specific times.  For example, a message that is played upon entry into
the queue and no other time, the current set of messages played every
frequency=XX, a message played to the caller when the call is accepted
by an agent (eg "transfering"), finally, a set of messages played to
the user based upon a predefined period int he config file.. see
example below

message1-time=<time in seconds>
message1-frequency=<never|once|always>
message1=<message1-file-loc>

message2-time=<time in seconds>
message2-frequency=<never|once|always>
message2=<message2-file-loc>

Where a message <messageX-file-loc> is played <never|once|always>
every <time in seconds>.

if time is set to 0, or freqency is set to never, the message is not played.

If time is set to >0, and frequency is set to once, message is played
at messagex-time, and never again.

if time is set to >0 and frequency is set to always, message is played
every messagex-time in seconds.

3.  Agent timeout (logs the agent off if they do not respond to a ring
in a defined about of time) does not track across calls.  For example,
if an agent steps away and forgets to log out, then thier phone will
ring based upon whatever call strategy is used.  If the agent timeout
is set higher than the time the queue polls a set of agents they will
never be logged out.  The timer needs to increment per agent across
multiple polls.  So if my queue poll timer is 20 secons, but the agent
timeout is set to 60 seconds, the preferred function would be to log
the agent out of the queue if they completely miss three poll events.

4. If a caller empties a handled queue (active agents) with no
callers, the caller will still hear messages (you are first in queue,
etc.).  This should not occur.  Someone posted a 2-line patch on -dev
list recently to fix this issue.



-Chris

Chris,

I agree with your assessment of asterisk's queues. I took Robert's reply
to
my original post, and came up with a way to tackle your first scenario (no
agents in queue=caller in limbo) with his idea of setting variables. My idea
deals with setting global variable states for each agent. I only have 4
agents, so it should work for me fairly easily. In the extensions.conf file
I would have something like this:

[globals]
GCSR1=off
GCSR2=off
GCSR3=off
GCSR4=off  

Then, in the context where my agents log in/out of queue, I set the global
variable to on/off depending on their action. When the agent dials 800,
GCSR1 becomes 'on'. When they dial 801##, GCSR1 becomes 'off'.

[fromcsr1]
exten=> 800,1,AgentCallbackLogin(101|101@dispatchlogin)
exten=> 800,2,SetGlobalVar(GCSR1=on)
exten=> 800,3,Hangup
exten=> 801,1,AgentCallBackLogin(101)
exten=> 801,2,SetGlobalVar(GCSR1=off)
exten=> 801,3,Hangup


Then, in my queue, I check for the value of GCSR1 before dumping them to the
queue. Otherwise, dump them to VM. Obviously, the GotoIf would have to check
if GCSR1 = on | GCSR2 = on | GCSR3 = on | etc... For my testing, I was just
using GCSR1.

[queue]
exten => 1,1,DigitTimeout,1
exten => 1,2,ResponseTimeout,1
exten => 1,3,GotoIf($[${GCSR1} = on]?4:5)
exten => 1,4,Queue(order|tT)
exten => 1,5,Goto(generalvm|s|1)


While this idea seems to make sense (in my head), I am unable to make it
work. For example, my GotoIF command does work, so the value of GCSR1 will
determine which path the caller takes. The part that doesn't work is in the
[fromcsr] context. My SetGlobalVar(GCSR1=on) seems to have no effect,
therefore, making my solution not work.

Does anyone have any ideas?

Thanks,

Marco



-----Original Message-----
From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Chris Icide
Sent: Saturday, September 25, 2004 1:34 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [Asterisk-Users] Queue and Agent functionality

I've seen alot of posts lately on Queue and Agent functionality, and alot of
hacks to make them do different things that most call center managers want.

In the sake of doing this one time, I'd like to develop a single list of
request so we can consolidate a feature request for the Queue/Agent system.

Here are the ones that I run into the most:

1.  Queue should know the status of agents assigned to a queue and act
accordingly.

 Here are a couple examples of the problem.  

A queue has no agents logged in and handling the queue, a call comes in for
the queue, the call remains in the queue until either an agent logs in, or
the queue reaches it's timeout.  What it should do is immediately time out
setting priority +101.  Normal timeout (caller in busy queue with agents
active) should exit with priority set +1.

A Queue has active agents in a prioritized fashion.  Agent 1 is priority 1,
2 is 2, 3 is 3, and 4 is 4.  Agent 1 needs to make an outbound call as does
agent 2.  Both are now 'busy'.  The Queue still attempts to call agent
1,
gets 'busy' back from the sip device (i've only tried this with
sip), and
then the system appears to wait for something like 7-8 seconds before trying
the next agent in line.

2. The queue system should allow a set of messages to be played at specific
times.  For example, a message that is played upon entry into the queue and
no other time, the current set of messages played every frequency=XX, a
message played to the caller when the call is accepted by an agent (eg
"transfering"), finally, a set of messages played to the user based
upon a
predefined period int he config file.. see example below

message1-time=<time in seconds>
message1-frequency=<never|once|always>
message1=<message1-file-loc>

message2-time=<time in seconds>
message2-frequency=<never|once|always>
message2=<message2-file-loc>

Where a message <messageX-file-loc> is played <never|once|always>
every
<time in seconds>.

if time is set to 0, or freqency is set to never, the message is not played.

If time is set to >0, and frequency is set to once, message is played at
messagex-time, and never again.

if time is set to >0 and frequency is set to always, message is played every
messagex-time in seconds.

3.  Agent timeout (logs the agent off if they do not respond to a ring in a
defined about of time) does not track across calls.  For example, if an
agent steps away and forgets to log out, then thier phone will ring based
upon whatever call strategy is used.  If the agent timeout is set higher
than the time the queue polls a set of agents they will never be logged out.
The timer needs to increment per agent across multiple polls.  So if my
queue poll timer is 20 secons, but the agent timeout is set to 60 seconds,
the preferred function would be to log the agent out of the queue if they
completely miss three poll events.

4. If a caller empties a handled queue (active agents) with no callers, the
caller will still hear messages (you are first in queue, etc.).  This should
not occur.  Someone posted a 2-line patch on -dev list recently to fix this
issue.



-Chris
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

!DSPAM:4155ba98170742049917856!

Hi!
> [fromcsr1]
> exten=> 800,1,AgentCallbackLogin(101|101@dispatchlogin)
> exten=> 800,2,SetGlobalVar(GCSR1=on)
> exten=> 800,3,Hangup
> determine which path the caller takes. The part that doesn't work is in
the
> [fromcsr] context. My SetGlobalVar(GCSR1=on) seems to have no effect,
> therefore, making my solution not work.
> 
> Does anyone have any ideas?
Unfortunately AgentCallbackLogin() _itself_ initiates the hangup, which 
means that any following priorities in your dialplan are useless. Besides 
your approach isn't yet perfect, what if an agent gets auto-logged out 
because he/she hasn't answered within the time limit?

Cheers, Philipp

> -----Original Message-----
> From: Chris Icide [mailto:cicide@gmail.com] 
> Sent: Saturday, September 25, 2004 2:34 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: [Asterisk-Users] Queue and Agent functionality
> 
> 
> 1.  Queue should know the status of agents assigned to a 
> queue and act accordingly.
> 
Agreed.  I propose that * actually monitors the channel
that the agent logs in from.  At the very least it keeps
* from trying to pass calls to agents that are on outbound
calls. 
> 2. The queue system should allow a set of messages to be 
> played at specific times.  
>
This is also a very important in a typical call center.
> 3.  Agent timeout (logs the agent off if they do not respond 
> to a ring in a defined about of time) does not track across 
> calls.  For example, if an agent steps away and forgets to 
> log out, then thier phone will ring based upon whatever call 
> strategy is used.  If the agent timeout is set higher than 
> the time the queue polls a set of agents they will never be 
> logged out.  The timer needs to increment per agent across 
> multiple polls.  So if my queue poll timer is 20 secons, but 
> the agent timeout is set to 60 seconds, the preferred 
> function would be to log the agent out of the queue if they 
> completely miss three poll events.
> 
Agreed.
> 4. If a caller empties a handled queue (active agents) with 
> no callers, the caller will still hear messages (you are 
> first in queue, etc.).  This should not occur.  Someone 
> posted a 2-line patch on -dev list recently to fix this issue.
> 
The patch works for us.  I am assuming this will end up in CVS
soon. 

I was planning to start coding on #1 this week as it is causing
us much heartache.  Please let me know any suggestions that you 
may have as to the best way to go about it.  As I said above
I was planning on either using a function similar to do_monitor in
chan_sip which would monitor the actual channel that the agent
logged in from or putting more code in the check_availability. 

I am also going to take a look at #3 while I have things opened up.

Please let me know if we are on the same page.


Robert Jackson