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

[jrose]

> On Jan. 18, 2012, 2:54 p.m., jrose wrote:
> > http://svn.asterisk.org/svn/asterisk/trunk/apps/app_mixmonitor.c, line 558
> > <https://reviewboard.asterisk.org/r/1643/diff/5/?file=23193#file23193line558>
> >
> >     Actually, another problem here is that the size of these struct pointers isn't necessarily 32 bits in the first place, so simply turning the address into an 8 character string won't work either.  It isn't so bad in the case of smaller struct pointers, but when the struct pointers are larger than 32 bits, we lose that guarantee of uniqueness.  Basically every extra bit doubles the number of addresses that will match this string.
> >     
> >     I think the trick here is to create the character buffer to have a length based on the sizeof a struct pointer to the mixmonitor_ds, of course also making sure you have the extra character left over in the buffer so that it can terminate the string.

Oh, Matt did in fact post to this effect already and the page just hadn't updated.


- jrose


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


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/c6b63915/attachment.htm>