| Summary: | ASTERISK-00181: Queue grabs call when no agents | ||
| Reporter: | Adam Goryachev (adamg) | Labels: | |
| Date Opened: | 2003-08-27 05:44:25 | Date Closed: | 2011-06-07 14:10:28 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_queue |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | When a queue has agents configured, but none of them are logged in, the call just sits in the queue instead of moving on to the next extension in the extensions.conf ****** ADDITIONAL INFORMATION ****** asterisk*CLI> show agents 1001 (Adam Goryachev) not logged in (musiconhold is 'default') 1002 (Sarah Gwilliam) not logged in (musiconhold is 'default') 1003 (Doris Mitchell) not logged in (musiconhold is 'default') asterisk*CLI> show queue No such command 'show queue' (type 'help' for help) asterisk*CLI> show queues queue has 1 calls (max unlimited) in 'ringall' strategy Members: Agent/1002 has taken no calls yet Callers: 1. Zap/2-1 (wait: 0:14) The call reaches here and just sits on hold, waiting... -- Playing 'local/Thanks_for_calling' -- Executing Queue("Zap/2-1", "queue|t") in new stack -- Started music on hold, class 'default', on Zap/2-1 | ||
| Comments: | By: Adam Goryachev (adamg) 2003-08-27 06:10:08 This could also be a problem for companies with agents who login in the morning, and calls are handled by the queue during the day, then when they logout at closing time, anyone 'left' in the queue gets 'stuck' instead of being moved to the after hours handling.... ie, voicemail or on-call options etc... By: Mark Spencer (markster) 2003-08-27 09:36:04 the Queue application can't see through the channel interface to know if anyone is logged in as an agent (remember, channels can also be members) and therefore has no way of being able to determine that this is in fact the condition. One work around would be to AgentLogin to a voicemail extension. By: tclark (tclark) 2003-08-27 11:48:56 another idea here is to add a queuetimeout to the queue.conf and after a user has been in the q for that timeout period it goes to the queue.conf context & runs the 's' extension logic as opposed to going to the specified extension like the current hit a digit does This also solves the customer service issue if the q is very busy and customers are not handled in the required time they can roll over to supervisors... as well as no agents logged into the q thoughts ?? By: Brian West (bkw918) 2003-08-28 21:34:06 http://bugs.digium.com/bug_view_page.php?bug_id=0000195 By: jrollyson (jrollyson) 2003-09-05 01:43:51 Also, no-agents conditions may happen briefly, ie, due to a poorly executed shift change. Most "no-agents" conditions are policy issues and not implementation issues though, a typical policy is that calls that enter a queue before "closing time" must be answered before agents start logging out, and that calls are prohibited from even entering the queue after closing time. Maybe an option to enforce such a policy could added into * ? Either give a advisory warning that there are (too many) calls in queue when an agent logs out (or tries to), where too many is calls / agents > some_arbitrary_value, or require a supervisor override to log out in those circumstances ? edited on: 09-05-03 01:25 By: Brian West (bkw918) 2003-12-06 12:06:12.000-0600 If you feel this is still an issue please find me on IRC (bkw_) irc.freenode.net #asterisk | ||