[asterisk-dev] [Code Review] INFO Record: on/off handled dynamically and separately with support for dynamic features.

[Matt Jordan]

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



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1634/#comment9292>

    Correct me if I'm wrong, but if you've set the record_on_feature / record_off_feature to being "", won't that trigger this warning?  I would imagine that if we've explicitly turned the feature off, we wouldn't want to be flooded with WARNINGs that we haven't registered the feature.



/trunk/channels/sip/include/sip.h
<https://reviewboard.asterisk.org/r/1634/#comment9290>

    Based on the conversation you and oej are having, should this be a feature that we have enabled automatically?  You could potentially have an issue where, since the default is a valid feature, "out of the box" it looks like any SIP endpoint could start recording on the Asterisk server by sending an INFO request to record.



/trunk/configs/sip.conf.sample
<https://reviewboard.asterisk.org/r/1634/#comment9291>

    Update this to reflect that a blank value turns the feature off


- Matt


On Dec. 19, 2011, 4:08 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1634/
> -----------------------------------------------------------
> 
> (Updated Dec. 19, 2011, 4:08 p.m.)
> 
> 
> Review request for Asterisk Developers, David Vossel and Matt Jordan.
> 
> 
> Summary
> -------
> 
> The reporter was was wanting to submit a feature change which would have allowed Record requests to search through dynamic features for a feature named automon rather than simply failing if it wasn't found in builtin features.
> 
> David Vossel responded to the issue suggesting he would rather see a setting added to specify the feature.
> 
> This patch goes a step beyond that by allowing the user to specify which feature to use when receiving the message separately depending on whether the incoming message contained Record: on or Record: off.  These applications can be set to the same value when using the built in features like automon/automixmon, or they can be set separately so that on always triggers the recording feature while off always triggers the  appropriate feature to shut the recording application off. In this case, the SNOM phone which this feature was made for will typically show the correct recording status indication after the button is pressed even if it previously fell out of sync somehow. *I would guess by the user being clumsy or mischievous and pressing record over and over again really quickly*
> 
> Thanks to this new setup, it is possible to forgo recording all together in favor of having Record: on louden the volume before blasting the other peer with weasels and then have Record: off raise the volume even more before blasting the other peer with iguanas.  Glorious.
> 
> Sadly, not a single aspect of the reporter's patch has remained, though oddly enough the first chunk in chan_sip was added just a few days ago in an unrelated issue.
> 
> 
> This addresses bug ASTERISK-16507.
>     https://issues.asterisk.org/jira/browse/ASTERISK-16507
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 348210 
>   /trunk/channels/sip/include/sip.h 348210 
>   /trunk/configs/sip.conf.sample 348210 
>   /trunk/main/features.c 348210 
> 
> Diff: https://reviewboard.asterisk.org/r/1634/diff
> 
> 
> Testing
> -------
> 
> Use of both built-in and dynamic features applied separately were performed with the settings being applied both globally and to peers individually.  Testing was also done to check that the default settings applied as intended.
> 
> 
> Thanks,
> 
> jrose
> 
>

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