<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>Il giorno Mar 11, 2014, alle ore 9:42 AM, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> ha scritto:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Tue, Mar 11, 2014 at 8:23 AM, Joshua Colp <<a href="mailto:jcolp@digium.com">jcolp@digium.com</a>> wrote:<br><blockquote type="cite">Ben Merrills wrote:<br><blockquote type="cite"><br>Interesting, the advantage I can see in taking your approach Joshua<br>is that any 'requirement' of a bridge, regardless of specific<br>properties (AST_BRIDGE_CAPABILITY_1TO1MIX), could be packaged up,<br>based on a number of properties or other low level specifics.<br><br>In one case 'dtmf_events' in another maybe something like<br>'speaker_events'. And because they are not bridge specific<br>properties, they can be abstracts of other features.<br></blockquote><br><br>Indeed. What I'd like to avoid is consumers having to know the<br>implementation details based on the features they need and having to<br>construct a bridge exactly how they think they need it at a low level.<br>Further down the road the implementation details may change and what they<br>think they need would no longer be true.<br><br><br><blockquote type="cite">In my use case, the actual properties of the bridge are of little<br>consequence, so long as features I need are available. Now, you would<br>have to account for conflicting requests, such as something that<br>requires media to be proxy'd vs native. I can't think of one off<br>hand, but I am sure you get the jist.<br></blockquote><br><br>I can't think of one either. There's no times that native should be<br>required, just times where people may desire it.<br><br></blockquote><br>I think that's a better approach as well. Right now, however, I can<br>only think of two requirements:<br><br></div></blockquote><div><br></div><div>If I may expand on this a bit: I think your first bullet is actually a stand-in for several possible other reasons:</div><br><blockquote type="cite"><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">* I want audio to pass through the core, as opposed to directly<br>between the participants<br></div></blockquote>because…</div><div>* I want to record the bridged audio or otherwise gather input from it</div><div>* I want to be able to play audio to the bridge or to individual bridge participants</div><div>* I want to be able to quickly mute or unmute certain participants (without doing gymnastics like a reINVITE)</div><div>or, of course:<br><blockquote type="cite"><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">* I want DTMF<br></div></blockquote><div><br></div><div>All of the above can be summarized as “I (the application) want to do something with the media."</div><br><div>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.</div><div><br></div><div>/BAK/</div><div><div style="orphans: 2; text-align: -webkit-auto; widows: 2; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span class="Apple-style-span" style="border-collapse: separate; text-align: -webkit-auto; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span class="Apple-style-span" style="border-collapse: separate; text-align: -webkit-auto; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div><br></div></div></span></div></span></div></span></div></span></div></div><blockquote type="cite"><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Everything else is handled transparently by the bridging core.<br><br>As another thought - this actually feels a lot like the mixing types -<br>at least from the perspective of the end user. Wanting a bridge that<br>does a holding mix as opposed to a two-party mix is, loosely speaking,<br>a 'requirement' of the bridge. Maybe the DTMF requirement should just<br>be in that same field, and we figure out which is which internally<br>when parsing it?<br><br>--<span class="Apple-converted-space"> </span><br>Matthew Jordan<br>Digium, Inc. | Engineering Manager<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at:<span class="Apple-converted-space"> </span><a href="http://digium.com/">http://digium.com</a><span class="Apple-converted-space"> </span>&<span class="Apple-converted-space"> </span><a href="http://asterisk.org/">http://asterisk.org</a><br><br></div></blockquote><div><br></div><div><br></div></div><div style="orphans: 2; widows: 2;"><div>-- </div><div>Ben Klang</div><div>Principal/Technology Strategist, Mojo Lingo</div><div><a href="mailto:bklang@mojolingo.com">bklang@mojolingo.com</a></div><div>+1.404.475.4841</div><div><br></div><div>Mojo Lingo -- <i>Voice applications that work like magic</i></div><div><a href="http://mojolingo.com/">http://mojolingo.com</a></div></div><div style="orphans: 2; widows: 2;">Twitter: @MojoLingo</div></body></html>