[asterisk-bugs] [JIRA] (ASTERISK-22781) ARI: Implement channel monitoring

[David M. Lee (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-22781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David M. Lee closed ASTERISK-22781.
-----------------------------------

    Resolution: Won't Fix

File has an idea for implementing snooping technology in a much more generic way (see his post on [the app-dev list|http://lists.digium.com/pipermail/asterisk-app-dev/2013-November/000201.html]. This would be a much cleaner path to get to monitoring than this idea.
                
> ARI: Implement channel monitoring
> ---------------------------------
>
>                 Key: ASTERISK-22781
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22781
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Applications/app_mixmonitor, Resources/res_ari
>    Affects Versions: 12.0.0-beta1
>            Reporter: Matt Jordan
>            Assignee: David M. Lee
>
> One of the missing features in ARI is the ability to monitor channels.
> Currently, ARI supports recording the media in one of two ways:
> # Via an explicit /record operation on a channels resource. This is used to record the media of a single channel that is not interacting with other channels or bridges, i.e., when a channel is in a voicemail.
> # Via an explicit /record operation on a bridges resource. This is used to record the media of all channels in a bridge, and the recording is tied to the bridge.
> We need the same functionality for /channels that was have for /bridges: that is, a recording operation that follows along with the channel that it is started on but does not interfere with the media path of that channel. This is basically a monitor (or, more accurately, MixMonitor).
> h3. Refactor mixmonitor header file to extract options
> Luckily, MixMonitor was already refactored in 12 to have {{app_mixmonitor}} register itself with the core as a MixMonitor provider. One aspect that is a little brittle in this implementation is the handling of options.
> Options are currently passed from callers of the function as a string of one letter characters, i.e., as the dialplan arguments. This has the effect of requiring consumers of the mixmonitor functionality to know of the dialplan implementation, which is not ideal.
> There are two ways we could deal with this:
> # Implement MixMonitor completely in the core, and make the dialplan application a thin wrapper around the core functionality. This may actually be the best long term approach, as both app_queue, app_mixmonitor, and res_ari will all need the core functionality.
> # As a quicker solution, implement the options as an enumeration or provide an optional function that takes in an enumeration and calls the existing function with those options mapped to their dialplan counterparts.
> The goal, at any rate, is to not require res_ari to be aware of app_mixmonitor dialplan arguments.
> h3. Update the models
> The proposed naming for the new /channels operation is {{/monitor}}. (MixMonitor is something of an Asterisk-ism - at the end of the day, what we're doing is monitoring the channels. The fact that Monitor is a poor implementation of this is besides the point.)
> This operation should use a POST to start monitoring and a DELETE to terminate it. As parameters, it should take in the following (which are the same as the /record options):
> # The name of the file to produce
> # The format of the file to produce
> # ifExists - action to take if the file already exists
> In addition, it should have the following parameters:
> # The name of the file that contains the transmission audio only. If specified, the name of the file to record should not be required.
> # The name of the file that contains the received audio only. If specified, the name of the file to record should not be required.
> Monitoring an already monitored channel should not be allowed.
> This operation should return a {{LiveRecording}} object for each file created. Note that we may want to specify in the {{LiveRecording}} object the media directions currently being recorded.
> h3. Implementation!
> Update {{resource_channels}} as appropriate.
> Update the MixMonitor code to handle the following frames:
> * AST_CONTROL_RECORD_CANCEL - this should destroy the MixMonitor, set the appropriate status variables, and destroy and the files created.
> * AST_CONTROL_RECORD_STOP - this should destroy the MixMonitor, set the appropriate status variables, and save the files.
> * AST_CONTROL_RECORD_SUSPEND - this should toggle suspending of the MixMonitor. Frames received on the hook should be discarded until a subsequent SUSPEND control frame is received.
> * AST_CONTROL_RECORD_MUTE - all audio sent from the channel that has the monitor attached to it should be discarded (or set to 0). Audio received should continue to be recorded. A subsequent reception of this control frame should unmute the MixMonitor.
> Note that Asterisk Test Suite tests should be written that cover monitoring a channel; destroying monitors; off nominal creation of monitors; as well as manipulating a monitor on a channel.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira