Review Board 1.7.16

Improve behavior of ast_answer() to not lose incoming frames

Review Request #196 - Created March 16, 2009 and submitted

Kevin Fleming
ast_answer(), when supplied a delay before returning to the caller, use ast_safe_sleep() to implement the delay. Unfortunately during this time any incoming frames are discarded, which is problematic for T.38 re-INVITES and other sorts of channel operations.

When a delay is not passed to ast_answer(), it still delays for up to 500 milliseconds, waiting for media to arrive. Again, though, it discards any control frames, or non-voice media frames.

This patch rectifies this situation, by storing all incoming frames during the delay period on a list, and then requeuing them onto the channel before returning to the caller.
Compile testing only.
Review request changed
Updated (March 17, 2009, 1:42 a.m.)
Minor update to ensure that when a delay is requested that the full delay is honored.
Ship it!
Posted (March 17, 2009, 4:24 a.m.)


/trunk/include/asterisk/channel.h (Diff revision 3)
It may also be worth noting that the channel does get locked internally to the function.  This is very useful to know when dealing with locking order issues.
/trunk/main/channel.c (Diff revision 3)
superfluous semicolon
/trunk/main/features.c (Diff revision 3)
trailing space
Ship it!
Posted (March 17, 2009, 4:27 a.m.)


/trunk/main/features.c (Diff revision 3)
This comment isn't actually true anymore after our further discussion. We don't service the peer here. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to