Summary:	ASTERISK-25266: Application Originate returns SUCCESS to ORIGINATE_STATUS upon failure to originate
Reporter:	Allen Ford (cyford33)	Labels:	pjsip
Date Opened:	2015-07-19 11:10:28	Date Closed:	2017-10-11 15:04:25
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_originate
Versions:	11.16.0 13.5.0	Frequency of Occurrence
Related Issues:
Environment:	CentOS release 6.6 (Final)	Attachments:
Description:	In my example   if "freeserver" is offline  or not responding i still get a SUCCESS status,  which is messing up my fail-over {noformat} exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = ""]?15:) exten => h,15,Set(goto=$[${PRIORITY} + 15]) exten => h,n,Originate(SIP/FreeServer/1${callerid},exten,BMP-Authentication-1,1${callerid},1) exten => h,n,Verbose(0, getting staus ${ORIGINATE_STATUS} ); exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "SUCCESS"]?hangup:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "FAILED"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "BUSY"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "CONGESTION"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "RINGING"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "HANGUP"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "UNKNOWN"]?${goto}:) exten => h,n,Hangup() exten => h,30,Set(goto=$[${PRIORITY} + 20]) exten => h,n,Originate(SIP/geils/1${callerid},exten,BMP-Authentication-1,${callerid},1) exten => h,n,Verbose(0, getting staus ${ORIGINATE_STATUS} ); exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "SUCCESS"]?hangup:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "FAILED"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "BUSY"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "CONGESTION"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "HANGUP"]?${goto}:) exten => h,n,GotoIf($["${ORIGINATE_STATUS}" = "UNKNOWN"]?${goto}:) exten => h,n,Hangup() {noformat}
Comments:	By: Asterisk Team (asteriskteam) 2015-07-19 11:10:30.347-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: Rusty Newton (rnewton) 2015-07-20 18:06:54.181-0500 Thanks for the report and debug. However we also need protocol specific debug captured at the time of the issue. Please include the following: * Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver. * Configuration information for the relevant channel driver, e.g. pjsip.conf. * A wireshark compatible packet capture, captured at the same time as the Asterisk log output. [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Make sure VERBOSE and DEBUG are included in the log. By: Allen Ford (cyford33) 2015-07-20 18:23:02.831-0500 I brought the bug from my live server..  i found that setting a timeout option with originate is a quick fix and i can not further troubleshoot..   however i do not know what wisreshark will add,   as i mentioned when the trunk is not available  like my remote asterisk is shut down  or froze  ( can not respond)   By: Rusty Newton (rnewton) 2015-08-25 09:38:34.607-0500 Reproduced in 13. Timeout option doesn't appear to affect the issue in 13.Failed originations to unavailable technologies or unavailable endpoints result in SUCCESS. I don't think this is expected, but if it is then we should at least document expected behavior the application help text. By: Sean Bright (seanbright) 2017-09-15 08:31:45.782-0500 When you have some time, can you try to reproduce with latest 13? This may have been fixed by [8936568|https://github.com/asterisk/asterisk/commit/8936568515d26eba6087a0064fe4d5d6e7f02ddd]. By: Rusty Newton (rnewton) 2017-09-15 17:44:19.455-0500 Yup, will do! By: Rusty Newton (rnewton) 2017-10-06 09:50:10.539-0500 [~seanbright] Finally got around to this. Unfortunately it still occurs in 13.17.2 {noformat} [Long-Distance] exten => 7000,1,Originate(PJSIP/Blah${callerid},app,playback,demo-congrats) same => n,Verbose(0, getting status: ${ORIGINATE_STATUS} ) {noformat} {noformat}    -- Executing [7000@Long-Distance:1] Originate("PJSIP/1107-00000001", "PJSIP/Blah,app,playback,demo-congrats") in new stack [Oct  6 17:44:51] ERROR[27342]: chan_pjsip.c:2156 request: Unable to create PJSIP channel with empty endpoint name    -- Executing [7000@Long-Distance:2] Verbose("PJSIP/1107-00000001", "0, getting status: SUCCESS ") in new stack getting status: SUCCESS {noformat} By: Friendly Automation (friendly-automation) 2017-10-11 15:04:25.859-0500 Change 6729 merged by Jenkins2: app_originate: Set ORIGINATE_STATUS correctly on failure [https://gerrit.asterisk.org/6729|https://gerrit.asterisk.org/6729] By: Friendly Automation (friendly-automation) 2017-10-11 15:14:58.039-0500 Change 6730 merged by Jenkins2: app_originate: Set ORIGINATE_STATUS correctly on failure [https://gerrit.asterisk.org/6730|https://gerrit.asterisk.org/6730] By: Friendly Automation (friendly-automation) 2017-10-11 15:42:55.894-0500 Change 6731 merged by Jenkins2: app_originate: Set ORIGINATE_STATUS correctly on failure [https://gerrit.asterisk.org/6731|https://gerrit.asterisk.org/6731] By: Friendly Automation (friendly-automation) 2017-10-11 16:04:01.095-0500 Change 6732 merged by Joshua Colp: app_originate: Set ORIGINATE_STATUS correctly on failure [https://gerrit.asterisk.org/6732|https://gerrit.asterisk.org/6732]