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

[Vladimir Mikhelson]

On 10/1/2012 4:15 PM, Mark Michelson wrote:
> 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
>
Mark,

First you need to consider compatibility with currently supported
packages which include auto-generated dial plans like AsteriskNow, PIAF,
etc.  If you plan to break their functionality you need to at least
coordinate your move with the maintainers.

Then you may want to consider backwards compatibility with packages
still widely used but not actively supported any more like Trixbox.
Maybe not the best example as their WEB site says, "This is the current
stable release based on Asterisk 1.6."

If you really want to make it not settable (and this is big, not a minor
change, if I were you I would definitely make it settable) then I would
go with case-insensitive as it allows for various custom notations, e.g.
Hungarian notation in naming of custom variables without a later
painstaking investigation whether "nCallID" is equal to "nCallId" or
not.  Consider the fact, most of the dial plan debugging happens in the
logs or in the Console Screen.  Someone may want to spell "nCALLID" just
to be able to see the difference between Latin "l" and "I" where the
first one is "L" lower case and the second one is "i" upper case.

Just my 2 cents.

-Vladimir