[asterisk-app-dev] Implementation of ChanSpy functionality in ARI

[Matthew Jordan]

On Tue, Oct 15, 2013 at 6:33 PM, Mark Michelson <mmichelson at digium.com>wrote:

>  On 10/15/2013 05:30 PM, Matthew Jordan wrote:
>
>
<snip>


> 0) Is this intended to be used on the current "mixing" ARI bridge, or
> would you expect that a new ARI bridge type would be created? I'd think for
> this type of application, you'd need a new type of bridge so that there
> would be absolutely no implicit behavior regarding where media is routed.
>

I would expect that this would be a different bridging technology. Channels
joining the bridge could request that they want the ability to set up media
paths, which could cause a bridge to switch to this mixing technology.


>
> 1) If you were to POST a mediaRoute with read channels specified but no
> write channels, would those read channels essentially join as spies?
>

That's how I'd envision it, yes.


>
> 2) Is it worthwhile to introduce the idea of mediaRoute modification?
> Consider that Alice and Bob are talking and Eve (Bob's supervisor) is
> spying on the conversation. Eve initially is only listening, but feels the
> need later to give Bob some coaching. In order to do so, a mediaRoute is
> created to allow for Eve's media to be directed to Bob (but not Alice).
> Later, Eve realizes that Bob is totally hopeless and Eve needs to step in
> and talk to Alice directly. With the current API, this would mean deleting
> Eve's current mediaRoute and adding one that allows for her to talk to Bob
> and Alice. What if the existing mediaRoute could be modified instead to add
> Alice into the write path?
>

Possibly, but there's value in treating a mediaRoute as an immutable object
that can only be replaced, not modified.

(1) It simplifies the API slightly to just CREATE/DELETE
(2) The underlying infrastructure can make the assumption that when it is
handed a new set of routes, it can just replace the existing ones with a
swap operation


>
> 3) I don't think the DELETE needs the same parameters as the POST. I think
> a DELETE should have the id of a mediaRoute in the resource and remove
> entire mediaRoute from the bridge. No need for any parameters.
>

Agreed: creating a media route should probably hand back a resource ID.
mediaRoute would then be its own mini-resource.


>
> 4) Not sure if you were thinking this way or not, but the POST should be
> tolerant of redundancy. In other words, if Alice appears in both the read
> and write channels of a mediaRoute, that shouldn't cause a problem.
> Allowing for this can help to reduce the number of mediaRoutes that need to
> be set up for conferences.
>

There's a number of ways to implement such a system, but both adjacency
lists/adjacency matrix solve the bidirectional graph problem effectively.


>
> 5) This is probably just insane, but can you foresee a situation where
> someone would only wish to route a subset of a channel's media somewhere?
> Consider that Alice and Bob are on a video call, and Eve spies on the call.
> Bob is aware of Eve's presence but Alice is not. Could it be reasonable for
> Eve to only want to get Alice's audio but not Alice's video in such a case?
> Probably not, but just throwing the idea out there.
>

Yes, but that feels like a future enhancement to me. It implies a finer
grain of control over media streams (ha!) then we currently have in the
core - but you could combine the concept of a media stream with media
routes in a future version.

<snip>

Thinking about this some more: I like this idea, but based on the feedback,
it feels like it may be a separate (but related) use case to "simple"
channel spying. As Josh pointed out, using the current channel spying
approach with a Local channel still has a lot of power and has a slightly
different purpose than this approach. We could implement channel spying
using the current approach: framehook, one channel spies/whispers on one
other channel - and save this for a rainy day.

Is anyone against approaching channel spying using the existing
implementation approach, and saving the bridge mixing technology approach
for another time?

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131018/2953ba6d/attachment-0001.html>