Summary:	ASTERISK-15770: When Answer is used for chan_local in Originate, the originate go crazy
Reporter:	Ido Kanner (ik_5)	Labels:
Date Opened:	2010-03-08 12:25:37.000-0600	Date Closed:	2011-06-07 14:01:02
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_local
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_console.txt
Description:	When I do the following Originate: action: Originate priority: 1 context: btest exten: s channel: Local/<test>@atest/n timeout: 60000 On a dialplan: [atest] exten => _X.,1,NoOp(Test Case A) exten => _X.,n,Answer() exten => _X.,n,DumpChan() exten => _X.,n,Dial(DAHDI/g1/<number>,120,L(100000:5000:1000)) [btest] exten => s,1,NoOp(Test case A-b) exten => s,n,Answer() exten => s,n,Dial(DAHDI/g1/<number>,120,rmg) If I do not remove the Answer function from atest, then Originate act crazy in an unknown way to predict, it will not execute the dialplan properly. ****** ADDITIONAL INFORMATION ****** This problem happens on Asterisk 1.4.30rc3 down to  1.4.21. I have not tested it on older versions of 1.4.
Comments:	By: Ido Kanner (ik_5) 2010-03-08 12:36:48.000-0600 I'm attaching an example for problem (On this example it have dialed, but sometimes it hangs up the first number). By: Leif Madsen (lmadsen) 2010-03-10 10:05:58.000-0600 This is expected behavior. Please check the localchannel.txt document file in the 1.4 branch which explains this exact type of scenario. Hint: You have the L() option in the wrong spot. Other than that, I don't see anything wrong, or "going crazy". By: Ido Kanner (ik_5) 2010-03-10 10:20:31.000-0600 How come my L is located on the wrong spot ? Dial(type/identifier, timeout, options, URL)   My first position is the DAHDI/g1/number@.... My Second place is timeout and my last place is option So how is it on the wrong place ? The thing is, that Every time I execute the above code when "answer" is in use, Dial is not acted as blocking. Further more, the output I gave, executed btest Dial before executing atest Dial. How is that proper reaction ? Some of the execution I made using Answer, makes the request drop with congestion/busy without actually running Dial. So unless this unexpected reaction of the dialplan a feature, I will call it "going crazy" and unexpected. By: Leif Madsen (lmadsen) 2010-03-10 11:00:04.000-0600 As mentioned, please read the localchannels.txt file I pointed you to. I just finished writing new documentation to explain this very behaviour. You have the L() option inside the Local channel, when you probably mean to have it outside of the Local channel. Anyways, the documentation explains why it is likely in the wrong spot. I don't see anything wrong in the file you've provided. Perhaps you can provide a file with some comments and information about the behaviour you're seeing, and better explain "going crazy" so I can better understand what that means. By: Ido Kanner (ik_5) 2010-03-10 11:00:22.000-0600 Further more, without any options at all: Dial(DAHDI/g1/<number>) The same reaction as with options. By: Leif Madsen (lmadsen) 2010-03-10 11:16:03.000-0600 I don't understand why this is New again, I'm still waiting for some output and explanation for "go crazy" By: Paul Belanger (pabelanger) 2010-04-28 15:55:59 Ping!  What is going on here? I get the feeling this is not an issue. By: Ido Kanner (ik_5) 2010-04-28 15:59:12 It exists on all versions of 1.4 that I'm using, and I needed to drop the Answer CMD in order to make it function like before. By: David Woolley (davidw) 2010-04-28 16:42:12 As far as I can tell, Asterisk is behaving correctly in the face of an unreasonable dial plan. When the Answer is issued on the local channel, the A side of the originate will appear up, so Asterisk will start dialing the B side.  Both B and A sides will proceed in parallel, until one of them hangups up. On the A side, it is the implied dial on the Local channel that is blocking.  The Answer removes that block. By: Ido Kanner (ik_5) 2010-04-28 16:52:47 But this behavior is not the same as old Asterisk versions, or as I understand from newer (have not tested it myself) 1.6x versions. Old Asterisk 1.2 and older 1.4 allowed the dial to remain blocking even with Answer on a local channel. The original goal of the Answer cmd is to make the Originate terminate successfully as fast as it can. Unless I'm missing something, the dial plan execution should not be jumping to other context unless they have a direct goto request, or it was finishing executing the first context. And on my test case, that are not the cases at all. So I do not think that it's proper behavior at all. By: David Woolley (davidw) 2010-04-28 17:46:25 There are no context jumps in your attached trace. The context is always atext and the priorities progress as follows:    ;2       ;1     1     2     3              1              2     4              3 By: Paul Belanger (pabelanger) 2010-04-28 19:49:44 This looks to be a support related issue (see below).  Feel free to find a marshal on #asterisk-bugs if you have questions. --- Thanks for your comments. This does not appear to be a bug report and we are closing it. We appreciate the difficulties you are facing, but it would make more sense to raise your question in the support tracker, http://www.asterisk.org/support