[asterisk-app-dev] ari events stop when two channels join mixing bridge

Matthew Jordan mjordan at digium.com
Tue Mar 11 08:42:18 CDT 2014


On Tue, Mar 11, 2014 at 8:23 AM, Joshua Colp <jcolp at digium.com> wrote:
> Ben Merrills wrote:
>>
>> Interesting, the advantage I can see in taking your approach Joshua
>> is that any 'requirement' of a bridge, regardless of specific
>> properties (AST_BRIDGE_CAPABILITY_1TO1MIX), could be packaged up,
>> based on a number of properties or other low level specifics.
>>
>> In one case 'dtmf_events' in another maybe something like
>> 'speaker_events'. And because they are not bridge specific
>> properties, they can be abstracts of other features.
>
>
> Indeed. What I'd like to avoid is consumers having to know the
> implementation details based on the features they need and having to
> construct a bridge exactly how they think they need it at a low level.
> Further down the road the implementation details may change and what they
> think they need would no longer be true.
>
>
>> In my use case, the actual properties of the bridge are of little
>> consequence, so long as features I need are available. Now, you would
>> have to account for conflicting requests, such as something that
>> requires media to be proxy'd vs native. I can't think of one off
>> hand, but I am sure you get the jist.
>
>
> I can't think of one either. There's no times that native should be
> required, just times where people may desire it.
>

I think that's a better approach as well. Right now, however, I can
only think of two requirements:

 * I want audio to pass through the core, as opposed to directly
between the participants
 * I want DTMF

Everything else is handled transparently by the bridging core.

As another thought - this actually feels a lot like the mixing types -
at least from the perspective of the end user. Wanting a bridge that
does a holding mix as opposed to a two-party mix is, loosely speaking,
a 'requirement' of the bridge. Maybe the DTMF requirement should just
be in that same field, and we figure out which is which internally
when parsing it?

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org



More information about the asterisk-app-dev mailing list