Summary:	ASTERISK-13503: DEVICE_STATE is not working for SIP channels after 1.6.0.5
Reporter:	Cristian Dimache (cristiandimache)	Labels:
Date Opened:	2009-02-03 05:16:52.000-0600	Date Closed:	2009-02-11 15:46:25.000-0600
Priority:	Blocker	Regression?	No
Status:	Closed/Complete	Components:	Functions/func_devstate
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	DEVICE_STATE always returns NOT_INUSE for all SIP Channels for versions after release 1.6.0.5. ****** ADDITIONAL INFORMATION ****** This affects queues, as agents already engaged in a call are rung. Could it have anything to do with the new caching of the state?
Comments:	By: Francesco Romano (francesco_r) 2009-02-03 06:41:32.000-0600 I have opened a similar bug a few days ago, see ASTERISK-13474 By: Mark Michelson (mmichelson) 2009-02-03 10:48:31.000-0600 I'm going to need more details. When I use 1.6.0.5, my SIP devices have the proper device state shown when they are called or when they place an outbound call. What was the last version you used where things worked as you expected? Do your SIP peers have a call-limit defined in sip.conf? When you say "DEVICE_STATE" are you referring specifically to the dialplan function or do you refer to general device state reporting in Asterisk? By: Cristian Dimache (cristiandimache) 2009-02-03 10:59:13.000-0600 In 1.6.0.5 SIP DEVICE_STATE works ok. In trunk it does not, and neither in 1.6.1-rc1. When I say DEVICE_STATE I am referring to the dialplan function, but as this issue affects the queue state then I guess the entire device state reporting for SIP channels is affected. The dialplan function is the one I used to see that the state is not correct after I noticed that an agent receives another call while busy. Note that device state for DAHDI channels works ok, just the SIP channels are affected. By: Mark Michelson (mmichelson) 2009-02-03 11:27:46.000-0600 Thanks for the feedback. I'll give the current trunk and 1.6.1 branches a try here and see if I can reproduce the problem. By: Mark Michelson (mmichelson) 2009-02-03 17:14:19.000-0600 Changing status back to "acknowledged" while I work on this. By: Mark Michelson (mmichelson) 2009-02-05 14:01:27.000-0600 Well, I've done some testing, and things are working correctly for me. I think it would be helpful for you to provide sip.conf and possibly console output showing the incorrect device state being reported. By: Cristian Dimache (cristiandimache) 2009-02-05 15:30:04.000-0600 SIP peers are stored in realtime. Could that change something? I'll give you the feedback in the weekend. By: Mark Michelson (mmichelson) 2009-02-05 15:57:18.000-0600 Ah, that could very well change things. As far as I understand it, because of the fact that the sip_peer object is created and destroyed with each database lookup, we can't actually keep any sort of state information. However, if you have rtcachefriends=yes set in the general section of sip.conf, I understand that is supposed to allow us to keep the peer in memory longer and be able to keep state information properly. Do you have this setting set in sip.conf? By: Cristian Dimache (cristiandimache) 2009-02-05 16:09:18.000-0600 No, I don't have rtcachefriends=yes set in sip.conf. However, I run 1.6.0.5 with realtime sip peers now, without the rtcachefriends setting, and the state of a SIP channel state is properly reported. A "sip show settings" confirms that "Cache Friends: No" I will add this parameter to sip.conf when I'll do the tests. By: Cristian Dimache (cristiandimache) 2009-02-08 12:55:25.000-0600 Okay, tested with SVN174149 and rtcachefriends=yes. The state is reported correctly. I also added rtautoclear=yes so that the changes can be made with realtime, and not require a module reload. I guess that rtcachefriends and rtautoclear should be defaulted to yes, as the realtime peers become less functional than the ones declared in sip.conf By: Cristian Dimache (cristiandimache) 2009-02-09 07:02:13.000-0600 Another interesting point about device_state (I guess this should be in another bug report): a queue will call an agent that is already engaged in a call and waiting for the remote party to pick up, because ringing is not considered as INUSE. By: caspy (caspy) 2009-02-09 07:29:54.000-0600 it seems that i hit the same problem last week, and as result: http://bugs.digium.com/view.php?id=14399 Please look, may be it's your case too. By: Leif Madsen (lmadsen) 2009-02-11 15:46:24.000-0600 It appears this issue is fixed by some recent commits. If you still have some additional issues, please open a new bug report for them. Thanks for the help getting this resolved!