[asterisk-dev] [Code Review] 3899: ARI: Improve reporting of dial events on call forwards; Allow for channel variables to be retrieved from channels not in Stasis()

[Matt Jordan]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140811/83842950/attachment-0001.html>