Summary:	ASTERISK-15542: [regression] Local channels broken for Originate and .callfiles : Call failed to go through, reason (3) Remote end Ringing
Reporter:	Matt King, M.A. Oxon. (kebl0155)	Labels:
Date Opened:	2010-01-29 05:47:30.000-0600	Date Closed:	2010-03-03 10:18:37.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Core/Channels
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Apologies if this is a dupe - I did look but couldn't find any similar. This is an error in 1.6.2.1 (which isn't an option in the Product Version pulldown - I'd be grateful if a bug marshall could please amend). In all versions of Asterisk up to and including 1.6.2.0, it is possible to launch a call to two different extensions using the Manager Originate action, or by placing a file to /var/spool/asterisk/outgoing Asterisk will ring the first extension, and when this is answered, launch the second extension. In 1.6.2.1, the second extension is never rung, so this is broken. These mechanisms are the basis of all automatic Dialler applications, so Asterisk will be unsuitable for any Dialler use until this bug is fixed. ****** ADDITIONAL INFORMATION ****** Steps to reproduce. In extensions.conf: [localchanneltest] exten => firstleg,1,NoOp(First Leg) exten => firstleg,n,Wait(5) exten => firstleg,n,Answer exten => firstleg,n,Wait(10) exten => firstleg,n,Hangup exten => secondleg,1,NoOp(Second Leg) exten => secondleg,n,Wait(5) exten => secondleg,n,Answer exten => secondleg,n,Wait(10) exten => secondleg,n,Hangup Then either place the following file in /var/spool/asterisk/outgoing: Channel: Local/firstleg@localchanneltest CallerID: Me <12345> MaxRetries: 0 RetryTime: 30 WaitTime: 10 Context: localchanneltest Extension: secondleg Priority: 1 Or send the following equivalent Manager action: Action: Originate Channel: Local/firstleg@localchanneltest Context: localchanneltest Exten: secondleg Priority: 1 In Asterisk 1.6.2.0 we get the correct output:     -- Attempting call on Local/firstleg@localchanneltest for secondleg@localchanneltest:1 (Retry 1)    -- Executing [firstleg@localchanneltest:1] NoOp("Local/firstleg@localchanneltest-d75b;2", "First Leg") in new stack    -- Executing [firstleg@localchanneltest:2] Wait("Local/firstleg@localchanneltest-d75b;2", "5") in new stack    -- Executing [firstleg@localchanneltest:3] Answer("Local/firstleg@localchanneltest-d75b;2", "") in new stack       > Channel Local/firstleg@localchanneltest-d75b;1 was answered.    -- Executing [secondleg@localchanneltest:1] NoOp("Local/firstleg@localchanneltest-d75b;1", "Second Leg") in new stack    -- Executing [secondleg@localchanneltest:2] Wait("Local/firstleg@localchanneltest-d75b;1", "5") in new stack    -- Executing [firstleg@localchanneltest:4] Wait("Local/firstleg@localchanneltest-d75b;2", "10") in new stack    -- Executing [secondleg@localchanneltest:3] Answer("Local/firstleg@localchanneltest-d75b;1", "") in new stack    -- Executing [secondleg@localchanneltest:4] Wait("Local/firstleg@localchanneltest-d75b;1", "10") in new stack    -- Executing [firstleg@localchanneltest:5] Hangup("Local/firstleg@localchanneltest-d75b;2", "") in new stack  == Spawn extension (localchanneltest, firstleg, 5) exited non-zero on 'Local/firstleg@localchanneltest-d75b;2'  == Spawn extension (localchanneltest, secondleg, 4) exited non-zero on 'Local/firstleg@localchanneltest-d75b;1' [Jan 29 11:17:11] NOTICE[3684]: pbx_spool.c:349 attempt_thread: Call completed to Local/firstleg@localchanneltest In the above the second leg starts as soon as the first leg is answered. The below output is from 1.6.2.1    -- Attempting call on Local/firstleg@localchanneltest for secondleg@localchanneltest:1 (Retry 1)    -- Executing [firstleg@localchanneltest:1] NoOp("Local/firstleg@localchanneltest-544d;2", "First Leg") in new stack    -- Executing [firstleg@localchanneltest:2] Wait("Local/firstleg@localchanneltest-544d;2", "5") in new stack    -- Executing [firstleg@localchanneltest:3] Answer("Local/firstleg@localchanneltest-544d;2", "") in new stack    -- Executing [firstleg@localchanneltest:4] Wait("Local/firstleg@localchanneltest-544d;2", "10") in new stack [Jan 29 11:14:28] NOTICE[2897]: pbx_spool.c:339 attempt_thread: Call failed to go through, reason (3) Remote end Ringing  == Spawn extension (localchanneltest, firstleg, 4) exited non-zero on 'Local/firstleg@localchanneltest-544d;2' Here the second leg is not activated.   The NOTICE only appears when the /var/spool/asterisk/outgoing method is used.  It looks like the Answer is not being picked up by the other end of the local channel.
Comments:	By: Leif Madsen (lmadsen) 2010-01-29 12:33:06.000-0600 When filing issues, please don't use the Product Version pulldown -- it is not used; you want to use the Asterisk Version field (yes, I know this is confusing, and and I want the Product Version field removed, but has not been done yet). By: Matt King, M.A. Oxon. (kebl0155) 2010-01-29 12:35:58.000-0600 Oops sorry - didn't know! By: Tilghman Lesher (tilghman) 2010-02-01 16:39:11.000-0600 I believe this is already fixed.  Please try SVN 1.6.2. By: Matt King, M.A. Oxon. (kebl0155) 2010-02-02 07:11:30.000-0600 Yes it's working with SVN 1.6.2 :-) By: Leif Madsen (lmadsen) 2010-02-02 08:56:20.000-0600 Thanks for the feedback! Closing this issue as fixed in the next version to be released. By: Matt King, M.A. Oxon. (kebl0155) 2010-02-04 17:40:53.000-0600 Really sorry to re-open this if I'm doing it in error but... It's not actually fixed in 1.6.2.2 - I just checked. By: Tilghman Lesher (tilghman) 2010-02-04 18:26:11.000-0600 That's because 1.6.2.2 is a security release.  It contained ONLY the security fix over and above what was in 1.6.2.1.  The next full release of 1.6.2 (could be 1.6.2.3 or might not be, if we have to do another security release) will have the fix. By: Matt King, M.A. Oxon. (kebl0155) 2010-03-03 10:14:06.000-0600 This is still broken in 1.6.2.5.   -- Attempting call on Local/firstleg@localchanneltest for secondleg@localchanneltest:1 (Retry 1)    -- Executing [firstleg@localchanneltest:1] NoOp("Local/firstleg@localchanneltest-5c24;2", "First Leg") in new stack    -- Executing [firstleg@localchanneltest:2] Wait("Local/firstleg@localchanneltest-5c24;2", "5") in new stack    -- Executing [firstleg@localchanneltest:3] Answer("Local/firstleg@localchanneltest-5c24;2", "") in new stack    -- Executing [firstleg@localchanneltest:4] Wait("Local/firstleg@localchanneltest-5c24;2", "10") in new stack  == Spawn extension (localchanneltest, firstleg, 4) exited non-zero on 'Local/firstleg@localchanneltest-5c24;2' By: Leif Madsen (lmadsen) 2010-03-03 10:18:20.000-0600 Exact same reason as 1.6.2.2 -- it is a security fix and not a bug fix release. Please look at the release announcements which clearly define what is fixed in a version or not, along with the ChangeLogs.