With Asterisk 1.8 we were relying on the behavior of Originate with
Local channels as mentioned in
https://issues.asterisk.org/jira/browse/ASTERISK-17239. This no longer
works in Asterisk 13.
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.
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.
-kkm
--
_____________________________________________________________________
-- 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
