Summary:	ASTERISK-16497: [regression] chan_local is hanging up the call upon first channel answer when calling from asterisk manager (inconsistent)
Reporter:	Rami (rami)	Labels:
Date Opened:	2010-08-03 09:50:11	Date Closed:	2014-03-05 07:11:52.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_local
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When originating a call from asterisk manager and using channel as local, when the first channel answers, the call should proceed to the exten, but about 50% of the times the call hangs up. Example for command: //----------------------- Action: originate Channel: Local/330@from-internal Exten: 501 Context: from-internal Priority: 1 //------------------------ 330 can be either SIP or TRUNK or anything else, once it will answer the call has 50% chance to get hanged up. The last asterisk version I check that did not have this problem is: 1.4.23.1, from there on up to 1.4.33 the problem occurs. I managed to fix the problem by disabled masquerade on chan_local channels, I did that by removing the line: ast_channel_masquerade(p->owner, p->chan->_bridge); on chan_local.c but this solution is obviously very wrong. by looking at the CLI it appears that that masquerade timing is cause the problem, there is 3 situations: 1. it happens on the first row of the dial plane when the first channel is answered - call get hanged up. 2. it happens on the middle of the dial plane when the first channel is answered - it removes the call callerid and some other variables, but the call is working 3. it happens in the end and everything is working fine (like in version 1.4.23.1 and below) please find a solution for this bug, this is very frustrating as most asterisk dialers are using chan_local and they can't work any more.
Comments:	By: Leif Madsen (lmadsen) 2010-08-05 15:33:58 It may be possible to step forward on versions to see which version first introduced this behaviour, then to review the ChangeLog to determine which revision may have caused this. If you can narrow it down to the revision that caused this issue, then it can be resolved much faster. By: Leif Madsen (lmadsen) 2010-08-06 13:37:26 Also can you provide some sample dialplan to reproduce this? That would certainly help in testing this issue and getting it resolved. By: Matt Jordan (mjordan) 2014-03-05 07:11:45.172-0600 I haven't been able to reproduce this problem, and the masquerade super-test makes chains of hundreds of Local channels without the masquerade process failing. I'm suspending this issue as Can't Reproduce in 1.8+.