[asterisk-app-dev] Implementation of ChanSpy functionality in ARI

[Matthew Jordan]

On Fri, Nov 1, 2013 at 10:35 AM, David M. Lee <dlee at digium.com> wrote:

> On Nov 1, 2013, at 7:17 AM, Joshua Colp <jcolp at digium.com> wrote:
>
>
>
<snip>


> >
> > 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.
> >
> > 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.
>
> 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.
>
>
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.


> There’s a lot of consistency to be gained, both in the API and in the
> implementation, by going down this route. For example:
>
>     POST /ari/channels/{chan1}/hook?channelId={chan2}
>     POST /ari/bridges/{bridge}/addChannel?channelId={chan2}
>
> 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.
>
> Now take the alternative.
>
>     POST /ari/channels/{chan1}/snoop => returns the snoop channel
>     POST /ari/bridges => returns a new bridge
>     POST /ari/bridges/{snoopBridge}/addChannel?channelId={snoop},{chan2}
>     POST /ari/bridges/{someOtherBridge}/addChannel?channelId={chan2}
>
> 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.
>
>     POST /ari/channels/{chan1}/snoop => returns the snoop channel
>     POST /ari/bridges => returns a new bridge
>     POST /ari/bridges/{snoopBridge}/addChannel?channelId={snoop},{chan2}
>     POST /ari/channels/{chan2}/snoop => returns the second snoop channel
>     POST /ari/bridges/{someOtherBridge}/addChannel?channelId={snoop2}
>
>
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.

Matt

-- 
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/20131104/a8733c11/attachment.html>