[Home]

Summary:ASTERISK-23727: Async AGI loop breaks when trying to stream missing file
Reporter:Chico Manobela (manobela)Labels:
Date Opened:2014-05-08 03:36:08Date Closed:2014-05-12 16:26:05
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Resources/res_agi
Versions:SVN 1.8.27.0 11.9.0 12.2.0 Frequency of
Occurrence		Constant
Related
Issues:
is a clone ofASTERISK-23736 Async AGI loop breaks when AGI command returns FAILURE
is duplicated byASTERISK-23738 Allow the Async AGI loop to continue even in case of AGI command returning FAILURE
Environment:CentOS 5Attachments:
Description:trying to stream a non existent file using AsyncAGI results in AsyncAGI loop breaks and  control returns to dial plan.

to reproduce:
1. start async agi loop on call - AGI(agi:async)
2. from the cli try to stream file that doesn't exists:
{noformat}
asterisk*CLI> agi exec SIP/192.168.10.22-00000020 "STREAM FILE x 5"
{noformat}
Asterisk will print the normal warning:
{noformat}
[May  8 11:24:58] WARNING[6805][C-00000020]: file.c:701 ast_openstream_full: File x does not exist in any format
<SIP/192.168.10.22-00000020>AGI Tx >> 200 result=-1 endpos=0
   -- Executing [talk@pbxtel-incoming-async:3]
{noformat}
Next thing asterisk does is to stop the loop and continue the dial plan:
{noformat}
Hangup("SIP/192.168.10.22-00000020", "") in new stack
 == Spawn extension (pbxtel-incoming-async, talk, 3) exited non-zero on 'SIP/192.168.10.22-00000020'
{noformat}
Comments:By: Rusty Newton (rnewton) 2014-05-09 18:09:05.257-0500

I can reproduce as well. As you said, I made a call to AGI(agi:async) , issued the command from the CLI and saw the same behavior.
By: Matt Jordan (mjordan) 2014-05-12 16:25:53.010-0500

This isn't a bug. The AGI command returns {{RESULT_FAILURE}}, which is supposed to break the channel out of the AGI:

{noformat}
if (!(fs = ast_openstream(chan, argv[2], ast_channel_language(chan)))) {
ast_agi_send(agi->fd, chan, "200 result=-1 endpos=%ld\n", sample_offset);
return RESULT_FAILURE;
}
{noformat}

When an AGI command results in a failure - any command - the AsyncAGI loop is broken. That's the expected behaviour.
By: Chico Manobela (manobela) 2014-05-13 01:09:20.212-0500

Of course it's a bug!
regular AGI script doesn't break when a file in "stream file" is not found.
Actually AGI script should not stop at all, not even on hangup.
The user can check the status and deal with it, however, when asterisk breaks the loop by itself, it takes control away from the user, which is a bad design for software.
This is not a critical failure nor a hangup, there is no reason to break the loop.

By: Chico Manobela (manobela) 2014-05-13 01:23:21.850-0500

Also,
just closing the bug and ignoring the request for a fix is not good for the future of this product.
If a user reports a bug, it probably has a reason,
if you think this is not a bug, please allow an option to control this "feature"
On normal AGI script, one can play non existing file without loosing control over the script.
please enable this option in AsyncAGI as well.
I don't need Asterisk to take control over my script,
need a way to tell asterisk to send me the events and let me do the needed actions to handle the events.

By: Matt Jordan (mjordan) 2014-05-13 08:01:12.160-0500

You weren't ignored.
# Rusty reproduced the issue you reported. He noted that the behaviour, and escalated this to someone to look into further.
# I took a look at the code to see if the behaviour was intentional. As I pointed out in my comment, {{stream file}} returns {{RESULT_FAILURE}}. A failure result from an AGI command results in AsyncAGI breaking out of its loop. Hence, it is not a bug but the intended result of the failure.

As far as AsyncAGI not behaving like the other AGI variants - that's because it isn't the same as the other AGI variants. It has its own control loop, and its behaviour with how {{stream file}} fails is consistent with how it behaves when any other AGI command fails.

I understand you don't like that behaviour - that's fine. You may wish it worked differently - great! Asterisk is open source. If you'd like to see the behaviour changed, provide a patch.

No one is under an obligation to change the behaviour simply because you don't care for it.

By: Chico Manobela (manobela) 2014-05-13 09:26:33.317-0500

Thanks for your reply.
Question is, why do AsyncAGI needs to break the loop in case of failure to execute a command?
There is an event for each executed AGI, the event includes a result field that can be used to check the status of the command.
Breaking the loop can be done easily by AMI command on reaction to the AsyncExec event which had a "FAIL" result.
Keeping the loop in the current situation would request a complicated code.
Perhaps we should ask wheater the "intented result" is the correct one.
Anyways, this could easily be solved by using a similar approach as the "AGISIGHUP" channel variable.
I will open a feature request for that.

I didn't ask to change the behaviour "simply because I don't care for it"
I truely believe that breaking the loop due to error in command is wrong design for such async execution queue.