Summary:	ASTERISK-15337: [patch] [regression] Custom devsate set to INUSE but shows as UNAVAILABLE when accessing through the dialplan
Reporter:	millsu2 (millsu2)	Labels:
Date Opened:	2009-12-18 16:02:59.000-0600	Date Closed:	2011-06-07 14:08:19
Priority:	Minor	Regression?	Yes
Status:	Closed/Complete	Components:	Functions/func_devstate
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dialplan.ael
Description:	I set a custom device state to "INUSE" using Set(DEVICE_STATE(Custom:device)=INUSE). Through "database show" or  "devstate list" the state is listed as "INUSE" as it should, but when getting the state in the dialplan using ${DEVICE_STATE(Custom:device)} it returns "UNAVAILABLE". If I do "devstate change Custom:device INUSE" after this happens then it works properly.
Comments:	By: millsu2 (millsu2) 2009-12-18 17:00:42.000-0600 This issue did not exist in 1.6.1.1. It showed up after upgrading to 1.6.1.11 and no changes were made to the dialplan. By: millsu2 (millsu2) 2009-12-22 15:12:57.000-0600 I'm still unable to duplicate the problem manually, but now when it does happen ${DEVICE_STATE(Custom:device)} is returning NOT_INUSE when it should be INUSE. If I remember right core show hints also shows the incorrect value. I'll have to double check on that. By: millsu2 (millsu2) 2009-12-22 15:49:58.000-0600 I updated to 1.6.1.12 and the problem still exists. I can't find anything in the debug that shows a change in the custom devstate between the time I set it and the time I check it (about 8 hours). I'd post the whole log but it's 1.1GB. By: millsu2 (millsu2) 2009-12-23 16:08:26.000-0600 I was able to check the core show hints and it does show the correct value. It appears that the times it returns the incorrect value is when using ${DEVICE_STATE(Custom:device)} or the device subscribes to the hint. By: David Vossel (dvossel) 2010-01-08 15:37:41.000-0600 I've spent about an hour with this using 1.6.1.11 and I can't reproduce it.  Is this something you can reproduce consistently?  If so can you outline exactly what steps I can do to achieve this? By: millsu2 (millsu2) 2010-01-13 00:31:08.000-0600 Unfortunately I can't consistently reproduce it. It probably only happens around 5% of the time. All I'm doing is setting the custom device state, then 4-8 hours later I'm checking it and occasionally it's wrong. Is there something I can look for in the debug info that may help? By: David Vossel (dvossel) 2010-01-25 12:32:45.000-0600 Can you provide an example dialplan showing how you are using the custom device state? By: millsu2 (millsu2) 2010-01-26 16:21:57.000-0600 The dial plan code should now be attached to this issue. I use the custom device state to tell whether an agent is logged in or not and for the Busy Lamp Field on the agents phone. I do see in the logs that the state is set correctly when the agent logs in, then sometime during the day it changes so when the agent tries to log out my dial plan thinks they are trying to log in because of the incorrect device state. The BLF is also incorrect at that time. By: David Vossel (dvossel) 2010-01-27 10:59:41.000-0600 We had a issue that was fixed a few weeks ago that involved hints being lost during reloading. Are any sort of config reloads occurring during the day? By: millsu2 (millsu2) 2010-01-27 13:36:48.000-0600 That could possibly be it. Reloads aren't done very often, but the frequency seems to match up with how often the problem is happening. When we do reload, it's rarely anything other than sip or ael reload. I will watch to see if it looks like that is causing this. Interestingly, though, when it does happen it only happens to one out of 30 or so custom states. By: David Vossel (dvossel) 2010-01-27 14:11:19.000-0600 I've been made aware of another change that could possibly have resolved this as well that is not yet in a release.  The patch for it was posted to this issue. https://issues.asterisk.org/view.php?id=16607 If you are able to, it may be worth trying the latest rev in svn to see if this problem still exists. By: David Vossel (dvossel) 2010-02-05 10:02:30.000-0600 We've had feedback on other issues related to this reporting that the patch on issue ASTERISK-15431 has resolved the issue.   A new release with that patch is being released soon.  If you continue to have issues after updating or using the patch feel free to re-open this issue.