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.
Kinsey Moore
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131023/da820e1b/attachment.html>
