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>
