[asterisk-dev] [Code Review]: Add asynchronous control of media playback using AMI

[Matt Jordan]

> On Jan. 21, 2013, 8:23 a.m., opticron wrote:
> > I have mixed feelings about normal playback being able to be controlled, but there are use cases I can think of for it.

I have mixed feelings too. Here's a proposal:

When a control frame is processed by a call to ast_waitstreamfr_w_cb/ast_waitstream_fr, the control frame value is passed back. Otherwise, the control frame breaks the media playback (as currently implemented), but the value is handled by the ast_waistream* function call and passed back as 0, indicating playback 'success'.

This would limit the potential damage from someone using AMI to stop a playback in, say, app_voicemail.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2265/#review7696
-----------------------------------------------------------


On Jan. 13, 2013, 8:34 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2265/
> -----------------------------------------------------------
> 
> (Updated Jan. 13, 2013, 8:34 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch adds a new AMI command "ControlPlayback" that allows a connected AMI client to control media being played to some channel. This behaves in one of two ways:
> * If the media was initiated using the ControlPlayback application or AGI command, all media operations (fast forward, reverse, pause, stop, restart) behave exactly as if the user had initiated it via DTMF.
> * If the media was initiated using the Playback application or AGI command (or any other mechanism of calling into ast_waitstream), the fast forward and reverse operations will move the media stream appropriately. Stop, pause, and restart all immediately stop playback.
> 
> As an added benefit, the AGI command 'control stream file' and 'stream file' now set the appropriate channel variables when done.
> 
> A corresponding set of tests was written for the Asterisk Test Suite, and is up for review at https://reviewboard.asterisk.org/r/2270
> 
> 
> This addresses bug ASTERISK-20882.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20882
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_agi.c 378998 
>   /trunk/main/file.c 378998 
>   /trunk/main/channel.c 378998 
>   /trunk/main/app.c 378998 
>   /trunk/include/asterisk/frame.h 378998 
>   /trunk/funcs/func_frame_trace.c 378998 
>   /trunk/include/asterisk/file.h 378998 
>   /trunk/apps/app_playback.c 378998 
>   /trunk/apps/app_controlplayback.c 378998 
> 
> Diff: https://reviewboard.asterisk.org/r/2265/diff
> 
> 
> Testing
> -------
> 
> Automated:
> The tests check for an AMI connection controlling both ControlPlayback as well as Playback. They test all five operations, and check that the channel variables have the appropriate values set after the test. Verification of stream manipulation is performed via test events.
> 
> System:
> Connected a SIP phone, dropped it into an AGI, and initiated a 'stream file' or 'control stream file'. Verified that an AMI connection could manipulate the stream. Listened to tt-monkeys incessantly, probably driving the people in the offices next to me crazy.
> 
> MONKEYS.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130121/5a036b0e/attachment-0001.htm>