asterisk users - Oct 2012 - 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

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

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

On 10/1/2012 5:15 PM, Mark Michelson wrote:
> ("HASH" would be evaluated properly but "hash" would
not). My personal
> opinion is that all variable evaluations should be case-sensitive.
+1

case insensitivity to accommodate carelessness is evil.  much easier for 
NoOp to tell us SIP_CODEC is unset, regardless of misspellings.

I could be convinced to vote up 1s for I, 0s for O, and 3 for E.  So 
SIP_CODEC, S1P_C0D3C, and SiP_cOdEC would all evaluate equally.  The 
next step would be to appease the English spelling reform people by 
allowing SIP_KODEK too.  :p

-- 

Jeremy Kister
http://jeremy.kister.net./

On 10/1/2012 4:15 PM, Mark Michelson wrote:
> 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
>
Mark,

First you need to consider compatibility with currently supported
packages which include auto-generated dial plans like AsteriskNow, PIAF,
etc.  If you plan to break their functionality you need to at least
coordinate your move with the maintainers.

Then you may want to consider backwards compatibility with packages
still widely used but not actively supported any more like Trixbox.
Maybe not the best example as their WEB site says, "This is the current
stable release based on Asterisk 1.6."

If you really want to make it not settable (and this is big, not a minor
change, if I were you I would definitely make it settable) then I would
go with case-insensitive as it allows for various custom notations, e.g.
Hungarian notation in naming of custom variables without a later
painstaking investigation whether "nCallID" is equal to
"nCallId" or
not.  Consider the fact, most of the dial plan debugging happens in the
logs or in the Console Screen.  Someone may want to spell "nCALLID"
just
to be able to see the difference between Latin "l" and "I"
where the
first one is "L" lower case and the second one is "i" upper
case.

Just my 2 cents.

-Vladimir

On Mon, Oct 1, 2012 at 4:15 PM, Mark Michelson <mmichelson at
digium.com>wrote:
> Hi!
>
> I've been confronted with an interesting issue to resolve. The
> issue is located here:
>
> <snip>
> 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
>
My vote is to maintain the case sensitivity as the way it is now - user
generated variables are case-insensitive, and asterisk-generated variables
are case sensitive.  I think breaking the existing behavior would be
causing more problems than it solves.

-- 
Thanks,
--Warren Selby, dCAP
http://www.SelbyTech.com <http://www.selbytech.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20121002/a9285f62/attachment-0001.htm>

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>

Il 01/10/2012 23.15, Mark Michelson ha scritto:
> https://issues.asterisk.org/jira/browse/ASTERISK-20163
>
> The issue involves case-sensitivity of channel and global variables
> in the dialplan.
+1 for case-sensitive variables everywhere.

I'm glad to see that this inconsistency issue will be finally addressed.
Whatever the final result it is important that there is **consistency**.

I believe also that from a programming perspective may be a small gain 
in parsing efficiency using case-sensitive variables.


-- 
TeeBX VoIP communication platform (coming soon)
http://code.google.com/p/teebx/
-----------------------------------------------
Lightweight++ Business Friendly++ Open++

On Tuesday 02 Oct 2012, Mark Michelson wrote:
>[snip]
> 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.
All dialplans that I've written so far will work fine in a case-
sensitive environment.  However, I appreciate that there will be legacy 
dialplans around that are, for one reason or another, case-inconsistent.  
To expect them all to switch to the new way of doing things immediately 
is impractical and unfair.

So here's the proposal: make case-insensitivity a configuration option 
for one or two releases.  Document the option (both externally and in 
the configuration file) with large warnings about how switching it on is 
DEPRECATED and how it will VANISH IN A FUTURE RELEASE.

That will suit the people who do not wish to conform (they will not 
upgrade), the people who want to conform but need time (will have a few 
months to fix and test while still being able to use the latest Asterisk 
features) and the people who are already conformant (don't need to do 
anything).

In short, my vote goes for case-sensitivity with a grace period for 
switching over.

Regards,

-- Raj
-- 
Raj Mathur                          || raju at kandalaya.org   || GPG:
http://otheronepercent.blogspot.com || http://kandalaya.org || CC68
It is the mind that moves           || http://schizoid.in   || D17F