[asterisk-dev] [Code Review] 3585: bridge_native_rtp: Reconfigure bridge on removal of framehook - take 2

[Phil Mickelson]

ast_channel_exit_bridge?

Phil Mickelson


On Thu, Jun 5, 2014 at 1:58 PM, Matt Jordan <reviewboard at asterisk.org>
wrote:

>    This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3585/
>
> On June 5th, 2014, 12:45 p.m. CDT, *Mark Michelson* wrote:
>
>   /branches/12/include/asterisk/channel.h
> <https://reviewboard.asterisk.org/r/3585/diff/1/?file=59216#file59216line4300> (Diff
> revision 1)
>
> struct ast_bridge *ast_channel_get_bridge(const struct ast_channel *chan);
>
>    4300
>
> int ast_channel_is_leaving_bridge(struct ast_channel *chan);
>
>   It's a tough thing to do, but I'd like to see this function's name imply that channels that are being hung up do not count as "leaving the bridge".
>
>  The intent is for a function to test to see if a channel that would normally be "hung up" (ast_check_hangup would return true) just wants out of a bridge, and is not actually "hung up".
>
> Our dual purposing of soft hangup flags was a really bad idea.
>
> Names I've thought of, besides this one:
>  - ast_channel_wants_out_of_bridge
>  - ast_channel_check_hangup_but_not_really_hungup
>  - ast_channel_will_survive_this_operation
>
> (Kidding, of course)
>
> Can you think of anything else to call this?
>
>
> - Matt
>
> On June 4th, 2014, 11:43 a.m. CDT, Matt Jordan wrote:
>   Review request for Asterisk Developers.
> By Matt Jordan.
>
> *Updated June 4, 2014, 11:43 a.m.*
>  *Repository: * Asterisk
> Description
>
> This patch is a re-do of review 3535.
>
> When review request 3535 was merged, a major problem with it was uncovered. UNBRIDGE soft hangup flags have a catastrophic effect on the pbx core if they leak out from the bridge layer: the channel gets hung up. With the number of threads involved in a blind transfer, and with the initial patch, it was likely that this would occur. This caused a large number of test failures
>
> This patch is nearly identical with the one proposed in review 3535, save for the following changes:
>  - We explicitly clear the UNBRIDGE flag when setting an after goto on a channel in a bridge
>  - Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it
>
>   Testing
>
> The blind transfer tests for PJSIP now pass (fingers crossed). See review 3586.
>
>   Diffs
>
>    - /branches/12/main/pbx.c (414996)
>    - /branches/12/main/framehook.c (414996)
>    - /branches/12/main/channel.c (414996)
>    - /branches/12/main/bridge_channel.c (414996)
>    - /branches/12/main/bridge_after.c (414996)
>    - /branches/12/include/asterisk/channel.h (414996)
>    - /branches/12/bridges/bridge_native_rtp.c (414996)
>
> View Diff <https://reviewboard.asterisk.org/r/3585/diff/>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140605/65c3d43b/attachment-0001.html>