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

[Olivier]

2012/10/1 Mark Michelson <mmichelson at digium.com>

> Hi!
>
> I've been confronted with an interesting issue to resolve. The
> issue is located here:
>
> https://issues.asterisk.org/**jira/browse/ASTERISK-20163<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<http://lists.digium.com/mailman/listinfo/asterisk-dev>
>
>
+1 for case-sensitivity

> --
> ______________________________**______________________________**_________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/**mailman/listinfo/asterisk-**users<http://lists.digium.com/mailman/listinfo/asterisk-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121003/2f5ce040/attachment.htm>