[asterisk-dev] [Code Review]: Allow specifying which MixMonitor to stop

jrose reviewboard at asterisk.org
Thu Dec 22 15:15:33 CST 2011



> On Dec. 22, 2011, 3:07 p.m., jrose wrote:
> > Alright, this looks good.
> 
> jrose wrote:
>     EDIT:  Actually, revoke that.  Missed kpfleming's recent post.

Ok, so what kpfleming is suggesting is basically this...
Create the search term based on something supplied to mixmonitor via an argument.  Like...

MixMonitor(filename.extension,i(name_of_channel_variable))

When mixmonitor is created and this option is present, this channel variable will be populated with some uniquely identifying string (at least uniquely identifying for the channel) which you'll need to create with some heuristic... possibly involving the system time that the variable is created or something similar.

Then from there you'd just use that as your identifier for stopmixmonitor.


- jrose


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


On Dec. 22, 2011, 12:03 p.m., telecos82 wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1643/
> -----------------------------------------------------------
> 
> (Updated Dec. 22, 2011, 12:03 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Currently, if there are several MixMonitor started on a channel, there is no way to specify which MixMonitor to stop with StopMixMonitor. With this patch we will allow this. One limitation of current implementation was that mixmonitor datastore was not identified with a uid so there was no way to identify a concrete MixMonitor. Furthermore, when retrieving audiohook to dettach from channel, there was no control on which audiohook to dettach, it always got first audiohook found of type mixmonitor_spy_type. With this patch we are identifying MixMonitor datastore by the filename asociated to it, and dettaching the concrete audiohook contained on datastore. Furthermore a new CLI command "mixmonitor list <channel_name>" to help querying active mixmonitors on a channel.
> 
> 
> This addresses bug ASTERISK-19096.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19096
> 
> 
> Diffs
> -----
> 
>   http://svn.asterisk.org/svn/asterisk/trunk/apps/app_mixmonitor.c 348737 
> 
> Diff: https://reviewboard.asterisk.org/r/1643/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> telecos82
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111222/3cf2d1e8/attachment.htm>


More information about the asterisk-dev mailing list