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-0600 | Date Closed: | 2011-06-07 14:00:42 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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. |