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

[Daniel Jenkins]

On Fri, Oct 18, 2013 at 4:45 PM, Matthew Jordan <mjordan at digium.com> wrote:

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

Absolutely, let's get something working with the existing implementation,
see how people use it, see what people want from that... +1


>
> --
> 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
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131019/0f56bcc2/attachment.html>