Summary:ASTERISK-17178: CHANNEL variable is set incorrectly by Asterisk
Reporter:Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech)Labels:
Date Opened:2010-12-29 02:22:38.000-0600Date Closed:2011-06-07 14:00:42
Versions:Frequency of
Description:Ever since I installed version of Asterisk, the CHANNEL variable appears to behave differently that before - specifically saying: it now doesn't return the technology type, and the the ID appears to be a little chopped.


Previously, when accessing the ${CHANNEL} variable via the dialplan, I would receive and indicator such as:

SIP/sip.greenfieldtech.net-0000000c - which is the channel name

Now, if I access via ${CHANNEL} I would only receive the follwing:

c - which doesn't tell me much to be honest.

Unless I've missed a doc change somewhere, this looks like a bug to me.
Comments:By: John Covert (jcovert) 2010-12-29 07:38:15.000-0600

I use the ${CHANNEL} variable extensively, and haven't noticed any problem in any 1.6 versions.

Could this be the way you are using it in your dialplan?

Could you post a few lines around your usage?

By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2011-01-01 01:12:27.000-0600

Here's an extract from my extensions.ael:

_X. => {

The INBOUND_CHANNEL variable is populated only with the ID portion of the CHANNEL data.

By: Tilghman Lesher (tilghman) 2011-01-03 10:44:14.000-0600

This isn't a problem with the CHANNEL variable; it's a problem with AEL.  Try doing the following:


The issue is that AEL does no semantic parsing of the input line; it leaves that to the dialplan.  Instead, it wraps all values with the expression delimiters, so a channel name actually looks to the expression parser as a complex math problem:  SIP divided by (name) minus [identifier].  This is garbage, of course, so you're left with the somewhat cryptic identifier.  Quoting the value should ensure that it is not interpreted as a math problem.