Summary:	ASTERISK-26115: pbx: AMI Originate ignore "failed" extension on call failure
Reporter:	Nasir Iqbal (nasir)	Labels:
Date Opened:	2016-06-15 03:33:57	Date Closed:	2017-02-13 07:12:10.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Core/PBX
Versions:	13.9.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 7	Attachments:	( 0) asterisk-13.0.2-failed.patch
Description:	We were using originate from AMI with target extension something like following {noformat} [my_dial] exten => failed,1,Set(_call_status=failed) exten => failed,n,Macro(call_failed,${UNIQUEID},${REASON}) exten => failed,n,Hangup() exten => _X.,4,Goto(my_context,${EXTEN},1) exten => h,1,Hangup() {noformat} Please note *failed* extension above, we used it to do required work in case outgoing call fail. it worked good until we upgraded asterisk from 11 to 13. In Asterisk 13 *failed* extension is being ignored. After some code reading I have concluded that "if" condition in "pbx.c:ast_pbx_outgoing_exten" is probably responsible for this error. {code} if (res < 0 /* Call failed to get connected for some reason. */ && 1 < synchronous && ast_exists_extension(NULL, context, "failed", 1, NULL)) { {code} As seen in above code _synchronous_ must be bigger then _1_ to execute *failed* extension code. However at the same time you can see that  *manager.c:fast_originate* call *pbx.c:ast_pbx_outgoing_exten* with _1_ as _synchronous_, so its obvious that above condition will fail and *failed* extension will not be called. Note: the most similar issue which I can find is ASTERISK-13180
Comments:	By: Asterisk Team (asteriskteam) 2016-06-15 03:34:00.273-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Nasir Iqbal (nasir) 2016-06-15 03:46:27.907-0500 To fix this issue I have removed *synchronous* check from mentioned condition, and it worked for me, However I am not sure if it will not break something else. By: Joshua C. Colp (jcolp) 2016-06-15 12:03:35.887-0500 I've checked the latest code and it has not changed so this still appears to be a problem. In the future though I'd suggest checking against the latest version of things when reporting an issue to see if it's been fixed. By: Friendly Automation (friendly-automation) 2017-02-13 07:12:11.511-0600 Change 4913 merged by zuul: manager: Restore Originate failure behavior from Asterisk 11 [https://gerrit.asterisk.org/4913|https://gerrit.asterisk.org/4913] By: Friendly Automation (friendly-automation) 2017-02-13 07:12:14.651-0600 Change 4915 merged by zuul: manager: Restore Originate failure behavior from Asterisk 11 [https://gerrit.asterisk.org/4915|https://gerrit.asterisk.org/4915] By: Friendly Automation (friendly-automation) 2017-02-13 07:23:46.554-0600 Change 4914 merged by Joshua Colp: manager: Restore Originate failure behavior from Asterisk 11 [https://gerrit.asterisk.org/4914|https://gerrit.asterisk.org/4914]