----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3522/#review11835 -----------------------------------------------------------
/branches/12/main/framehook.c <https://reviewboard.asterisk.org/r/3522/#comment21702> I'm assuming that attaching the framehook during a bridge requires an unbridge simply to force the smart bridging logic to kick in and re-evaluate the allowed mixing technology. The documentation of this soft hangup flag is a little wonky: /*! * Used to break a bridge so the channel can be spied upon * instead of actually hanging up. */ AST_SOFTHANGUP_UNBRIDGE = (1 << 6), Looking at this code, I would assume that it would permanently break the bridge, instead of just causing the bridge to check if it needs to be reconfigured. It may be a good idea to update the documentation of this soft hangup flag as part of this patch. - Matt Jordan On May 5, 2014, 1:48 p.m., Joshua Colp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3522/ > ----------------------------------------------------------- > > (Updated May 5, 2014, 1:48 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-23497 > https://issues.asterisk.org/jira/browse/ASTERISK-23497 > > > Repository: Asterisk > > > Description > ------- > > Framehooks currently provide no mechanism for anything to determine what > frame types they are consuming. This is problematic for logic which uses this > information to determine what to do (such as native bridging). This means > that code has had to block certain things (such as RTP native bridging) if > *any* framehooks are present - even if they are not interested in the media > at all. The attached change adds some functionality to improve this: > > 1. An optional callback has been added to the framehook interface which > allows the framehook implementation to be queried for whether it is consuming > a frame type or not. If this callback is not implemented it is assumed they > are consuming all types, which is the previous behavior. > 2. Some framehooks have had the callback implemented. > 3. The unbridge softhangup flag is now being set when a framehook is attached > or detached to trigger a re-evaluation within the bridge universe. > > These together allow the bridge_native_rtp module to be smarter about when to > prevent its use. > > > Diffs > ----- > > /branches/12/main/framehook.c 413303 > /branches/12/main/channel.c 413303 > /branches/12/main/bridge_basic.c 413303 > /branches/12/include/asterisk/framehook.h 413303 > /branches/12/bridges/bridge_native_rtp.c 413303 > > Diff: https://reviewboard.asterisk.org/r/3522/diff/ > > > Testing > ------- > > Performed numerous attended transfers across SIP and PJSIP. Before patch > simple_bridge would be used after completion for attended. After patch the > expected native_rtp would be used. > > > Thanks, > > Joshua Colp > >
-- _____________________________________________________________________ -- 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
