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

[Richard Mudgett]

On Wed, Jan 4, 2017 at 1:45 PM, Kirill Katsnelson <kkm at smartaction.com>
wrote:

> On 170103 2114, Richard Mudgett wrote:
>
>> 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.
>>>
>>> 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, thanks for the explanation and notes. I pretty much suspected
> that I was relying on undefined behavior.
>
> 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').
>
>   P = "${CHANNEL(name):0:-1}2";  // Local/Sample at test-local-00000007;2
>   Q = "${IMPORT(${P},QUUX)}";
>
> 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?


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.

v1.4 = Local/exten at context-random,1 and ,2  (random is a 4 digit randomly
generated hex number)

v1.6.0 = Local/exten at context-random;1 and ;2 (comma changed to semicolon I
suspect because the application parameter delimiter changed from the pipe
to the comma)

v1.8 = Local/exten at 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)

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