[Home]

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
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Ever since I installed version 1.6.2.14 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.

****** ADDITIONAL INFORMATION ******

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. => {
__GLOBAL_T1=${EPOCH};
__CONTINUED_CALL=FALSE;
__T1=${EPOCH};
TIMEOUT(digit)=3;
TIMEOUT(response)=3;
__INBOUND_DID=${EXTEN};
__INBOUND_CHANNEL=${CHANNEL};
__INBOUND_CALLERID=${CALLERID(num)};
.
.
.
.
.
hangup();
       };

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:

__INBOUND_CHANNEL="${CHANNEL}";

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.