On Tue, Mar 11, 2014 at 8:23 AM, Joshua Colp < jcolp@xxxxxxxxxx> 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 +1.404.475.4841
Mojo Lingo -- Voice applications that work like magic Twitter: @MojoLingo |
