On Wed, Jan 4, 2017 at 1:45 PM, Kirill Katsnelson <[email protected]> wrote:
> On 170103 2114, Richard Mudgett wrote: > >> On Tue, Jan 3, 2017 at 9:38 PM, Kirill Katsnelson <[email protected]> >> 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@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@context-random,1 and ,2 (random is a 4 digit randomly generated hex number) 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) 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) Richard
-- _____________________________________________________________________ -- 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
