On Wed, Oct 23, 2013 at 5:06 PM, Kinsey Moore <kmoore at digium.com> wrote:
> Hello App Developers,
> We have been thinking about what information is exposed via the ARI requests
> for lists of channels (GET /ari/channels) and bridges (GET /ari/bridges).
> Currently, these requests return all information about any channel or bridge
> in the system.
>
> As an example, imagine you have channels SIP/Alice and SIP/Bob in the
> Stasis() application being bridged by ARI-created bridge Foo. In the same
> system, you also have channels SIP/Charlie and SIP/David being bridged by
> Dial()-created bridge DialBridge. When you GET /ari/channels, you will
> receive:
> [
> { "name": "SIP/Alice", ... },
> { "name": "SIP/Bob", ... },
> { "name": "SIP/Charlie", ... },
> { "name": "SIP/David", ... }
> ]
>
> When you GET /ari/bridges, you will receive:
> [
> { "id": "Foo", ... },
> { "id": "DialBridge", ... }
> ]
>
> This situation is non-ideal since channels SIP/Charlie and SIP/David and
> bridge DialBridge can not be acted upon via ARI. We propose limiting these
> queries to channels and bridges which ARI can affect. In this case, the
> /ari/channels query would return:
> [
> { "name": "SIP/Alice", ... },
> { "name": "SIP/Bob", ... }
> ]
>
> The /ari/bridges query would return:
> [
> { "id": "Foo", ... }
> ]
>
> The rework would also include an optional filter parameter for ARI user or
> Stasis application to increase the available granularity.
>
Sorry, having a hard time understanding what you are proposing. If I
understand, if a channel does not exist within an ARI application, you
don't want to list in via ARI, correct?
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
