[asterisk-users] Case-sensitivity of Dialplan variables.

[john at millican.us]

On 10/1/2012 5:19 PM, Danny Nicholas wrote:
> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com
> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Mark Michelson
> Sent: Monday, October 01, 2012 4:15 PM
> To: asterisk-users at lists.digium.com
> Subject: [asterisk-users] Case-sensitivity of Dialplan variables.
>
> Hi!
>
> I've been confronted with an interesting issue to resolve. The issue is
> located here:
>
> https://issues.asterisk.org/jira/browse/ASTERISK-20163
>
> The issue involves case-sensitivity of channel and global variables in the
> dialplan. Current behavior is as follows:
>
> 1) Variables created in the dialplan by users are case-insensitive.
> Thus if the variable MARK were set, then ${MARK} and ${mark} would both
> evaluate to the set value.
>
> 2) Variables used internally by Asterisk are case sensitive. So if some
> application set a variable called MARK, it would be different from a
> variable set by some application called mark.
>
> First off, this inconsistency is just weird. It would be much easier to just
> have things work one way or the other, not to have this mix.
>
> In addition, this can lead to some awkward situations. Consider that someone
> wants to use a specific SIP codec and so they set the variable SIP_CODEc to
> be "g722". Notice that the final 'c' is lowercase, presumably due to a
> typing error. The option would not take effect because chan_sip specifically
> checks the value of the case-sensitive ${SIP_CODEC}. What makes this weirder
> is that if the dialplan writer were to check ${SIP_CODEC} in the dialplan
> using a NoOp or Verbose call, then he would see the variable set to the
> value he set it to when he set ${SIP_CODEc} because the variable
> substitution is case-insensitive in the dialplan. This makes debugging the
> problem difficult.
>
> I propose that dialplan variables need to be made consistent in their
> evaluation. We need to choose either to be always case-sensitive or always
> case-insensitive. The problem is, I don't know which of these changes would
> have a larger effect on people. This is where I would like your feedback.
> Which way should it go?
>
> Some of you might be eager to propose a configuration option to decide which
> it should be. I'm sick of having hundreds of options in Asterisk to slightly
> tweak the behavior one way or another. This needs to go one way or the
> other, not be configurable.
>
> What I plan to do, no matter which way the vote goes, is to document on the
> wiki how things currently behave in Asterisk, to include the example I gave
> above (or something similar anyway). Depending how the vote goes, I will
> make the necessary code changes in Asterisk trunk. I will document the
> behavior change both in UPGRADE.txt and on the wiki.
>
> When considering which way you lean, consider that we really don't have much
> of a precedent to go on. For instance, dialplan applications are
> case-insensitive ("answer" and "Answer" and "ANSWER" are all the same).
> Dialplan functions, on the other hand, are case sensitive ("HASH" would be
> evaluated properly but "hash" would not). My personal opinion is that all
> variable evaluations should be case-sensitive.
> I don't feel all that strongly about it though and could easily be swayed
> the other way if people respond overwhelmingly in opposition.
>
> So respond here and let me know what you think. I got a couple of replies on
> the -dev list and they said that this would be good to put out on the -users
> list too.
>
> Mark Michelson
>
> In true Republican fashion, I'm going to vote for case-insensitivity.
>
>
I will definitely cast my vote for always case-sensitive.  asterisk == 
asterisk != Asterisk != ASTERISK   In my opinion this would make 
troubleshooting much easier.  Normally I would fuss like hell if a 
change that would break existing behavior were proposed but, again just 
my opinion, this is fixing something that has always been broken and 
because of this I would also suggest making this the normal behavior for 
all aspects of Asterisk.
JohnM