> On Aug. 11, 2014, 8:54 a.m., Matt Jordan wrote: > > /branches/12/main/manager_channels.c, lines 187-192 > > <https://reviewboard.asterisk.org/r/3899/diff/1/?file=66454#file66454line187> > > > > The optional presence of a Forwarded channel should get noted in the > > CHANGES file for 12.5.0.
And since this patch is rather handy (it makes Forwards work via AMI/ARI; it makes the channel variables more useful in ARI and the retrieval of channel information consistent); I'd say let's get this in for the 13 beta. Which means it probably should go in today. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3899/#review13065 ----------------------------------------------------------- On Aug. 8, 2014, 3:26 p.m., Mark Michelson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3899/ > ----------------------------------------------------------- > > (Updated Aug. 8, 2014, 3:26 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24134 and ASTERISK-24138 > https://issues.asterisk.org/jira/browse/ASTERISK-24134 > https://issues.asterisk.org/jira/browse/ASTERISK-24138 > > > Repository: Asterisk > > > Description > ------- > > This patch addresses a few issues: > > 1) The order of Dial events have been changed when performing a call forward. > The order has now been altered to > 1) Dial begins dialing channel A. > 2) When A forwards the call to B, we issue the dial end event to channel > A, indicating the dial is being canceled due to a forward to B. > 3) When the call to channel B occurs, we then issue a new dial begin to > channel B. > > 2) Call forwards are now reported on the calling channel, not the peer > channel. > > 3) AMI DialEnd events have been altered to display the extension the call is > being forwarded to when relevant. > > 4) You can now get the values of channel variables for channels that are not > currently in the Stasis application. This brings the retrieval of channel > variables more in line with the rest of channel read operations since they > may be performed on channels not in Stasis. > > Note that this patch was mostly written by Matt Jordan. I made a few > alterations to it before posting it here. > > > Diffs > ----- > > /branches/12/res/stasis/control.c 420558 > /branches/12/res/stasis/app.c 420558 > /branches/12/res/ari/resource_channels.c 420558 > /branches/12/main/stasis_channels.c 420558 > /branches/12/main/manager_channels.c 420558 > /branches/12/include/asterisk/stasis_app.h 420558 > /branches/12/apps/app_dial.c 420558 > > Diff: https://reviewboard.asterisk.org/r/3899/diff/ > > > Testing > ------- > > Matt also wrote a nifty python script that could be used to test that ARI > events were received as they were expected during a call forward. Part of the > script also grabbed a channel variable from a cahnnel not in Stasis as well. > > Finally, I connected an AMI session when running the test and ensured that > the Forward: header was present in the DialEnd when the call got forwarded. > > > Thanks, > > Mark Michelson > >
-- _____________________________________________________________________ -- 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
