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.
-- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
