Summary:ASTERISK-05762: dial-out (pbx_spool) and variable inheritance problems
Reporter:jalsot (jalsot)Labels:
Date Opened:2005-12-02 10:46:29.000-0600Date Closed:2005-12-03 14:27:10.000-0600
Versions:Frequency of
Description:The dial out through Local channel does not inherit variables. After call establishment the local channel is torn down, but it's variables are not inherited to the incoming context's channel.

Example result:
The result:
   -- Attempting call on Local/1@mytest-out for 1@mytest-in:1 (Retry 1)
   -- Executing NoOp("Local/1@mytest-out-88e0,2", "hello") in new stack
   -- Executing Dial("Local/1@mytest-out-88e0,2",
"Zap/g1/061111111|10|H|g") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called g1/061111111
   -- Zap/1-1 is proceeding passing it to Local/1@mytest-out-88e0,2
Dec  2 17:28:18 NOTICE[13079]: channel.c:2412 __ast_request_and_dial:
Don't know what to do with control frame 15
   -- Zap/1-1 answered Local/1@mytest-out-88e0,2
      > Channel Local/1@mytest-out-88e0,1 was answered.
   -- Executing NoOp("Local/1@mytest-out-88e0,1", "") in new stack
   -- Executing Wait("Local/1@mytest-out-88e0,1", "20") in new stack
 == Spawn extension (mytest-out, 1, 2) exited non-zero on

As you can see, the MYVAR1 variable did not inherit, which breaks my
dial-out application. This way it worked well for a long time, however
an upgrade to recent HEAD version broke things.

****** STEPS TO REPRODUCE ******

exten => 1,1,NoOp(${MYVAR1})
exten => 1,n,Wait(20)
exten => 1,n,Hangup()

exten => 1,1,NoOp(${MYVAR1})
exten => 1,n,Dial(Zap/g1/061111111,10,H|g)

my test dial.out file:
Channel: Local/1@mytest-out
MaxRetries: 0
Context: mytest-in
Extension: 1
Priority: 1
Set: __MYVAR1=hello


Unfortunately I don't know which version worked fine, I didn't use this feature for a long time and just now I upgraded... About a half year old CVS HEAD worked well for sure.
Comments:By: Tilghman Lesher (tilghman) 2005-12-02 11:07:15.000-0600

Two related fixes went into the trunk last night, one of which is likely to fix your issue.  Please update to revision 7283 and try again.

By: Tilghman Lesher (tilghman) 2005-12-03 14:27:10.000-0600

I'm going to close this one out; reopen if you're still having trouble with revision 7283 or later.