[asterisk-dev] Problem with chan_local variables, optimization, and timing

[Tim Ringenbach]

The way chan_local decides when to optimize itself out is very
nondeterministic, (based on incoming frames and the ability to get locks),
and has caused me plenty of problems in the past with whether or not certain
parts of the dialplan are executed on Local or real channels and what
channel variables will be available.. What I sometimes do is use the G
option to dial to throw away the local channel on purpose, but that only
makes sense in certain circumstances.

On Fri, Jan 29, 2010 at 8:29 AM, Geoffrey Mina <geoffreymina at gmail.com>wrote:

> That doesn't really answer the question as to why a 250ms pause in my
> FastAGI script provides a 'fix' to the problem.  The pause would lead
> me to believe that there is a timing bug in the Local channel
> optimizing itself out of the chain.
>
>
>
> On Fri, Jan 29, 2010 at 8:25 AM, Olle E. Johansson <oej at edvina.net> wrote:
> >
> > 29 jan 2010 kl. 14.19 skrev Geoffrey Mina:
> >
> >> Hello,
> >> I am not sure exactly how to trouble shoot this one, and until I have
> >> more detailed information I would rather not open a bug report.  I
> >> have a problem with channel variables created on a local channel never
> >> getting copied to the SIP channel after Local optimizes itself out.  I
> >> am running 1.4.26.1 right now.  I have checked chan_local extensively
> >> and don't see any work on a fix for this type of problem through
> >> 1.4.29, so I'm pretty sure the bug still exists.
> >>
> >> Here is what I am doing to recreate this problem:
> >>
> >> 1) Manager Originate Local at blah with variables set in the command
> >> 2) Dial(SIP/blah2,30) from the [blah] context
> >> 3) Call FastAGI on Answer
> >> 4) The FastAGI script performs some DB lookups and sets context,
> >> extension, priority and promptly exits.
> >> 5) The channel exits the FastAGI script and moves to the destination
> >> context/extension
> >>
> >> At this point, none of my variables exist on the SIP channel.  "core
> >> show channels" shows a channel type of "Local" instead of "SIP".  It
> >> seems that the 'redirect' after the FastAGI may have clobbered the
> >> optimization process.
> >>
> >> All I have to do to work around the bug is insert a 250ms sleep
> >> between step 3 and 4.  I am guessing this short pause gives the Local
> >> channel enough time to optimize itself out and copy all of the
> >> variables into the destination SIP channel.
> >>
> >> If anyone can provide any info on how I should word this in the Bug
> >> Tracker, i would really appreciate it.
> >>
> > Have you tried prefixing the variable names with two underscores?
> > __MYVARIABLE
> >
> > With one underscore, a channel variable is inherited once. With two,
> > as long as there's a channel spawned, we copy the variable.
> >
> > /O
> >
> > --
> > _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100129/ae2a82d3/attachment.htm