Skip to end of metadata
Go to start of metadata

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.

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.

  • No labels