[asterisk-dev] Why are there 2 command id's in res_agi.c for async AGI.

[Christophe Devriese]

This makes it very hard to use the command_id for it's intended purpose.

The idea is, I think, first you put a channel into async AGI mode in
extensions.conf :

[phone]
1,1,answer()
1,2,AGI(agi:async)
...

Then you connect a manager application, which gets and AsyncAGI event
(subevent start) and is then supposed to queue up AGI commands by sending
AGIActions. These contain a command_id.

The commands are converted into a struct agi_cmd (res_agi.c: 963) :
struct agi_cmd {
        char *cmd_buffer;
        char *cmd_id;
        AST_LIST_ENTRY(agi_cmd) entry;
};

When time comes to execute these, they're executed by agi_handle_command
(res_agi.c: 3249) which starts :

static int agi_handle_command(struct ast_channel *chan, AGI *agi, char *buf,
int dead)
{
        const char *argv[MAX_ARGS];
        int argc = MAX_ARGS, res;
        agi_command *c;
        const char *ami_res = "Unknown Result";
        char *ami_cmd = ast_strdupa(buf);
*****************************
        int command_id = ast_random(), resultcode = 200;
*****************************

Right there a new command_id is made up as a random string, which is then
used to generate events about the command (command start, end, result, ...).
This makes it impossible to use the command_id's for their intended purpose
: associate the requested command with events describing it's execution.
Wouldn't it be better to pass the agi_cmd struct into the agi_handle_command
function and use it's cmd_id ?

Christophe
--
Reality is that which, when you stop believing in it, doesn't go away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110404/4a1c3220/attachment.htm>