Summary:	ASTERISK-00491: ExtraChannel in transfer causes crash
Reporter:	matt (matt)	Labels:
Date Opened:	2003-11-06 09:24:20.000-0600	Date Closed:	2004-09-25 02:49:15
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ast_broken.txt
Description:	Attempted goal: Have a 'robot' program Redirect both ends of an already-connected call to a meetme room using the ExtraChannel feature through the management interface. The command used was like this: Action: Redirect Channel: Zap/1-1 ExtraChannel: SIP/3064-7e00 (varies) Exten: 680 Priority: 1 Where 680 is an extension that sends you to a MeetMe room. Result: With the original ordering of the channels (with Zap/1-1 as "Channel" and SIP/xxxx-yyyy as "ExtraChannel") Asterisk crashes If the identical Redirect command is issued manually through the management interface, it works 95% of the time but also crashed this way once. If the robot reverses the order, putting the SIP/xxxx-yyyy channel as "channel" and the Zap channel as ExtraChannel, it works.  But I don't trust it. Asterisk version: It's a few months removed from the CVS (for the sake of configuration control), but I do often apply patches for individual bugs, particularly when they're localized.  I searched the buglist and applied any that seemed related, to no effect.  You will also notice some custom debugging messages in the output.  It seems though that the bridging and masquerading logic is the same as what I have, which *seems* to be where the problem is, but you never know. Attached files: A debug run of one time that crashes and one time that works. Between the two runs, the logic splits right after the first redirect, the bridging logic gives the "nobody there, continuing...." message.  After that it's all downhill. It seems that those two are in different threads, which surprises me a little that it is so consistently reproducible. Apologies if this is something that's been fixed already, but I sure can't find where.  I did quite a bit of digging before writing a bug report.
Comments:	By: Paul Cadach (pcadach) 2003-11-06 10:29:24.000-0600 For me it's looks like a bug near with: DEBUG[278544]: File channel.c, Line 1883 (ast_do_masquerade): Got clone lock on 'SIP/3063-7e00' at 0x816eda0                               (null)(null)"TRAVERSE CI, MI" <2319290233> As you can see, it contains EXTRA output instead if just "Got clone lock on '<channel_name>' at <pointer address>". So, check your sources around pointed line (line 1883 at channel.c) to check is log format specified correctly and is all parameters for format are supplied. By: Mark Spencer (markster) 2003-11-06 15:19:51.000-0600 Masquerade is highly changed in recent weeks, can you please test with recent CVS? By: Brian West (bkw918) 2003-12-14 12:03:01.000-0600 Any update on this? By: matt (matt) 2003-12-15 08:45:55.000-0600 Shortly after that, I did make a new build that was updated to the CVS, and my initial reaction was that it did seem like it had been fixed. I had been thinking of closing it out, but then about a week and a half ago I think it happened again, but I didn't spend a lot of time investigating because it's part of a relatively minor feature we have and I have such larger critical fires to put out.  Besides, I was planning to try to synchronize again with cvs. So on Friday, 12/13/03, I synchronized our Asterisk with CVS once again.  Unfortunately, this time it appears that the video support is broken.  My previous version supported the h.263 video fine, but now it doesn't.  It appears to be an SDP/codec negotiation issue.  I see lots of "format UNKN" and/or "format 0".  This is what I'm going to work on this week, is restoring the video functionality.  If it is indeed code breakage, I'll write another bug for that but I wanted to make sure it wasn't just my mistake first. So I guess the short answer is, it's still unresolved in my mind, it's *probably* fixed, I haven't forgotten about it, but it'll be a little while before I can get back to retesting it. Understand that our Asterisk has a few hundred lines of modifications, so it's non-trivial to resynch with CVS, particularly in the really big files like chan_sip.c By: zoa (zoa) 2003-12-15 10:13:33.000-0600 matt, are the sources for that robot public ? It could be part of a solution to do live monitoring on sip / iax calls. By: Brian West (bkw918) 2004-01-07 00:09:57.000-0600 Matt can you provide more feedback? By: matt (matt) 2004-01-07 08:38:47.000-0600 Funny you should ask this today.  Yesterday was the first time I've had the chance to re-test it in a while, and It seems to be fixed.  The version that crashed was quite a ways back, before the masquerading section was re-written. I'd be OK with closing this out.  Worst case we can re-open or write a new one if it comes back, but I really don't expect that to happen. Thanks.