Summary:	ASTERISK-23724: Agent stay "In use" after logoff
Reporter:	Javier Furio (javier.furio)	Labels:
Date Opened:	2014-05-07 06:57:22	Date Closed:	2014-05-28 09:36:43
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:	11.8.1	Frequency of Occurrence	Constant
Related Issues:	duplicates ASTERISK-18411 Queue members with hints for state_interface get stuck in "In Use" state.
Environment:	Standard FreePBX distro 11.8, FreePBX 1.8 & fresh Centos plus asterisk	Attachments:	( 0) Agent-queue-problem.txt
Description:	When an agent logoff from a queue (standar *12), the playback says "Agent Logoff", and can't get any new call, but always stay as "In Use" instead of "Unavailable", so . I've found several previous issues, but all of them were resolved before 2013, and those distributions are new. Regards
Comments:	By: Rusty Newton (rnewton) 2014-05-07 16:05:37.600-0500 Hi! It is apparent you haven't read the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] please do so before using the issue tracker further. After reading the guidelines, please remove your large debug traces from the Description field and attach any relevant debug as .txt files. To investigate the issue, we need to be able to reproduce it. app_queue issues can be very tricky to recreate. You'll need to figure out how to provide * a simple configuration that we can run on a fresh Asterisk install to reproduce the problem * instructional steps on how to reproduce the issue with that Asterisk configuration. * specifically a configuration that does not require FreePBX , as we are not troubleshooting that application/layer on this issue tracker. You are using the FreePBX GUI, which does a lot of neat stuff for you. Have you already worked with the FreePBX community or team on their [forums|http://www.freepbx.org/forums] or tracker to make sure this is an Asterisk issue and not an issue with your configuration through FreePBX? By: Javier Furio (javier.furio) 2014-05-08 01:09:01.869-0500 Here are the results By: Javier Furio (javier.furio) 2014-05-08 01:53:28.388-0500 OK. I have tried to attach the debug data to a file, but did not see any button "Attach file", so while I was asking my colleagues, I attached the description data to be able to access the information. apology for the inconvenience I am in contact with support FreePBX, and they were who told me that there was a bug in that version that had not been resolved in later versions of Asterisk, so we ought to open a case directly with you. I'm using two fresh Asterisk installation, one with FreePBX and one with AsteriskNow & FreePBX and both has the same problem, even when AsteriskNow was without FreePBX. Regards By: Rusty Newton (rnewton) 2014-05-08 17:50:33.600-0500 Did they point out the specific bug? It would likely be ASTERISK-16115, ASTERISK-18411 from a quick search. If they or you are sure it is one of those issues then we need to know which one so that we can close your report out as a duplicate of that issue. If you believe the issue is not one of those two (or another) issue, then we still need the requested reproduction and debug information so that we can investigate if necessary. By: Javier Furio (javier.furio) 2014-05-09 02:54:15.571-0500 Hi Rusty ASTERISK-16115 and ASTERISK-18411 are similar situations, but they're not the same issue. I'ts more like ASTERISK-18411, but in our case, the statics agent stay "In use" or "Not in use" when the static agent logout, instead of "unavailable". (we're using hot-desktop) If poweroff the device where that agent is loged in, the agent stay "In Use" or "Not in use", but never "unavailable" so our time-consuming statistics are wrong, becasuse the agent is gone. which files do you need for further investigation? Regards By: Rusty Newton (rnewton) 2014-05-09 18:47:34.183-0500 {quote} which files do you need for further investigation? {quote} Any configuration that you determine is necessary to reproduce the issue. That is, we need you to provide a set of configuration files and a set of steps (using that configuration) with which to reproduce the issue. Again, the configuration needs to be as simplified as possible so that the bug is easily and quickly demonstrated. We should be able to run it without installation of FreePBX since we are just looking at Asterisk here. By: Javier Furio (javier.furio) 2014-05-11 01:53:43.592-0500 It's very easy. We'd reproduce it several times in a very reduced configuration. *Standar FreePBX installation in Device&User. AsteriskNow+FreePbx or FreePBX *Create two devices (1611 and 1612). Create as AdHoc. *Add two users (agents) (1689 and 1690) *Create a Queue (1640) *Add those agents(1689 and 1690) to that queue (1640) as satic agents *Login (*11) any agent (1689 or 1690) in any extension (1611 or 1612) *Logout (*12) that agent or use Toggle queue (*45) *Exec asterisk -rx "queue show". The Agent stay in "Not In Use" if you used logout (*12) or "In use" (*45) instead of "Unavailable" Regards By: Rusty Newton (rnewton) 2014-05-28 09:29:54.710-0500 You have provided a list of steps to reproduce the issue via FreePBX configuration. That would be helpful for the FreePBX team so that they could reproduce and identify what the underlying triggers for the issue are (within Asterisk) and then file a bug report with us if they find one. Another way to think of this is of Asterisk as a vehicle engine, and FreePBX as a vehicle. You have reported to the engine manufacturer a list of steps you take to observe an issue in the vehicle, when you really need to be reporting that to the vehicle manufacturer.  If you say to the engine manufacturer that the vehicle manufacturer found a problem with the engine, then they'll expect some data from the vehicle manufacturer detailing where the problem is. The steps you have provided are not useful to me, as I don't know what each of those FreePBX GUI configuration steps does within Asterisk configuration. I'm not satisfied this issue is a different issue than ASTERISK-16115 or ASTERISK-18411, so I'm going to close this out until we receive a bug report detailing the Asterisk configuration needed to demonstrate an issue different than the two previously mentioned issues.