Summary:	ASTERISK-12285: Queue members as SIP/XXXX do not update status correctly
Reporter:	evandro (evandro)	Labels:
Date Opened:	2008-06-30 13:07:46	Date Closed:	2011-06-07 14:02:44
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) debug.log ( 1) debug2.log
Description:	I have queue members logged in as SIP/XXXX with Addqueuemember(01|SIP/XXX), and when there are many calls on the queue, the status of this members delay to update, making that calls do not send to the members, unless i remove and add members in the queue again When have a few numbers of calls, the system work normally anyone can help? ****** ADDITIONAL INFORMATION ****** the queues are set as the follow: [01] strategy=leastrecent announce-holdtime=once announce-frequency=98 queue-youarenext=queue-youarenext   joinempty=yes setinterfacevar=yes ringinuse=no eventmemberstatus=yes eventwhencalled=yes wrapuptime=0 autofill=no memberdelay=0 the members are set in sip.conf as the follow: general: limitonpeers=yes [6407] callerid="SAC 7"<6407> nat=no host=dynamic type=friend secret=xxxxxxx permit=0.0.0.0/0.0.0.0 context=atendimento call-limit=1
Comments:	By: Mark Michelson (mmichelson) 2008-06-30 13:51:16 Are members getting stuck in an "in use" state forever or is it just taking a long time for the members to move back into the "not in use" state? By: evandro (evandro) 2008-06-30 14:17:59 it's just taking a long time for the members move back into the "not in use" state. typing "show channels" on the CLI, not presents the member channel, but on typing "queue show" the member status are still "busy", and other times the member channel is up and the member status are "not in use"... By: Sean Bright (seanbright) 2008-10-05 10:42:55 Is this still a problem with the latest release (1.4.22)? By: Thiago Garcia (thiagarcia) 2008-10-08 09:49:25 For me in the asterisk 1.4.22 the status does not change,  and in the answer the console generate the error: [Oct  8 11:53:03] WARNING[13277]: app_queue.c:3014 try_calling: The device state of this queue member, SIP/5590, is still 'Not in Use' when it probably should not be! Please check UPGRADE.txt for correct configuration settings. Asterisk 1.4.22 Zaptel 1.4.12.1 Libpri 1.4.7 Slackware 12.0 Kernel 2.6.24.3 By: BJ Weschke (bweschke) 2008-10-19 21:38:39 thiagarcia - Your issue sounds like a config issue. Please check the following. From UPGRADE.txt * Queues depend on the channel driver reporting the proper state  for each member of the queue. To get proper signalling on  queue members that use the SIP channel driver, you need to  enable a call limit (could be set to a high value so it  is not put into action) and also make sure that both inbound  and outbound calls are accounted for. evandro - please provide an update on your issue when possible and whether it still exists on the latest 1.4.X  Example:       [general]       limitonpeer = yes       [peername]       type=friend       call-limit=10 By: mbrevda (lazytt) 2008-11-10 09:25:45.000-0600 I'm going to hijack this bug and add a 'me too' as it seems that I'm having the same issue: my agents always show "Not In Use" limitonpeers=yes and Call limit=50 type=friend Asterisk = 1.4.22 By: mbrevda (lazytt) 2008-11-11 01:24:43.000-0600 bweschke: Is this what you wanted? By: mbrevda (lazytt) 2008-11-12 09:23:58.000-0600 Just for the record, I recently went from 1.4.18 to 1.4.22. The problem only began when I moved By: Mark Michelson (mmichelson) 2008-11-12 10:14:24.000-0600 Before continuing any further, I would like to double-check that lazytt and thiagarcia have the same problem and not simply the same symptoms. Based on the debug2.log file that lazytt uploaded, I'm thinking that these are in fact separate but similar issues. The reason for this is that it is apparent from the log file that lazytt's queue members are not specified as SIP/XXXX but as Local/XXXX. This makes a substantial difference regarding the reporting of device state of queue members. So, as far as thiagarcia goes, I'm still interested to know if the latest version of Asterisk fixes this issue. There was a change made that is in 1.4.22 which I suspect will fix his issue, but I'd like to have confirmation first. As for lazytt, I've never known Local channels to properly update device state when used as queue members. The reason for this is that once the call is bridged, the SIP channel that ultimately answers takes the local channel's place and the local channel itself hangs up. The way to keep the local channel around once the call is bridged is to specify the local channels in queues.conf with an extra /n on the end, such as Local/230@from-internal/n. The drawback to this approach is that if a queue member should ever transfer a call, that queue member will not be able to take any more calls until the transferred call has completed. By: Thiago Garcia (thiagarcia) 2008-11-12 11:37:41.000-0600 Fixing the configuration solved my issue. Lazytt, Does the call limit directive requires a dash? or can I use the directive pasted above? By: mbrevda (lazytt) 2008-11-12 13:20:56.000-0600 No spaces, use the example from the documentation. I use /n on all the Local channels. In the past (prior to 1.4.22) I've seen the state update just fine (and there is no problem transferring the call). By: Leif Madsen (lmadsen) 2008-11-12 13:30:48.000-0600 putnopvut: would this be solved with the "magic bullet"? :) By: Mark Michelson (mmichelson) 2008-11-12 13:39:48.000-0600 blitzrage: yes, I was thinking that that would solve thiagarcia's particular case. lazytt's is something different though, and is most likely a local-channel specific thing. If the /n doesn't work any more, then I would suspect there's been some sort of change to local channel device state handling, and I should perhaps try to figure out what that change is. By: mbrevda (lazytt) 2008-11-12 13:54:59.000-0600 /me ducks at the mention of the word bullet. What are you guys on about? And who said /n doesn't work? By: Mark Michelson (mmichelson) 2008-11-12 14:03:02.000-0600 Oh, the magic bullet thing is a reference to a specific commit that was made that has been used to solve several people's issues with device state updates. The "magic bullet" is already part of 1.4.22. I may have misunderstood one of your previous messages, lazytt. "I use /n on all the Local channels. In the past (prior to 1.4.22) I've seen the state update just fine (and there is no problem transferring the call)." I took this to mean that you are still using /n on your local channels but that now the device state is not updating properly on them. By: mbrevda (lazytt) 2008-11-12 14:15:24.000-0600 Thats exactly what I mean By: Mark Michelson (mmichelson) 2008-11-14 12:46:48.000-0600 I set up some tests using Asterisk 1.4.22 and the latest svn checkout of the 1.4 branch. In both cases, setting queue members as Local/something@somecontext/n correctly showed the device state when I checked the output of "queue show" at the CLI. I looked at the debug2.log file again, but it's difficult to trace what's happening at a high level since verbose messages are not in that trace. Just looking at the device state changes, I can see that the local channel undergoes some state changes, but they all occur within the same second. If you could get another trace, but this time set both the debug and verbose output levels to at least 3, I may be able to see more detail. Also, I would recommend turning off the DEBUG_CHANNEL_LOCKS flag from menuselect because that's actually cluttering up the output more than it is helping in this case. By: Tilghman Lesher (tilghman) 2008-12-18 14:15:01.000-0600 lazytt:  can you provide an updated debug with putnopvut's suggested changes, please? By: David Brillert (aragon) 2008-12-18 15:37:23.000-0600 putnopvut What revision does the magic bullet refer to in 1.4.22 ? We have been using a backport of custom device state from 1.6 to fix member status issues... We had serious problems trying to backport the shared wrap patch from 1.6 and have abandoned that backport. When we attempted to do shared wrap timers with agents logged to multiple queues we often saw messages like "The device state of this queue member, SIP/5590, is still 'Not in Use' when it probably should not be! Please check UPGRADE.txt for correct configuration settings." By: Mark Michelson (mmichelson) 2008-12-18 15:38:46.000-0600 The magic bullet is revision 133649 of the 1.4 branch. This revision is incorporated into the 1.4.22 release. By: Mark Michelson (mmichelson) 2009-02-10 15:03:13.000-0600 There has been no response on this for quite a while. I'm convinced that known device state issues have been fixed through several commits to the 1.4 branch. Please open a new bug report if there are still issues.