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

[Matt Jordan]

> On Jan. 10, 2013, 5:08 p.m., opticron wrote:
> > /trunk/funcs/func_frame_trace.c, lines 330-344
> > <https://reviewboard.asterisk.org/r/2265/diff/1/?file=32705#file32705line330>
> >
> >     None of the other string representations of these control frame subtypes include "AST_CONTROL_".  These should be consistent with the existing entries.

Fixed.


> On Jan. 10, 2013, 5:08 p.m., opticron wrote:
> > /trunk/apps/app_playback.c, line 484
> > <https://reviewboard.asterisk.org/r/2265/diff/1/?file=32704#file32704line484>
> >
> >     Adjacent blob.

Terminated.


> On Jan. 10, 2013, 5:08 p.m., opticron wrote:
> > /trunk/main/channel.c, lines 3708-3709
> > <https://reviewboard.asterisk.org/r/2265/diff/1/?file=32708#file32708line3708>
> >
> >     The documentation for ast_waitfordigit and ast_waitfordigit_full needs to be modified to accomodate this change.  The ast_waitstream* documentation may need to be modified as well.  Consumers of these functions will need to be checked to ensure they handle these changes appropriately.

Any of the ast_waitfor* functions can technically return this, so I'll update the documentation. I've investigated the major applications that use it and updated them accordingly to be tolerant of the control frame as a return value; however, they're used all over the code base. To an extent, the user of the ControlPlayback AMI action has to be somewhat cognizant of what is occurring in the system when it's executed.

An alternative approach to this would be to not return the value of the control frame unless the call comes through ast_waitstream_fr_w_cb or ast_waitstream_fr; however, that would mean you wouldn't be able to rewind or fast forward when using app_playback.


- Matt


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


On Jan. 8, 2013, 3:22 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2265/
> -----------------------------------------------------------
> 
> (Updated Jan. 8, 2013, 3:22 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 378650 
>   /trunk/main/file.c 378650 
>   /trunk/main/channel.c 378650 
>   /trunk/main/app.c 378650 
>   /trunk/include/asterisk/frame.h 378650 
>   /trunk/apps/app_playback.c 378650 
>   /trunk/funcs/func_frame_trace.c 378650 
>   /trunk/apps/app_controlplayback.c 378650 
> 
> 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/20130114/de44b4d6/attachment.htm>