On 1 Nov 2013 13:15, "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. > > >> 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 > > _______________________________________________ > asterisk-app-dev mailing list > asterisk-app-dev at lists.digium.com > http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev So thinking outside of the box, Is chan spy an application written, using the ari, which creates a way to do all this as a convenience method as such It would do exactly as matt said, create a channel, put it in the bridge for you etc, yes you'd need to be able to control channel audio /speech direction but then that's a setting against a bridge/channel combo... I'm in between laptops for a few days due to moving work, so sorry if this makes no sense whatsoever -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131101/5d976a28/attachment.html>
