[asterisk-bugs] [JIRA] (ASTERISK-22780) ARI: Implement channel spying

[Matt Jordan (JIRA)]

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

Matt Jordan reassigned ASTERISK-22780:
--------------------------------------

    Assignee: Joshua Colp
    
> ARI: Implement channel spying
> -----------------------------
>
>                 Key: ASTERISK-22780
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22780
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Applications/app_chanspy, Resources/res_ari
>    Affects Versions: 12.0.0-beta1
>            Reporter: Matt Jordan
>            Assignee: Joshua Colp
>
> One of the missing features in ARI is the ability to spy on channels. A discussion was had on the [asterisk-app-dev mailing list|http://lists.digium.com/pipermail/asterisk-app-dev/2013-October/000012.html], in which two proposals were made:
> # Use the existing ChanSpy functionality (refactored appropriately). This would result in a new 'spy' operation being added to the channels resource. This option is more expedient, in that the existing code can mostly be reused, and provides a useful implementation of the whisper/spy functionality. It is not ideal for barge functionality, as the spy operation has to be stopped before a channel is added into a bridge.
> # Create a new bridge technology that could set up media paths between participants. This is more flexible than the first option, as it allows for  whisper/spy/barge (as well as more complicated scenarios), but has a relatively complex implementation and may be more difficult to use.
> For now, the community decided to go with option #1. This issue is to do that.
> h3. Refactoring
> Refactor the common execution code in {{app_chanspy}} into a core file. This should include all generator code, audiohook code, and any shared execution code between the existing dialplan channel spy applications.
> Verify that we don't break the existing dialplan applications.
> h3. Update the models
> Add a new operation to the {{channels}} resource. The channel referenced by the operation is the channel performing the spying operation. The parameters should be:
> # The ID of the channel to spy in
> # The mode of the operation. This should be {{whisper}} and {{spy}}.
> A POST should start a spy operation; a DELETE should terminate it.
> While spying, a channel cannot be in a bridge, nor can it enter a bridge.
> While spying, other media operations should be prevented that conflict with the operation, i.e., recording.
> Note that we'll defer for now on {{barge}}. Barging is complicated in multi-channel bridges - if you want to go from whisper/spy to acting as a full participant, you should end the operation and put the channel into the bridge with the participants.
> h3. Implement said feature
> Add the necessary plumbing to {{resource_channels}} to call into the core functionality implemented previously.
> Add tests to the Asterisk Test Suite to verify spy and whisper mode operations.

--
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