[Home]

Summary:ASTERISK-00948: Half of AGI broken when using VERBOSE
Reporter:philipp2 (philipp2)Labels:
Date Opened:2004-01-29 12:42:32.000-0600Date Closed:2004-09-25 02:53:51
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Any AGI command with "GET" in it like "GET VARIABLE X" will fail, i.e. not return any result if AGI "VERBOSE" has been used before. That particularly nasty thing is that it is common practice to use VERBOSE for debugging AGI scripts...

****** ADDITIONAL INFORMATION ******

For testing: Toggle $debug in the php script and check the file output.

exten => 333,1,Playback(What-event-in-history-is-linked-to-this-extension-number)
exten => 333,2,SetVar(DIALSTRING=123456)
exten => 333,3,AGI(test.agi)

#!/usr/bin/php -q
<?php

ob_implicit_flush(true);
set_time_limit(30);
$in = fopen("php://stdin","r");
$stdlog = fopen('/var/log/asterisk/my_agi.log', 'w');

$debug = false;
// $debug = true;

function __read__() {
  global $in, $debug, $stdlog;
  $input = str_replace("\n", "", fgets($in, 4096));
  fputs($stdlog, $input . "\n");
  if ($debug) echo "VERBOSE \"read: $input\"\n";
  return $input;
}

function __write__($line) {
  global $debug;
  if ($debug) echo "VERBOSE \"write: $line\"\n";
  print $line."\n";
}

// parse agi headers into array
while ($env=__read__()) {
  $s = split(": ",$env);
  $agi[str_replace("agi_","",$s[0])] = trim($s[1]);
  if (($env == "") || ($env == "\n")) {
    break;
  }
}

fputs($stdlog, "Call from ".$agi["callerid"]."\n");
__write__("ANSWER");
__read__();
__write__("SAY DIGITS 68 \"7\"");
__read__();
__write__("GET VARIABLE DIALSTRING");
__read__();

// clean up
fclose($in);
fclose($stdlog);

exit;
?>
Comments:By: Olle Johansson (oej) 2004-01-29 12:54:59.000-0600

VERBOSE <message> <level>
is a proper syntax according to app_agi.c

Have you checked the response for VERBOSE? I don't know what happens, if this results in an error message and an early closure of the connection. This might also be the problem with the Perl library.

By: Olle Johansson (oej) 2004-01-29 12:57:01.000-0600

No, the perl library use a 'level'. Sorry about that. Still, you're not sending level in the PHP script.

By: philipp2 (philipp2) 2004-01-29 13:13:17.000-0600

Same problem if I specify the level. Also, http://home.cogeco.ca/~camstuff/agi.html claims that level is optional, which I believe to be correct.

By: James Golovich (jamesgolovich) 2004-02-02 13:33:03.000-0600

It looks like your not reading the return result from AGI 'VERBOSE' command you are sending.  So you should be getting very odd results from your code.  Every AGI commands result has to be read before you can start sending new commands.  And in the case of your __write__ sub, you are writing the VERBOSE line before your writing the text to send

By: philipp2 (philipp2) 2004-02-02 15:11:07.000-0600

Hm... I see what you mean - I had already thought about that and tested it with modified __read__() and __write__() functions like this:

function __read__() {
  global $in, $debug, $stdlog;
  $input = str_replace("\n", "", fgets($in, 4096));
  fputs($stdlog, $input . "\n");
  if ($debug) {
     echo "VERBOSE \"read: $input\" 1\n";
     $input2 = str_replace("\n", "", fgets($in, 4096));
     fputs($stdlog, "VERBOSE read response\n");
     fputs($stdlog, $input2 . "\n");
  }
  return $input;
}

function __write__($line) {
  print $line."\n";
}

So why does the above fail? Now the script will hang. I am still not convinced that everything is fine with VERBOSE.

By: James Golovich (jamesgolovich) 2004-02-02 15:48:48.000-0600

Where is the script hanging at?  I would guess that it would hang right before the first AGI command gets sent, because you are going to be writing VERBOSE commands before the AGI environment has been printed since you are calling __read__ when parsing the AGI environment stuff.

I do not have any problem with using VERBOSE in my AGIs, this just looks like a php coding problem

By: James Golovich (jamesgolovich) 2004-03-20 02:27:37.000-0600

I'm unable to duplicate these results.  Reopen if its still an issue