<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">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 class="h5">
<div>On 10/15/2013 05:30 PM, Matthew Jordan
wrote:<br>
</div>
<br></div></div></div></blockquote><div><br></div><div style><snip></div><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 class="h5"></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 style>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> </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 style>That's how I'd envision it, yes.</div><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 style>Possibly, but there's value in treating a mediaRoute as an immutable object that can only be replaced, not modified.</div><div style>
<br></div><div style>(1) It simplifies the API slightly to just CREATE/DELETE</div><div style>(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> </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 style>Agreed: creating a media route should probably hand back a resource ID. mediaRoute would then be its own mini-resource.</div><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 style>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> </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 style>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 style><br></div><div style><snip></div><div style><br></div><div style>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 style><br></div><div style>Is anyone against approaching channel spying using the existing implementation approach, and saving the bridge mixing technology approach for another time?</div><div style><br></div></div>-- <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>