<br><br><div class="gmail_quote">2012/10/1 Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com" target="_blank">mmichelson@digium.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
I've been confronted with an interesting issue to resolve. The<br>
issue is located here:<br>
<br>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20163" target="_blank">https://issues.asterisk.org/<u></u>jira/browse/ASTERISK-20163</a><br>
<br>
The issue involves case-sensitivity of channel and global variables<br>
in the dialplan. Current behavior is as follows:<br>
<br>
1) Variables created in the dialplan by users are case-insensitive.<br>
Thus if the variable MARK were set, then ${MARK} and ${mark} would<br>
both evaluate to the set value.<br>
<br>
2) Variables used internally by Asterisk are case sensitive. So if<br>
some application set a variable called MARK, it would be different<br>
from a variable set by some application called mark.<br>
<br>
First off, this inconsistency is just weird. It would be much easier<br>
to just have things work one way or the other, not to have this mix.<br>
<br>
In addition, this can lead to some awkward situations. Consider that<br>
someone wants to use a specific SIP codec and so they set the<br>
variable SIP_CODEc to be "g722". Notice that the final 'c' is<br>
lowercase, presumably due to a typing error. The option would not<br>
take effect because chan_sip specifically checks the value of the<br>
case-sensitive ${SIP_CODEC}. What makes this weirder is that if<br>
the dialplan writer were to check ${SIP_CODEC} in the dialplan<br>
using a NoOp or Verbose call, then he would see the variable set<br>
to the value he set it to when he set ${SIP_CODEc} because the<br>
variable substitution is case-insensitive in the dialplan. This<br>
makes debugging the problem difficult.<br>
<br>
I propose that dialplan variables need to be made consistent in their<br>
evaluation. We need to choose either to be always case-sensitive or<br>
always case-insensitive. The problem is, I don't know which of these<br>
changes would have a larger effect on people. This is where I would<br>
like your feedback. Which way should it go?<br>
<br>
Some of you might be eager to propose a configuration option to<br>
decide which it should be. I'm sick of having hundreds of options<br>
in Asterisk to slightly tweak the behavior one way or another. This<br>
needs to go one way or the other, not be configurable.<br>
<br>
What I plan to do, no matter which way the vote goes, is to document<br>
on the wiki how things currently behave in Asterisk, to include the<br>
example I gave above (or something similar anyway). Depending how<br>
the vote goes, I will make the necessary code changes in Asterisk<br>
trunk. I will document the behavior change both in UPGRADE.txt and<br>
on the wiki.<br>
<br>
When considering which way you lean, consider that we really don't<br>
have much of a precedent to go on. For instance, dialplan applications<br>
are case-insensitive ("answer" and "Answer" and "ANSWER" are all the<br>
same). Dialplan functions, on the other hand, are case sensitive<br>
("HASH" would be evaluated properly but "hash" would not). My personal<br>
opinion is that all variable evaluations should be case-sensitive.<br>
I don't feel all that strongly about it though and could easily be<br>
swayed the other way if people respond overwhelmingly in opposition.<br>
<br>
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.<br>
<br>
Mark Michelson<br>
<br>
--<br>
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-dev</a><br>
<br></blockquote><div><br>+1 for case-sensitivity <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
--<br>
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-<u></u>users</a><br>
</blockquote></div><br>