Matthew Jordan wrote: > > On Fri, Nov 1, 2013 at 9:22 AM, Joshua Colp <jcolp at digium.com > <mailto: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> > <mailto: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. Yup, can't argue that it is easier. > > > 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. So my question becomes (for everyone)... will a featureless "hook" operation actually be used for connecting two channels together of a non-virtual (Local or something else) type, or will everyone have to resort to always connecting it to a virtual channel to add features/functionality/further control? > <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. Much more clunkier, unless we put together something roughly based on Local channels. Otherwise since it's based around going into the dialplan... you've now got the ARI developer mucking more with dialplan. -- 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
