Summary:	ASTERISK-17994: Regression - GROUP_COUNT value not decremented on channel hangup
Reporter:	daren ferreira (daren)	Labels:
Date Opened:	2011-06-10 05:44:57	Date Closed:	2011-06-13 13:10:39
Priority:	Major	Regression?
Status:	Closed/Complete	Components:
Versions:	1.8.4	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I'm using Set(GROUP()=CALLS) and GROUP_COUNT(CALLS) to set call limits without any problem, but since i upgraded from 1.6.2.16 to 1.8.4.2 it seems that the GROUP CALLS variable value is not always decremented, so with one channel up i get a value of 6 without channels up i get a value of 5 I still haven't found how to reproduce this issue.
Comments:	By: Leif Madsen (lmadsen) 2011-06-13 13:10:39.307-0500 When you're able to clearly reproduce the issue please reopen this issue. I have no been able to reproduce the issue locally. By: daren ferreira (daren) 2011-07-01 05:32:57.131-0500 It is difficult to determine the origin of the problem, it always occurs but i don't know where. Do you have any idea on how to discover the origin? I use AGI script with dozen of functions for multiple possible scenarios... so it's like a needle in a haystack... By: daren ferreira (daren) 2011-07-11 02:25:28.613-0500 The problem occurs on a totally different setup. On the first setup, i used in-file SIP accounts, dozen of functions through FastAGI , functions that might create the problem (queues, IVR etc) But on another setup, i use Realtime SIP accounts, and also FastAGI, only for simple functions (callerid cleaning, call forward/busy/unavailable) On both setups the only common point i see is FastAGI. I didn't got such issue on 1.6.X releases of asterisk... Unfortunately i have no idea on where to begin to identify precisely the origin of this issue... As you can guess it begins to be problematic because GROUP_COUNT is used, as advised, for a replacement of the call-limit feature... a replacement that don't work anymore... Thank you for any advice you can give me...