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

[Danny Nicholas]

-----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.