[Home]

Summary:ASTERISK-06260: Meetme does not release channels when using 3rd party driver(CHAN_SCCP2)
Reporter:zamsler (zamsler)Labels:
Date Opened:2006-02-06 07:41:53.000-0600Date Closed:2006-02-14 12:48:19.000-0600
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Applications/app_meetme
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I am using chan_sccp2. When I leave a meetme the channels are not torn down correctly. i have been working with the developer of chan_sccp2 on this and can find no way to prevent this. Please look at the code snips and debug below and let me know what needs to happen to make this work.

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

Feb  5 10:32:08 DEBUG[21185] channel.c: Scheduling timer at 160 sample intervals
Feb  5 10:32:11 DEBUG[21185] channel.c: Scheduling timer at 0 sample intervals
Feb  5 10:32:11 DEBUG[21185] channel.c: Scheduling timer at 0 sample intervals
Feb  5 10:32:11 DEBUG[21185] app_meetme.c: Placed channel SCCP/361-00000001 in ZAP conf 1023
Feb  5 10:32:11 DEBUG[21185] channel.c: Scheduling timer at 160 sample intervals
Feb  5 10:32:11 DEBUG[21185] channel.c: Generator got voice, switching to phase locked mode
Feb  5 10:32:11 DEBUG[21185] channel.c: Scheduling timer at 0 sample intervals

---- Hungup the phone
Feb  5 10:32:26 DEBUG[21185] app_meetme.c: Ooh, something swapped out under us, starting over
Feb  5 10:32:26 DEBUG[21185] app_meetme.c: Placed channel SCCP/361-00000001 in ZAP conf 1023
Comments:By: Jason Parker (jparker) 2006-02-06 11:21:54.000-0600

Zac, please be VERY careful when putting code into a bug.  The chan_sccp2 code isn't disclaimed, so there could be legal issues with other developers seeing this code - *cough*cough*.  It makes it quite troublesome, but...what're you gonna do?


Anyhow..  This also happens with h323 (per Math on IRC), and I believe somebody mentioned it also happens on zap channels.  The problem here is two-fold.

1) This issue can/probably does exist on IAX2/SIP as well, however, those technologies can easily drop a channel and forget about it.  This isn't the case with sccp.  As far as I understand it, the sccp channel gets completely locked until everything releases it.
2) This is a third-party channel driver.  These aren't supported (for good reason), and not many of the asterisk developers are able to test this issue as it relates to sccp.  If, however, somebody were able to show that this also happens with chan_skinny (in the asterisk tree), this might be easier to work through.


When Zac says "The channels aren't torn down correctly.", he means the pseudo/timing channel.  As long as the pseudo channel is there, the meetme conf will not go away.

Note: This also happens to me (I could only really reproduce this at work...same version of * - weird, eh?)
By: zamsler (zamsler) 2006-02-06 11:31:42.000-0600

I am sorry.. Please remove the code snip from this bug..
By: Jason Parker (jparker) 2006-02-06 11:34:51.000-0600

No real harm done...but in the future, please do be careful.
By: Michiel van Baak (mvanbaak) 2006-02-07 10:09:17.000-0600

This issue also happens on pure ZAP meetme conferences.
1 of our customers is running asterisk 1.2.1 with a sangoma 101 isdn30 E1.
When the last person leaves the meetme the whole machine dissapears from the network, and after a few minutes re-appears and load avg shows the box has been really busy.
They can reproduce this by dialing in on the E1 line with some ppl and join a meetme. No other technoligies involved.
And indeed they also have it with chan_sccp.
By: Serge Vecher (serge-v) 2006-02-07 10:31:02.000-0600

mvanbaak: can you upgrade your customer to v.1.2.4? There has been fixes to MeetMe since 1.2.1
By: Michiel van Baak (mvanbaak) 2006-02-07 10:51:55.000-0600

vechers: mail with your reply is sent to them.
They now maintain the box themselves. I just gave them training how it all works :) Thnx.
By: Mark Spencer (markster) 2006-02-11 10:55:01.000-0600

This appears to be a hardware problem as described in the bug report.  Please pursue through your hardware vendor.
By: Jason Parker (jparker) 2006-02-11 17:48:34.000-0600

Mark, I believe you may have misread the description on this.

The only hardware involved (in my specific case) is a Cisco phone with sccp firmware, and Zap hardware.  I do believe this also happens with ztdummy (can somebody please confirm?).  I believe the problem lies somewhere with meetme or the pseudo zap channel.

I think I understand what Mark means now.  Can somebody confirm that this happens with Digium hardware, or ztdummy?  If not, I'll close this bug out, and agree with Mark's findings.
By: Michiel van Baak (mvanbaak) 2006-02-11 17:54:56.000-0600

confirmed on 1.2.4 with zap channels only. using ztdummy as timer source, sangoma 101 as interface. 3 calls incoming on the sangoma (E1), last one leaves, box goes dead for several minutes and comes back with load avg 100.
By: Jason Parker (jparker) 2006-02-11 17:59:40.000-0600

Sangoma cards use chan_zap, right?  If so, that would provide the timing, and not ztdummy.

Unfortunately, that isn't good enough to keep this open (unless you can prove it happens without the sangoma card in the machine).  Anybody else?
By: Michiel van Baak (mvanbaak) 2006-02-11 18:05:13.000-0600

yeah, sangoma cards using the wanpipe driver are seen as chan_zap cards.
Sorry I cannot help, but this is all I can do now.
I'll recompile my setup tomorrow with only iax2 peers and ztdummy as timer.
Will post results after that (if my iax2 provider activated my new keys)
By: Mark Spencer (markster) 2006-02-14 12:48:17.000-0600

If the problem occurs with a Digium card, it should still be handled through Digium tech support *not* through the bug tracker since it is hardware related.  If it only occurs with sangoma then take it to sangoma.