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

Ben Merrills b.merrills at mersontech.co.uk
Tue Mar 11 08:15:17 CDT 2014


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.

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.

Ben

> 
> Greetings everyone,
> 
> I'm currently working on one of the issues that Ben ran into where DTMF
> events may stop when channels are bridged together in ARI[1].
> 
> The suggestion from Matt was to add a capabilities field to bridge creation
> that allows capabilities to be specified which then influence the bridge itself.
> One of these would be a native capability which when set would enable
> native bridging. After implementing and playing with this I'm not sure I
> actually like it. I think it exposes internal details that then require an extra
> explanation and understanding of.
> 
> I'd like to propose an alternative option which is to be able to specify what
> you need from the bridge when creating it. This already exists in the form of
> the bridge type but would also include more high level properties. As I'm
> working on DTMF the first one would be something like "dtmf_events". For
> what Ben is working on this would mean he would create a mixing bridge
> which ensures DTMF events occur. Internally this may mean that native
> bridging gets disabled but to him it doesn't matter and he doesn't have to
> know this. It's an implementation detail.
> 
> Thoughts?
> 
> [1] https://issues.asterisk.org/jira/browse/ASTERISK-23437
> 
> --
> 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 at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev



More information about the asterisk-app-dev mailing list