<div dir="ltr">Hello App Developers,<br>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.<br><br>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:<br>[<br>   { "name": "SIP/Alice", ...
  },<br>   { "name": "SIP/Bob", ...
  },<br>   { "name": "SIP/Charlie", ...
  },<br>   { "name": "SIP/David", ...
  }<br>]<br><br>When you GET /ari/bridges, you will receive:<br>[<br>  { "id": "Foo", ... },<br><div>  { "id": "DialBridge", ... }<br>]<br><br>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:<br>[<br>   { "name": "SIP/Alice", ...
  },<br>   { "name": "SIP/Bob", ...
  }<br>]<br><br></div><div>The /ari/bridges query would return:<br>[<br>  { "id": "Foo", ... }<br>]<br><br>
 The rework would also include an optional filter parameter for ARI user
 or Stasis application to increase the available granularity.</div><br><span>Kinsey Moore<br></span><span>Digium, Inc. | Software Developer<br></span><span>445 Jan Davis Drive NW - Huntsville, AL 35806 - US</span> </div>