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

[jrose]

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



http://svn.asterisk.org/svn/asterisk/trunk/apps/app_mixmonitor.c
<https://reviewboard.asterisk.org/r/1643/#comment9718>

    You have a rather major faux-pas here that I noticed while testing.  You are using this as a string of 8 characters, but you have no place for a termination character in that string. When sprintf writes to this, it attempts to place a terminator string at index 8 which gets caught by overflow protection making Asterisk crash.
    
    I think this should be fairly easy to fix just by making this a 9 character buffer.



http://svn.asterisk.org/svn/asterisk/trunk/apps/app_mixmonitor.c
<https://reviewboard.asterisk.org/r/1643/#comment9684>

    All if statements should use braces regardless of number of lines. I know this isn't actually realized everywhere, but it's in the style guide and we enforce it for all new code.


By the by, do you have commit access? If not, I can take it from here.

- jrose


On Jan. 17, 2012, 5:26 a.m., telecos82 wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1643/
> -----------------------------------------------------------
> 
> (Updated Jan. 17, 2012, 5:26 a.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/20120118/802da4ab/attachment.htm>