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

[Ben Klang]

Il giorno Mar 11, 2014, alle ore 9:42 AM, Matthew Jordan <mjordan at digium.com> ha scritto:

> 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:
> 

If I may expand on this a bit: I think your first bullet is actually a stand-in for several possible other reasons:

> * I want audio to pass through the core, as opposed to directly
> between the participants
because…
* I want to record the bridged audio or otherwise gather input from it
* I want to be able to play audio to the bridge or to individual bridge participants
* I want to be able to quickly mute or unmute certain participants (without doing gymnastics like a reINVITE)
or, of course:
> * I want DTMF

All of the above can be summarized as “I (the application) want to do something with the media."

I can’t think of a good reason to want audio to pass through core unless you want to somehow interact with the media.  The only other time I would not want peers to directly exchange media is for NAT reasons, but that’s something that I want Asterisk to figure out for me, not something the application should care about.

/BAK/


> 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
> 


-- 
Ben Klang
Principal/Technology Strategist, Mojo Lingo
bklang at mojolingo.com
+1.404.475.4841

Mojo Lingo -- Voice applications that work like magic
http://mojolingo.com
Twitter: @MojoLingo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140311/4b262357/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140311/4b262357/attachment-0001.pgp>