Implementation of ChanSpy functionality in ARI

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

 



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.

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

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

> 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



[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