Skip to content

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.