[asterisk-users] Unsetting Global Vars

[Johann Hoehn]

Hi,

Thanks for your response.  I've kinda worked around the situation, but
still need to do more testing on it.

Yuan LIU wrote:
>> From: Johann Hoehn <johann.hoehn at ecommerce.com>
>> Date: Wed, 28 Mar 2007 16:45:28 -0500
>>
>> How do I clear a global variable for good?  I have a situation of
>> needing to use global variables to aide in channel communication, but
>> will be changing the name within a defined scope.
>
> Not sure if I understand what "clear a variable" mean.  I don't think
> there is a concept like "unset" in Asterisk.  If you want to make sure
> a used variable does not cause side effects, simply set it to null
> string.
I want to remove it from memory.  I do not want Asterisk to keep
allocating more and more ram for global variables.  Does setting it to a
null string remove it from memory?  Channel variables are freed when the
channel is gone.  When does a global variable get freed?
>
>> Additional Background...
>> I want to get a variable from a channel (child) that is created by
>> another channel (parent), however the execution of the parent channel
>> does not continue until the child channel is gone.  So I want to use a
>> global variable as 'scratch' space and later the parent to grab it.
>> Basically I need to be able to do the opposite of variable inheritance.
>> I need to propagate a variable status up the channel chain instead of
>> down.
>
> I feel the need to propagate a variable up the chain from time to
> time.  But I still don't understand why this is necessary in your
> case, much less how this relates to the need to unset.  Maybe you can
> give more specifics, even pseudo code.
It's related to a quality assurance feature that I am working on.  I've
wrapped part of the call in a local channel and having Asterisk call
itself with a dial statement to continue execution afterward.  The local
channel while it exists joins the caller to a queue and later to an
agent.  I want to be able to track that agent they talk to when the
execution returns from that local call.  This is the part that will
invoke the AGI script that handles the QA feedback portion.

Very rough pseudo code for Asterisk 1.2.x

[menu]
exten => s,1,Set(__CURRENT_CHANNEL=GLOBAL_${CHANNEL})
exten => s,2,Background(menu)

exten => 1,1,Dial(Local/support at menu/n,,g)
exten => 1,2,AGI(qa-feedback)

exten => support,1,Queue(support,t)

[queue]
exten => 100,1,Set(${CURRENT_CHANNEL}=${EXTEN})
exten => 100,2,Dial(SIP/${EXTEN},,to)

This is very stripped down, but shows the core logic.  I set a channel
variable that will be inherited by all future bridged channels that
specifies which global variable to store the agent id that got the
call.  If the agent doesn't answer then it will call another agent an
overwrite the variable.  The last contents of that variable are the
agent they spoke with.  The AGI script looks at the channel variable to
see which global variable will have the information it needs.

After the AGI script gets it's information, I originally wanted to
remove the global variable from memory.  I've since decided to change
the implementation to use a variable based on the zap channel number the
call comes in on.  This will result in a fixed amount of memory being
used and prevent an ever growing list of global variables.

All of this assumes the agent hangs up and not the customer.  Not
included in the psuedo code is another AGI script that is called before
they join the queue to determine if QA should be done.  Additional
messages telling the customer how the system works are also not shown.

We are using call back agents.  During the process there are up to 5
channels bridged together.  The zap channel the customer calls in on, a
local channel to keep them around after the agent hangs up, another
local channel to contact the agent which optimizes itself out of the
loop, the agent channel itself, and finally the sip channel that the
employee is on.  It's nasty, but mostly functional.  I just need to work
out the issue for the data on who they spoke to going all the way back
to the first local channel.  To avoid repetition there are also several
macros that are invoked during the various stages, which further adds to
the nested mess.  MixMonitor() when called in one of those macros causes
Asterisk to crash instantly.
>
> Yuan Liu
>
>> -- 
>> Johann Hoehn
>> Project Coordinator, Administration
>> Direct: 270-707-2040 x 4011
>> Ecommerce Corporation (www.ecommerce.com)
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users


-- 
Johann Hoehn
Project Coordinator, Administration
Direct: 270-707-2042
Ecommerce Corporation (www.ecommerce.com)