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
