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

Mark Michelson mmichelson at digium.com
Tue Oct 15 18:33:01 CDT 2013 

On 10/15/2013 05:30 PM, Matthew Jordan wrote:
> Hey all:
>
> We've known we're going to need ChanSpy functionality in ARI for some 
> time. The
> ability to have a channel direct its audio specifically into another 
> channel
> while that channel is in a bridge or is otherwise engaged with another 
> party
> is an important use case for Queues and other systems.
>
> Currently, ChanSpy-ing in Asterisk is implemented using audio hooks 
> and what
> amounts to a very specific 'mini-bridge' in app_chanspy:
>
>    Spied channel          Unwitting participant
>  <-------[[-------> ( Bridge ) <----------------------->
>          ^
>          |
>          |
>          | Spyer Channel
>          |
> Flags on the operation determine whether or not audio is written from 
> the spyer
> channel into the spied channel as well as having the audio from the spied
> channel relayed to the spyer channel.
>
> This works well, but has a few issues:
>
> (1) Most of the logic is baked directly into app_chanspy. Ideally, 
> this would be
>     a core operation of some sort, so that other entities could use it 
> as a
>     an operation with their own business logic placed on top of it. 
> Extracting
>     it wouldn't be terribly difficult, but is a bit of a pain.
> (2) It is a very channel centric implementation for what feels like a 
> bridging
>     operation: that is, I want to know what is going on in this bridge 
> but I
>     only want some subset of the channels to hear me. This made sense 
> when we
>     had no bridging framework and the only unit of operation was the 
> channel;
>     now, however, there are other options available to us.
> (3) The biggest issue using the new framework is that there isn't an 
> easy way
>     to go from being a spyer to a full participant in the bridge. For 
> example,
>     a supervisor listening in on an agent and a caller may want to 
> jump into
>     the bridge as a full participant. Using this implementation, we'd 
> have to:
>     (a) Detach ourselves and the audio hook from the spied channel
>     (b) Take control of the spyer channel (possibly yanking them: this 
> depends
>         on how we refactor the existing code)
>     (c) Place them into the bridge
>
> All of which feels a bit cumbersome.
>
> 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.
>
> 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.
>
> 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)
>

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.

1) If you were to POST a mediaRoute with read channels specified but no 
write channels, would those read channels essentially join as spies?

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?

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.

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.

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.

> You could go rather crazy with this functionality, and set up some rather
> interesting advanced conferencing applications as well.

Yes, I could foresee a web app that either looks like the matrix you 
showed earlier or a visual one where individual paths between 
participants can be clicked to toggle the media path on and off. Pretty 
cool!

>
> 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'?

I agree that softmix should stay as it is and that this functionality 
should live in its own mixing technology.

>
> Thoughts?
>
>
> -- 
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131015/549ed1de/attachment-0001.html>

More information about the asterisk-app-dev mailing list