Summary:ASTERISK-03832: originate manager command bug
Reporter:dviper01 (dviper01)Labels:
Date Opened:2005-04-01 10:14:22.000-0600Date Closed:2008-01-15 15:31:04.000-0600
Versions:Frequency of
Description:The originate manager action has a bug that causes problems when  async=false: The given variables are never passed to the channel


In manager.c in function action_originate():

res = ast_pbx_outgoing_app(tech, AST_FORMAT_SLINEAR, data, to, app, appdata, &reason, 0, !ast_strlen_zero(callerid) ? callerid : NULL, variable, account);

... as well as ...

res = ast_pbx_outgoing_exten(tech, AST_FORMAT_SLINEAR, data, to, context, exten, pi, &reason, 0, !ast_strlen_zero(callerid) ? callerid : NULL, variable, account);

should both have '1' as parameter 9 instead of '0'.
Parameter 9 reads sync and NOT async.
Comments:By: Kevin P. Fleming (kpfleming) 2005-04-01 10:23:56.000-0600

The code path you mention is not even used in 'async' mode; the block above it is run when ast_true(async) returns non-zero (i.e. async mode).

Reviewing the code in CVS HEAD, it does appear that the contents of the Variable header are properly passed to the thread that originates the call, and that the calls to ast_pbx_outgoing_* do pass the async flag properly in the helper function that the thread executes.

We will need more evidence of what is actually occurring on your system before this can be resolved. Please include actual dumps of the manager action(s) you are submitting and a trace (using NoOp in the dialplan) showing that the variables are/are not set.

By: dviper01 (dviper01) 2005-04-01 12:04:55.000-0600

Yes, I said that the problem occurs when async is off.

It says
if(ast_true(async)) {
} else {
... bla bla and the lines I mentioned

So the code gets executed when it's NOT running in asynchronous mode (as it should). Under these circumstances however the parameter as mentioned should be 1, right?

The problem is not with the dialplan for the given extension but with the channel-parameter. The called channel never sees the variables because in pbx.c in function ast_pbx_outgoing_exten() it's calling ast_request_and_dial() instead of __ast_request_and_dial() because sync is false.

By: Kevin P. Fleming (kpfleming) 2005-04-01 13:15:01.000-0600

OK, I misunderstood your problem report, sorry. I'll take another look, thanks for the details.

By: Kevin P. Fleming (kpfleming) 2005-04-01 13:34:33.000-0600

The code is somewhat different in CVS HEAD, this problem would not occur (but if the 'sync' flag was set, the variables would not be applied there either... I've fixed that in CVS already).

The problem in stable is _not_ that __ast_request_and_dial is being called, because that function (or its alternatives) don't handle the variables anyway. The problem is that the function just doesn't apply the supplied variables to the channel at all, in many cases. Since this is the stable branch, I can't directly change it, but I'll add a patch to this bug so you can continue working and it can get merged for 1.0.8.

edited on: 04-01-05 13:36

By: Kevin P. Fleming (kpfleming) 2005-04-01 13:46:50.000-0600

OK, that's not quite it either... still working this out.

By: Kevin P. Fleming (kpfleming) 2005-04-01 13:56:32.000-0600

I'll have to get Mark's input on this... I don't understand why the sync flag to ast_pbx_outgoing_* is not being set to true.

By: dviper01 (dviper01) 2005-04-01 17:26:26.000-0600

Well, when setting the parameter to 1 the flow is like this:

1. [pbx.c] ast_pbx_outgoing_exten is called from manager.c with sync correctly set.
after if(sync) { ... } it copies them into the outgoing_helper struct
2. [channel.c] __ast_request_and_dial is called with the outgoing_helper struct and processes the variables (pbx_builtin_setvar( chan, var ))
3. ast_call takes over. In my case all variables finally arrive in sip_call in sip.c

The already mentioned quick-fix solved my problem - the channel gets its variables. This is important in my case because I need auto-answer enabled on my SIP phone and I'm using originate for automated outbound-dialling. I couldn't just reverse the dialing order (channel<>extension/context) because we're using A LOT of zaptel hardware and are doing least-cost routing using GSM gateways.

By: Kevin P. Fleming (kpfleming) 2005-04-01 19:05:25.000-0600

Fixed in CVS, thanks!

By: Kevin P. Fleming (kpfleming) 2005-04-01 19:06:48.000-0600

Note: my fix was only applied to CVS HEAD. The maintainer of the stable branch will need to apply the corresponding fix there before you will see it in the code you are using.

By: Russell Bryant (russell) 2005-04-05 05:47:00

Heyyy Kevin ... I saw where you committed a fix for this, but then reverted it (your first oops commit).  Then, I never saw another patch go in for this.

Am I just blind?  (I have been bug tracking all night ...)

By: Kevin P. Fleming (kpfleming) 2005-04-05 17:07:36

Actually, the first commit was reverted, then a different fix went in (just changing '0' to '1' in the calls to the ast_request_* functions). That fix is still present in CVS HEAD.

By: Russell Bryant (russell) 2005-04-06 11:53:18

fixed in 1.0, Thanks  :)

By: Digium Subversion (svnbot) 2008-01-15 15:29:54.000-0600

Repository: asterisk
Revision: 5345

U   trunk/pbx.c

r5345 | kpfleming | 2008-01-15 15:29:53 -0600 (Tue, 15 Jan 2008) | 2 lines

ensure that variables supplied to ast_pbx_outgoing_exten are applied to the channel even in 'sync' mode (bug ASTERISK-3832, for HEAD only)



By: Digium Subversion (svnbot) 2008-01-15 15:30:03.000-0600

Repository: asterisk
Revision: 5356

U   trunk/manager.c

r5356 | kpfleming | 2008-01-15 15:30:03 -0600 (Tue, 15 Jan 2008) | 2 lines

correct 'sync' setting for manager-originated calls (bug ASTERISK-3832)



By: Digium Subversion (svnbot) 2008-01-15 15:31:04.000-0600

Repository: asterisk
Revision: 5426

U   branches/v1-0/manager.c

r5426 | russell | 2008-01-15 15:31:03 -0600 (Tue, 15 Jan 2008) | 2 lines

correct 'sync' on action_originate (bug ASTERISK-3832)