[asterisk-dev] ARI Extending Existing Feature: bridge control
mmichelson at digium.com
Wed Dec 17 17:26:51 CST 2014
On 12/17/2014 05:01 PM, Nir Simionovich wrote:
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-dev