Channelvariables not set in Newchannel event and DADHIChanne

I’d like to receive channelvariables in my AMI-events. Unfortunately this seems not to work for Newchannel- and DAHDIChannel- events caused by an Originate.
In manager.conf I putted the following line: channelvars=CHANNEL(uniqueid),AJ_TRACE_ID . Only CHANNEL(uniqueid) appears to work for every event.

This seems like a bug to me, or is there a purpose for this behaviour?
Anyway, receiving channelvariables in Newchannel- and DAHDIChannel- events would be a very useful functionality for my application.

Best regards,
Arjan Kroon

Below you’ll find some information about my testcase.

Asterisk 1.8.15

settings in manager.conf



  1. originate with __AJ_TRACE_ID=AJ_ORIGINATE_2
  2. Newchannel event received without AJ_TRACE_ID set
  3. DAHDIChannel event received without AJ_TRACE_ID set
  4. NewAccountCode event received and AJ_TRACE_ID is set

action: Originate
actionid: 608078545_40#AJ_ORIGINATE_2
async: true
variable: CALLERPRES()=prohib
variable: dcoModURL=
variable: dcoCoreURL=http://localhost:8080/DijkConnectIVRWebApp/services/TestService
variable: dcoLicenseeId=39
variable: dcoApplicationReference=
variable: dcoPresentationNumber=
variable: dcoCallId=TESTMOBILLION3
variable: dcoRecordingStorageReference=
variable: dcoRedirectCallId=
variable: dcoSetupTimedOut=SETUP
variable: dcoAgentId=100
variable: dcoDestinationNumber=0031650747314
variable: dcoRecordingMode=
variable: dcoConnectionTimeOut=60
variable: dcoUserRole=OUTBOUND_AGENT
variable: dcoRecordingProcessingURL=
variable: dcoDialMode=AGENT
variable: dcoRingTimeOut=60
variable: dcoRecordingStorageDuration=
variable: dcoBillingReference=t=mobtest
priority: 1
exten: s
context: setup_agent
channel: DAHDI/g1/0031650747314
timeout: 130000

message : Originate successfully queued
response : Success
actionid : 608078545_40#AJ_ORIGINATE_2

Event: Newchannel
Privilege: call,all
SequenceNumber: 1877
File: channel.c
Line: 1349
Func: __ast_channel_alloc_ap
Channel: DAHDI/i1/0031650747314-3
ChannelState: 1
ChannelStateDesc: Rsrvd
Context: incoming
ChanVariable(DAHDI/i1/0031650747314-3): CHANNEL(uniqueid)
ChanVariable(DAHDI/i1/0031650747314-3): AJ_TRACE_ID=

– above: AJ_TRACE_ID not set

Event: DAHDIChannel
Privilege: call,all
SequenceNumber: 1878
File: chan_dahdi.c
Line: 2141
Func: dahdi_ami_channel_event
Channel: DAHDI/i1/0031650747314-3
DAHDISpan: 1
DAHDIChannel: 1
ChanVariable(DAHDI/i1/0031650747314-3): CHANNEL(uniqueid)
ChanVariable(DAHDI/i1/0031650747314-3): AJ_TRACE_ID=

– above: AJ_TRACE_ID not set

action: GetVar
actionid: 608078545_41#
variable: AJ_TRACE_ID
channel: DAHDI/i1/0031650747314-3

response : Success
actionid : 608078545_41#
value : AJ_ORIGINATE_2
variable : AJ_TRACE_ID

Event: NewAccountCode
Privilege: call,all
SequenceNumber: 1900
File: cdr.c
Line: 1010
Func: ast_cdr_setaccount
Channel: DAHDI/i1/0031650747314-3
ChanVariable(DAHDI/i1/0031650747314-3): CHANNEL(uniqueid)
ChanVariable(DAHDI/i1/0031650747314-3): AJ_TRACE_ID=AJ_ORIGINATE_2

– above: AJ_TRACE_ID set


Does anybody help me further with this problem?


Arjan Kroon
Mobillion BV

This seems to be a new feature, which is probably little used, so maybe no-one here is using it.

However, subject to actually reading the code, I would expect the channel allocation and the setting of the variables to be two distinct operations, so the variables will not have been set at the time of the new channel and dahdi channel events. Changing that would be considered a feature request, not a bug, so should be made on the developer mailing list not on the bug tracker.

Incidnteally, CHANNEL(uniqueid) is a function, although most places in Asterisk which say they access variables will also access funtions.

Hi David,

I think you are right. Channel allocation and the setting of the variables are distinct operations.
When I add ‘dialplan’ to the ‘read’ property in manager.conf, I’ll receive separate SetVar events for the variables that I added to my Originate Event.
I’ll receive these, after receiving the NewChannel event. Thus channel allocation and setting variables are distinct operations, although they are caused by just one Originate event.

The issue can be closed; it is indeed not a bug.

Best regards,
Arjan Kroon