Summary:	ASTERISK-12731: Agent state not updating using both dynamic and direct agents.
Reporter:	Doug (doug)	Labels:
Date Opened:	2008-09-15 03:13:23	Date Closed:	2011-06-07 14:02:56
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) default_queues.conf.info.txt ( 1) queues.conf.info.txt ( 2) state_incorrect.txt ( 3) state_incorrect2.txt ( 4) state_ok.txt
Description:	Hi We have a problem where the agent states do not update correctly and will show "not in use" when the agents are on a call. Originally we used dynamic agents and state_interface patch. Because state_interface is a back port we reverted to direct SIP agents and have the problem here as well. From this it is safe to assume that this problem is not being caused by this patch. The queue app sends second and 3rd calls to the agents even when set to limit 1 call due to the fact that the queue assumes the agent is "not in use" ****** ADDITIONAL INFORMATION ****** When using direct SIP agents we constantly see messages like: [Sep 15 10:07:02] WARNING[637]: app_queue.c:3069 try_calling: The device state of this queue member, SIP/1851, is still 'Not in Use' when it probably should not be! Please check UPGRADE.txt for correct configuration settings. When using dynamic SIP agents we constantly see messages like: [Sep 8 16:55:36] WARNING[13905] app_queue.c: The device state of this queue member, Local/1841@default-agent/n, is still 'Not in Use' when it probably should not be! Please check UPGRADE.txt for correct configuration settings. We are using 1.4.21.2 due to having queue lock issues with 1.4.22
Comments:	By: Leif Madsen (lmadsen) 2008-09-15 12:43:08 You have not provided enough information to move this issue forward. We are going to require steps to reproduce, in addition to relevant portions of your dialplan and queues.conf file. That message typically indicates a configuration issue, so we need to verify if this is really a bug or not. Thanks! By: Doug (doug) 2008-09-16 03:17:30 Hi blitzrange I have added a debug of a working system (state_ok.txt) and a not working one (state_incorrect.txt and state_incorrect2.txt). From my limited understanding I see a an error that comes up: app_queue.c: Device 'SIP/1851' changed to state '8' (On Hold) but we don't care because they're not a member of any queue. from this it seems that the the queue is trying to reference a state but cannot link the agent to a queue. We are using dynamic SIP agents. As a test we added the queue members to the queues.conf as we would using static agents, this corrected the problem and states work well this way. I believe this is because by having the member in the queues.conf asterisk links the agent to the correct queue and updates the state. Please let me know if you need any other info or debugs? Thanks By: Doug (doug) 2008-09-16 04:51:58 Looking at the difference from state_ok.txt and state_incorrect.txt. Again my understanding is that the app_queue passes the members in each queue and then hands off the states to the devstate manager. This seems to happen in the working version: [Sep 16 08:32:25] DEBUG[2393] app_queue.c: Device 'SIP/9304' changed to state '2' (In use) ' [Sep 16 08:32:25] DEBUG[2340] devicestate.c: Changing state for SIP/9304 - state 2 (In use) Where in the not working version we only see: [Sep 15 16:03:41] DEBUG[16317] app_queue.c: Device 'SIP/1893' changed to state '2' (In use) but we don't care because they're not a member of any queue. [Sep 15 16:03:41] DEBUG[16317] app_queue.c: Device 'SIP/1893' changed to state '2' (In use) but we don't care because they're not a member of any queue. By: Joel Vandal (jvandal) 2008-09-16 09:21:08 I found that the problem is related to the state_interface argument used on AddQueueMember where we sometime send 'Local' instead of SIP/IAX channels. Since state_interface patch is not officially supported on 1.4, I think this ticket must be closed. By: Leif Madsen (lmadsen) 2008-09-18 12:20:20 I agree with jvandal, and I've already closed another similar issue for the same reason previously.