[asterisk-dev] ARI Extending Existing Feature: bridge control

[Mark Michelson]

On 12/17/2014 05:01 PM, Nir Simionovich wrote:
> <snip>
> Let's try to stick to the tech for now and answer the first two questions:
>
>   1. Is there a way to obtain the information in ast_bridge_config for 
> each of the iterated bridges?

ast_bridge_config is not used at all for Stasis bridges. 
ast_bridge_config describes bridge features that basic bridges use based 
on Dial(), Queue(), and FollowMe() features. For instance, when Dial is 
called with the 't' and 'T' options, the ast_bridge_config indicates 
that the caller and callee can perform DTMF transfers based on 
features.conf settings.

For Stasis bridges, the idea of using ast_bridge_config does not make 
sense for several reasons

1) Stasis applications are intended to be fully in control of everything 
that happens in the bridge. There should be nothing that the 
participants should be able to do independently of the Stasis 
application to change the bridge.
2) ast_bridge_config relies heavily on the concept that a bridge 
contains exactly two participants. For basic bridges, this assumption 
holds. Stasis bridges can have any number of participants, though, so 
this structure doesn't work well.

>   2. Is there a way to manipulate the configuration of the bridge, via 
> modifying the associated bridge configuration in real time?

The configuration of a Stasis bridge is defined by the Stasis 
application that creates and manipulates the bridge. It is up to the 
Stasis application to determine properties of the bridge and manipulate 
the bridge based on those properties. Whether you can manipulate this in 
real time is based on the programming language and runtime model of the 
ARI library you use.

>
> Nir
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141217/36ababac/attachment.html>