Summary:ASTERISK-09732: Agi exits without any possibility to catch on stream file
Reporter:Gaspar Zoltan (gasparz)Labels:
Date Opened:2007-06-22 05:19:39Date Closed:2007-06-25 13:20:16
Versions:Frequency of
Environment:Attachments:( 0) asterisk-1.4.69845-streamfile-hangup.patch
( 1) cli.h
( 2) res_agi.c

When somebody hangs up in the middle of a stream file, the agi script terminates right away. Setting Sighup handler to SIG_IGN doesn't help.

I think this can be reproduced in all versions of the 1.2 branch (I checked the code in the 1.4 version and I think it still has the problem).

How to reproduce:

write an agi script like:

declare(ticks = 1);
   if (function_exists('pcntl_signal')) {
  pcntl_signal(SIGHUP,  SIG_IGN);
$agi = new AGI();
$agi->verbose("before stream file",3);
$agi->stream_file("prepaid-no-enough-credit-stop", "");
$agi->verbose("after stream file",3);

exten => 10,1,AGI(test.php);

expected result:
In any case of hangup to write the text: "after stream file";

If the call is hung_up before the whole file is played back it exits right away and in the cli doesn't write the "after stream file".

in res_agi.c

when it is hanged up prematurly you have -1 in res otherwise 0

00590    if (res >= 0)
00591       return RESULT_SUCCESS;
00592    else
00593       return RESULT_FAILURE;

Fixing the problem is to retun RESULT_SUCCESS; on line 00593 not return RESULT_FAILURE;

With this it works just fine.

Another thing:
res = ast_playstream(fs);
00573    if (res) {
00574       fdprintf(agi->fd, "200 result=%d endpos=%ld\n", res, sample_offset);
00575       if (res >= 0)
00576          return RESULT_SHOWUSAGE;
00577       else
00578          return RESULT_FAILURE;
00579    }

ast_playstream ALWAYS returns 0 so the whole if is for nothing!

Same in branch 1.4
00590    res = ast_playstream(fs);
00591    if (vfs)
00592       vres = ast_playstream(vfs);
00594    if (res) {
00595       fdprintf(agi->fd, "200 result=%d endpos=%ld\n", res, sample_offset);
00596       return (res >= 0) ? RESULT_SHOWUSAGE : RESULT_FAILURE;
00597    }

Comments:By: Jason Parker (jparker) 2007-06-22 10:04:09

The first part of this report is intended behavior.  As for the second part, I've committed fixes to svn branches 1.2, 1.4, and trunk in revisions 71065, 71068, and 71069.

By: Gaspar Zoltan (gasparz) 2007-06-22 12:10:40

Please explain, if this is the correct functionality, in exec command you return -1 on hangup (event can be cached in agi if you are ignoring sighup) and you are returning: RESULT_FAILURE (2) -> uncachable response in stream file.

This is why a person wrote in the wiki:

to not use this method and use exec playback (exec works as expected).

I am asking this so that all agi methods work the same in a case of a hangup. It's really frustrating to trouble shoot every possibility and every case to work, as expected differently:
hangup during exec,
hangup during stream file
hangup during get data and so on...


By: Gaspar Zoltan (gasparz) 2007-06-25 04:18:50

As I said AGI functions behave differently to the hangup event.
handle_exec returns -1
handle_streamfile returns 2

So the agi script sometimes can handle the event and sometimes it can't depending during what command the hangup event occured.

I discussed this problem with HarryR in the irc channel and he concluded:
<HarryR> ideally it should just return the status and not do anything automagic like hangup the channel
<HarryR> allowing the AGI script to decide what to do

This is why we set a new result status: RESULT_WARNING -1 (cli.h) for the cases we have a hangup event for every agi function (res_agi.c modified for branch 1.2).


By: Harry Roberts (harryr) 2007-06-25 04:19:06

I've attached a patch for the 1.4 trunk (69845) which allows an AGI script to detect if the call was hungup during the middle of a "STREAM FILE" command by defining a new return status (RESULT_WARNING - non fatal return).

-1 is returned by waitstream_core/ast_waitstream_full on hangup, which handle_streamfile considers a failure and returns RESULT_FAILURE.

By: Tilghman Lesher (tilghman) 2007-06-25 13:20:16

Committed change in 71656, 71657, 71658.