[asterisk-dev] [Code Review] 3535: bridge_native_rtp: Reconfigure bridge on removal of framehook; don't send re-INVITE to hungup channel

[Matt Jordan]

> On May 13, 2014, 12:54 p.m., rmudgett wrote:
> > /branches/12/bridges/bridge_native_rtp.c, lines 233-234
> > <https://reviewboard.asterisk.org/r/3535/diff/1/?file=58431#file58431line233>
> >
> >     Soft hangup flags are bit flags.  You need to be using the & operator to test not the == operator.
> >     
> >     if (flags & (ASYNCGOTO | UNBRIDGE))
> >       at least one of the flags is set

Actually, no, this change was intentional. There are times, for example, when both the UNBRIDGE and one of the 'hangup' soft hang up flags is set to True - in which case merely testing for the presence of one of the bit flags results in a false positive here.

This probably *should* test for the value of the two combined together explicitly, which I will add.


- Matt


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


On May 13, 2014, 7:11 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3535/
> -----------------------------------------------------------
> 
> (Updated May 13, 2014, 7:11 a.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch fixes the currently failing pjsip/transfers/blind_transfer/caller_direct_media test (with a few small tweaks to the test as well).
> 
> The test currently fails primarily for two reasons:
> (1) When Bob and Charlie (the transfer target and the transfer destination) enter a bridge together, the framehook remains on the transfer target channel until both channels are in the bridge. As it consumes voice frames, the initial bridge type is a simple bridge. The framehook is removed when both channels are in the bridge; however, this does not currently cause the bridging framework to re-evaluate the bridge. This patch adds a AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a framehook is removed so the bridge can re-evaluate itself.
> 
> (2) When a channel leaves a native RTP bridge, it may be leaving due to being hung up. Sending a re-INVITE to a channel that is about to be hung up is not nice - in fact, there's a good chance we'll send the BYE request before the channel has had a chance to send back a 200 OK. To be somewhat nicer, this patch makes it so that we only send the re-INVITE if there's a chance the channel will survive the native bridging experience.
> 
> 
> Diffs
> -----
> 
>   /branches/12/main/framehook.c 413786 
>   /branches/12/bridges/bridge_native_rtp.c 413786 
> 
> Diff: https://reviewboard.asterisk.org/r/3535/diff/
> 
> 
> Testing
> -------
> 
> Once some timing issues were removed from the test, it passes with this patch.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140515/61fe0b93/attachment-0001.html>