[asterisk-dev] Local channel variable propagation: expired hack or a bug?

[Richard Mudgett]

On Tue, Jan 3, 2017 at 9:38 PM, Kirill Katsnelson <kkm at smartaction.com>
wrote:

> With Asterisk 1.8 we were relying on the behavior of Originate with Local
> channels as mentioned in https://issues.asterisk.org/ji
> ra/browse/ASTERISK-17239. This no longer works in Asterisk 13.
>
> Specifically, when a call is originated (e. g. via AMI) between "channel"
> Local/x at local-side and "extension" y at remote-side, the local-side runs on
> the Local/xxx;1 channel, and sets some variables in the dialplan. The old,
> 1.8 behavior, was to propagate the variables to the Local/xxx;2 channel
> when it gets it's turn to execute dialplan (y at remote-side in the
> example), after an infinitesimal Wait(), as the ticket explains.
>
> This does not happen anymore in Asterisk 13. In fact, no variables are set
> on the remote-side, Local/xxx;2 channel; none of BRIDGEPEER,
> DIALEDPEERNUMBER, SIPCALLID from the ticket flow are set.
>
> Local channel optimization does not occur in this example, as there is
> only one bridge (and the LocalBridge between the Local channels)
>
> So my question is, did we use an undocumented hack, and therefore must
> find a different solution, or the current implementation has a bug that
> should be fixed? I honestly cannot remember where I got the idea initially,
> and whether or not it was documented.
>

You were definitely depending upon an implementation detail and some luck
on when the optimization would happen.  Asterisk versions before v12 used
masquerades to implement local channel optimizations.  The channel
executing dialplan before the wait turns into a different channel after the
wait because of the masquerade.  The wait simply made the local channel
optimization more likely to happen during the wait because the optimization
could happen any time during the exchange of media frames.  Asterisk v12+
no longer optimizes local channels this way.  Instead it moves a channel
from one bridge to another.  (See discussion on
https://issues.asterisk.org/jira/browse/ASTERISK-26681)

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170103/066b6b81/attachment.html>