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

[Mark Michelson]

> On June 5, 2014, 5:45 p.m., Mark Michelson wrote:
> > /branches/12/include/asterisk/channel.h, line 4300
> > <https://reviewboard.asterisk.org/r/3585/diff/1/?file=59216#file59216line4300>
> >
> >     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".
> 
> Matt Jordan wrote:
>     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?

Um...no. ast_channel_check_break_bridge() is the only thing I can think of but it's not any better (in fact it's worse) than ast_channel_is_leaving_bridge().


- Mark


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


On June 4, 2014, 4:43 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3585/
> -----------------------------------------------------------
> 
> (Updated June 4, 2014, 4:43 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> 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
> 
> 
> 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 
> 
> Diff: https://reviewboard.asterisk.org/r/3585/diff/
> 
> 
> Testing
> -------
> 
> The blind transfer tests for PJSIP now pass (fingers crossed). See review 3586.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140605/e342fa53/attachment.html>