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

[jrose]

> On Jan. 20, 2012, 11 a.m., jrose wrote:
> > Did you actually test this latest patch?  Just so you know, that character array you made ends up having a length of 5 on my box (You need two characters to represent a single byte... 00-FF, and the sizeof function gets the size of a variable in bytes), and I'm pretty sure the using %p is going to mean this requires an extra 2 characters on top of the ones it needed previously that since they have 0x in front of them.  This means sprintf is just going to eat even more space, which is again going to trigger buffer overflow detection.
> > 
> > Well, I did say I'd take it from here, so I'll do that.  But please in the future try to at least check that your patches don't end up unconditionally cause crashes just from using the feature you are trying to make.

Alrighty, managed to clean it up with a few changes.  Thanks for all your work on this.  I know there were a lot of little problems to deal with and it probably ended up being a bit of a hassle.  We appreciate it though.


- jrose


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


On Jan. 19, 2012, 8:48 a.m., telecos82 wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1643/
> -----------------------------------------------------------
> 
> (Updated Jan. 19, 2012, 8:48 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/20120120/34731e62/attachment.htm>