[asterisk-bugs] [Asterisk 0014265]: Variable prefixed with '__' not inherited when call originated via AMI

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14265 
====================================================================== 
Reported By:                chris-mac
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14265
Category:                   Core/Channels
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 168551 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-17 09:41 CST
Last Modified:              2009-01-17 13:31 CST
====================================================================== 
Summary:                    Variable prefixed with '__' not inherited when call
originated via AMI
Description: 
Despite variable is prefixed with '__' it is no inherited by child channel,
when call is originated via AMI. How to reproduce:

extensions.conf
----------%<-------------------
[test1]
exten => _X.,1,NoOp(**** TEST 1 ****)
exten => _X.,n,Set(__X_GLOBAL_VAR=TEST)
exten => _X.,n,Dial(SIP/10000 at OpenSER,30)

[test2]
exten => _X.,1,NoOp(**** TEST 2 **** X_GLOBAL_VAR: ${X_GLOBAL_VAR})
exten => _X.,n,Hangup()
----------%<-------------------

AMI:
----------%<-------------------
Action: Originate
Channel: LOCAL/111 at test1/n
Context: test2
Exten: 222
Priority: 1
Callerid: Operator
Timeout: 30000
Account: 1
----------%<-------------------

Console output:
----------%<-------------------
  == Manager 'admin' logged on from 127.0.0.1
    -- Executing [111 at test1:1] NoOp("Local/111 at test1-1dbc;2", "**** TEST 1
****") in new stack
    -- Executing [111 at test1:2] Set("Local/111 at test1-1dbc;2",
"__X_GLOBAL_VAR=TEST") in new stack
    -- Executing [111 at test1:3] Dial("Local/111 at test1-1dbc;2",
"SIP/10000 at OpenSER,30") in new stack
  == Using SIP RTP CoS mark 5
    -- Called 10000 at OpenSER
    -- SIP/OpenSER-08205468 is ringing
    -- SIP/OpenSER-08205468 answered Local/111 at test1-1dbc;2
       > Channel Local/111 at test1-1dbc;1 was answered.
    -- Executing [222 at test2:1] NoOp("Local/111 at test1-1dbc;1", "**** TEST 2
**** X_GLOBAL_VAR: ") in new stack
    -- Executing [222 at test2:2] Hangup("Local/111 at test1-1dbc;1", "") in new
stack
  == Spawn extension (test2, 222, 2) exited non-zero on
'Local/111 at test1-1dbc;1'
  == Spawn extension (test1, 111, 3) exited non-zero on
'Local/111 at test1-1dbc;2'
  == Manager 'admin' logged off from 127.0.0.1
----------%<-------------------

NOTE: ${X_GLOBAL_VAR} is not inherited in [test2] context!
====================================================================== 

---------------------------------------------------------------------- 
 (0098087) Corydon76 (administrator) - 2009-01-17 13:31
 http://bugs.digium.com/view.php?id=14265#c98087 
---------------------------------------------------------------------- 
It's actually a consequence of the Local channel type.  The channel
variables ARE actually inherited, but they are inherited BEFORE the context
runs.  This is because the two parts of the Local channel are created at
the same time, so only the variables which you set in the callfile are able
to be inherited.  If you really want this, I would suggest that you either
use the SHARE() dialplan function to copy variables between the two halves
of the Local channel or you use the IMPORT() function in the second context
to pull in variables from the first.

For example:
Set(chan1=${CUT(CHANNEL,\;,1)}\;2)
Set(__X_GLOBAL_VAR=${IMPORT(${chan1},X_GLOBAL_VAR)}) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-17 13:31 Corydon76      Note Added: 0098087                          
======================================================================