[Home]

Summary:ASTERISK-18958: Asterisk Manager incorrectly sets a ChannelID to be global in highly repeatable circumstances
Reporter:Red (redwolf890)Labels:
Date Opened:2011-12-02 10:08:42.000-0600Date Closed:2011-12-07 15:38:16.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/ManagerInterface Documentation
Versions:1.8.7.1 Frequency of
Occurrence		Constant
Related
Issues:
is duplicated byASTERISK-18966 Consistent AMI error causing Channel variable setting to create global variables
Environment:CentOS 5.5 Final. Kernel 2.6.18-274.7.1.el5 x64.Attachments:( 0) __20111207-manager-setvar-docs.patch.txt
( 1) jira_asterisk_18958_v1.8.patch
Description:Asterisk Manager "Action: SetVar" command is broken when it is applied to a Channel.  If a user executes the following AMI command (the Channel header is blank):

Action: SetVar
ChannelID:
Variable: TEST_VARIABLE
Value: TEST_VALUE

the variable "TEST_VARIABLE" becomes globally set to "TEST_VALUE".  The reason this is an error is that all other AMI commands that use a ChannelID header send the error reply "Response: Error\r\nMessage: Channel not specified" when no value is supplied for the Channel.

This can severly and horrendously breaks things if you are setting things like CallerID variables on a channel and get some text parsing failure that causes Channel header to be set to blank.  Every single person on your system gets broken CallerID details.
Comments:By: Richard Mudgett (rmudgett) 2011-12-02 12:12:34.850-0600

This is intended behavior.

The "Channel" header is optional.  How else are you going to set a global variable?

{noformat}
*CLI> manager show command setvar
[Syntax]
Action: Setvar
[ActionID:] <value>
[Channel:] <value>
Variable: <value>
Value: <value>

[Synopsis]
Set a channel variable.

[Description]
Set a global or local channel variable.

[Arguments]
ActionID
   ActionID for this transaction. Will be returned.
Channel
   Channel to set variable for.
Variable
   Variable name.
Value
   Variable value.

[See Also]
Not available
{noformat}

Please note that "ChannelID" is not a valid header name for this AMI action.

By: Red (redwolf890) 2011-12-05 07:50:27.855-0600

Yes ChannelID was a consistent typo in my original bug report.  This is correct.  And I also agree that Channel is a an optional header -- thus you are correct in noting that globals are set by omitting said header.  Except that when you set globals you _omit_ the Channel header, you don't include it with a blank value.

This still does not resolve the issue that AMI commands that use the Channel header return the error "Response: Error\r\nMessage: Channel not specified."  How can I open this back up, because this is definitely incorrect and not intended behavior.  It is not intuitive and I can promise other people will have this bug creep up on them and cause severe problems.

If "Action: Hangup" hung up every channel when a blank channel value was supplied would you call this "intended behavior"?
By: Richard Mudgett (rmudgett) 2011-12-05 09:51:19.890-0600

"Action: Hangup" requires the channel so of course if you do not supply it it returns error.  It does not matter if you do not have the header or do not supply the value.  It is still missing and is an error.

"Action: SetVar" does not require the channel so it will not complain.  It does not care if you do not supply the header or do not supply a value.  Since it is optional, it will not complain.
By: Matt Jordan (mjordan) 2011-12-05 10:56:23.549-0600

Red:

The behavior of the scenario you've described is technically undefined.  Here is what is defined:
1. When setting a variable through an AMI action, if no channel name is provided, then the variable is global.
2. When setting a variable through an AMI action, if a channel is provided and that channel name is valid, the variable applies to the channel.
3. When setting a variable through an AMI action, if a channel is provided and the channel name is not valid, an error message should be sent back.

So, when providing either an empty channel name (no channel name provided) or when the channel key name is omitted (as the channel name is an optional field), we treat the variable assignment as global.

Comparing this situation to AMI actions with non-optional fields is a false comparison; obviously failing to provide non-optional information is an error.  Given that this AMI action also has a valid use case wherein the channel name is empty makes it more tricky and difficult to compare to other AMI actions.

As it is, I agree with Richard that this is the intended behavior - although I can see why this would be confusing and why you might expect that this is a bug.  If you feel strongly that the behavior of this AMI action should change, please ask the open source community what they feel on the asterisk-dev mailing list or on #asterisk-dev.  Please keep in mind changing an existing AMI action and its behavior could have large repercussions on a number of Asterisk users, so in a case like this where whether or not it is a bug is debatable, erring on the side of caution and not changing the behavior may still be the best course of action.

I'll keep this issue open for a little while, in case the community as a whole disagrees and believes that this is a bug and should be fixed.

Thanks

Matt
By: Red (redwolf890) 2011-12-05 12:48:02.232-0600

"3. When setting a variable through an AMI action, if a channel is provided and the channel name is not valid, an error message should be sent back."

Okay.  I understand what both Richard and Matt are saying.  If nothing else, is it possible to add this technically undefined scenario to the docs?  If will help explain to other AMI users the difference between:

Action: SetVar
Channel: InvalidChannelIdentifier
Variable: TEST_VARIABLE
Value: TEST_VALUE

Response: Error
Message: No such channel

And:

Action: SetVar
Channel:
Variable: TEST_VARIABLE
Value: TEST_VALUE

Response: Success
Message: Variable Set

Thanks for helping to explain this behavior.
By: Matt Jordan (mjordan) 2011-12-06 11:48:29.808-0600

We can update the documentation for the SetVar manager action to better explain what happens with the Channel parameter.  Thanks for providing the feedback!
By: Leif Madsen (lmadsen) 2011-12-07 11:02:50.515-0600

Let me know if this is an acceptable documentation update.
By: Richard Mudgett (rmudgett) 2011-12-07 14:43:30.351-0600

[^jira_asterisk_18958_v1.8.patch] is a better way to express what is expected.

The patch also updates the Getvar documentation since it behaves the same as Setvar.
By: Leif Madsen (lmadsen) 2011-12-07 15:17:44.729-0600

Ship it!
By: Red (redwolf890) 2011-12-12 09:26:09.208-0600

Thanks for adding this to the documentation, I think this is more than enough to clarify expected behavior.