Framehooks can be used in a reactive manner to execute specific logic
when a frame is received with a certain type and payload. Since it is
possible for framehooks to provide frames it was possible for this
reactive framehook to be unaware of frames it is looking for.
This change makes it so that when framehooks return a modified frame
the code will now re-iterate (from the beginning) and call any
previous framehooks that have not provided a modified frame themselves.
Review: https://reviewboard.asterisk.org/r/3046/
........
Merged revisions 404027 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When checking compatability for the native RTP bridge technology there is a
race condition between clearing framehooks that are destroyed when leaving
certain bridges with certain technologies (such as bridge_native_rtp) and
joining bridges with the bridge_native_rtp technology. Yes, that means a
channel in a native RTP bridge could move to another native RTP bridge and
be considered incompatible with the new native RTP bridge causing it to
revert to a simple bridge technology0. This fixes that bug by ignoring
framehooks that have been marked for destruction when checking for
compatibility with the bridge_native_rtp technology.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
Add support-level indications to many more source files.
Since we now have tools that scan through the source tree looking for files
with specific support levels, we need to ensure that every file that is
a component of a 'core' or 'extended' module (or the main Asterisk binary)
is explicitly marked with its support level. This patch adds support-level
indications to many more source files in tree, but avoids adding them to
third-party libraries that are included in the tree and to source files
that don't end up involved in Asterisk itself.
........
r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
Add a script to enable finding source files without support-levels defined.
........
Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines
Addition of the FrameHook API (AKA AwesomeHooks)
So far all our tools for viewing and manipulating media streams
within Asterisk have been entirely focused on audio. That made
sense then, but is not scalable now. The FrameHook API lets us
tap into and manipulate _ANY_ type of media or signaling passed
on a channel present today or in the future. This tool is a step
in the direction of expanding Asterisk's boundaries and will help
generate some rather interesting applications in the future.
In addition to the FrameHook API, a simple dialplan function
exercising the api has been included as well. This function
is called FRAME_TRACE(). FRAME_TRACE() allows for the internal
ast_frames read and written to a channel to be output. Filters
can be placed on this function to debug only certain types of frames.
This function could be thought of as an internal way of doing
ast_frame packet captures.
Review: https://reviewboard.asterisk.org/r/925/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
