|Summary:||ASTERISK-01301: [workaround] Documentation of agentcallback problems|
|Date Opened:||2004-03-26 16:59:02.000-0600||Date Closed:||2011-06-07 14:05:27|
|Description:||Ive heard from some people that agentcallback has some problems, and I tried it myself in a small callcenter and noticed a lot of problems or bugs. I just wanted to document them here-|
****** ADDITIONAL INFORMATION ******
1) If there are several agents available to take a call, and the station that asterisk attempts to deliver the next call has their station set on DND, or for whatever reason their phone is rejecting calls without triggering the timeout to auto logoff the phone, asterisk will continue attempting to deliver calls to that phone over and over until the station accepts the call, or logs off the queue.
Asterisk will not attempt to skip over that agent and deliver the call to the next available agent, no matter what queueing strategy we use (except ringall).
2) If Agent-1 takes a call from a queue, and transfers the call to another station, asterisk will consider Agent1 to be unavailable until the station that took the call hangs up.
3) This isn't really a bug but a feature request... If there are 4 agents available and 4 calls in queue, asterisk will deliver the calls one at a time, and run into the problem described in #1. The bigger a callcenter gets, the less efficient the callcenter becomes as a result of this. I think asterisk should attempt to deliver calls in parallel to all available agents.
|Comments:||By: jesses (jesses) 2004-03-26 17:58:11.000-0600|
Regarding problem number 2, your call is more likely to be dropped than transferred out of queue... Here is the similar result of the last 10 times I tested transferring calls out of queue-
-- Executing Dial("SIP/ruben-5efa", "Sip/support6-2") in new stack
-- Called support6-2
-- SIP/support6-2-762b is ringing
== Spawn extension (employee-extensions, 5216, 1) exited non-zero on 'SIP/ruben-5efa'
== Spawn extension (employee-extensions, 69, 1) exited non-zero on 'Zap/16-1'
-- Hungup 'Zap/16-1'
By: Mark Spencer (markster) 2004-03-29 13:02:40.000-0600
#2: You cannot use the SIP transfer on an agent callback.
By: mike9 (mike9) 2004-03-29 14:00:59.000-0600
#1 addition: Or if ring timeout is reached for the agent line, Asterisk will continue that agent, ignoring other available agents.
By: jesses (jesses) 2004-03-29 14:10:51.000-0600
OK transferring calls out of an agent's phone can only be done with #transfer, not the transfer fuction of the phone itself.
As far as calls not being delivered to phones, I've also noticed that the queue will attempt to deliver calls to agents that arent even logged in-
Example I have a call in queue and the debug logs says-
Mar 29 13:58:34 DEBUG: Trying 'Agent/006' with metric 6
Mar 29 13:58:34 DEBUG: Trying 'Agent/007' with metric 7
Mar 29 13:58:34 DEBUG: Trying 'Agent/010' with metric 8
Mar 29 13:58:34 DEBUG: Trying 'Agent/011' with metric 9
Mar 29 13:58:34 DEBUG: Trying 'Agent/012' with metric 10
Mar 29 13:58:34 DEBUG: Trying 'Agent/013' with metric 11
Mar 29 13:58:34 DEBUG: Trying 'Agent/014' with metric 12
Mar 29 13:58:34 DEBUG: Trying 'Agent/015' with metric 13
Mar 29 13:58:34 DEBUG: Trying 'Agent/018' with metric 14
Mar 29 13:58:34 DEBUG: Trying 'Agent/019' with metric 15
Mar 29 13:58:34 DEBUG: Trying 'Agent/020' with metric 16
Mar 29 13:58:34 DEBUG: Trying 'Agent/022' with metric 17
Mar 29 13:58:34 DEBUG: Trying 'Agent/024' with metric 18
Thats nice but the only agent logged in right now is 007, 014, 024... And 024 was on an agent call at the time.
By: Mark Spencer (markster) 2004-04-04 16:32:47
Yes, but this is not a bug. The queue knows nothing about which agents are available, logged in, etc. All the queue does is try them in a specific order which should rotate each time through whatever strategy is selected.
By: jrollyson (jrollyson) 2004-04-07 22:35:07
You may find that roundrobin or random strategy will work around the queue blocking - leastrecent and fewestcalls will always block if the agent that is supposed to take the call doesn't do so - the workaround if you still need to use leastrecent/fewestcalls is to set this up so that agents are logged out if they don't answer
By: jesses (jesses) 2004-04-08 14:29:05
Lets close this bug since its not really a bug