[asterisk-dev] [Code Review] 2535: Add ability to call a function when a channel leaves the bridging system.

[rmudgett]

> On May 14, 2013, 2:45 a.m., Matt Jordan wrote:
> > /team/group/bridge_construction/include/asterisk/bridging.h, line 1475
> > <https://reviewboard.asterisk.org/r/2535/diff/1/?file=37823#file37823line1475>
> >
> >     "when will"

Changed to "when it will"


> On May 14, 2013, 2:45 a.m., Matt Jordan wrote:
> > /team/group/bridge_construction/main/bridging.c, line 2596
> > <https://reviewboard.asterisk.org/r/2535/diff/1/?file=37824#file37824line2596>
> >
> >     Highlander!

Yes, the after bridge goto also beheads the previously set goto location. :)


> On May 14, 2013, 2:45 a.m., Matt Jordan wrote:
> > /team/group/bridge_construction/main/bridging.c, lines 3143-3146
> > <https://reviewboard.asterisk.org/r/2535/diff/1/?file=37824#file37824line3143>
> >
> >     If a channel has an after_bridge_callback and it successfully runs, would we want to bother with an after_bridge_goto run? Should these return a success failure, and we only execute the next 'goto' option if the prior attempts to hand a channel off after a bridge fail?

The after bridge goto is placed there at the request of the user's dialplan or Bridge AMI action so we should eventually run it if the user's dialplan doesn't overwrite it.

The after bridge callback can only be a detour of the normal thread execution flow so success/fail is meaningless.  However, the callback could call ast_after_bridge_goto_discard() to eliminate any after bridge goto set on the channel.

Please note that any softhangup flag (including the AST_SOFTHANGUP_ASYNCGOTO flag) currently takes precedence over both the callback and goto.


> On May 14, 2013, 2:45 a.m., Matt Jordan wrote:
> > /team/group/bridge_construction/include/asterisk/bridging.h, lines 1458-1467
> > <https://reviewboard.asterisk.org/r/2535/diff/1/?file=37823#file37823line1458>
> >
> >     Document that this locks chan

Done.  And done to many others in this file.  I am wondering how this note will help though.


- rmudgett


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2535/#review8591
-----------------------------------------------------------


On May 13, 2013, 7:12 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2535/
> -----------------------------------------------------------
> 
> (Updated May 13, 2013, 7:12 p.m.)
> 
> 
> Review request for Asterisk Developers, David Lee, Matt Jordan, and Mark Michelson.
> 
> 
> Bugs: ASTERISK-21640
>     https://issues.asterisk.org/jira/browse/ASTERISK-21640
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> There are times when a module would like to gain control of a channel that is already in the bridging system but the module does not want the channel in the bridging system when it gains control.
> 
> 1) The mythical app_queue holding priority bridge when the channel is selected to dial an agent.
> 2) Stasis-HTTP when it needs to gain control before it initiates dialing.
> 3) Attended transferring a bridged channel to an application.
> 
> Example usage:
> ast_after_bridge_callback_set(chan, callback_fn, failed_fn, data);
> ast_bridge_remove(bridge, chan)
> 
> When the channel leaves the bridge the callback_fn(chan, data) will be made.
> 
> 
> Diffs
> -----
> 
>   /team/group/bridge_construction/include/asterisk/bridging.h 388574 
>   /team/group/bridge_construction/main/bridging.c 388574 
> 
> Diff: https://reviewboard.asterisk.org/r/2535/diff/
> 
> 
> Testing
> -------
> 
> Added test code to add a callback when a channel leaves a bridge.
> 1) The callback was called when the channel left the bridge and was not hung up.
> 2) The failed callback was called when the channel simply hung up.
> 
> Added an explicit remove of the callback datastore.
> The failed callback was called as expected.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130514/c95229c8/attachment-0001.htm>