[asterisk-app-dev] Implementation of ChanSpy functionality in ARI

[Joshua Colp]

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