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

Mark Michelson mmichelson at digium.com
Mon Oct 1 16:15:12 CDT 2012


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

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev



More information about the asterisk-users mailing list