<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 18, 2013 at 4:45 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Tue, Oct 15, 2013 at 6:33 PM, Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com" target="_blank">mmichelson@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div>
<div>On 10/15/2013 05:30 PM, Matthew Jordan
wrote:<br>
</div>
<br></div></div></div></blockquote><div><br></div></div><div><snip></div><div class="im"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div><div></div></div>
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. <br></div></blockquote><div><br></div></div><div>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.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
1) If you were to POST a mediaRoute with read channels specified but
no write channels, would those read channels essentially join as
spies?<br></div></blockquote><div><br></div></div><div>That's how I'd envision it, yes.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<br>
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?<br></div></blockquote><div><br></div></div><div>Possibly, but there's value in treating a mediaRoute as an immutable object that can only be replaced, not modified.</div><div>
<br></div><div>(1) It simplifies the API slightly to just CREATE/DELETE</div><div>(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</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
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.<br></div></blockquote><div><br></div></div><div>Agreed: creating a media route should probably hand back a resource ID. mediaRoute would then be its own mini-resource.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<br>
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.<br></div></blockquote><div><br></div></div><div>There's a number of ways to implement such a system, but both adjacency lists/adjacency matrix solve the bidirectional graph problem effectively.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
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.</div></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div><snip></div><div><br></div><div>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.</div>
<div><br></div><div>Is anyone against approaching channel spying using the existing implementation approach, and saving the bridge mixing technology approach for another time?</div></div></div></div></blockquote><div><br>
</div><div>Absolutely, let's get something working with the existing implementation, see how people use it, see what people want from that... +1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div><div class="im">-- <br>
<div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div></div>
<br>_______________________________________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev</a><br>
<br></blockquote></div><br></div></div>