[asterisk-dev] [Code Review] 3046: framehooks: Re-iterate when frame is changed

Matt Jordan reviewboard at asterisk.org
Mon Dec 9 20:20:53 CST 2013



> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131210/d524721e/attachment.html>


More information about the asterisk-dev mailing list