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

[Joshua Colp]

Matthew Jordan wrote:
>
> On Fri, Nov 1, 2013 at 8:15 AM, Joshua Colp <jcolp at digium.com
> <mailto:jcolp at digium.com>> wrote:
>
>     Matthew Jordan wrote:
>
>         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 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.

> 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.

>
>         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.

>
>
>         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.

>
>
>         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.
>
>
>  From the perspective of achieving ChanSpy like functionality, maybe.
> But from having a truly generic ability to hook a channel onto another
> channel, then the approach you've outlined sacrifices flexibility for
> convenience.

Can you clarify that?

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