<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 1, 2013 at 10:35 AM, David M. Lee <span dir="ltr"><<a href="mailto:dlee@digium.com" target="_blank">dlee@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Nov 1, 2013, at 7:17 AM, Joshua Colp <<a href="mailto:jcolp@digium.com">jcolp@digium.com</a>> wrote:<br>
<br><br></div></blockquote><div><br></div><div style><snip></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> The /snoop operation will work on any channel technology. The channel it returns is a specific channel implementation called Snoop. Since you can bridge any technology with any technology anything can act as an active spyer.<br>
><br>
> The fundamental difference with this approach is that it's not an operation which performs "channel A spies on channel B". It's an operation which performs "provide me a conduit to snoop the media becing received or sent on channel B". What that conduit ends up being connected to is up to the application developer.<br>
<br>
</div>When you put it that way, The Snoop channel concept sounds like an end-run around the limitation that a channel can be in at most one bridge at a time. It does so with a really clean conceptual model, too. For someone coming to Asterisk fresh, it would certainly be easier to explain this concept than a Local channel.<br>
<br></blockquote><div><br></div><div style>I can't argue with that. Local channels are still a very "Asterisk specific" concept that take a lot to get used to, particularly the concept of optimization. Avoiding requiring their use is a strong argument.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There’s a lot of consistency to be gained, both in the API and in the implementation, by going down this route. For example:<br>
<br>
POST /ari/channels/{chan1}/hook?channelId={chan2}<br>
POST /ari/bridges/{bridge}/addChannel?channelId={chan2}<br>
<br>
What happens when you attempt to add a channel to a bridge that’s currently hooked to another channel? It could reasonably unhook the channel, return a 409 Conflict, or magically do both. We would have to document what the expected behavior is, and that has to become a part of the mental model for ARI users. In the implementation, there’s an additional state a channel could be in, and something we have to deal with in terms of what you can and cannot do on that channel.<br>
<br>
Now take the alternative.<br>
<br>
POST /ari/channels/{chan1}/snoop => returns the snoop channel<br>
POST /ari/bridges => returns a new bridge<br>
POST /ari/bridges/{snoopBridge}/addChannel?channelId={snoop},{chan2}<br>
POST /ari/bridges/{someOtherBridge}/addChannel?channelId={chan2}<br>
<br>
We already have the at-most-one-bridge rule, so the second addChannel follows the same rules the user should already be familiar with (which is to switch the channel from snoopBridge to someOtherBridge). And if this is what they really wanted to do, now they have a path forward to do that.<br>
<br>
POST /ari/channels/{chan1}/snoop => returns the snoop channel<br>
POST /ari/bridges => returns a new bridge<br>
POST /ari/bridges/{snoopBridge}/addChannel?channelId={snoop},{chan2}<br>
POST /ari/channels/{chan2}/snoop => returns the second snoop channel<br>
POST /ari/bridges/{someOtherBridge}/addChannel?channelId={snoop2}<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div style>I'll concede :-). Going the route of the Snoop channel has obvious benefits and - if it does turn out to have some drawbacks - doesn't necessarily preclude letting an arbitrary channel snoop as well in the future.</div>
<div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>