|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|
|Description:||I'm using Set(GROUP()=CALLS) and GROUP_COUNT(CALLS) to set call limits without any problem, but since i upgraded from 126.96.36.199 to 188.8.131.52 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...