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>
