<div dir="ltr"><div class="gmail_extra">On Wed, Oct 16, 2013 at 12:06 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Matthew Jordan wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hey all:<br>
</blockquote>
<br>
<shipped away all the other parts to get to the good stuff, see Matt's original email for it><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Another approach would be to make use of the bridging framework to<br>
create a true<br>
softmix bridge that understands the concept of media paths. Currently, in<br>
the softmix bridge, all frames for all channels are mixed together and<br>
resent<br>
to all channels. It doesn't have to be that way however.<br>
</blockquote>
<br></div>
Quite.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We could conceivably have a different mixing technology that allowed for<br>
paths<br>
to be set up:<br>
Channel A Channel B Channel C<br>
Channel A X Y Y<br>
<br>
Channel B Y X Y<br>
<br>
Channel C Y N X<br>
<br>
That is, Channel A's audio is mixed and sent to B and C; Channel B's<br>
audio is<br>
mixed and sent to A and C; but Channel C's audio is mixed and sent only<br>
to A.<br>
This let's them effectively spy on B without them knowing they're there.<br>
</blockquote>
<br></div>
Yup!<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Modifying the 'spying' would require allowing the routes to be changed<br>
dynamically. The benefit here is that there aren't any Bridge Enter/Leave<br>
operations that have to be performed, and a channel can easily toggle<br>
back and<br>
forth between spying and not spying.<br>
<br>
I'd imagine the API would look something like this:<br>
<br>
POST /bridges/{id}/mediaRoute<br>
parameters:<br>
writeChannels: IDs of the channels that media can be sent to<br>
readChannels: IDs of the channels that media can be recieved from<br>
DELETE /bridges/{id}/mediaRoute<br>
parameters:<br>
(Same, just removes routes instead)<br>
</blockquote>
<br></div>
I like it.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
You could go rather crazy with this functionality, and set up some rather<br>
interesting advanced conferencing applications as well.<br>
<br>
I would, however, prefer not to mangle softmix with this feature.<br>
Softmix is a performant mixing technology used by a lot of things, and this<br>
feature is overkill except for some advanced queueing/conferencing use<br>
cases.<br>
The act of maintaining the routes (which are basically adjacency lists or an<br>
adjacency matrix) isn't as "cheap" as the mixing that softmix performs, so<br>
it feels like a bad idea to impose this functionality on all multi-party<br>
bridges. Maybe 'smartmix'?<br>
</blockquote>
<br></div>
Agreed.<br>
<br>
The only explicit con of this is that it is *not* ChanSpy functionality. It's cool functionality that you can use to achieve similar results for some situations. As long as everyone is okay with that...<br>
<br>
Honestly I could see the ChanSpy functionality being useful too. If it was exposed as a channel then you could use the same operations we have now and throw it into a Stasis application. Want to record a channel? Use the record operation on it. Want to multiplex it out to other channels? Add it to a bridge.<br>
<br>
That's where my mind originally led me down, but the bridging stuff you mentioned above would also be extremely useful.<br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<div class="im"><br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br></div>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
______________________________<u></u>_________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com" target="_blank">asterisk-app-dev@lists.digium.<u></u>com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-<u></u>bin/mailman/listinfo/asterisk-<u></u>app-dev</a></blockquote><div><br></div><div><br></div><div>
<br></div><div>Throwing it completely out there, it's kinda relevant but not at the same time,</div><div><br></div><div>As a developer programming for web, and I want to listen in on a channel, I'd rather have a media stream, streamed to me via http/websocket rather than having to say setup a webrtc enabled sip endpoint etc etc and mix in the sip channel.<br>
</div><div><br></div><div>So as a developer thinking about future web applications, would this ever happen? Being able to spy without the need for a "channel to mix in"</div><div><br></div><div>What you've both said so far makes sense to me, as much as i understand the internals of Asterisk.</div>
<div><br></div><div>Dan</div></div><br></div></div>