Implementation of ChanSpy functionality in ARI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 1, 2013 at 8:15 AM, Joshua Colp <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.

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.


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


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


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

-- 
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/95d4fb74/attachment.html>


[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux