[asterisk-dev] [Code Review] 2620: bridge features: Make one touch Monitor and MixMonitor into bridge features

[rmudgett]

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


I think a different approach needs to be taken because bridges can be multi-party.  Probably all of the peers need to start/stop their own recording.


/trunk/bridges/bridge_builtin_features.c
<https://reviewboard.asterisk.org/r/2620/#comment17473>

    Just check ast_bridge_peer() for NULL if the bridge is unsuitable.  You don't need to get the container of bridge channels.



/trunk/bridges/bridge_builtin_features.c
<https://reviewboard.asterisk.org/r/2620/#comment17479>

    You won't be able to stop the recording if the bridge becomes multi-party.
    



/trunk/bridges/bridge_builtin_features.c
<https://reviewboard.asterisk.org/r/2620/#comment17475>

    You really should get in the habit of coding like this:
    
    var = func();
    if (var) {
    }
    
    This format has better line break opportunities when var = func(); is a long line and the compiler generates the same code.



/trunk/bridges/bridge_builtin_features.c
<https://reviewboard.asterisk.org/r/2620/#comment17476>

    Missing TOUCH_MONITOR_PREFIX code that was in original feature.



/trunk/bridges/bridge_builtin_features.c
<https://reviewboard.asterisk.org/r/2620/#comment17478>

    Copy pasta.  Wrong channel variable.



/trunk/bridges/bridge_builtin_features.c
<https://reviewboard.asterisk.org/r/2620/#comment17474>

    Just check ast_bridge_peer() for NULL if the bridge is unsuitable.  You don't need to get the container of bridge channels.



/trunk/bridges/bridge_builtin_features.c
<https://reviewboard.asterisk.org/r/2620/#comment17477>

    Would you want to add TOUCH_MONITOR_PREFIX equivalent to mixmonitor version as well?


- rmudgett


On June 14, 2013, 4:51 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2620/
> -----------------------------------------------------------
> 
> (Updated June 14, 2013, 4:51 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and rmudgett.
> 
> 
> Bugs: asterisk-21553
>     https://issues.asterisk.org/jira/browse/asterisk-21553
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Adds Monitor and MixMonitor as bridge features.  In order to avoid using PBX execution and autoservice, I added some additional API for MixMonitor provided through loadable function callbacks provided by app_mixmonitor.
> 
> In order to make One Touch MixMonitor behave more like its Monitor equivalent, I went ahead and added a couple channel variables for playing start and stop recording sounds (TOUCH_MIXMONITOR_MESSAGE_START and TOUCH_MIXMONITOR_MESSAGE_STOP)
> 
> 
> Diffs
> -----
> 
>   /trunk/main/mixmonitor.c PRE-CREATION 
>   /trunk/main/features_config.c 391828 
>   /trunk/include/asterisk/mixmonitor.h PRE-CREATION 
>   /trunk/bridges/bridge_builtin_features.c 391828 
>   /trunk/apps/app_mixmonitor.c 391828 
> 
> Diff: https://reviewboard.asterisk.org/r/2620/diff/
> 
> 
> Testing
> -------
> 
> Tried both Monitor and MixMonitor with various channel variables set for filename/format and start/stop sounds. They appear to be working as one would expect.
> Also checked the behavior of MixMonitor with app_mixmonitor loaded and unloaded. As expected, it is rejected smoothly when MixMonitor is not loaded.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130615/41e9a77b/attachment-0001.htm>