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

[Matthew Jordan]

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?

[Joshua Colp]

<shipped away all the other parts to get to the good stuff, see Matt's
original email for it>

Post by Matthew Jordan
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.

Post by Matthew Jordan
We could conceivably have a different mixing technology that allowed for
paths
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!

Post by Matthew Jordan
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.
POST /bridges/{id}/mediaRoute
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
(Same, just removes routes instead)

I like it.

Post by Matthew Jordan
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.

[Alistair Cunningham]

Post by Joshua Colp
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...

Also agreed. What Matt and you have written sounds entirely sensible to
me, and I find it hard to imagine anyone objecting if similar results
can be achieved. What I'd like to see is an ARI action or actions to
take an existing incoming call from an endpoint, and route it to spying
on an existing call with the following scenarios:

1. Spy on the call, listen only.

2. Spy on the call, and talk to a single party - presumably by
specifying the channel to talk to in the ARI action. It's then up to API
app developers such as us to figure out which channel is the caller and
which is the called.

3. Spy on the call, and talk to all parties, i.e. form an ad-hoc conference.

We don't have any need to change scenario mid-spy (using DTMF for
example), but others might. Likewise, we don't have any need to talk to
two or more (but not all) participants in the original call, but others
might.

[Daniel Jenkins]

On Wed, Oct 16, 2013 at 12:20 AM, Alistair Cunningham <

Post by Alistair Cunningham

Post by Joshua Colp
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...

Also agreed. What Matt and you have written sounds entirely sensible to
me, and I find it hard to imagine anyone objecting if similar results can
be achieved. What I'd like to see is an ARI action or actions to take an
existing incoming call from an endpoint, and route it to spying on an
1. Spy on the call, listen only.
2. Spy on the call, and talk to a single party - presumably by specifying
the channel to talk to in the ARI action. It's then up to API app
developers such as us to figure out which channel is the caller and which
is the called.

If you were spying on the channel, would you then be able to change that
spy object as such to have one way audio? Or would you have to remix, with
a NEW mediaRoute which would override the previous one? I can see a need to
be able to change it mid call as it were

Post by Alistair Cunningham
3. Spy on the call, and talk to all parties, i.e. form an ad-hoc conference.

I think this is as you say, a conference and shouldn't be put anywhere near
the functionality of ChanSpy in ARI, otherwise you're just duplicating
methods in the ARI

Post by Alistair Cunningham
We don't have any need to change scenario mid-spy (using DTMF for
example), but others might. Likewise, we don't have any need to talk to two
or more (but not all) participants in the original call, but others might.
--
Alistair Cunningham
[phone]
[phone]
http://integrics.com/
______________________________**_________________
asterisk-app-dev mailing list
http://lists.digium.com/cgi-**bin/mailman/listinfo/asterisk-**app-dev<http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev>

[Daniel Jenkins]

Post by Joshua Colp
<shipped away all the other parts to get to the good stuff, see Matt's
original email for it>

Post by Matthew Jordan
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

Post by Matthew Jordan
paths
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

Post by Matthew Jordan
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.
POST /bridges/{id}/mediaRoute
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
(Same, just removes routes instead)

I like it.

Post by Matthew Jordan
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
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

[David M. Lee]

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"

So GET /channels/{channelId}/tap, which just gives you a media stream for that channel.

Sounds nice, but the more Asterisk/media savvy folks on the list will have to comment on how feasible it is. My guess is that there's probably audio quality/format issues that would make this an ideal solution.

[Daniel Jenkins]

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"
So GET /channels/{channelId}/tap, which just gives you a media stream for that channel.
Sounds nice, but the more Asterisk/media savvy folks on the list will have
to comment on how feasible it is. My guess is that there's probably audio
quality/format issues that would make this an ideal solution.

Exactly! this would be amazing if we can do it! completely understand
theres alot of complexity in this though

--
David M. Lee
Digium, Inc. | 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
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[Mark Michelson]

Post by Matthew Jordan
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
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.
(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
(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
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.
POST /bridges/{id}/mediaRoute
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
(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.

Post by Matthew Jordan
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!

Post by Matthew Jordan
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.

Post by Matthew Jordan
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
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[Matthew Jordan]

<snip>

Post by Mark Michelson
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.

I would expect that this would be a different bridging technology. Channels
joining the bridge could request that they want the ability to set up media
paths, which could cause a bridge to switch to this mixing technology.

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

That's how I'd envision it, yes.

Post by Mark Michelson
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?

Possibly, but there's value in treating a mediaRoute as an immutable object
that can only be replaced, not modified.

(1) It simplifies the API slightly to just CREATE/DELETE
(2) The underlying infrastructure can make the assumption that when it is
handed a new set of routes, it can just replace the existing ones with a
swap operation

Post by Mark Michelson
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.

Agreed: creating a media route should probably hand back a resource ID.
mediaRoute would then be its own mini-resource.

Post by Mark Michelson
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.

There's a number of ways to implement such a system, but both adjacency
lists/adjacency matrix solve the bidirectional graph problem effectively.

Post by Mark Michelson
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.

Yes, but that feels like a future enhancement to me. It implies a finer
grain of control over media streams (ha!) then we currently have in the
core - but you could combine the concept of a media stream with media
routes in a future version.

<snip>

Thinking about this some more: I like this idea, but based on the feedback,
it feels like it may be a separate (but related) use case to "simple"
channel spying. As Josh pointed out, using the current channel spying
approach with a Local channel still has a lot of power and has a slightly
different purpose than this approach. We could implement channel spying
using the current approach: framehook, one channel spies/whispers on one
other channel - and save this for a rainy day.

Is anyone against approaching channel spying using the existing
implementation approach, and saving the bridge mixing technology approach
for another time?

[Daniel Jenkins]

Post by Matthew Jordan
<snip>

Post by Mark Michelson
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.

I would expect that this would be a different bridging technology.
Channels joining the bridge could request that they want the ability to set
up media paths, which could cause a bridge to switch to this mixing
technology.

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

That's how I'd envision it, yes.

Post by Mark Michelson
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?

Possibly, but there's value in treating a mediaRoute as an immutable
object that can only be replaced, not modified.
(1) It simplifies the API slightly to just CREATE/DELETE
(2) The underlying infrastructure can make the assumption that when it is
handed a new set of routes, it can just replace the existing ones with a
swap operation

Post by Mark Michelson
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.

Agreed: creating a media route should probably hand back a resource ID.
mediaRoute would then be its own mini-resource.

Post by Mark Michelson
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.

There's a number of ways to implement such a system, but both adjacency
lists/adjacency matrix solve the bidirectional graph problem effectively.

Post by Mark Michelson
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.

Yes, but that feels like a future enhancement to me. It implies a finer
grain of control over media streams (ha!) then we currently have in the
core - but you could combine the concept of a media stream with media
routes in a future version.
<snip>
Thinking about this some more: I like this idea, but based on the
feedback, it feels like it may be a separate (but related) use case to
"simple" channel spying. As Josh pointed out, using the current channel
spying approach with a Local channel still has a lot of power and has a
slightly different purpose than this approach. We could implement channel
spying using the current approach: framehook, one channel spies/whispers on
one other channel - and save this for a rainy day.
Is anyone against approaching channel spying using the existing
implementation approach, and saving the bridge mixing technology approach
for another time?

Absolutely, let's get something working with the existing implementation,
see how people use it, see what people want from that... +1

Post by Matthew Jordan
--
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
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[Matthew Jordan]

Post by Daniel Jenkins

Post by Matthew Jordan
<snip>
Thinking about this some more: I like this idea, but based on the
feedback, it feels like it may be a separate (but related) use case to
"simple" channel spying. As Josh pointed out, using the current channel
spying approach with a Local channel still has a lot of power and has a
slightly different purpose than this approach. We could implement channel
spying using the current approach: framehook, one channel spies/whispers on
one other channel - and save this for a rainy day.
Is anyone against approaching channel spying using the existing
implementation approach, and saving the bridge mixing technology approach
for another time?

Absolutely, let's get something working with the existing implementation,
see how people use it, see what people want from that... +1

I forgot to mention:

* Add ChanSpy like functionality -
https://issues.asterisk.org/jira/browse/ASTERISK-22780
* Add Monitor like functionality (this is very related, actually) -
https://issues.asterisk.org/jira/browse/ASTERISK-22781

I fully expect the descriptions in those two issues to become obsolete in
the next few days, but we've at least got issues in the tracker to get this
done.

[Joshua Colp]

So, as Matt mentioned I do think the descriptions for these tasks in
JIRA is going to change and here's why! Dun dun dun.

As I'm looking at implementing the functionality I'm unhappy with the
thought of simply making Chanspy available over ARI. This is going down
the same road as the /dial operation was. I've taken a step back and
actually looked at what I mentioned awhile ago and how feasible it is...
and I'd like to go further down that road!

I'd like to expose a /snoop operation (although I'm open to changing the
name... I just wanted something to encompass both spy and whisper) on
channels. This operation would accept a direction for spying and a
direction for whispering. Of course "none" would be an option for both
in case you don't want to do them. This operation would internally
create a Snoop channel which snoops on another channel (oddly enough).
Anything written to it is whispered to the other channel (if a direction
is specified) and anything read from it is the spied audio (if a
direction is specified). The operation would also accept the name of a
Stasis application and optionally some arguments. The Snoop channel
would be placed into this app. The operation would return a snapshot of
this Snoop channel.

Why this way?

ULTIMATE POWER! By ultimate power I mean since this is a channel in your
Stasis application you can do anything to it that can be done with a
channel. Monitoring becomes creating a snoop channel and calling record
on it. Whispering or live monitoring becomes creating a snoop channel,
creating a bridge, and putting another channel in the bridge. Whispering
media becomes creating a snoop channel and calling playback on it.

Thoughts?

[Daniel Jenkins]

So, as Matt mentioned I do think the descriptions for these tasks in JIRA

is going to change and here's why! Dun dun dun.

As I'm looking at implementing the functionality I'm unhappy with the

thought of simply making Chanspy available over ARI. This is going down the
same road as the /dial operation was. I've taken a step back and actually
looked at what I mentioned awhile ago and how feasible it is... and I'd
like to go further down that road!

I'd like to expose a /snoop operation (although I'm open to changing the

name... I just wanted something to encompass both spy and whisper) on
channels. This operation would accept a direction for spying and a
direction for whispering. Of course "none" would be an option for both in
case you don't want to do them. This operation would internally create a
Snoop channel which snoops on another channel (oddly enough). Anything
written to it is whispered to the other channel (if a direction is
specified) and anything read from it is the spied audio (if a direction is
specified). The operation would also accept the name of a Stasis
application and optionally some arguments. The Snoop channel would be
placed into this app. The operation would return a snapshot of this Snoop
channel.

Why this way?
ULTIMATE POWER! By ultimate power I mean since this is a channel in your

Stasis application you can do anything to it that can be done with a
channel. Monitoring becomes creating a snoop channel and calling record on
it. Whispering or live monitoring becomes creating a snoop channel,
creating a bridge, and putting another channel in the bridge. Whispering
media becomes creating a snoop channel and calling playback on it.

Thoughts?
--
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
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

Sounds good to me, would you be able to change direction, or being able to
whisper etc etc part way through the channel's lifetime?

Still interested to see if you'd then be able to snoop and return an audio
stream via http but that's another issue

[Joshua Colp]

Post by Daniel Jenkins
Sounds good to me, would you be able to change direction, or being able
to whisper etc etc part way through the channel's lifetime?

It's possible but it would be the same as if hanging up the snoop
channel and creating a new one.

Post by Daniel Jenkins
Still interested to see if you'd then be able to snoop and return an
audio stream via http but that's another issue

This does not discount creating an operation which exposes the audio
streams externally somehow.

[Alistair Cunningham]

Post by Joshua Colp
I'd like to expose a /snoop operation (although I'm open to changing the
name... I just wanted something to encompass both spy and whisper) on
channels. This operation would accept a direction for spying and a
direction for whispering.

Would this allow whispering to both directions - i.e. an ad-hoc conference?

Post by Joshua Colp
Monitoring becomes creating a snoop channel and calling record on it.

Presumably there still needs to be a REST action to tell Asterisk to
save the recorded audio/video to disk?

[Joshua Colp]

Post by Alistair Cunningham

Post by Joshua Colp
I'd like to expose a /snoop operation (although I'm open to changing the
name... I just wanted something to encompass both spy and whisper) on
channels. This operation would accept a direction for spying and a
direction for whispering.

Would this allow whispering to both directions - i.e. an ad-hoc conference?

I'm trying to do that, yes. Right now ChanSpy does this by whispering to
each channel involved in it (not into each direction of the channel you
are spying on) so I'm seeing if I can improve that.

Post by Alistair Cunningham

Post by Joshua Colp
Monitoring becomes creating a snoop channel and calling record on it.

Presumably there still needs to be a REST action to tell Asterisk to
save the recorded audio/video to disk?

The record operation does this already.

[Matthew Jordan]

So, as Matt mentioned I do think the descriptions for these tasks in JIRA
is going to change and here's why! Dun dun dun.
As I'm looking at implementing the functionality I'm unhappy with the
thought of simply making Chanspy available over ARI. This is going down the
same road as the /dial operation was. I've taken a step back and actually
looked at what I mentioned awhile ago and how feasible it is... and I'd
like to go further down that road!
I'd like to expose a /snoop operation (although I'm open to changing the
name... I just wanted something to encompass both spy and whisper) on
channels. This operation would accept a direction for spying and a
direction for whispering. Of course "none" would be an option for both in
case you don't want to do them. This operation would internally create a
Snoop channel which snoops on another channel (oddly enough). Anything
written to it is whispered to the other channel (if a direction is
specified) and anything read from it is the spied audio (if a direction is
specified). The operation would also accept the name of a Stasis
application and optionally some arguments. The Snoop channel would be
placed into this app. The operation would return a snapshot of this Snoop
channel.
Why this way?
ULTIMATE POWER! By ultimate power I mean since this is a channel in your
Stasis application you can do anything to it that can be done with a
channel. Monitoring becomes creating a snoop channel and calling record on
it. Whispering or live monitoring becomes creating a snoop channel,
creating a bridge, and putting another channel in the bridge. Whispering
media becomes creating a snoop channel and calling playback on it.
Thoughts?

{quote}
Whispering or live monitoring becomes creating a snoop channel, creating a
bridge, and putting another channel in the bridge.
{quote}

Do you envision the /snoop operation working on multiple channel
technologies? Or is the snoop-ing channel a specific technology? The way
that's worded, it makes it sound as if you could not use one SIP channel to
snoop on another SIP channel directly.

[Joshua Colp]

Post by Matthew Jordan
{quote}
Whispering or live monitoring becomes creating a snoop channel, creating
a bridge, and putting another channel in the bridge.
{quote}
Do you envision the /snoop operation working on multiple channel
technologies? Or is the snoop-ing channel a specific technology? The way
that's worded, it makes it sound as if you could not use one SIP channel
to snoop on another SIP channel directly.

The /snoop operation will work on any channel technology. The channel it
returns is a specific channel implementation called Snoop. Since you can
bridge any technology with any technology anything can act as an active
spyer.

The fundamental difference with this approach is that it's not an
operation which performs "channel A spies on channel B". It's an
operation which performs "provide me a conduit to snoop the media becing
received or sent on channel B". What that conduit ends up being
connected to is up to the application developer.

[Matthew Jordan]

Post by Joshua Colp

Post by Matthew Jordan
{quote}
Whispering or live monitoring becomes creating a snoop channel, creating
a bridge, and putting another channel in the bridge.
{quote}
Do you envision the /snoop operation working on multiple channel
technologies? Or is the snoop-ing channel a specific technology? The way
that's worded, it makes it sound as if you could not use one SIP channel
to snoop on another SIP channel directly.

The /snoop operation will work on any channel technology. The channel it
returns is a specific channel implementation called Snoop. Since you can
bridge any technology with any technology anything can act as an active
spyer.
The fundamental difference with this approach is that it's not an
operation which performs "channel A spies on channel B". It's an operation
which performs "provide me a conduit to snoop the media becing received or
sent on channel B". What that conduit ends up being connected to is up to
the application developer.

I'm not entirely sure of this approach.

On the one hand, having a nice, clean virtual channel driver that has this
explicit purpose is a nice convenience - it is certainly easier to
manipulate than a Local channel (both halves).

On the other hand, it feels like it limits the usage of /snoop a bit, and
makes it a bit more complicated to construct some scenarios. For example,
if I want a SIP channel to spy on another SIP channel, I have to:

(1) Make a bridge
(2) Put my SIP channel in it
(3) Call /snoop on the channel I want to spy on
(4) Take the Snoop channel and put it in the bridge

That's not onerous, but it is a bit more complicated than having /snoop be
an operation on any channel.

I do worry as well that a specific channel driver may have its own rules
that have to be followed via ARI. The lifetime of a Snoop channel would
have to be defined carefully as well - once the channel it is hooked onto
is disposed of, you'd almost certainly have to dispose of the Snoop channel
automatically as well - you don't really "control" the end of the Snoop
channel that was hooked onto the real channel.

I wonder if we're not providing another convenience mechanism similar to
/dial - only this time in the form of a specific channel driver.

Matt

[Joshua Colp]

Post by Matthew Jordan
I'm not entirely sure of this approach.
On the one hand, having a nice, clean virtual channel driver that has
this explicit purpose is a nice convenience - it is certainly easier to
manipulate than a Local channel (both halves).
On the other hand, it feels like it limits the usage of /snoop a bit,
and makes it a bit more complicated to construct some scenarios. For
(1) Make a bridge
(2) Put my SIP channel in it
(3) Call /snoop on the channel I want to spy on
(4) Take the Snoop channel and put it in the bridge

That's an application. The act of spying on another channel is an
application, that's what I'm trying to avoid because it limits things
(take for example all of the gotchas you put in your description) and
also means we now have to continue to add features to this operation. By
providing the snoop as a media conduit primitive we give more control.
That does come at the cost of having to do the above.

Post by Matthew Jordan
That's not onerous, but it is a bit more complicated than having /snoop
be an operation on any channel.

Well, it'll be an operation on any channel - it just won't take another
channel as an argument and connect them together for spying. ^_^

Post by Matthew Jordan
I do worry as well that a specific channel driver may have its own rules
that have to be followed via ARI. The lifetime of a Snoop channel would
have to be defined carefully as well - once the channel it is hooked
onto is disposed of, you'd almost certainly have to dispose of the Snoop
channel automatically as well - you don't really "control" the end of
the Snoop channel that was hooked onto the real channel.

Correct, when the hooks that snoop uses are terminated then it would
hangup. If you want to stop snooping, then you hangup the snoop channel
yourself.

Post by Matthew Jordan
I wonder if we're not providing another convenience mechanism similar to
/dial - only this time in the form of a specific channel driver.

I would say the original approach is the convenience mechanism.

[Daniel Jenkins]

Post by Joshua Colp

Post by Matthew Jordan
I'm not entirely sure of this approach.
On the one hand, having a nice, clean virtual channel driver that has
this explicit purpose is a nice convenience - it is certainly easier to
manipulate than a Local channel (both halves).
On the other hand, it feels like it limits the usage of /snoop a bit,
and makes it a bit more complicated to construct some scenarios. For
(1) Make a bridge
(2) Put my SIP channel in it
(3) Call /snoop on the channel I want to spy on
(4) Take the Snoop channel and put it in the bridge

That's an application. The act of spying on another channel is an

application, that's what I'm trying to avoid because it limits things (take
for example all of the gotchas you put in your description) and also means
we now have to continue to add features to this operation. By providing the
snoop as a media conduit primitive we give more control. That does come at
the cost of having to do the above.

Post by Joshua Colp

Post by Matthew Jordan
That's not onerous, but it is a bit more complicated than having /snoop
be an operation on any channel.

Well, it'll be an operation on any channel - it just won't take another

channel as an argument and connect them together for spying. ^_^

Post by Joshua Colp

Post by Matthew Jordan
I do worry as well that a specific channel driver may have its own rules
that have to be followed via ARI. The lifetime of a Snoop channel would
have to be defined carefully as well - once the channel it is hooked
onto is disposed of, you'd almost certainly have to dispose of the Snoop
channel automatically as well - you don't really "control" the end of
the Snoop channel that was hooked onto the real channel.

Correct, when the hooks that snoop uses are terminated then it would

hangup. If you want to stop snooping, then you hangup the snoop channel
yourself.

Post by Joshua Colp

Post by Matthew Jordan
I wonder if we're not providing another convenience mechanism similar to
/dial - only this time in the form of a specific channel driver.

I would say the original approach is the convenience mechanism.
--
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
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

So thinking outside of the box,

Is chan spy an application written, using the ari, which creates a way to
do all this as a convenience method as such

It would do exactly as matt said, create a channel, put it in the bridge
for you etc, yes you'd need to be able to control channel audio /speech
direction but then that's a setting against a bridge/channel combo...

I'm in between laptops for a few days due to moving work, so sorry if this
makes no sense whatsoever

[Joshua Colp]

Post by Daniel Jenkins
So thinking outside of the box,
Is chan spy an application written, using the ari, which creates a way
to do all this as a convenience method as such
It would do exactly as matt said, create a channel, put it in the bridge
for you etc, yes you'd need to be able to control channel audio /speech
direction but then that's a setting against a bridge/channel combo...
I'm in between laptops for a few days due to moving work, so sorry if
this makes no sense whatsoever

Sorry, this doesn't parse for me. >_>

[BJ Weschke]

+1

Having this layer of granularity also makes it much easier to answer
questions like "How come ARI? What's wrong with AMI/AGI ?"

Post by Joshua Colp

Post by Matthew Jordan
I'm not entirely sure of this approach.
On the one hand, having a nice, clean virtual channel driver that has
this explicit purpose is a nice convenience - it is certainly easier to
manipulate than a Local channel (both halves).
On the other hand, it feels like it limits the usage of /snoop a bit,
and makes it a bit more complicated to construct some scenarios. For
(1) Make a bridge
(2) Put my SIP channel in it
(3) Call /snoop on the channel I want to spy on
(4) Take the Snoop channel and put it in the bridge

That's an application. The act of spying on another channel is an
application, that's what I'm trying to avoid because it limits things
(take for example all of the gotchas you put in your description) and
also means we now have to continue to add features to this operation.
By providing the snoop as a media conduit primitive we give more
control. That does come at the cost of having to do the above.

Post by Matthew Jordan
That's not onerous, but it is a bit more complicated than having /snoop
be an operation on any channel.

Well, it'll be an operation on any channel - it just won't take
another channel as an argument and connect them together for spying. ^_^

Post by Matthew Jordan
I do worry as well that a specific channel driver may have its own rules
that have to be followed via ARI. The lifetime of a Snoop channel would
have to be defined carefully as well - once the channel it is hooked
onto is disposed of, you'd almost certainly have to dispose of the Snoop
channel automatically as well - you don't really "control" the end of
the Snoop channel that was hooked onto the real channel.

Correct, when the hooks that snoop uses are terminated then it would
hangup. If you want to stop snooping, then you hangup the snoop
channel yourself.

Post by Matthew Jordan
I wonder if we're not providing another convenience mechanism similar to
/dial - only this time in the form of a specific channel driver.

I would say the original approach is the convenience mechanism.

[Matthew Jordan]

Post by Joshua Colp

Post by Matthew Jordan
I'm not entirely sure of this approach.
On the one hand, having a nice, clean virtual channel driver that has
this explicit purpose is a nice convenience - it is certainly easier to
manipulate than a Local channel (both halves).
On the other hand, it feels like it limits the usage of /snoop a bit,
and makes it a bit more complicated to construct some scenarios. For
(1) Make a bridge
(2) Put my SIP channel in it
(3) Call /snoop on the channel I want to spy on
(4) Take the Snoop channel and put it in the bridge

That's an application. The act of spying on another channel is an
application, that's what I'm trying to avoid because it limits things (take
for example all of the gotchas you put in your description) and also means
we now have to continue to add features to this operation. By providing the
snoop as a media conduit primitive we give more control. That does come at
the cost of having to do the above.

Yes, it is an application. But it's an application that could also be
achieved easier if there wasn't an explicit channel technology.

I think the way I'm looking at it is that the operation in question isn't
"snoop", but rather "hook" - that is, hook this channel onto this other
channel. Fundamentally, that means that spying/whispering/whatnot is a
direct operation between the channel being hooked and the target of the
operation - whether or not that's a SIP channel or a virtual channel of
some sort doesn't really matter.

Post by Joshua Colp
That's not onerous, but it is a bit more complicated than having /snoop

Post by Matthew Jordan
be an operation on any channel.

Well, it'll be an operation on any channel - it just won't take another
channel as an argument and connect them together for spying. ^_^

This is a tangentially related line of questioning, but what happens if I
call /snoop on a Snoop channel? Or /snoop multiple times on a single
non-Snoop channel? Does the behavior change?

Post by Joshua Colp
I do worry as well that a specific channel driver may have its own rules

Post by Matthew Jordan
that have to be followed via ARI. The lifetime of a Snoop channel would
have to be defined carefully as well - once the channel it is hooked
onto is disposed of, you'd almost certainly have to dispose of the Snoop
channel automatically as well - you don't really "control" the end of
the Snoop channel that was hooked onto the real channel.

Correct, when the hooks that snoop uses are terminated then it would
hangup. If you want to stop snooping, then you hangup the snoop channel
yourself.

Given my previous question, this could be a bit 'interesting' with a chain
of Snoop channels. With a non-Snoop channel technology in a hook operation,
you wouldn't have to automatically destroy the hooked channel when the
target hangs up.

Post by Joshua Colp
I wonder if we're not providing another convenience mechanism similar to

Post by Matthew Jordan
/dial - only this time in the form of a specific channel driver.

I would say the original approach is the convenience mechanism.

[Joshua Colp]

Post by Matthew Jordan
I'm not entirely sure of this approach.
On the one hand, having a nice, clean virtual channel driver that has
this explicit purpose is a nice convenience - it is certainly easier to
manipulate than a Local channel (both halves).
On the other hand, it feels like it limits the usage of /snoop a bit,
and makes it a bit more complicated to construct some scenarios. For
(1) Make a bridge
(2) Put my SIP channel in it
(3) Call /snoop on the channel I want to spy on
(4) Take the Snoop channel and put it in the bridge
That's an application. The act of spying on another channel is an
application, that's what I'm trying to avoid because it limits
things (take for example all of the gotchas you put in your
description) and also means we now have to continue to add features
to this operation. By providing the snoop as a media conduit
primitive we give more control. That does come at the cost of having
to do the above.
Yes, it is an application. But it's an application that could also be
achieved easier if there wasn't an explicit channel technology.

Not exactly. It would be achieved easier if there was an explicit
operation that did exactly what you wanted. The fact that I've proposed
using a Snoop channel is an implementation detail present to leverage
all the functionality we have for interacting with channels themselves.
It could be exposed as a resource and then we'd have to write specific
operations for the resources which duplicates stuff we already have for
channels. At which point having explicit operations as you originally
proposed would be better.

Post by Matthew Jordan
I think the way I'm looking at it is that the operation in question
isn't "snoop", but rather "hook" - that is, hook this channel onto this
other channel. Fundamentally, that means that spying/whispering/whatnot
is a direct operation between the channel being hooked and the target of
the operation - whether or not that's a SIP channel or a virtual channel
of some sort doesn't really matter.

Oh, I see what you are saying now. Meh.

I'm still of the belief that this hooking is an application and going
down that road takes us to /dial again. We'll have to expose all of the
features that ChanSpy allows, and potentially maintain them/add more.
Not to mention there's more of a penalty of doing that and if you want
to (in an ARI app) now allow multiple people to spy using the same hook
you've got more complicated logic unless you start out with this virtual
channel to begin with.

Post by Matthew Jordan
That's not onerous, but it is a bit more complicated than having /snoop
be an operation on any channel.
Well, it'll be an operation on any channel - it just won't take
another channel as an argument and connect them together for spying. ^_^
This is a tangentially related line of questioning, but what happens if
I call /snoop on a Snoop channel? Or /snoop multiple times on a single
non-Snoop channel? Does the behavior change?

You'd snoop on whatever it is snooping on, as far as you want to go. As
for multiple times this is entirely allowed by the audiohooks API.

Post by Matthew Jordan
I do worry as well that a specific channel driver may have its own rules
that have to be followed via ARI. The lifetime of a Snoop channel would
have to be defined carefully as well - once the channel it is hooked
onto is disposed of, you'd almost certainly have to dispose of the Snoop
channel automatically as well - you don't really "control" the end of
the Snoop channel that was hooked onto the real channel.
Correct, when the hooks that snoop uses are terminated then it would
hangup. If you want to stop snooping, then you hangup the snoop
channel yourself.
Given my previous question, this could be a bit 'interesting' with a
chain of Snoop channels. With a non-Snoop channel technology in a hook
operation, you wouldn't have to automatically destroy the hooked channel
when the target hangs up.

Generally you wouldn't snoop on a snoop but if so then you aren't
snooping on the channel you are snooping on that snoop and are subject
to the lifetime of it.

Post by Matthew Jordan
I wonder if we're not providing another convenience mechanism similar to
/dial - only this time in the form of a specific channel driver.
I would say the original approach is the convenience mechanism.

[Matthew Jordan]

Post by Joshua Colp

Post by Matthew Jordan
Yes, it is an application. But it's an application that could also be
achieved easier if there wasn't an explicit channel technology.

Not exactly. It would be achieved easier if there was an explicit
operation that did exactly what you wanted. The fact that I've proposed
using a Snoop channel is an implementation detail present to leverage all
the functionality we have for interacting with channels themselves. It
could be exposed as a resource and then we'd have to write specific
operations for the resources which duplicates stuff we already have for
channels. At which point having explicit operations as you originally
proposed would be better.

Easier:

(1) SIP channel calls /hook?channel_id=other_sip_channel

Done.

Post by Joshua Colp
I think the way I'm looking at it is that the operation in question

Post by Matthew Jordan
isn't "snoop", but rather "hook" - that is, hook this channel onto this
other channel. Fundamentally, that means that spying/whispering/whatnot
is a direct operation between the channel being hooked and the target of
the operation - whether or not that's a SIP channel or a virtual channel
of some sort doesn't really matter.

Oh, I see what you are saying now. Meh.
I'm still of the belief that this hooking is an application and going down
that road takes us to /dial again. We'll have to expose all of the features
that ChanSpy allows, and potentially maintain them/add more. Not to mention
there's more of a penalty of doing that and if you want to (in an ARI app)
now allow multiple people to spy using the same hook you've got more
complicated logic unless you start out with this virtual channel to begin
with.

I do agree that we don't want /hook (or whatever it is called) to turn into
ChanSpy. The only thing it should stipulate - in the same fashion as /snoop
- is the media directions. That's all. Beyond that, I think it's actually
more generic than /snoop, as it doesn't limit what you hook onto another
channel.

<snip>

[Joshua Colp]

Post by Matthew Jordan
Yes, it is an application. But it's an application that could also be
achieved easier if there wasn't an explicit channel technology.
Not exactly. It would be achieved easier if there was an explicit
operation that did exactly what you wanted. The fact that I've
proposed using a Snoop channel is an implementation detail present
to leverage all the functionality we have for interacting with
channels themselves. It could be exposed as a resource and then we'd
have to write specific operations for the resources which duplicates
stuff we already have for channels. At which point having explicit
operations as you originally proposed would be better.
(1) SIP channel calls /hook?channel_id=other_sip_channel
Done.

Yup, can't argue that it is easier.

Post by Matthew Jordan
I think the way I'm looking at it is that the operation in question
isn't "snoop", but rather "hook" - that is, hook this channel onto this
other channel. Fundamentally, that means that
spying/whispering/whatnot
is a direct operation between the channel being hooked and the target of
the operation - whether or not that's a SIP channel or a virtual channel
of some sort doesn't really matter.
Oh, I see what you are saying now. Meh.
I'm still of the belief that this hooking is an application and
going down that road takes us to /dial again. We'll have to expose
all of the features that ChanSpy allows, and potentially maintain
them/add more. Not to mention there's more of a penalty of doing
that and if you want to (in an ARI app) now allow multiple people to
spy using the same hook you've got more complicated logic unless you
start out with this virtual channel to begin with.
I do agree that we don't want /hook (or whatever it is called) to turn
into ChanSpy. The only thing it should stipulate - in the same fashion
as /snoop - is the media directions. That's all. Beyond that, I think
it's actually more generic than /snoop, as it doesn't limit what you
hook onto another channel.

So my question becomes (for everyone)... will a featureless "hook"
operation actually be used for connecting two channels together of a
non-virtual (Local or something else) type, or will everyone have to
resort to always connecting it to a virtual channel to add
features/functionality/further control?

Post by Matthew Jordan
<snip>

[David M. Lee]

Post by Joshua Colp

Post by Matthew Jordan
(1) SIP channel calls /hook?channel_id=other_sip_channel
Done.

Yup, can't argue that it is easier.

By that same argument, /dial was easier. So would /channels/{channelId}/bridgeTo?channel_id=other_sip_channel for creating two-party bridges. But what we’re seeing more advantages keeping the API simpler, by providing more powerful primitives instead of higher level abstractions.

We can build out higher level abstractions on top of these primitives a lot easier than it would be to tease out the primitives later. +1 to snoop channels.

[David M. Lee]

Post by Matthew Jordan
{quote}
Whispering or live monitoring becomes creating a snoop channel, creating
a bridge, and putting another channel in the bridge.
{quote}
Do you envision the /snoop operation working on multiple channel
technologies? Or is the snoop-ing channel a specific technology? The way
that's worded, it makes it sound as if you could not use one SIP channel
to snoop on another SIP channel directly.

The /snoop operation will work on any channel technology. The channel it returns is a specific channel implementation called Snoop. Since you can bridge any technology with any technology anything can act as an active spyer.
The fundamental difference with this approach is that it's not an operation which performs "channel A spies on channel B". It's an operation which performs "provide me a conduit to snoop the media becing received or sent on channel B". What that conduit ends up being connected to is up to the application developer.

When you put it that way, The Snoop channel concept sounds like an end-run around the limitation that a channel can be in at most one bridge at a time. It does so with a really clean conceptual model, too. For someone coming to Asterisk fresh, it would certainly be easier to explain this concept than a Local channel.

There’s a lot of consistency to be gained, both in the API and in the implementation, by going down this route. For example:

POST /ari/channels/{chan1}/hook?channelId={chan2}
POST /ari/bridges/{bridge}/addChannel?channelId={chan2}

What happens when you attempt to add a channel to a bridge that’s currently hooked to another channel? It could reasonably unhook the channel, return a 409 Conflict, or magically do both. We would have to document what the expected behavior is, and that has to become a part of the mental model for ARI users. In the implementation, there’s an additional state a channel could be in, and something we have to deal with in terms of what you can and cannot do on that channel.

Now take the alternative.

POST /ari/channels/{chan1}/snoop => returns the snoop channel
POST /ari/bridges => returns a new bridge
POST /ari/bridges/{snoopBridge}/addChannel?channelId={snoop},{chan2}
POST /ari/bridges/{someOtherBridge}/addChannel?channelId={chan2}

We already have the at-most-one-bridge rule, so the second addChannel follows the same rules the user should already be familiar with (which is to switch the channel from snoopBridge to someOtherBridge). And if this is what they really wanted to do, now they have a path forward to do that.

POST /ari/channels/{chan1}/snoop => returns the snoop channel
POST /ari/bridges => returns a new bridge
POST /ari/bridges/{snoopBridge}/addChannel?channelId={snoop},{chan2}
POST /ari/channels/{chan2}/snoop => returns the second snoop channel
POST /ari/bridges/{someOtherBridge}/addChannel?channelId={snoop2}

[Matthew Jordan]

<snip>

Post by Joshua Colp

Post by Joshua Colp
The /snoop operation will work on any channel technology. The channel it

returns is a specific channel implementation called Snoop. Since you can
bridge any technology with any technology anything can act as an active
spyer.

Post by Joshua Colp
The fundamental difference with this approach is that it's not an

operation which performs "channel A spies on channel B". It's an operation
which performs "provide me a conduit to snoop the media becing received or
sent on channel B". What that conduit ends up being connected to is up to
the application developer.
When you put it that way, The Snoop channel concept sounds like an end-run
around the limitation that a channel can be in at most one bridge at a
time. It does so with a really clean conceptual model, too. For someone
coming to Asterisk fresh, it would certainly be easier to explain this
concept than a Local channel.

I can't argue with that. Local channels are still a very "Asterisk
specific" concept that take a lot to get used to, particularly the concept
of optimization. Avoiding requiring their use is a strong argument.

Post by Joshua Colp
There’s a lot of consistency to be gained, both in the API and in the
POST /ari/channels/{chan1}/hook?channelId={chan2}
POST /ari/bridges/{bridge}/addChannel?channelId={chan2}
What happens when you attempt to add a channel to a bridge that’s
currently hooked to another channel? It could reasonably unhook the
channel, return a 409 Conflict, or magically do both. We would have to
document what the expected behavior is, and that has to become a part of
the mental model for ARI users. In the implementation, there’s an
additional state a channel could be in, and something we have to deal with
in terms of what you can and cannot do on that channel.
Now take the alternative.
POST /ari/channels/{chan1}/snoop => returns the snoop channel
POST /ari/bridges => returns a new bridge
POST /ari/bridges/{snoopBridge}/addChannel?channelId={snoop},{chan2}
POST /ari/bridges/{someOtherBridge}/addChannel?channelId={chan2}
We already have the at-most-one-bridge rule, so the second addChannel
follows the same rules the user should already be familiar with (which is
to switch the channel from snoopBridge to someOtherBridge). And if this is
what they really wanted to do, now they have a path forward to do that.
POST /ari/channels/{chan1}/snoop => returns the snoop channel
POST /ari/bridges => returns a new bridge
POST /ari/bridges/{snoopBridge}/addChannel?channelId={snoop},{chan2}
POST /ari/channels/{chan2}/snoop => returns the second snoop channel
POST /ari/bridges/{someOtherBridge}/addChannel?channelId={snoop2}

I'll concede :-). Going the route of the Snoop channel has obvious benefits
and - if it does turn out to have some drawbacks - doesn't necessarily
preclude letting an arbitrary channel snoop as well in the future.

Matt