<div dir="ltr">Amazing, clear answer. Thank you so much Richard. That documentation link is also very helpful.<div><br></div><div>Regards,</div><div>Steve</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 20 Nov 2017 at 17:56 Richard Mudgett <<a href="mailto:rmudgett@digium.com">rmudgett@digium.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 20, 2017 at 7:03 AM, Steve Davies <span dir="ltr"><<a href="mailto:davies147@gmail.com" target="_blank">davies147@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><br>Perhaps the answer to this will be pointing me at some documentation - That is fine, but I've failed to find it so far, so forgive me if the following is a dumb question.<br><br>With Asterisk-11 I added a built-in feature which allowed a very customised version of stopping call recording on a bridge, playing back different messages to each channel, and so forth based on some channel variables, and depending whether the feature was enabled per channel.<br><br>I want to port this to Asterisk-15, but am struggling to understand the new bridge playback methods. I variously see ast_bridge_channel_queue_playfile(), ast_bridge_channel_write_playfile(), or even one followed by the other. <br><br>What I'd like to do is queue playback message(s) to both halves of a bridge simultaneously so that the bridge will resume once all messages on both channels are complete.<br><br>An a first read-through, I was fairly convinced that I would be able to just call ast_bridge_channel_queue_playfile() as many times as needed on both the bridge, and peer channels, and magic would happen, until I saw the code in bridges/bridge_builtin_features.c: start_automixmonitor(), after which I became most confused :)<br><br>Help please?</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Reaching across the bridge is not allowed.  A channel in a bridge is not supposed to know</div><div>who it is exchanging frames with because the channel could be exchanging frames with zero</div><div> or more other channels at any given time.  Over time, the participant channels in the bridge</div><div> could change.  Channels could be added, removed, or swapped with other channels in the bridge.<br></div><br><div>ast_bridge_channel_queue_playfile() - This function queues the playfile onto the channel itself</div><div>for the channel to play the file.</div><div><br></div><div>ast_bridge_channel_write_playfile() - This function puts the playfile request into the bridge for</div><div>the other channels in the bridge to play the file.  The bridge handles distributing the request to</div><div> all other channels in the bridge according to the bridge technology.</div><div><br></div><div>More information can be found here [1].<br></div><br><div>Richard</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">[1] <a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project</a><br></div></div></div>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>