<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 4, 2017 at 1:45 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 170103 2114, Richard Mudgett wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Tue, Jan 3, 2017 at 9:38 PM, Kirill Katsnelson <<a href="mailto:kkm@smartaction.com" target="_blank">kkm@smartaction.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With Asterisk 1.8 we were relying on the behavior of Originate with Local<br>
channels as mentioned in <a href="https://issues.asterisk.org/ji" rel="noreferrer" target="_blank">https://issues.asterisk.org/ji</a><br>
ra/browse/ASTERISK-17239. This no longer works in Asterisk 13.<br>
<br>
</blockquote></span><span class="">
You were definitely depending upon an implementation detail and some luck<br>
on when the optimization would happen.  Asterisk versions before v12 used<br>
masquerades to implement local channel optimizations.  The channel<br>
executing dialplan before the wait turns into a different channel after the<br>
wait because of the masquerade.  The wait simply made the local channel<br>
optimization more likely to happen during the wait because the optimization<br>
could happen any time during the exchange of media frames.  Asterisk v12+<br>
no longer optimizes local channels this way.  Instead it moves a channel<br>
from one bridge to another.  (See discussion on<br>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-26681" rel="noreferrer" target="_blank">https://issues.asterisk.org/ji<wbr>ra/browse/ASTERISK-26681</a>)<br>
</span></blockquote>
<br>
Richard, thanks for the explanation and notes. I pretty much suspected that I was relying on undefined behavior.<br>
<br>
I am thinking of using the IMPORT() function to get channel variables from the second "half" of the Local channel. That works, but I have to rely on knowing the naming scheme of the channels: drop the last character, which is the '1' after the ';', and then add a '2').<br>
<br>
  P = "${CHANNEL(name):0:-1}2";  // Local/Sample@test-local-000000<wbr>07;2<br>
  Q = "${IMPORT(${P},QUUX)}";<br>
<br>
But this also a bit hackish. Is this naming scheme not going to change so I can rely on it? Can you maybe think of a more canonical/kosher/reliable approach?</blockquote><div><br></div><div>I don't think it will change anymore.  It looks like the local channel name scheme has changed some over the years but the last character has been a 1 or a 2 to differentiate the two paired channels.  Local channels by their nature have to be created in pairs so if the scheme does change I doubt it will be difficult to adjust anyway.  In fact as recently as v11, Asterisk itself did a similar local channel name manipulation to get the paired channel in the DTMF features code.<br><br></div><div>v1.4 = Local/exten@context-random,1 and ,2  (random is a 4 digit randomly generated hex number)<br><br></div><div>v1.6.0 = Local/exten@context-random;1 and ;2 (comma changed to semicolon I suspect because the application parameter delimiter changed from the pipe to the comma)<br><br></div><div>v1.8 = Local/exten@context-sequence;1 and ;2 (sequence is a 8 digit incrementing hex number counting each local channel pair created.  Changed to a sequence number because it was possible for random to create duplicate active channel names)<br></div><div><br></div><div>Richard<br></div></div><br></div></div>