Summary: | ASTERISK-14125: [patch] Asterisk Manager API Action Originate / OriginateResponse | ||||
Reporter: | Nicholas Blasgen (nblasgen) | Labels: | |||
Date Opened: | 2009-05-13 22:16:27 | Date Closed: | 2009-10-09 13:56:37 | ||
Priority: | Major | Regression? | No | ||
Status: | Closed/Complete | Components: | General | ||
Versions: | Frequency of Occurrence | ||||
Related Issues: |
| ||||
Environment: | Attachments: | ( 0) manager-timeout1.diff | |||
Description: | I have the following issue. When placing an outbound call with Asterisk Manager's Originate command, if the call times out, I get an OriginateResponse reason of `0` and `Failure` as the response. I should be getting a "No Answer" response instead (code `4`) (at least in my mind a timeout should not be a failure). I've tested on the following platforms: Asterusj 1.4.20 Asterisk 1.4.23 Asterisk 1.4.24.1 Asterisk 1.4 r191778 Asterisk 1.4 r193870 My test method was to initiate a Originate call to myself (Asterisk -> SIP -> PSTN) with a short 4 second timeout and look at the OriginateResponse that came back 4 seconds after starting that call. ASYNC is set to True. Can someone tell me if this is really the expected outcome of a timeout? I expect a Failure to mean the call was rejected by the remote side. And since someone will end up looking into this, can we maybe get an update to the different "reason" codes? | ||||
Comments: | By: Nicholas Blasgen (nblasgen) 2009-05-13 22:18:58 I had listed this as major because the issue prevents me from correctly handling the business logic after placing a call. Right now my system is removing hundreds of numbers because some calls get marked as reason `0` and some correctly as `4`. By: Nicholas Blasgen (nblasgen) 2009-05-27 15:16:50 from frame.h (1.4 svn r194356). 0 = FAILURE 1 = HANGUP (rarely seen on PRI in my experience) 3 = RINGING (i.e. timeout) 4 = ANSWER 5 = BUSY (that is where your 5 errors are coming from) 8 = CONGESTION This issue has continued with Asterisk SVN-branch-1.4-r196826. Thanks to the help from Matthew Nicholson, I have received a patch which will report a timeout as being "RINGING" (code 3). By: Matthew Nicholson (mnicholson) 2009-05-27 15:39:36 I uploaded a patch that should fix this issue. The ideal solution would be to modify the originate command so that it specifically returns a status code similar to the DIALSTATUS variable when using the Dial application. By: Nicholas Blasgen (nblasgen) 2009-06-03 13:21:17 So as previously stated, I've tested this and confirmed that the patch works to address my specific issue. What I want to do is test that the system still returns 0 in the correct situations and not the newly forced response of 3. I'm not aware of how to cause a correctly defined 0. Can someone provide input? And as MNicholson said, this is the wrong way to go about solving the issue but it works. If response equals zero, make it 3 instead. That's a hack, not a solution. But I don't know Asterisk code, so maybe this is standard. By: Matthew Nicholson (mnicholson) 2009-06-04 14:00:16 To test actual failure (0), request a channel like "nothing/nothing", or request a channel like "sip/this-will-surely-fail", and maybe requesting an extension that does not exist might work as well. Well, that is not exactly how my patch works. It specifically detects a timeout and returns 3. By: Digium Subversion (svnbot) 2009-10-09 13:23:41 Repository: asterisk Revision: 223225 U branches/1.4/main/channel.c ------------------------------------------------------------------------ r223225 | mnicholson | 2009-10-09 13:23:40 -0500 (Fri, 09 Oct 2009) | 8 lines Signal timeouts by returning AST_CONTROL_RINGING when originating calls. (closes issue ASTERISK-14125) Reported by: nblasgen Patches: manager-timeout1.diff uploaded by mnicholson (license 96) Tested by: nblasgen, mnicholson ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=223225 By: Digium Subversion (svnbot) 2009-10-09 13:37:36 Repository: asterisk Revision: 223273 _U trunk/ U trunk/main/channel.c ------------------------------------------------------------------------ r223273 | mnicholson | 2009-10-09 13:37:36 -0500 (Fri, 09 Oct 2009) | 14 lines Merged revisions 223225 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r223225 | mnicholson | 2009-10-09 13:20:11 -0500 (Fri, 09 Oct 2009) | 8 lines Signal timeouts by returning AST_CONTROL_RINGING when originating calls. (closes issue ASTERISK-14125) Reported by: nblasgen Patches: manager-timeout1.diff uploaded by mnicholson (license 96) Tested by: nblasgen, mnicholson ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=223273 By: Digium Subversion (svnbot) 2009-10-09 13:39:41 Repository: asterisk Revision: 223276 _U branches/1.6.0/ U branches/1.6.0/main/channel.c ------------------------------------------------------------------------ r223276 | mnicholson | 2009-10-09 13:39:41 -0500 (Fri, 09 Oct 2009) | 21 lines Merged revisions 223273 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r223273 | mnicholson | 2009-10-09 13:34:08 -0500 (Fri, 09 Oct 2009) | 14 lines Merged revisions 223225 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r223225 | mnicholson | 2009-10-09 13:20:11 -0500 (Fri, 09 Oct 2009) | 8 lines Signal timeouts by returning AST_CONTROL_RINGING when originating calls. (closes issue ASTERISK-14125) Reported by: nblasgen Patches: manager-timeout1.diff uploaded by mnicholson (license 96) Tested by: nblasgen, mnicholson ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=223276 By: Digium Subversion (svnbot) 2009-10-09 13:40:05 Repository: asterisk Revision: 223277 _U branches/1.6.1/ U branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r223277 | mnicholson | 2009-10-09 13:40:05 -0500 (Fri, 09 Oct 2009) | 21 lines Merged revisions 223273 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r223273 | mnicholson | 2009-10-09 13:34:08 -0500 (Fri, 09 Oct 2009) | 14 lines Merged revisions 223225 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r223225 | mnicholson | 2009-10-09 13:20:11 -0500 (Fri, 09 Oct 2009) | 8 lines Signal timeouts by returning AST_CONTROL_RINGING when originating calls. (closes issue ASTERISK-14125) Reported by: nblasgen Patches: manager-timeout1.diff uploaded by mnicholson (license 96) Tested by: nblasgen, mnicholson ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=223277 By: Digium Subversion (svnbot) 2009-10-09 13:56:37 Repository: asterisk Revision: 223286 _U branches/1.6.2/ U branches/1.6.2/main/channel.c ------------------------------------------------------------------------ r223286 | mnicholson | 2009-10-09 13:56:37 -0500 (Fri, 09 Oct 2009) | 21 lines Merged revisions 223273 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r223273 | mnicholson | 2009-10-09 13:34:08 -0500 (Fri, 09 Oct 2009) | 14 lines Merged revisions 223225 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r223225 | mnicholson | 2009-10-09 13:20:11 -0500 (Fri, 09 Oct 2009) | 8 lines Signal timeouts by returning AST_CONTROL_RINGING when originating calls. (closes issue ASTERISK-14125) Reported by: nblasgen Patches: manager-timeout1.diff uploaded by mnicholson (license 96) Tested by: nblasgen, mnicholson ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=223286 By: kondik (kondik) 2014-05-29 08:21:12.556-0500 I use Asterisk in 12.1.1. version and I have similar issue. When I use Originate Action with Async=True then I receive OriginateResponse Event, but when call is no_answered the Response is "Failure" and "Reason" is always "0" instead of any other value like 1 (no answer) etc. Could anyone confirm that this issue was fixed at 12.1.1. version or is still broken? Thanks in advance Konrad By: Matt Jordan (mjordan) 2014-05-29 08:44:08.406-0500 No, this is not broken. Dialplan: {code} [default] exten => busy_test,1,NoOp() same => n,Busy() {code} AMI: {code} Action: Originate Channel: Local/busy_test@default Async: True Application: Echo Data: {code} OriginateResponse: {code} Event: OriginateResponse Privilege: call,all Response: Failure Channel: Local/busy_test@ari Context: Exten: Reason: 5 Uniqueid: <null> CallerIDNum: <unknown> CallerIDName: <unknown> {code} Response is always either "Failure" or "Success". The reason code, on the other hand, is dependent on why the outgoing channel hung up. Without actually looking at a DEBUG log, there's no way anyone can say why you would be getting '0' instead of some other value. By: kondik (kondik) 2014-05-29 09:00:32.222-0500 many thanks for your quick response. I have tested one more putting the same as you wrote above and my OriginateAction and OriginateResponse are: Action: Originate Channel: Local/busy_test@test Async: True Application: Echo Data: Event: OriginateResponse Privilege: call,all Response: Failure Channel: Local/busy_test@test-00000090;1 Context: Exten: Reason: 0 Uniqueid: 1401371669.608 CallerIDNum: <unknown> CallerIDName: <unknown> I know that the Response is either "Failure" or "Success" and it is ok, but I don't know why I have always: "Reason: 0" . Below my debug log: [May 29 15:59:54] VERBOSE[30053] dial.c: -- Called busy_test@test [May 29 15:59:54] VERBOSE[30054][C-000000a3] pbx.c: -- Executing [busy_test@test:1] NoOp("Local/busy_test@test-00000091;2", "") in new stack [May 29 15:59:54] VERBOSE[30054][C-000000a3] pbx.c: -- Executing [busy_test@test:2] Busy("Local/busy_test@test-00000091;2", "") in new stack [May 29 15:59:54] VERBOSE[30053] dial.c: -- Local/busy_test@test-00000091;1 is busy [May 29 15:59:54] VERBOSE[30054][C-000000a3] pbx.c: == Spawn extension (test, busy_test, 2) exited non-zero on 'Local/busy_test@test-00000091;2' By: Richard Mudgett (rmudgett) 2014-05-29 11:20:51.211-0500 The following commit corrected the regression that you are seeing: {noformat} r412581 | rmudgett | 2014-04-18 11:38:20 -0500 (Fri, 18 Apr 2014) | 25 lines Originated calls: Fix several originate call problems. * Restore the reason value set by pbx_outgoing_attempt() to use AST_CONTROL_xxx values as all the consumers were expecting rather than cause codes. * Fixed the dial routines to set cause codes for more than just ast_request() so pbx_outgoing_attempt() reason codes will function. * Fix inconsistent locked_channel return status in pbx_outgoing_attempt(). The chanel may not have been locked or the channel may have been a stale pointer. * Fixed the OutgoingSpoolFailed channel to run dialplan whenever the dialing fails for an originate exten and 1 < synchronous. * Fix incorrect ast_cond_wait() usage in pbx_outgoing_attempt(). Indroduced by issue ASTERISK-22212 patch. * Made struct pbx_outgoing use the ao2 lock instead of its own lock for the cond wait mutex. No sense in having two locks associated with the same struct when only one is needed. Review: https://reviewboard.asterisk.org/r/3421/ {noformat} By: kondik (kondik) 2014-05-30 05:07:15.472-0500 Many thanks for your help. I have installed Asterisk 12.3.0 and now it works!!! So 12.1 version has a bug. Regards, Konrad |