> On May 7, 2014, 3:41 p.m., Matt Jordan wrote: > > /branches/12/main/channel.c, line 2668 > > <https://reviewboard.asterisk.org/r/3522/diff/1/?file=58291#file58291line2668> > > > > Should the audiohooks/other frame hooks be updated to report the types > > they consume?
The other framehooks I could find consumed voice frames so updating them wouldn't really change anything. I can do a full audit if you want though and make them explicit. As for audiohooks they aren't built upon framehooks and don't have this same problem. - Joshua ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3522/#review11836 ----------------------------------------------------------- On May 5, 2014, 6: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, 6: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
