# Asterisk Project : Case Sensitivity

Added by mmichelson , edited by mmichelson on Oct 29, 2012

Case sensitivity of channel variables in Asterisk is dependent on the version of Asterisk in use.

# Versions prior to Asterisk 12

This includes versions

- Asterisk 1.0.X
- Asterisk 1.2.X
- Asterisk 1.4.X
- Asterisk 1.6.0.X
- Asterisk 1.6.1.X
- Asterisk 1.6.2.X
- Asterisk 1.8.X
- Asterisk 10.X
- Asterisk 11.X

These versions of Asterisk follow these three rules:

- Variables evaluated in the dialplan are case-insensitive
- Variables evaluated within Asterisk's internals are case-sensitive
- Built-in variables are case-sensitive

This is best illustrated through the following examples

### Example 1: A user-set variable

In this example, the user retrieves a value from the AstDB and then uses it as the destination for a `Dial` command.

    [default]
    exten => 1000,1,Set(DEST=${DB(egg/salad)})
        same => n,Dial(${DEST},15)

Since the `DEST` variable is set and evaluated in the dialplan, its evaluation is case-insensitive. Thus the following would be equivalent:

    exten => 1000,1,Set(DEST=${DB(egg/salad)})
        same => n,Dial(${dest},15)

As would this:

    exten => 1000,1,Set(DeSt=${DB(egg/salad)})
        same => n,Dial(${dEsT},15)

### Example 2: Using a built-in variable

In this example, the user wishes to use a built-in variable in order to determine the destination for a call.

    exten => _X.,1,Dial(SIP/${EXTEN})

Since the variable `EXTEN` is a built-in variable, the following would not be equivalent:

    exten => _X.,1,Dial(SIP/${exten})

The lowercase `exten` variable would evaluate to an empty string since no previous value was set for `exten`.

### Example 3: A variable used internally by Asterisk

In this example, the user wishes to suggest to the SIP channel driver what codec to use on the call.

    exten => 1000,Set(SIP_CODEC=g729)
    same => n,Dial(SIP/1000,15)

`SIP_CODEC` is set in the dialplan, but it gets evaluated inside of Asterisk, so the evaluation is case-sensitive. Thus the following dialplan would not be equivalent:

    exten => 1000,Set(sip_codec=g729)
        same => n,Dial(SIP/1000,15)

This can lead to some rather confusing situations. Consider that a user wrote the following dialplan. He intended to set the variable `SIP_CODEC` but instead made a typo:

    exten => 1000,Set(SIP_CODEc=g729)
        same => n,Dial(SIP/1000,15)

As has already been discussed, this is not equivalent to using `SIP_CODEC`. The user looks over his dialplan and does not notice the typo. As a way of debugging, he decides to place a `NoOp` in the dialplan:

    exten => 1000,Set(SIP_CODEc=g729)
        same => n,NoOp(${SIP_CODEC})
        same => n,Dial(SIP/1000,15)

When the user checks the verbose logs, he sees that the second priority has evaluated `SIP_CODEC` to be "g729". This is because the evaluation in the dialplan was done case-insensitively.

# Asterisk 12 and above

Due to potential confusion stemming from the policy, for Asterisk 12, it was proposed that variables should be evaluated consistently. E-mails were sent to the Asterisk-developers and Asterisk-users lists about whether variables should be evaluated case-sensitively or case-insensitively. The majority opinion swayed towards case-sensitive evaluation. Thus in Asterisk 12, all variable evaluation, whether done in the dialplan or internally, will be case-sensitive.

For those who are upgrading to Asterisk 12 from a previous version, be absolutely sure that your variables are used consistently throughout your dialplan.