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)
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'?
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131015/8ec2ef4a/attachment-0001.html>
