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: * 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 _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
