[asterisk-dev] Variable Inheritance,
Setting Channel Variables outside of current context
Tilghman Lesher
tilghman at mail.jeffandtilghman.com
Wed May 17 14:43:22 MST 2006
On Wednesday 17 May 2006 15:58, Peter Beckman wrote:
> On Wed, 17 May 2006, Kevin P. Fleming wrote:
> In this situation, the 'parent context' would be 'foo', and the
> 'child context' would be 'macro-bar' or just 'bar' for variable
> inheritance discussions? Channel variables set in foo such as _FOO
> and __FOO would be inherited by the macro called by the Dial() in
> 'foo' context, right?
In that case, what you said was incorrect. There is no "child" or
"parent" context, when it comes to setting variables. Variables which
you set in Macro (other than the special ARG variables used for passing
parameters) will still be set when Macro returns.
> > Macros can return values back to their callers via MACRO_RESULT,
> > but the rest of what you said appears to be true and expected
> > behavior.
>
> It seems that the only way to communicate between channels is via
> Global variables. In order to prevent overwriting them while
> multiple calls are in progress, a unique name for the Global variable
> is required.
If you wanted to do this directly, yes. A much better approach would
be to write a value into a database, for retrieval at the appropriate
time by another channel.
> Once a Global variable is set, how do you "unset" that Global
> variable, in order to avoid overwriting and variable messyness?
Setting it to an empty string effectively resets the value.
> I'll put the inter-channel communication into Mantis as a feature
> request.
There's no need. A database does this just fine already, in a
completely predictable way. Setting another channel's variables
asynchronously is not a smart idea. For example, if one channel
is using ${i} to iterate through a loop and you asynchronously change
the value of ${i} halfway through the loop, the dialplan is going to do
something unpredictable and completely unreproduceable.
--
Tilghman
More information about the asterisk-dev
mailing list