Summary:ASTERISK-00236: chan_local does not correctly sandbox variables
Reporter:John Todd (jtodd)Labels:
Date Opened:2003-09-08 18:21:35Date Closed:2011-06-07 14:05:13
Versions:Frequency of
Description:chan_local will switch between environments after a call is answered by an application or Dial, leading to terrible confusion in what variables are to be used by certain applications.  This makes chan_local almost (but not quite) unusable for anything complex that involves variables.  I never did get a response to my mail to -users if this was the expected behavior or not, so I will assume "not" and report it as a bug.


I'm having some difficulty with chan_local dial requests.  It seems that when a chan_local call is picked up, that the native bridge "pops" the environment back to the settings of the original call.  This is unexpected and leads to very frustrating results.   My example below is a very distilled sample of a much more complex dialplan problem I'm having with chan_local, but it illustrates the point.

In my example below, the variable MYTEST is set in the "original" call.  Then, the call is handed to chan_local at a different dialed number.  Then, as expected, a new environment is set up, and I cannot see the value I set for MYTEST in this new environment - so far,so goo.  I create another variable called OTHERTEST in this new environment.

However, as soon as the "Answer" application is called, I see the Local channel hangs up.   Suddenly, the environment of the call is handed back to the original call's settings!  This seems counter-intuitive, since my dial plan is following a path and expecting variable settings that may not be available in the original call's environment.  I would think that Local calls would be "sandboxed" such that they cannot see the environments from other calls, since that is how all the other channel types work...

Is this the expected behavior?


Calls are handed from my SIP phone directly to [local].  The user at SIP extension 2209 is not registered, so the "Busy" (priority 105 in this case) routines will be called.

exten => 2213,1,SetVar(MYTEST=ishouldnotseethis)  
exten => 2213,2,Dial(Local/2209@local)

exten => 2209,1,SetVar(OTHERTEST=goodness)
exten => 2209,2,NoOp(${MYTEST})
exten => 2209,3,NoOp(${OTHERTEST})
exten => 2209,4,Dial(SIP/2209)
exten => 2209,105,Answer
exten => 2209,106,Playback(invalid)
exten => 2209,107,NoOp(${MYTEST})
exten => 2209,108,NoOp(${OTHERTEST})
exten => 2209,109,Hangup

   -- Executing SetVar("SIP/2203-2496", "MYTEST=ishouldnotseethis") in new stack
   -- Executing Dial("SIP/2203-2496", "Local/2209@local") in new stack
   -- Called 2209@local
   -- Executing SetVar("Local/2209@local-2af6,2", "OTHERTEST=goodness") in new stack
   -- Executing NoOp("Local/2209@local-2af6,2", "") in new stack
   -- Executing NoOp("Local/2209@local-2af6,2", "goodness") in new stack
   -- Executing Dial("Local/2209@local-2af6,2", "SIP/2209") in new stack
 == Everyone is busy at this time
   -- Executing Answer("Local/2209@local-2af6,2", "") in new stack
   -- Local/2209@local-2af6,1 answered SIP/2203-2496
   -- Executing Playback("Local/2209@local-2af6,2", "invalid") in new stack
   -- Playing 'invalid'
 == Spawn extension (local, 2213, 2) exited non-zero on 'Local/2209@local-2af6,2<ZOMBIE>'
ms1*CLI> [I hear the recording on my SIP phone at this point]
   -- Executing NoOp("SIP/2203-2496", "ishouldnotseethis") in new stack
   -- Executing NoOp("SIP/2203-2496", "") in new stack
   -- Executing Hangup("SIP/2203-2496", "") in new stack
 == Spawn extension (local, 2209, 109) exited non-zero on 'SIP/2203-2496'
Comments:By: Mark Spencer (markster) 2003-10-07 21:15:05

This is not a bug, it has to do with chan_local optimizing itself out of the path.  However, I've added a "/n" parameter you can add to your local channel to cause it to not optimize.