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>
