<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 3, 2017 at 9:38 PM, Kirill Katsnelson <span dir="ltr"><<a href="mailto:kkm@smartaction.com" target="_blank">kkm@smartaction.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">With Asterisk 1.8 we were relying on the behavior of Originate with Local channels as mentioned in <a href="https://issues.asterisk.org/jira/browse/ASTERISK-17239" rel="noreferrer" target="_blank">https://issues.asterisk.org/ji<wbr>ra/browse/ASTERISK-17239</a>. This no longer works in Asterisk 13.<br>
<br>
Specifically, when a call is originated (e. g. via AMI) between "channel" Local/x@local-side and "extension" y@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@remote-side in the example), after an infinitesimal Wait(), as the ticket explains.<br>
<br>
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.<br>
<br>
Local channel optimization does not occur in this example, as there is only one bridge (and the LocalBridge between the Local channels)<br>
<br>
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.<br></blockquote><div><br></div><div>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 <a href="https://issues.asterisk.org/jira/browse/ASTERISK-26681">https://issues.asterisk.org/jira/browse/ASTERISK-26681</a>)<br><br></div><div>Richard<br></div></div><br></div></div>