[Home]

Summary:ASTERISK-17515: groupcount or group doesn't "release" channels and group shows channels which doesn't exists
Reporter:Arkadiusz Malka (yarns)Labels:
Date Opened:2011-03-04 07:16:34.000-0600Date Closed:2012-08-08 18:23:07
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_chanspy Functions/func_groupcount
Versions:11 1.8.3 10.7.0 Frequency of
Occurrence
Related
Issues:
is duplicated byASTERISK-20169 Channel groups assigned with GROUP() are not cleared after hanging up
Environment:Attachments:( 0) asterisk-17515-destroy-autochan.diff
( 1) sip.conf
Description:In some cases (we dont know yet when) channels are not released from group.
Below channels in groups and channels available to hangup.

****** ADDITIONAL INFORMATION ******

asterisk2*CLI> group show channels
Channel                    Group                 Category
SIP/192.168.3.114-00000dfb  gsm2                  (default)
SIP/192.168.3.111-00000e4d  gsm2                  (default)
SIP/192.168.3.111-00000e7c  gsm2                  (default)
SIP/192.168.3.114-00000eb2  gsm2                  (default)
SIP/192.168.3.111-00000f0c  gsm2                  (default)
SIP/192.168.3.111-000011e7  gsm2                  (default)
SIP/192.168.3.111-000012e9  gsm2                  (default)
SIP/192.168.3.114-000014b1  gsm2                  (default)
SIP/192.168.3.114-0000176d  gsm2                  (default)
9 active channels

Channels available to hangup:
asterisk2*CLI> hangup request
SIP/10.0.0.3-00002e90
SIP/10.0.0.7-00002f4a
SIP/10.0.0.9-00002dfe
SIP/192.168.3.103-00002e5e
SIP/192.168.3.104-00002f58
SIP/192.168.3.105-00002f52
SIP/192.168.3.106-00002f39
SIP/192.168.3.107-00002f72
SIP/192.168.3.110-00002e0c
SIP/192.168.3.111-00002efb
SIP/192.168.3.112-00002f44
SIP/192.168.3.114-00002e10
SIP/192.168.3.115-00002f1c
SIP/192.168.3.116-00002f64
SIP/192.168.3.119-00002f00
SIP/192.168.3.120-00002f5c
SIP/192.168.3.121-00002efa
SIP/192.168.3.122-00002ee4
SIP/192.168.3.124-00002f0c
SIP/192.168.3.125-00002d33
SIP/192.168.3.126-00002eda
SIP/192.168.3.128-00002f6a
SIP/192.168.3.129-00002f2e
SIP/192.168.3.131-00002ed4
SIP/192.168.3.134-00002ee7
SIP/192.168.3.135-00002c1c
SIP/192.168.3.137-00002d7b
SIP/192.168.3.139-00002f68
SIP/192.168.3.153-00002d9d
SIP/192.168.3.159-00002f2a
SIP/192.168.3.161-00002f6e
SIP/192.168.3.163-00002f3c
SIP/192.168.3.170-00002e7e
SIP/192.168.3.171-00002f4c
SIP/192.168.3.180-00002f6c
SIP/192.168.3.181-00002e2c
SIP/192.168.3.182-00002f34
SIP/192.168.3.183-00002f54
SIP/192.168.3.188-00002ef6
SIP/192.168.3.190-00002ef0
SIP/192.168.3.195-00002f62
SIP/192.168.4.17-0000213e
SIP/192.168.5.1-00002f70
SIP/192.168.5.2-00002f66
SIP/trunk-00002c1d
SIP/trunk-00002d34
SIP/trunk-00002d7c
SIP/trunk-00002d9e
SIP/trunk-00002dff
SIP/trunk-00002e0d
SIP/trunk-00002e11
SIP/trunk-00002e2d
SIP/trunk-00002e5f
SIP/trunk-00002e7f
SIP/trunk-00002e91
SIP/trunk-00002ed5
SIP/trunk-00002edb
SIP/trunk-00002ee5
SIP/trunk-00002ee9
SIP/trunk-00002ef1
SIP/trunk-00002ef7
SIP/trunk-00002efc
SIP/trunk-00002efd
SIP/trunk-00002f01
SIP/trunk-00002f0e
SIP/trunk-00002f1d
SIP/trunk-00002f2b
SIP/trunk-00002f2f
SIP/trunk-00002f35
SIP/trunk-00002f3b
SIP/trunk-00002f3d
SIP/trunk-00002f45
SIP/trunk-00002f4b
SIP/trunk-00002f4d
SIP/trunk-00002f53
SIP/trunk-00002f55
SIP/trunk-00002f59
SIP/trunk-00002f5d
SIP/trunk-00002f63
SIP/trunk-00002f65
SIP/trunk-00002f67
SIP/trunk-00002f69
SIP/trunk-00002f6d
SIP/trunk-00002f6f
SIP/trunk-00002f71
SIP/trunk-00002f73
SIP/trunk-00002f6b
Comments:By: Arkadiusz Malka (yarns) 2011-03-08 07:51:33.000-0600

We done some investigations. Now we can say that Reproducibility can be set to always.

Steps to reproduce:

Make call and set GROUP on it. While connected attach chanspy on existing channel. When spied channel is being closed its stay in group to which was added.
By: Leif Madsen (lmadsen) 2011-03-08 11:45:18.000-0600

Please provide the exact configuration being used (dialplan, sip.conf) so that this can be reproduced by someone. Thanks.
By: Arkadiusz Malka (yarns) 2011-03-08 12:00:45.000-0600

context testowy {
4=>{
Set(GROUP()=testgroup);
Dial(SIP/XXXXXXXXX5@nsti,,rR);
}
5=>{
ChanSpy(SIP/test,qe(SIP/test));
}
};

Step to reproduce:
Register with test, then dial 4. When connected register with 2test and dial 5. Hangup with test while spying. Command GROUP SHOW CHANNELS will show channel which doesnt exist anymore.
By: Arkadiusz Malka (yarns) 2011-03-22 02:14:39

Do you need any additional information?
By: Marcus Spurkel (mspurkel) 2011-05-25 17:27:55

I have the same problem on 1.8.3.2 and ChanSpy is the common element for us as well.  Once the channel group has been "orphaned", there seems to be no way to clear it out of memory other than to restart Asterisk.
By: Benoit P (b_plessis) 2011-11-16 02:14:29.218-0600

Hi,
Just to add intel, this still happens with 1.8.7.1, and i found that not only there were groups for unexistants channels, but also that the ChanSpy channels were left behind after everyone had hangup.
By: laszlovl (lvl) 2012-02-13 10:28:36.546-0600

This issue still exists in 1.8.9.0.

"group show channels" shows a channel that has been hung up hours ago; the channel doesn't appear in the 'core show channels' list, and indeed ChanSpy has been executed on this channel.

Severity should be bumped to 'Major' IMO, as this can block all incoming/outgoing calls if you're depending on groups to limit your channels - and once a channel is 'hung' like this, it can't be fixed in any way besides restarting asterisk.

I can provide a full debug log if that helps, but as far as I can see the debug output doesn't contain any information on the GROUP logic?
By: laszlovl (lvl) 2012-02-18 10:45:01.706-0600

I did some more testing, and I couldn't reproduce the issue with the dialplan Arkadiusz Malka provided. Also, Arkadiusz noted that the issue occurs when you hang up the call while spying - but in my setup the issue only occurs when the callspy channel hangs up first.

I created a new issue @ ASTERISK-19386
By: laszlovl (lvl) 2012-02-22 15:54:35.067-0600

For everybody still suffering from this issue: you might want to grab a version that includes r352957 (or patch your asterisk manually) and try again, it seems to have fixed the problem for me!
By: Richard Mudgett (rmudgett) 2012-07-26 17:10:17.310-0500

There may still be a channel reference leak somewhere because of the ASTERISK-20169 report.
By: Aleksandr Gordeev (axonaro) 2012-07-27 00:14:44.865-0500

The patch is available ?
By: Aleksandr Gordeev (axonaro) 2012-07-31 07:02:25.404-0500

I use :
ChanSpy(${check_channel},qoE)

if use
ChanSpy(${check_channel},qoS)
trouble does not occur
By: Aleksandr Gordeev (axonaro) 2012-07-31 07:13:36.426-0500

Info about application 'ChanSpy'
E: Exit when the spied-on channel hangs up.
S: Stop when no more channels are left to spy on.

What difference ?
By: Arkadiusz Malka (yarns) 2012-07-31 13:04:44.304-0500

With 'S' when spied channels hangs up chanspy switch to another one, with 'E' should exit without switching.

BTW problem still exist in v.10 ?
By: Aleksandr Gordeev (axonaro) 2012-08-01 00:04:40.728-0500

Yes, I tested with asterisk 10.7.0
By: Michael L. Young (elguero) 2012-08-01 13:02:57.054-0500

Give this patch a try, [^asterisk-17515-destroy-autochan.diff]. From my testing, I was able to reproduce the problem and this should resolve it.

It would appear that the channel is not being unreferenced upon exiting.
By: Aleksandr Gordeev (axonaro) 2012-08-02 00:19:34.304-0500

With patch is no problem. Thanks.
By: Aleksandr Gordeev (axonaro) 2012-08-06 02:57:44.994-0500

I have some trouble and I do not know whether it is connected with this topics, but see this : http://forums.asterisk.org/viewtopic.php?f=1&t=83716&p=176695