-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mark Michelson Sent: Monday, October 01, 2012 4:15 PM To: [email protected] 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. -- _____________________________________________________________________ -- 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
