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

[Matt Jordan]

> On June 5, 2014, 12: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".

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


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


On June 4, 2014, 11:43 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3585/
> -----------------------------------------------------------
> 
> (Updated June 4, 2014, 11:43 a.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/ab76402f/attachment.html>