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

[David M. Lee]

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

> Matthew Jordan wrote:
>> 
>> {quote}
>> Whispering or live monitoring becomes creating a snoop channel, creating
>> a bridge, and putting another channel in the bridge.
>> {quote}
>> 
>> Do you envision the /snoop operation working on multiple channel
>> technologies? Or is the snoop-ing channel a specific technology? The way
>> that's worded, it makes it sound as if you could not use one SIP channel
>> to snoop on another SIP channel directly.
> 
> 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.

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}

-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org