> On Dec. 9, 2013, 8:02 p.m., Mark Michelson wrote: > > The loop situation Matt described is possible. > > > > When ast_channel_suppress() is called, it results in AST_FRAME_VOICE being > > turned into AST_FRAME_NULL. > > If there is a jitter buffer on a channel, then AST_FRAME_NULL gets turned > > into AST_FRAME_VOICE. > > > > While I don't think this will loop infinitely, it may result in the jitter > > buffer being depleted.
Well, nuts. A framehook that mutes a channel and a jitter buffer would certainly be interesting. Josh and I had talked a bit about this in #asterisk-dev. While we need to prevent framehooks from getting stuck in a loop, we also will need to avoid undo processing here. I wonder if all framehooks really need to be treated in this fashion. Jitter buffers certainly don't want to be called multiple times - they've already returned a frame that was in the next slot and/or interpolated a frame. Maybe only certain framehooks should be called again if a frame they previously passed on is transformed. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3046/#review10339 ----------------------------------------------------------- On Dec. 9, 2013, 1:27 a.m., Joshua Colp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3046/ > ----------------------------------------------------------- > > (Updated Dec. 9, 2013, 1:27 a.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > Currently when a frame is changed by a frame hook previous hooks aren't aware > of it. This can be a problem when a previous hook reacts to the types of > frames that a subsequent hook produces. An example of this would be the fax > gateway hook and the PJSIP T.38 hook. Since the fax gateway hook injects T.38 > control frames after the T.38 hook, nothing happens. > > The attached change makes it so if a frame hook produces a different frame > the hook iteration loop is restarted, skipping the hook that has produced the > frame. > > > Diffs > ----- > > /branches/12/main/framehook.c 403448 > > Diff: https://reviewboard.asterisk.org/r/3046/diff/ > > > Testing > ------- > > Ran fax tests, confirmed fixed. > > > 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
