On Wed, Oct 16, 2013 at 12:06 AM, Joshua Colp <jcolp at digium.com> wrote:
> Matthew Jordan wrote:
>
>> Hey all:
>>
>
> <shipped away all the other parts to get to the good stuff, see Matt's
> original email for it>
>
>
>
>> Another approach would be to make use of the bridging framework to
>> create a true
>> softmix bridge that understands the concept of media paths. Currently, in
>> the softmix bridge, all frames for all channels are mixed together and
>> resent
>> to all channels. It doesn't have to be that way however.
>>
>
> Quite.
>
>
> We could conceivably have a different mixing technology that allowed for
>> paths
>> to be set up:
>> Channel A Channel B Channel C
>> Channel A X Y Y
>>
>> Channel B Y X Y
>>
>> Channel C Y N X
>>
>> That is, Channel A's audio is mixed and sent to B and C; Channel B's
>> audio is
>> mixed and sent to A and C; but Channel C's audio is mixed and sent only
>> to A.
>> This let's them effectively spy on B without them knowing they're there.
>>
>
> Yup!
>
>
> Modifying the 'spying' would require allowing the routes to be changed
>> dynamically. The benefit here is that there aren't any Bridge Enter/Leave
>> operations that have to be performed, and a channel can easily toggle
>> back and
>> forth between spying and not spying.
>>
>> I'd imagine the API would look something like this:
>>
>> POST /bridges/{id}/mediaRoute
>> parameters:
>> writeChannels: IDs of the channels that media can be sent to
>> readChannels: IDs of the channels that media can be recieved from
>> DELETE /bridges/{id}/mediaRoute
>> parameters:
>> (Same, just removes routes instead)
>>
>
> I like it.
>
>
>
>> You could go rather crazy with this functionality, and set up some rather
>> interesting advanced conferencing applications as well.
>>
>> I would, however, prefer not to mangle softmix with this feature.
>> Softmix is a performant mixing technology used by a lot of things, and
>> this
>> feature is overkill except for some advanced queueing/conferencing use
>> cases.
>> The act of maintaining the routes (which are basically adjacency lists or
>> an
>> adjacency matrix) isn't as "cheap" as the mixing that softmix performs, so
>> it feels like a bad idea to impose this functionality on all multi-party
>> bridges. Maybe 'smartmix'?
>>
>
> Agreed.
>
> 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...
>
> 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.
>
> That's where my mind originally led me down, but the bridging stuff you
> mentioned above would also be extremely useful.
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
>
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: www.digium.com & www.asterisk.org
>
> ______________________________**_________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.**com <asterisk-app-dev at lists.digium.com>
> http://lists.digium.com/cgi-**bin/mailman/listinfo/asterisk-**app-dev<http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev>
Throwing it completely out there, it's kinda relevant but not at the same
time,
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.
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"
What you've both said so far makes sense to me, as much as i understand the
internals of Asterisk.
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131016/f12c8740/attachment-0001.html>
