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

[Matthew Jordan]

On Fri, Nov 1, 2013 at 9:22 AM, Joshua Colp <jcolp at digium.com> wrote:

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


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

<snip>


>>  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?
>
>
Sure. If I can /hook any channel onto another, I can use Local channels
(albeit, in a slightly more clunky fashion) to achieve the same
functionality as the Snoop channel technology. However, I can also directly
/hook any channel technology - even those connected to a physical device -
directly onto another channel. With the Snoop channel, the only way I can
achieve that is to create a Bridge and put the Snoop channel and the 'real'
channel into it. Not that it's a 'bad' thing to do that - in fact, that's
useful for the non-technology specific approach as well (/hook with a Local
channel, put the other end in a Bridge so that multiple participants can
listen/whisper) - but it's the *only* way to get a real channel to listen
in.

-- 
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/20131101/2bad3be1/attachment-0001.html>