[Home]

Summary:ASTERISK-14125: [patch] Asterisk Manager API Action Originate / OriginateResponse
Reporter:Nicholas Blasgen (nblasgen)Labels:
Date Opened:2009-05-13 22:16:27Date Closed:2009-10-09 13:56:37
Priority:MajorRegression?No
Status:Closed/CompleteComponents:General
Versions:Frequency of
Occurrence
Related
Issues:
is a clone ofASTERISK-23804 Asterisk Manager API Action Originate / OriginateResponse
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