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>
