Files
asterisk/include/asterisk/frame.h

627 lines
24 KiB
C
Raw Normal View History

/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 1999 - 2005, Digium, Inc.
*
* Mark Spencer <markster@digium.com>
*
* See http://www.asterisk.org for more information about
* the Asterisk project. Please do not directly contact
* any of the maintainers of this project for assistance;
* the project provides a web site, mailing lists and IRC
* channels for your use.
*
* This program is free software, distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree.
*/
/*! \file
* \brief Asterisk internal frame definitions.
* \arg For an explanation of frames, see \ref Def_Frame
* \arg Frames are send of Asterisk channels, see \ref Def_Channel
*/
#ifndef _ASTERISK_FRAME_H
#define _ASTERISK_FRAME_H
#if defined(__cplusplus) || defined(c_plusplus)
extern "C" {
#endif
#include <sys/time.h>
#include "asterisk/format.h"
#include "asterisk/endian.h"
#include "asterisk/linkedlists.h"
/*!
* \page Def_Frame AST Multimedia and signalling frames
* \section Def_AstFrame What is an ast_frame ?
* A frame of data read used to communicate between
* between channels and applications.
* Frames are divided into frame types and subclasses.
*
* \par Frame types
* \arg \b VOICE: Voice data, subclass is codec (AST_FORMAT_*)
* \arg \b VIDEO: Video data, subclass is codec (AST_FORMAT_*)
* \arg \b DTMF: A DTMF digit, subclass is the digit
* \arg \b IMAGE: Image transport, mostly used in IAX
* \arg \b TEXT: Text messages and character by character (real time text)
* \arg \b HTML: URL's and web pages
* \arg \b MODEM: Modulated data encodings, such as T.38 and V.150
* \arg \b IAX: Private frame type for the IAX protocol
* \arg \b CNG: Comfort noice frames
* \arg \b CONTROL:A control frame, subclass defined as AST_CONTROL_
* \arg \b NULL: Empty, useless frame
*
* \par Files
* \arg frame.h Definitions
* \arg frame.c Function library
* \arg \ref Def_Channel Asterisk channels
* \section Def_ControlFrame Control Frames
* Control frames send signalling information between channels
* and devices. They are prefixed with AST_CONTROL_, like AST_CONTROL_FRAME_HANGUP
* \arg \b HANGUP The other end has hungup
* \arg \b RING Local ring
* \arg \b RINGING The other end is ringing
* \arg \b ANSWER The other end has answered
* \arg \b BUSY Remote end is busy
* \arg \b TAKEOFFHOOK Make it go off hook (what's "it" ? )
* \arg \b OFFHOOK Line is off hook
* \arg \b CONGESTION Congestion (circuit is busy, not available)
* \arg \b FLASH Other end sends flash hook
* \arg \b WINK Other end sends wink
* \arg \b OPTION Send low-level option
* \arg \b RADIO_KEY Key radio (see app_rpt.c)
* \arg \b RADIO_UNKEY Un-key radio (see app_rpt.c)
* \arg \b PROGRESS Other end indicates call progress
* \arg \b PROCEEDING Indicates proceeding
* \arg \b HOLD Call is placed on hold
* \arg \b UNHOLD Call is back from hold
* \arg \b VIDUPDATE Video update requested
* \arg \b SRCUPDATE The source of media has changed (RTP marker bit must change)
* \arg \b SRCCHANGE Media source has changed (RTP marker bit and SSRC must change)
* \arg \b CONNECTED_LINE Connected line has changed
* \arg \b REDIRECTING Call redirecting information has changed.
*/
/*!
* \brief Frame types
*
* \note It is important that the values of each frame type are never changed,
* because it will break backwards compatability with older versions.
* This is because these constants are transmitted directly over IAX2.
*/
enum ast_frame_type {
/*! DTMF end event, subclass is the digit */
AST_FRAME_DTMF_END = 1,
/*! Voice data, subclass is AST_FORMAT_* */
AST_FRAME_VOICE,
/*! Video frame, maybe?? :) */
AST_FRAME_VIDEO,
/*! A control frame, subclass is AST_CONTROL_* */
AST_FRAME_CONTROL,
/*! An empty, useless frame */
AST_FRAME_NULL,
/*! Inter Asterisk Exchange private frame type */
AST_FRAME_IAX,
/*! Text messages */
AST_FRAME_TEXT,
/*! Image Frames */
AST_FRAME_IMAGE,
/*! HTML Frame */
AST_FRAME_HTML,
/*! Comfort Noise frame (subclass is level of CNG in -dBov),
body may include zero or more 8-bit quantization coefficients */
AST_FRAME_CNG,
/*! Modem-over-IP data streams */
AST_FRAME_MODEM,
/*! DTMF begin event, subclass is the digit */
AST_FRAME_DTMF_BEGIN,
/*! Internal bridge module action. */
AST_FRAME_BRIDGE_ACTION,
/*! Internal synchronous bridge module action.
* Synchronous bridge actions may be queued onto bridge
* channels, but they absolutely must not ever be written
* directly into bridges.
*/
AST_FRAME_BRIDGE_ACTION_SYNC,
};
#define AST_FRAME_DTMF AST_FRAME_DTMF_END
Merged revisions 98943 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines Commit a fix for some memory access errors pointed out by the valgrind2.txt output on issue #11698. The issue here is that it is possible for an instance of a translator to get destroyed while the frame allocated as a part of the translator is still being processed. Specifically, this is possible anywhere between a call to ast_read() and ast_frame_free(), which is _a lot_ of places in the code. The reason this happens is that the channel might get masqueraded during this time. During a masquerade, existing translation paths get destroyed. So, this patch fixes the issue in an API and ABI compatible way. (This one is for you, paravoid!) It changes an int in ast_frame to be used as flag bits. The 1 bit is still used to indicate that the frame contains timing information. Also, a second flag has been added to indicate that the frame came from a translator. When a frame with this flag gets released and has this flag, a function is called in translate.c to let it know that this frame is doing being processed. At this point, the flag gets cleared. Also, if the translator was requested to be destroyed while its internal frame still had this flag set, its destruction has been deffered until it finds out that the frame is no longer being processed. Admittedly, this feels like a hack. But, it does fix the issue, and I was not able to think of a better solution ... ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-01-15 23:31:53 +00:00
enum {
/*! This frame contains valid timing information */
AST_FRFLAG_HAS_TIMING_INFO = (1 << 0),
/*! This frame has been requeued */
AST_FRFLAG_REQUEUED = (1 << 1),
Merged revisions 98943 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines Commit a fix for some memory access errors pointed out by the valgrind2.txt output on issue #11698. The issue here is that it is possible for an instance of a translator to get destroyed while the frame allocated as a part of the translator is still being processed. Specifically, this is possible anywhere between a call to ast_read() and ast_frame_free(), which is _a lot_ of places in the code. The reason this happens is that the channel might get masqueraded during this time. During a masquerade, existing translation paths get destroyed. So, this patch fixes the issue in an API and ABI compatible way. (This one is for you, paravoid!) It changes an int in ast_frame to be used as flag bits. The 1 bit is still used to indicate that the frame contains timing information. Also, a second flag has been added to indicate that the frame came from a translator. When a frame with this flag gets released and has this flag, a function is called in translate.c to let it know that this frame is doing being processed. At this point, the flag gets cleared. Also, if the translator was requested to be destroyed while its internal frame still had this flag set, its destruction has been deffered until it finds out that the frame is no longer being processed. Admittedly, this feels like a hack. But, it does fix the issue, and I was not able to think of a better solution ... ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-01-15 23:31:53 +00:00
};
media formats: re-architect handling of media for performance improvements In the old times media formats were represented using a bit field. This was fast but had a few limitations. 1. Asterisk was limited in how many formats it could handle. 2. Formats, being a bit field, could not include any attribute information. A format was strictly its type, e.g., "this is ulaw". This was changed in Asterisk 10 (see https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for notes on that work) which led to the creation of the ast_format structure. This structure allowed Asterisk to handle attributes and bundle information with a format. Additionally, ast_format_cap was created to act as a container for multiple formats that, together, formed the capability of some entity. Another mechanism was added to allow logic to be registered which performed format attribute negotiation. Everywhere throughout the codebase Asterisk was changed to use this strategy. Unfortunately, in software, there is no free lunch. These new capabilities came at a cost. Performance analysis and profiling showed that we spend an inordinate amount of time comparing, copying, and generally manipulating formats and their related structures. Basic prototyping has shown that a reasonably large performance improvement could be made in this area. This patch is the result of that project, which overhauled the media format architecture and its usage in Asterisk to improve performance. Generally, the new philosophy for handling formats is as follows: * The ast_format structure is reference counted. This removed a large amount of the memory allocations and copying that was done in prior versions. * In order to prevent race conditions while keeping things performant, the ast_format structure is immutable by convention and lock-free. Violate this tenet at your peril! * Because formats are reference counted, codecs are also reference counted. The Asterisk core generally provides built-in codecs and caches the ast_format structures created to represent them. Generally, to prevent inordinate amounts of module reference bumping, codecs and formats can be added at run-time but cannot be removed. * All compatibility with the bit field representation of codecs/formats has been moved to a compatibility API. The primary user of this representation is chan_iax2, which must continue to maintain its bit-field usage of formats for interoperability concerns. * When a format is negotiated with attributes, or when a format cannot be represented by one of the cached formats, a new format object is created or cloned from an existing format. That format may have the same codec underlying it, but is a different format than a version of the format with different attributes or without attributes. * While formats are reference counted objects, the reference count maintained on the format should be manipulated with care. Formats are generally cached and will persist for the lifetime of Asterisk and do not explicitly need to have their lifetime modified. An exception to this is when the user of a format does not know where the format came from *and* the user may outlive the provider of the format. This occurs, for example, when a format is read from a channel: the channel may have a format with attributes (hence, non-cached) and the user of the format may last longer than the channel (if the reference to the channel is released prior to the format's reference). For more information on this work, see the API design notes: https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite Finally, this work was the culmination of a large number of developer's efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the work in the Asterisk core, chan_sip, and was an invaluable resource in peer reviews throughout this project. There were a substantial number of patches contributed during this work; the following issues/patch names simply reflect some of the work (and will cause the release scripts to give attribution to the individuals who work on them). Reviews: https://reviewboard.asterisk.org/r/3814 https://reviewboard.asterisk.org/r/3808 https://reviewboard.asterisk.org/r/3805 https://reviewboard.asterisk.org/r/3803 https://reviewboard.asterisk.org/r/3801 https://reviewboard.asterisk.org/r/3798 https://reviewboard.asterisk.org/r/3800 https://reviewboard.asterisk.org/r/3794 https://reviewboard.asterisk.org/r/3793 https://reviewboard.asterisk.org/r/3792 https://reviewboard.asterisk.org/r/3791 https://reviewboard.asterisk.org/r/3790 https://reviewboard.asterisk.org/r/3789 https://reviewboard.asterisk.org/r/3788 https://reviewboard.asterisk.org/r/3787 https://reviewboard.asterisk.org/r/3786 https://reviewboard.asterisk.org/r/3784 https://reviewboard.asterisk.org/r/3783 https://reviewboard.asterisk.org/r/3778 https://reviewboard.asterisk.org/r/3774 https://reviewboard.asterisk.org/r/3775 https://reviewboard.asterisk.org/r/3772 https://reviewboard.asterisk.org/r/3761 https://reviewboard.asterisk.org/r/3754 https://reviewboard.asterisk.org/r/3753 https://reviewboard.asterisk.org/r/3751 https://reviewboard.asterisk.org/r/3750 https://reviewboard.asterisk.org/r/3748 https://reviewboard.asterisk.org/r/3747 https://reviewboard.asterisk.org/r/3746 https://reviewboard.asterisk.org/r/3742 https://reviewboard.asterisk.org/r/3740 https://reviewboard.asterisk.org/r/3739 https://reviewboard.asterisk.org/r/3738 https://reviewboard.asterisk.org/r/3737 https://reviewboard.asterisk.org/r/3736 https://reviewboard.asterisk.org/r/3734 https://reviewboard.asterisk.org/r/3722 https://reviewboard.asterisk.org/r/3713 https://reviewboard.asterisk.org/r/3703 https://reviewboard.asterisk.org/r/3689 https://reviewboard.asterisk.org/r/3687 https://reviewboard.asterisk.org/r/3674 https://reviewboard.asterisk.org/r/3671 https://reviewboard.asterisk.org/r/3667 https://reviewboard.asterisk.org/r/3665 https://reviewboard.asterisk.org/r/3625 https://reviewboard.asterisk.org/r/3602 https://reviewboard.asterisk.org/r/3519 https://reviewboard.asterisk.org/r/3518 https://reviewboard.asterisk.org/r/3516 https://reviewboard.asterisk.org/r/3515 https://reviewboard.asterisk.org/r/3512 https://reviewboard.asterisk.org/r/3506 https://reviewboard.asterisk.org/r/3413 https://reviewboard.asterisk.org/r/3410 https://reviewboard.asterisk.org/r/3387 https://reviewboard.asterisk.org/r/3388 https://reviewboard.asterisk.org/r/3389 https://reviewboard.asterisk.org/r/3390 https://reviewboard.asterisk.org/r/3321 https://reviewboard.asterisk.org/r/3320 https://reviewboard.asterisk.org/r/3319 https://reviewboard.asterisk.org/r/3318 https://reviewboard.asterisk.org/r/3266 https://reviewboard.asterisk.org/r/3265 https://reviewboard.asterisk.org/r/3234 https://reviewboard.asterisk.org/r/3178 ASTERISK-23114 #close Reported by: mjordan media_formats_translation_core.diff uploaded by kharwell (License 6464) rb3506.diff uploaded by mjordan (License 6283) media_format_app_file.diff uploaded by kharwell (License 6464) misc-2.diff uploaded by file (License 5000) chan_mild-3.diff uploaded by file (License 5000) chan_obscure.diff uploaded by file (License 5000) jingle.diff uploaded by file (License 5000) funcs.diff uploaded by file (License 5000) formats.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) bridges.diff uploaded by file (License 5000) mf-codecs-2.diff uploaded by file (License 5000) mf-app_fax.diff uploaded by file (License 5000) mf-apps-3.diff uploaded by file (License 5000) media-formats-3.diff uploaded by file (License 5000) ASTERISK-23715 rb3713.patch uploaded by coreyfarrell (License 5909) rb3689.patch uploaded by mjordan (License 6283) ASTERISK-23957 rb3722.patch uploaded by mjordan (License 6283) mf-attributes-3.diff uploaded by file (License 5000) ASTERISK-23958 Tested by: jrose rb3822.patch uploaded by coreyfarrell (License 5909) rb3800.patch uploaded by jrose (License 6182) chan_sip.diff uploaded by mjordan (License 6283) rb3747.patch uploaded by jrose (License 6182) ASTERISK-23959 #close Tested by: sgriepentrog, mjordan, coreyfarrell sip_cleanup.diff uploaded by opticron (License 6273) chan_sip_caps.diff uploaded by mjordan (License 6283) rb3751.patch uploaded by coreyfarrell (License 5909) chan_sip-3.diff uploaded by file (License 5000) ASTERISK-23960 #close Tested by: opticron direct_media.diff uploaded by opticron (License 6273) pjsip-direct-media.diff uploaded by file (License 5000) format_cap_remove.diff uploaded by opticron (License 6273) media_format_fixes.diff uploaded by opticron (License 6273) chan_pjsip-2.diff uploaded by file (License 5000) ASTERISK-23966 #close Tested by: rmudgett rb3803.patch uploaded by rmudgetti (License 5621) chan_dahdi.diff uploaded by file (License 5000) ASTERISK-24064 #close Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose rb3814.patch uploaded by rmudgett (License 5621) moh_cleanup.diff uploaded by opticron (License 6273) bridge_leak.diff uploaded by opticron (License 6273) translate.diff uploaded by file (License 5000) rb3795.patch uploaded by rmudgett (License 5621) tls_fix.diff uploaded by mjordan (License 6283) fax-mf-fix-2.diff uploaded by file (License 5000) rtp_transfer_stuff uploaded by mjordan (License 6283) rb3787.patch uploaded by rmudgett (License 5621) media-formats-explicit-translate-format-3.diff uploaded by file (License 5000) format_cache_case_fix.diff uploaded by opticron (License 6273) rb3774.patch uploaded by rmudgett (License 5621) rb3775.patch uploaded by rmudgett (License 5621) rtp_engine_fix.diff uploaded by opticron (License 6273) rtp_crash_fix.diff uploaded by opticron (License 6273) rb3753.patch uploaded by mjordan (License 6283) rb3750.patch uploaded by mjordan (License 6283) rb3748.patch uploaded by rmudgett (License 5621) media_format_fixes.diff uploaded by opticron (License 6273) rb3740.patch uploaded by mjordan (License 6283) rb3739.patch uploaded by mjordan (License 6283) rb3734.patch uploaded by mjordan (License 6283) rb3689.patch uploaded by mjordan (License 6283) rb3674.patch uploaded by coreyfarrell (License 5909) rb3671.patch uploaded by coreyfarrell (License 5909) rb3667.patch uploaded by coreyfarrell (License 5909) rb3665.patch uploaded by mjordan (License 6283) rb3625.patch uploaded by coreyfarrell (License 5909) rb3602.patch uploaded by coreyfarrell (License 5909) format_compatibility-2.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-20 22:06:33 +00:00
struct ast_frame_subclass {
/*! A frame specific code */
int integer;
media formats: re-architect handling of media for performance improvements In the old times media formats were represented using a bit field. This was fast but had a few limitations. 1. Asterisk was limited in how many formats it could handle. 2. Formats, being a bit field, could not include any attribute information. A format was strictly its type, e.g., "this is ulaw". This was changed in Asterisk 10 (see https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for notes on that work) which led to the creation of the ast_format structure. This structure allowed Asterisk to handle attributes and bundle information with a format. Additionally, ast_format_cap was created to act as a container for multiple formats that, together, formed the capability of some entity. Another mechanism was added to allow logic to be registered which performed format attribute negotiation. Everywhere throughout the codebase Asterisk was changed to use this strategy. Unfortunately, in software, there is no free lunch. These new capabilities came at a cost. Performance analysis and profiling showed that we spend an inordinate amount of time comparing, copying, and generally manipulating formats and their related structures. Basic prototyping has shown that a reasonably large performance improvement could be made in this area. This patch is the result of that project, which overhauled the media format architecture and its usage in Asterisk to improve performance. Generally, the new philosophy for handling formats is as follows: * The ast_format structure is reference counted. This removed a large amount of the memory allocations and copying that was done in prior versions. * In order to prevent race conditions while keeping things performant, the ast_format structure is immutable by convention and lock-free. Violate this tenet at your peril! * Because formats are reference counted, codecs are also reference counted. The Asterisk core generally provides built-in codecs and caches the ast_format structures created to represent them. Generally, to prevent inordinate amounts of module reference bumping, codecs and formats can be added at run-time but cannot be removed. * All compatibility with the bit field representation of codecs/formats has been moved to a compatibility API. The primary user of this representation is chan_iax2, which must continue to maintain its bit-field usage of formats for interoperability concerns. * When a format is negotiated with attributes, or when a format cannot be represented by one of the cached formats, a new format object is created or cloned from an existing format. That format may have the same codec underlying it, but is a different format than a version of the format with different attributes or without attributes. * While formats are reference counted objects, the reference count maintained on the format should be manipulated with care. Formats are generally cached and will persist for the lifetime of Asterisk and do not explicitly need to have their lifetime modified. An exception to this is when the user of a format does not know where the format came from *and* the user may outlive the provider of the format. This occurs, for example, when a format is read from a channel: the channel may have a format with attributes (hence, non-cached) and the user of the format may last longer than the channel (if the reference to the channel is released prior to the format's reference). For more information on this work, see the API design notes: https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite Finally, this work was the culmination of a large number of developer's efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the work in the Asterisk core, chan_sip, and was an invaluable resource in peer reviews throughout this project. There were a substantial number of patches contributed during this work; the following issues/patch names simply reflect some of the work (and will cause the release scripts to give attribution to the individuals who work on them). Reviews: https://reviewboard.asterisk.org/r/3814 https://reviewboard.asterisk.org/r/3808 https://reviewboard.asterisk.org/r/3805 https://reviewboard.asterisk.org/r/3803 https://reviewboard.asterisk.org/r/3801 https://reviewboard.asterisk.org/r/3798 https://reviewboard.asterisk.org/r/3800 https://reviewboard.asterisk.org/r/3794 https://reviewboard.asterisk.org/r/3793 https://reviewboard.asterisk.org/r/3792 https://reviewboard.asterisk.org/r/3791 https://reviewboard.asterisk.org/r/3790 https://reviewboard.asterisk.org/r/3789 https://reviewboard.asterisk.org/r/3788 https://reviewboard.asterisk.org/r/3787 https://reviewboard.asterisk.org/r/3786 https://reviewboard.asterisk.org/r/3784 https://reviewboard.asterisk.org/r/3783 https://reviewboard.asterisk.org/r/3778 https://reviewboard.asterisk.org/r/3774 https://reviewboard.asterisk.org/r/3775 https://reviewboard.asterisk.org/r/3772 https://reviewboard.asterisk.org/r/3761 https://reviewboard.asterisk.org/r/3754 https://reviewboard.asterisk.org/r/3753 https://reviewboard.asterisk.org/r/3751 https://reviewboard.asterisk.org/r/3750 https://reviewboard.asterisk.org/r/3748 https://reviewboard.asterisk.org/r/3747 https://reviewboard.asterisk.org/r/3746 https://reviewboard.asterisk.org/r/3742 https://reviewboard.asterisk.org/r/3740 https://reviewboard.asterisk.org/r/3739 https://reviewboard.asterisk.org/r/3738 https://reviewboard.asterisk.org/r/3737 https://reviewboard.asterisk.org/r/3736 https://reviewboard.asterisk.org/r/3734 https://reviewboard.asterisk.org/r/3722 https://reviewboard.asterisk.org/r/3713 https://reviewboard.asterisk.org/r/3703 https://reviewboard.asterisk.org/r/3689 https://reviewboard.asterisk.org/r/3687 https://reviewboard.asterisk.org/r/3674 https://reviewboard.asterisk.org/r/3671 https://reviewboard.asterisk.org/r/3667 https://reviewboard.asterisk.org/r/3665 https://reviewboard.asterisk.org/r/3625 https://reviewboard.asterisk.org/r/3602 https://reviewboard.asterisk.org/r/3519 https://reviewboard.asterisk.org/r/3518 https://reviewboard.asterisk.org/r/3516 https://reviewboard.asterisk.org/r/3515 https://reviewboard.asterisk.org/r/3512 https://reviewboard.asterisk.org/r/3506 https://reviewboard.asterisk.org/r/3413 https://reviewboard.asterisk.org/r/3410 https://reviewboard.asterisk.org/r/3387 https://reviewboard.asterisk.org/r/3388 https://reviewboard.asterisk.org/r/3389 https://reviewboard.asterisk.org/r/3390 https://reviewboard.asterisk.org/r/3321 https://reviewboard.asterisk.org/r/3320 https://reviewboard.asterisk.org/r/3319 https://reviewboard.asterisk.org/r/3318 https://reviewboard.asterisk.org/r/3266 https://reviewboard.asterisk.org/r/3265 https://reviewboard.asterisk.org/r/3234 https://reviewboard.asterisk.org/r/3178 ASTERISK-23114 #close Reported by: mjordan media_formats_translation_core.diff uploaded by kharwell (License 6464) rb3506.diff uploaded by mjordan (License 6283) media_format_app_file.diff uploaded by kharwell (License 6464) misc-2.diff uploaded by file (License 5000) chan_mild-3.diff uploaded by file (License 5000) chan_obscure.diff uploaded by file (License 5000) jingle.diff uploaded by file (License 5000) funcs.diff uploaded by file (License 5000) formats.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) bridges.diff uploaded by file (License 5000) mf-codecs-2.diff uploaded by file (License 5000) mf-app_fax.diff uploaded by file (License 5000) mf-apps-3.diff uploaded by file (License 5000) media-formats-3.diff uploaded by file (License 5000) ASTERISK-23715 rb3713.patch uploaded by coreyfarrell (License 5909) rb3689.patch uploaded by mjordan (License 6283) ASTERISK-23957 rb3722.patch uploaded by mjordan (License 6283) mf-attributes-3.diff uploaded by file (License 5000) ASTERISK-23958 Tested by: jrose rb3822.patch uploaded by coreyfarrell (License 5909) rb3800.patch uploaded by jrose (License 6182) chan_sip.diff uploaded by mjordan (License 6283) rb3747.patch uploaded by jrose (License 6182) ASTERISK-23959 #close Tested by: sgriepentrog, mjordan, coreyfarrell sip_cleanup.diff uploaded by opticron (License 6273) chan_sip_caps.diff uploaded by mjordan (License 6283) rb3751.patch uploaded by coreyfarrell (License 5909) chan_sip-3.diff uploaded by file (License 5000) ASTERISK-23960 #close Tested by: opticron direct_media.diff uploaded by opticron (License 6273) pjsip-direct-media.diff uploaded by file (License 5000) format_cap_remove.diff uploaded by opticron (License 6273) media_format_fixes.diff uploaded by opticron (License 6273) chan_pjsip-2.diff uploaded by file (License 5000) ASTERISK-23966 #close Tested by: rmudgett rb3803.patch uploaded by rmudgetti (License 5621) chan_dahdi.diff uploaded by file (License 5000) ASTERISK-24064 #close Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose rb3814.patch uploaded by rmudgett (License 5621) moh_cleanup.diff uploaded by opticron (License 6273) bridge_leak.diff uploaded by opticron (License 6273) translate.diff uploaded by file (License 5000) rb3795.patch uploaded by rmudgett (License 5621) tls_fix.diff uploaded by mjordan (License 6283) fax-mf-fix-2.diff uploaded by file (License 5000) rtp_transfer_stuff uploaded by mjordan (License 6283) rb3787.patch uploaded by rmudgett (License 5621) media-formats-explicit-translate-format-3.diff uploaded by file (License 5000) format_cache_case_fix.diff uploaded by opticron (License 6273) rb3774.patch uploaded by rmudgett (License 5621) rb3775.patch uploaded by rmudgett (License 5621) rtp_engine_fix.diff uploaded by opticron (License 6273) rtp_crash_fix.diff uploaded by opticron (License 6273) rb3753.patch uploaded by mjordan (License 6283) rb3750.patch uploaded by mjordan (License 6283) rb3748.patch uploaded by rmudgett (License 5621) media_format_fixes.diff uploaded by opticron (License 6273) rb3740.patch uploaded by mjordan (License 6283) rb3739.patch uploaded by mjordan (License 6283) rb3734.patch uploaded by mjordan (License 6283) rb3689.patch uploaded by mjordan (License 6283) rb3674.patch uploaded by coreyfarrell (License 5909) rb3671.patch uploaded by coreyfarrell (License 5909) rb3667.patch uploaded by coreyfarrell (License 5909) rb3665.patch uploaded by mjordan (License 6283) rb3625.patch uploaded by coreyfarrell (License 5909) rb3602.patch uploaded by coreyfarrell (License 5909) format_compatibility-2.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-20 22:06:33 +00:00
/*! The asterisk media format */
struct ast_format *format;
/*! For video formats, an indication that a frame ended */
unsigned int frame_ending;
};
/*! \brief Data structure associated with a single frame of data
*/
struct ast_frame {
/*! Kind of frame */
enum ast_frame_type frametype;
/*! Subclass, frame dependent */
media formats: re-architect handling of media for performance improvements In the old times media formats were represented using a bit field. This was fast but had a few limitations. 1. Asterisk was limited in how many formats it could handle. 2. Formats, being a bit field, could not include any attribute information. A format was strictly its type, e.g., "this is ulaw". This was changed in Asterisk 10 (see https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for notes on that work) which led to the creation of the ast_format structure. This structure allowed Asterisk to handle attributes and bundle information with a format. Additionally, ast_format_cap was created to act as a container for multiple formats that, together, formed the capability of some entity. Another mechanism was added to allow logic to be registered which performed format attribute negotiation. Everywhere throughout the codebase Asterisk was changed to use this strategy. Unfortunately, in software, there is no free lunch. These new capabilities came at a cost. Performance analysis and profiling showed that we spend an inordinate amount of time comparing, copying, and generally manipulating formats and their related structures. Basic prototyping has shown that a reasonably large performance improvement could be made in this area. This patch is the result of that project, which overhauled the media format architecture and its usage in Asterisk to improve performance. Generally, the new philosophy for handling formats is as follows: * The ast_format structure is reference counted. This removed a large amount of the memory allocations and copying that was done in prior versions. * In order to prevent race conditions while keeping things performant, the ast_format structure is immutable by convention and lock-free. Violate this tenet at your peril! * Because formats are reference counted, codecs are also reference counted. The Asterisk core generally provides built-in codecs and caches the ast_format structures created to represent them. Generally, to prevent inordinate amounts of module reference bumping, codecs and formats can be added at run-time but cannot be removed. * All compatibility with the bit field representation of codecs/formats has been moved to a compatibility API. The primary user of this representation is chan_iax2, which must continue to maintain its bit-field usage of formats for interoperability concerns. * When a format is negotiated with attributes, or when a format cannot be represented by one of the cached formats, a new format object is created or cloned from an existing format. That format may have the same codec underlying it, but is a different format than a version of the format with different attributes or without attributes. * While formats are reference counted objects, the reference count maintained on the format should be manipulated with care. Formats are generally cached and will persist for the lifetime of Asterisk and do not explicitly need to have their lifetime modified. An exception to this is when the user of a format does not know where the format came from *and* the user may outlive the provider of the format. This occurs, for example, when a format is read from a channel: the channel may have a format with attributes (hence, non-cached) and the user of the format may last longer than the channel (if the reference to the channel is released prior to the format's reference). For more information on this work, see the API design notes: https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite Finally, this work was the culmination of a large number of developer's efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the work in the Asterisk core, chan_sip, and was an invaluable resource in peer reviews throughout this project. There were a substantial number of patches contributed during this work; the following issues/patch names simply reflect some of the work (and will cause the release scripts to give attribution to the individuals who work on them). Reviews: https://reviewboard.asterisk.org/r/3814 https://reviewboard.asterisk.org/r/3808 https://reviewboard.asterisk.org/r/3805 https://reviewboard.asterisk.org/r/3803 https://reviewboard.asterisk.org/r/3801 https://reviewboard.asterisk.org/r/3798 https://reviewboard.asterisk.org/r/3800 https://reviewboard.asterisk.org/r/3794 https://reviewboard.asterisk.org/r/3793 https://reviewboard.asterisk.org/r/3792 https://reviewboard.asterisk.org/r/3791 https://reviewboard.asterisk.org/r/3790 https://reviewboard.asterisk.org/r/3789 https://reviewboard.asterisk.org/r/3788 https://reviewboard.asterisk.org/r/3787 https://reviewboard.asterisk.org/r/3786 https://reviewboard.asterisk.org/r/3784 https://reviewboard.asterisk.org/r/3783 https://reviewboard.asterisk.org/r/3778 https://reviewboard.asterisk.org/r/3774 https://reviewboard.asterisk.org/r/3775 https://reviewboard.asterisk.org/r/3772 https://reviewboard.asterisk.org/r/3761 https://reviewboard.asterisk.org/r/3754 https://reviewboard.asterisk.org/r/3753 https://reviewboard.asterisk.org/r/3751 https://reviewboard.asterisk.org/r/3750 https://reviewboard.asterisk.org/r/3748 https://reviewboard.asterisk.org/r/3747 https://reviewboard.asterisk.org/r/3746 https://reviewboard.asterisk.org/r/3742 https://reviewboard.asterisk.org/r/3740 https://reviewboard.asterisk.org/r/3739 https://reviewboard.asterisk.org/r/3738 https://reviewboard.asterisk.org/r/3737 https://reviewboard.asterisk.org/r/3736 https://reviewboard.asterisk.org/r/3734 https://reviewboard.asterisk.org/r/3722 https://reviewboard.asterisk.org/r/3713 https://reviewboard.asterisk.org/r/3703 https://reviewboard.asterisk.org/r/3689 https://reviewboard.asterisk.org/r/3687 https://reviewboard.asterisk.org/r/3674 https://reviewboard.asterisk.org/r/3671 https://reviewboard.asterisk.org/r/3667 https://reviewboard.asterisk.org/r/3665 https://reviewboard.asterisk.org/r/3625 https://reviewboard.asterisk.org/r/3602 https://reviewboard.asterisk.org/r/3519 https://reviewboard.asterisk.org/r/3518 https://reviewboard.asterisk.org/r/3516 https://reviewboard.asterisk.org/r/3515 https://reviewboard.asterisk.org/r/3512 https://reviewboard.asterisk.org/r/3506 https://reviewboard.asterisk.org/r/3413 https://reviewboard.asterisk.org/r/3410 https://reviewboard.asterisk.org/r/3387 https://reviewboard.asterisk.org/r/3388 https://reviewboard.asterisk.org/r/3389 https://reviewboard.asterisk.org/r/3390 https://reviewboard.asterisk.org/r/3321 https://reviewboard.asterisk.org/r/3320 https://reviewboard.asterisk.org/r/3319 https://reviewboard.asterisk.org/r/3318 https://reviewboard.asterisk.org/r/3266 https://reviewboard.asterisk.org/r/3265 https://reviewboard.asterisk.org/r/3234 https://reviewboard.asterisk.org/r/3178 ASTERISK-23114 #close Reported by: mjordan media_formats_translation_core.diff uploaded by kharwell (License 6464) rb3506.diff uploaded by mjordan (License 6283) media_format_app_file.diff uploaded by kharwell (License 6464) misc-2.diff uploaded by file (License 5000) chan_mild-3.diff uploaded by file (License 5000) chan_obscure.diff uploaded by file (License 5000) jingle.diff uploaded by file (License 5000) funcs.diff uploaded by file (License 5000) formats.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) bridges.diff uploaded by file (License 5000) mf-codecs-2.diff uploaded by file (License 5000) mf-app_fax.diff uploaded by file (License 5000) mf-apps-3.diff uploaded by file (License 5000) media-formats-3.diff uploaded by file (License 5000) ASTERISK-23715 rb3713.patch uploaded by coreyfarrell (License 5909) rb3689.patch uploaded by mjordan (License 6283) ASTERISK-23957 rb3722.patch uploaded by mjordan (License 6283) mf-attributes-3.diff uploaded by file (License 5000) ASTERISK-23958 Tested by: jrose rb3822.patch uploaded by coreyfarrell (License 5909) rb3800.patch uploaded by jrose (License 6182) chan_sip.diff uploaded by mjordan (License 6283) rb3747.patch uploaded by jrose (License 6182) ASTERISK-23959 #close Tested by: sgriepentrog, mjordan, coreyfarrell sip_cleanup.diff uploaded by opticron (License 6273) chan_sip_caps.diff uploaded by mjordan (License 6283) rb3751.patch uploaded by coreyfarrell (License 5909) chan_sip-3.diff uploaded by file (License 5000) ASTERISK-23960 #close Tested by: opticron direct_media.diff uploaded by opticron (License 6273) pjsip-direct-media.diff uploaded by file (License 5000) format_cap_remove.diff uploaded by opticron (License 6273) media_format_fixes.diff uploaded by opticron (License 6273) chan_pjsip-2.diff uploaded by file (License 5000) ASTERISK-23966 #close Tested by: rmudgett rb3803.patch uploaded by rmudgetti (License 5621) chan_dahdi.diff uploaded by file (License 5000) ASTERISK-24064 #close Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose rb3814.patch uploaded by rmudgett (License 5621) moh_cleanup.diff uploaded by opticron (License 6273) bridge_leak.diff uploaded by opticron (License 6273) translate.diff uploaded by file (License 5000) rb3795.patch uploaded by rmudgett (License 5621) tls_fix.diff uploaded by mjordan (License 6283) fax-mf-fix-2.diff uploaded by file (License 5000) rtp_transfer_stuff uploaded by mjordan (License 6283) rb3787.patch uploaded by rmudgett (License 5621) media-formats-explicit-translate-format-3.diff uploaded by file (License 5000) format_cache_case_fix.diff uploaded by opticron (License 6273) rb3774.patch uploaded by rmudgett (License 5621) rb3775.patch uploaded by rmudgett (License 5621) rtp_engine_fix.diff uploaded by opticron (License 6273) rtp_crash_fix.diff uploaded by opticron (License 6273) rb3753.patch uploaded by mjordan (License 6283) rb3750.patch uploaded by mjordan (License 6283) rb3748.patch uploaded by rmudgett (License 5621) media_format_fixes.diff uploaded by opticron (License 6273) rb3740.patch uploaded by mjordan (License 6283) rb3739.patch uploaded by mjordan (License 6283) rb3734.patch uploaded by mjordan (License 6283) rb3689.patch uploaded by mjordan (License 6283) rb3674.patch uploaded by coreyfarrell (License 5909) rb3671.patch uploaded by coreyfarrell (License 5909) rb3667.patch uploaded by coreyfarrell (License 5909) rb3665.patch uploaded by mjordan (License 6283) rb3625.patch uploaded by coreyfarrell (License 5909) rb3602.patch uploaded by coreyfarrell (License 5909) format_compatibility-2.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-20 22:06:33 +00:00
struct ast_frame_subclass subclass;
/*! Length of data */
int datalen;
/*! Number of samples in this frame */
int samples;
/*! Was the data malloc'd? i.e. should we free it when we discard the frame? */
int mallocd;
/*! The number of bytes allocated for a malloc'd frame header */
size_t mallocd_hdr_len;
/*! How many bytes exist _before_ "data" that can be used if needed */
int offset;
/*! Optional source of frame for debugging */
const char *src;
/*! Pointer to actual data */
union { void *ptr; uint32_t uint32; char pad[8]; } data;
/*! Global delivery time */
struct timeval delivery;
/*! For placing in a linked list */
AST_LIST_ENTRY(ast_frame) frame_list;
Merged revisions 98943 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines Commit a fix for some memory access errors pointed out by the valgrind2.txt output on issue #11698. The issue here is that it is possible for an instance of a translator to get destroyed while the frame allocated as a part of the translator is still being processed. Specifically, this is possible anywhere between a call to ast_read() and ast_frame_free(), which is _a lot_ of places in the code. The reason this happens is that the channel might get masqueraded during this time. During a masquerade, existing translation paths get destroyed. So, this patch fixes the issue in an API and ABI compatible way. (This one is for you, paravoid!) It changes an int in ast_frame to be used as flag bits. The 1 bit is still used to indicate that the frame contains timing information. Also, a second flag has been added to indicate that the frame came from a translator. When a frame with this flag gets released and has this flag, a function is called in translate.c to let it know that this frame is doing being processed. At this point, the flag gets cleared. Also, if the translator was requested to be destroyed while its internal frame still had this flag set, its destruction has been deffered until it finds out that the frame is no longer being processed. Admittedly, this feels like a hack. But, it does fix the issue, and I was not able to think of a better solution ... ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-01-15 23:31:53 +00:00
/*! Misc. frame flags */
unsigned int flags;
/*! Timestamp in milliseconds */
long ts;
/*! Length in milliseconds */
long len;
/*! Sequence number */
int seqno;
};
/*!
* Set the various field of a frame to point to a buffer.
* Typically you set the base address of the buffer, the offset as
* AST_FRIENDLY_OFFSET, and the datalen as the amount of bytes queued.
* The remaining things (to be done manually) is set the number of
* samples, which cannot be derived from the datalen unless you know
* the number of bits per sample.
*/
#define AST_FRAME_SET_BUFFER(fr, _base, _ofs, _datalen) \
{ \
(fr)->data.ptr = (char *)_base + (_ofs); \
(fr)->offset = (_ofs); \
(fr)->datalen = (_datalen); \
}
/*! Queueing a null frame is fairly common, so we declare a global null frame object
for this purpose instead of having to declare one on the stack */
extern struct ast_frame ast_null_frame;
/*! \brief Offset into a frame's data buffer.
*
* By providing some "empty" space prior to the actual data of an ast_frame,
* this gives any consumer of the frame ample space to prepend other necessary
* information without having to create a new buffer.
*
* As an example, RTP can use the data from an ast_frame and simply prepend the
* RTP header information into the space provided by AST_FRIENDLY_OFFSET instead
* of having to create a new buffer with the necessary space allocated.
*/
#define AST_FRIENDLY_OFFSET 64
#define AST_MIN_OFFSET 32 /*! Make sure we keep at least this much handy */
/*! Need the header be free'd? */
#define AST_MALLOCD_HDR (1 << 0)
/*! Need the data be free'd? */
#define AST_MALLOCD_DATA (1 << 1)
/*! Need the source be free'd? (haha!) */
#define AST_MALLOCD_SRC (1 << 2)
/* MODEM subclasses */
/*! T.38 Fax-over-IP */
#define AST_MODEM_T38 1
/*! V.150 Modem-over-IP */
#define AST_MODEM_V150 2
/* HTML subclasses */
/*! Sending a URL */
#define AST_HTML_URL 1
/*! Data frame */
#define AST_HTML_DATA 2
/*! Beginning frame */
#define AST_HTML_BEGIN 4
/*! End frame */
#define AST_HTML_END 8
/*! Load is complete */
#define AST_HTML_LDCOMPLETE 16
/*! Peer is unable to support HTML */
#define AST_HTML_NOSUPPORT 17
/*! Send URL, and track */
#define AST_HTML_LINKURL 18
/*! No more HTML linkage */
#define AST_HTML_UNLINK 19
/*! Reject link request */
#define AST_HTML_LINKREJECT 20
chan_iax2: Block unnecessary control frames to/from the wire. Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later) results in an unexpected call disconnect. The problem happens because newer values in the enum ast_control_frame_type are not consistent between the branch versions of Asterisk. For example: 1) v1.4 calls v1.8 (or later) using IAX2 2) v1.8 answers and sends a connected line update control frame. (on v1.8 AST_CONTROL_CONNECTED_LINE = 22) 3) v1.4 receives the control frame as an end-of-q (on v1.4 AST_CONTROL_END_OF_Q = 22) 4) v1.4 disconnects the call once the receive queue becomes empty. Several things are done by this patch to fix the problem and attempt to prevent it from happening again in the future: * Added a warning at the definition of enum ast_control_frame_type about how to add new control frame values. * Made block sending and receiving control frames that have no reason to go over the wire. * Extended the connectedline iax.conf parameter to also include the redirecting information updates. * Updated the connectedline iax.conf parameter documentation to include a notice that the parameter must be "no" when the peer is an Asterisk v1.4 instance. (closes issue AST-1302) Review: https://reviewboard.asterisk.org/r/3174/ ........ Merged revisions 407678 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 407727 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 407729 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-02-07 18:29:49 +00:00
/*!
* \brief Internal control frame subtype field values.
*
* \warning
* IAX2 sends these values out over the wire. To prevent future
* incompatibilities, pick the next value in the enum from whatever
* is on the current trunk. If you lose the merge race you need to
* fix the previous branches to match what is on trunk. In addition
* you need to change chan_iax2 to explicitly allow the control
* frame over the wire if it makes sense for the frame to be passed
* to another Asterisk instance.
*/
enum ast_control_frame_type {
AST_CONTROL_HANGUP = 1, /*!< Other end has hungup */
AST_CONTROL_RING = 2, /*!< Local ring */
AST_CONTROL_RINGING = 3, /*!< Remote end is ringing */
AST_CONTROL_ANSWER = 4, /*!< Remote end has answered */
AST_CONTROL_BUSY = 5, /*!< Remote end is busy */
AST_CONTROL_TAKEOFFHOOK = 6, /*!< Make it go off hook */
AST_CONTROL_OFFHOOK = 7, /*!< Line is off hook */
AST_CONTROL_CONGESTION = 8, /*!< Congestion (circuits busy) */
AST_CONTROL_FLASH = 9, /*!< Flash hook */
AST_CONTROL_WINK = 10, /*!< Wink */
AST_CONTROL_OPTION = 11, /*!< Set a low-level option */
AST_CONTROL_RADIO_KEY = 12, /*!< Key Radio */
AST_CONTROL_RADIO_UNKEY = 13, /*!< Un-Key Radio */
AST_CONTROL_PROGRESS = 14, /*!< Indicate PROGRESS */
AST_CONTROL_PROCEEDING = 15, /*!< Indicate CALL PROCEEDING */
AST_CONTROL_HOLD = 16, /*!< Indicate call is placed on hold */
AST_CONTROL_UNHOLD = 17, /*!< Indicate call is left from hold */
AST_CONTROL_VIDUPDATE = 18, /*!< Indicate video frame update */
_XXX_AST_CONTROL_T38 = 19, /*!< T38 state change request/notification \deprecated This is no longer supported. Use AST_CONTROL_T38_PARAMETERS instead. */
AST_CONTROL_SRCUPDATE = 20, /*!< Indicate source of media has changed */
AST_CONTROL_TRANSFER = 21, /*!< Indicate status of a transfer request */
AST_CONTROL_CONNECTED_LINE = 22,/*!< Indicate connected line has changed */
AST_CONTROL_REDIRECTING = 23, /*!< Indicate redirecting id has changed */
AST_CONTROL_T38_PARAMETERS = 24,/*!< T38 state change request/notification with parameters */
AST_CONTROL_CC = 25, /*!< Indication that Call completion service is possible */
AST_CONTROL_SRCCHANGE = 26, /*!< Media source has changed and requires a new RTP SSRC */
AST_CONTROL_READ_ACTION = 27, /*!< Tell ast_read to take a specific action */
AST_CONTROL_AOC = 28, /*!< Advice of Charge with encoded generic AOC payload */
Merged revisions 295866 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines Merged revisions 295843 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines Merged revisions 295790 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call. To recreate the problem: 1) Party A calls Party B 2) Invoke CLI "channel redirect" command to redirect channel call leg associated with A. 3) All associated channels are hung up. Note that if the CLI command were done on the channel call leg associated with B it works. This regression was a result of the fix for issue #16946 (https://reviewboard.asterisk.org/r/740/). The regression affects all features that use an async goto to execute the dialplan because of an external event: Channel redirect, AMI redirect, SIP REFER, and FAX detection. The struct ast_channel._softhangup code is a mess. The variable is used for several purposes that do not necessarily result in the call being hung up. I have added doxygen comments to describe how the various _softhangup bits are used. I have corrected all the places where the variable was tested in a non-bit oriented manner. The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak hangup request so the soft hangup requests that do not normally result in a hangup do not hangup. JIRA SWP-2470 JIRA SWP-2489 (closes issue #18171) Reported by: SantaFox (closes issue #18185) Reported by: kwemheuer (closes issue #18211) Reported by: zahir_koradia (closes issue #18230) Reported by: vmarrone (closes issue #18299) Reported by: mbrevda (closes issue #18322) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@295867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-11-22 19:42:02 +00:00
AST_CONTROL_END_OF_Q = 29, /*!< Indicate that this position was the end of the channel queue for a softhangup. */
Merged revisions 335078 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/10 ................ r335078 | mjordan | 2011-09-09 11:27:01 -0500 (Fri, 09 Sep 2011) | 29 lines Merged revisions 335064 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r335064 | mjordan | 2011-09-09 11:09:09 -0500 (Fri, 09 Sep 2011) | 23 lines Updated SIP 484 handling; added Incomplete control frame When a SIP phone uses the dial application and receives a 484 Address Incomplete response, if overlapped dialing is enabled for SIP, then the 484 Address Incomplete is forwarded back to the SIP phone and the HANGUPCAUSE channel variable is set to 28. Previously, the Incomplete application dialplan logic was automatically triggered; now, explicit dialplan usage of the application is required. Additionally, this patch adds a new AST_CONTOL_FRAME type called AST_CONTROL_INCOMPLETE. If a channel driver receives this control frame, it is an indication that the dialplan expects more digits back from the device. If the device supports overlap dialing it should attempt to notify the device that the dialplan is waiting for more digits; otherwise, it can handle the frame in a manner appropriate to the channel driver. (closes issue ASTERISK-17288) Reported by: Mikael Carlsson Tested by: Matthew Jordan Review: https://reviewboard.asterisk.org/r/1416/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@335079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-09-09 16:28:23 +00:00
AST_CONTROL_INCOMPLETE = 30, /*!< Indication that the extension dialed is incomplete */
AST_CONTROL_MCID = 31, /*!< Indicate that the caller is being malicious. */
AST_CONTROL_UPDATE_RTP_PEER = 32, /*!< Interrupt the bridge and have it update the peer */
AST_CONTROL_PVT_CAUSE_CODE = 33, /*!< Contains an update to the protocol-specific cause-code stored for branching dials */
AST_CONTROL_MASQUERADE_NOTIFY = 34, /*!< A masquerade is about to begin/end. (Never sent as a frame but directly with ast_indicate_data().) */
chan_iax2: Block unnecessary control frames to/from the wire. Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later) results in an unexpected call disconnect. The problem happens because newer values in the enum ast_control_frame_type are not consistent between the branch versions of Asterisk. For example: 1) v1.4 calls v1.8 (or later) using IAX2 2) v1.8 answers and sends a connected line update control frame. (on v1.8 AST_CONTROL_CONNECTED_LINE = 22) 3) v1.4 receives the control frame as an end-of-q (on v1.4 AST_CONTROL_END_OF_Q = 22) 4) v1.4 disconnects the call once the receive queue becomes empty. Several things are done by this patch to fix the problem and attempt to prevent it from happening again in the future: * Added a warning at the definition of enum ast_control_frame_type about how to add new control frame values. * Made block sending and receiving control frames that have no reason to go over the wire. * Extended the connectedline iax.conf parameter to also include the redirecting information updates. * Updated the connectedline iax.conf parameter documentation to include a notice that the parameter must be "no" when the peer is an Asterisk v1.4 instance. (closes issue AST-1302) Review: https://reviewboard.asterisk.org/r/3174/ ........ Merged revisions 407678 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 407727 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 407729 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-02-07 18:29:49 +00:00
/*
* WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
*
* IAX2 sends these values out over the wire. To prevent future
* incompatibilities, pick the next value in the enum from whatever
* is on the current trunk. If you lose the merge race you need to
* fix the previous branches to match what is on trunk. In addition
* you need to change chan_iax2 to explicitly allow the control
* frame over the wire if it makes sense for the frame to be passed
* to another Asterisk instance.
*
* WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
*/
/* Control frames used to manipulate a stream on a channel. The values for these
* must be greater than the allowed value for a 8-bit char, so that they avoid
* conflicts with DTMF values. */
AST_CONTROL_STREAM_STOP = 1000, /*!< Indicate to a channel in playback to stop the stream */
AST_CONTROL_STREAM_SUSPEND = 1001, /*!< Indicate to a channel in playback to suspend the stream */
AST_CONTROL_STREAM_RESTART = 1002, /*!< Indicate to a channel in playback to restart the stream */
AST_CONTROL_STREAM_REVERSE = 1003, /*!< Indicate to a channel in playback to rewind */
AST_CONTROL_STREAM_FORWARD = 1004, /*!< Indicate to a channel in playback to fast forward */
/* Control frames to manipulate recording on a channel. */
AST_CONTROL_RECORD_CANCEL = 1100, /*!< Indicated to a channel in record to stop recording and discard the file */
AST_CONTROL_RECORD_STOP = 1101, /*!< Indicated to a channel in record to stop recording */
AST_CONTROL_RECORD_SUSPEND = 1102, /*!< Indicated to a channel in record to suspend/unsuspend recording */
AST_CONTROL_RECORD_MUTE = 1103, /*!< Indicated to a channel in record to mute/unmute (i.e. write silence) recording */
Enhancements to connected line and redirecting work. From reviewboard: Digium has a commercial customer who has made extensive use of the connected party and redirecting information present in later versions of Asterisk Business Edition and which is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions have come about. This patch adds several enhancements to maximize usage of the connected party and redirecting information functionality. First, Asterisk trunk already had connected line interception macros. These macros allow you to manipulate connected line information before it was sent out to its target. This patch adds the same feature except for redirecting information instead. Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI, mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is that it can be set to whatever value the administrator likes. Later, when running connected line and redirecting macros, the admin can read the tag off the appropriate structure to determine what action to take. You can think of this sort of like a channel variable, except that instead of having the variable associated with a channel, the variable is associated with a specific identity within Asterisk. Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force a specific calling presentation value on the outgoing channel. Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party being transferred would not have the opportunity to run a connected line interception macro to possibly alter the transfer target's connected line information. The issue here was that during a blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line update. The way this was corrected was to add this new control frame subclass. Now, we queue an AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should be run. When ast_read is called to read the frame, ast_read responds by calling a callback function associated with the specific read action the control frame describes. In this case, the action taken is to run the connected line interception macro on the transferee's channel. Review: https://reviewboard.asterisk.org/r/652/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-05-17 15:36:31 +00:00
};
enum ast_frame_read_action {
AST_FRAME_READ_ACTION_CONNECTED_LINE_MACRO,
};
struct ast_control_read_action_payload {
/* An indicator to ast_read of what action to
* take with the frame;
*/
enum ast_frame_read_action action;
/* The size of the frame's payload
*/
size_t payload_size;
/* A payload for the frame.
*/
unsigned char payload[0];
};
enum ast_control_t38 {
AST_T38_REQUEST_NEGOTIATE = 1, /*!< Request T38 on a channel (voice to fax) */
AST_T38_REQUEST_TERMINATE, /*!< Terminate T38 on a channel (fax to voice) */
AST_T38_NEGOTIATED, /*!< T38 negotiated (fax mode) */
AST_T38_TERMINATED, /*!< T38 terminated (back to voice) */
Improve handling of T.38 re-INVITEs that arrive before a T.38-capable application is executing on a channel. This patch addresses an issue found during working with end-users using res_fax. If an incoming call is answered in the dialplan, or jumps to the 'fax' extension due to reception of a CNG tone (with faxdetect enabled), and then the remote endpoint sends a T.38 re-INVITE, it is possible for the channel's T.38 state to be 'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately, even if the application wants to use T.38, it can't respond to the peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS control frame that chan_sip sent originally has been lost, and the application needs the content of that frame to be able to formulate a reply. This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS, AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip will re-send the original control frame (with AST_T38_REQUEST_NEGOTIATE as the request type), and the application can respond as normal. If this occurs within the five second timeout in chan_sip, the automatic cancellation of the peer reinvite will be stopped, and the application will 'own' the negotiation process from that point onwards. This also improves the code path in chan_sip to allow sip_indicate(), when called for AST_CONTROL_T38_PARAMETERS, to be able to return a non-zero response, which should have been in place before since the control frame *can* fail to be processed properly. It also modifies ast_indicate() to return whatever result the channel driver returned for this control frame, rather than converting all non-zero results into '-1'. Finally, the new request type intentionally returns a positive value, so that an application that sends AST_T38_REQUEST_PARMS can know for certain whether the channel driver accepted it and will be replying with a control frame of its own, or whether it was ignored (if the sip_indicate()/ast_indicate() path had properly supported failure responses before, this would not be necessary). This patch also modifies res_fax to take advantage of the new request. In addition, this patch makes sip_t38_abort() actually lock the private structure before doing its work... bad programmer, no donut. This patch also enhances chan_sip's 'faxdetect' support to allow triggering on T.38 re-INVITEs received as well as CNG tone detection. Review: https://reviewboard.asterisk.org/r/556/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-03-25 15:27:31 +00:00
AST_T38_REFUSED, /*!< T38 refused for some reason (usually rejected by remote end) */
AST_T38_REQUEST_PARMS, /*!< request far end T.38 parameters for a channel in 'negotiating' state */
};
enum ast_control_t38_rate {
AST_T38_RATE_2400 = 1,
AST_T38_RATE_4800,
AST_T38_RATE_7200,
AST_T38_RATE_9600,
AST_T38_RATE_12000,
/* Set to 0 so it's taken as default when unspecified.
* See ITU-T T.38 Implementors' Guide (11 May 2012),
* Table H.2: if the T38MaxBitRate attribute is omitted
* it should use a default of 14400. */
AST_T38_RATE_14400 = 0,
};
enum ast_control_t38_rate_management {
AST_T38_RATE_MANAGEMENT_TRANSFERRED_TCF = 0,
AST_T38_RATE_MANAGEMENT_LOCAL_TCF,
};
struct ast_control_t38_parameters {
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
enum ast_control_t38 request_response; /*!< Request or response of the T38 control frame */
unsigned int version; /*!< Supported T.38 version */
unsigned int max_ifp; /*!< Maximum IFP size supported */
enum ast_control_t38_rate rate; /*!< Maximum fax rate supported */
enum ast_control_t38_rate_management rate_management; /*!< Rate management setting */
unsigned int fill_bit_removal:1; /*!< Set if fill bit removal can be used */
unsigned int transcoding_mmr:1; /*!< Set if MMR transcoding can be used */
unsigned int transcoding_jbig:1; /*!< Set if JBIG transcoding can be used */
};
enum ast_control_transfer {
AST_TRANSFER_SUCCESS = 0, /*!< Transfer request on the channel worked */
AST_TRANSFER_FAILED, /*!< Transfer request on the channel failed */
};
struct ast_control_pvt_cause_code {
char chan_name[AST_CHANNEL_NAME]; /*!< Name of the channel that originated the cause information */
unsigned int emulate_sip_cause:1; /*!< Indicates whether this should be used to emulate SIP_CAUSE support */
int ast_cause; /*!< Asterisk cause code associated with this message */
char code[1]; /*!< Tech-specific cause code information, beginning with the name of the tech */
};
/* Option identifiers and flags */
#define AST_OPTION_FLAG_REQUEST 0
#define AST_OPTION_FLAG_ACCEPT 1
#define AST_OPTION_FLAG_REJECT 2
#define AST_OPTION_FLAG_QUERY 4
#define AST_OPTION_FLAG_ANSWER 5
#define AST_OPTION_FLAG_WTF 6
/*! Verify touchtones by muting audio transmission
* (and reception) and verify the tone is still present
* Option data is a single signed char value 0 or 1 */
#define AST_OPTION_TONE_VERIFY 1
/*! Put a compatible channel into TDD (TTY for the hearing-impared) mode
* Option data is a single signed char value 0 or 1 */
#define AST_OPTION_TDD 2
/*! Relax the parameters for DTMF reception (mainly for radio use)
* Option data is a single signed char value 0 or 1 */
#define AST_OPTION_RELAXDTMF 3
/*! Set (or clear) Audio (Not-Clear) Mode
* Option data is a single signed char value 0 or 1 */
#define AST_OPTION_AUDIO_MODE 4
/*! Set channel transmit gain
* Option data is a single signed char representing number of decibels (dB)
* to set gain to (on top of any gain specified in channel driver) */
#define AST_OPTION_TXGAIN 5
/*! Set channel receive gain
* Option data is a single signed char representing number of decibels (dB)
* to set gain to (on top of any gain specified in channel driver) */
#define AST_OPTION_RXGAIN 6
/* set channel into "Operator Services" mode
* Option data is a struct oprmode
*
* \note This option should never be sent over the network */
#define AST_OPTION_OPRMODE 7
/*! Explicitly enable or disable echo cancelation for the given channel
* Option data is a single signed char value 0 or 1
*
* \note This option appears to be unused in the code. It is handled, but never
* set or queried. */
#define AST_OPTION_ECHOCAN 8
/*! \brief Handle channel write data
* If a channel needs to process the data from a func_channel write operation
* after func_channel_write executes, it can define the setoption callback
* and process this option. A pointer to an ast_chan_write_info_t will be passed.
*
* \note This option should never be passed over the network. */
#define AST_OPTION_CHANNEL_WRITE 9
/* !
* Read-only. Allows query current status of T38 on the channel.
* data: ast_t38state
*/
#define AST_OPTION_T38_STATE 10
/*! Request that the channel driver deliver frames in a specific format
* Option data is a format_t */
#define AST_OPTION_FORMAT_READ 11
/*! Request that the channel driver be prepared to accept frames in a specific format
* Option data is a format_t */
#define AST_OPTION_FORMAT_WRITE 12
/*! Request that the channel driver make two channels of the same tech type compatible if possible
* Option data is an ast_channel
*
* \note This option should never be passed over the network */
#define AST_OPTION_MAKE_COMPATIBLE 13
/*! Get or set the digit detection state of the channel
* Option data is a single signed char value 0 or 1 */
#define AST_OPTION_DIGIT_DETECT 14
/*! Get or set the fax tone detection state of the channel
* Option data is a single signed char value 0 or 1 */
#define AST_OPTION_FAX_DETECT 15
/*! Get the device name from the channel (Read only)
* Option data is a character buffer of suitable length */
Merge Call completion support into trunk. From Reviewboard: CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date overview of the architecture can be found in the file doc/CCSS_architecture.pdf in the CCSS branch. Off the top of my head, the big differences between what is implemented and what is in the document are as follows: 1. We did not end up modifying the Hangup application at all. 2. The document states that a single call completion monitor may be used across multiple calls to the same device. This proved to not be such a good idea when implementing protocol-specific monitors, and so we ended up using one monitor per-device per-call. 3. There are some configuration options which were conceived after the document was written. These are documented in the ccss.conf.sample that is on this review request. For some basic understanding of terminology used throughout this code, see the ccss.tex document that is on this review. This implements CCBS and CCNR in several flavors. First up is a "generic" implementation, which can work over any channel technology provided that the channel technology can accurately report device state. Call completion is requested using the dialplan application CallCompletionRequest and can be canceled using CallCompletionCancel. Device state subscriptions are used in order to monitor the state of called parties. Next, there is a SIP-specific implementation of call completion. This method uses the methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion using SIP signaling. There are a few things to note here: * The agent/monitor terminology used throughout Asterisk sometimes is the reverse of what is defined in the referenced draft. * Implementation of the draft required support for SIP PUBLISH. I attempted to write this in a generic-enough fashion such that if someone were to want to write PUBLISH support for other event packages, such as dialog-state or presence, most of the effort would be in writing callbacks specific to the event package. * A subportion of supporting PUBLISH reception was that we had to implement a PIDF parser. The PIDF support added is a bit minimal. I first wrote a validation routine to ensure that the PIDF document is formatted properly. The rest of the PIDF reading is done in-line in the call-completion-specific PUBLISH-handling code. In other words, while there is PIDF support here, it is not in any state where it could easily be applied to other event packages as is. Finally, there are a variety of ISDN-related call completion protocols supported. These were written by Richard Mudgett, and as such I can't really say much about their implementation. There are notes in the CHANGES file that indicate the ISDN protocols over which call completion is supported. Review: https://reviewboard.asterisk.org/r/523 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
#define AST_OPTION_DEVICE_NAME 16
/*! Get the CC agent type from the channel (Read only)
* Option data is a character buffer of suitable length */
Merge Call completion support into trunk. From Reviewboard: CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date overview of the architecture can be found in the file doc/CCSS_architecture.pdf in the CCSS branch. Off the top of my head, the big differences between what is implemented and what is in the document are as follows: 1. We did not end up modifying the Hangup application at all. 2. The document states that a single call completion monitor may be used across multiple calls to the same device. This proved to not be such a good idea when implementing protocol-specific monitors, and so we ended up using one monitor per-device per-call. 3. There are some configuration options which were conceived after the document was written. These are documented in the ccss.conf.sample that is on this review request. For some basic understanding of terminology used throughout this code, see the ccss.tex document that is on this review. This implements CCBS and CCNR in several flavors. First up is a "generic" implementation, which can work over any channel technology provided that the channel technology can accurately report device state. Call completion is requested using the dialplan application CallCompletionRequest and can be canceled using CallCompletionCancel. Device state subscriptions are used in order to monitor the state of called parties. Next, there is a SIP-specific implementation of call completion. This method uses the methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion using SIP signaling. There are a few things to note here: * The agent/monitor terminology used throughout Asterisk sometimes is the reverse of what is defined in the referenced draft. * Implementation of the draft required support for SIP PUBLISH. I attempted to write this in a generic-enough fashion such that if someone were to want to write PUBLISH support for other event packages, such as dialog-state or presence, most of the effort would be in writing callbacks specific to the event package. * A subportion of supporting PUBLISH reception was that we had to implement a PIDF parser. The PIDF support added is a bit minimal. I first wrote a validation routine to ensure that the PIDF document is formatted properly. The rest of the PIDF reading is done in-line in the call-completion-specific PUBLISH-handling code. In other words, while there is PIDF support here, it is not in any state where it could easily be applied to other event packages as is. Finally, there are a variety of ISDN-related call completion protocols supported. These were written by Richard Mudgett, and as such I can't really say much about their implementation. There are notes in the CHANGES file that indicate the ISDN protocols over which call completion is supported. Review: https://reviewboard.asterisk.org/r/523 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
#define AST_OPTION_CC_AGENT_TYPE 17
/*! Get or set the security options on a channel
* Option data is an integer value of 0 or 1 */
#define AST_OPTION_SECURE_SIGNALING 18
#define AST_OPTION_SECURE_MEDIA 19
struct oprmode {
struct ast_channel *peer;
int mode;
} ;
struct ast_option_header {
/* Always keep in network byte order */
#if __BYTE_ORDER == __BIG_ENDIAN
uint16_t flag:3;
uint16_t option:13;
#else
#if __BYTE_ORDER == __LITTLE_ENDIAN
uint16_t option:13;
uint16_t flag:3;
#else
#error Byte order not defined
#endif
#endif
uint8_t data[0];
};
/*! \brief Requests a frame to be allocated
*
* \param source
* Request a frame be allocated. source is an optional source of the frame,
* len is the requested length, or "0" if the caller will supply the buffer
*/
#if 0 /* Unimplemented */
struct ast_frame *ast_fralloc(char *source, int len);
#endif
/*!
* \brief Frees a frame or list of frames
*
* \param fr Frame to free, or head of list to free
* \param cache Whether to consider this frame for frame caching
*/
void ast_frame_free(struct ast_frame *fr, int cache);
#define ast_frfree(fr) ast_frame_free(fr, 1)
/*!
* \brief NULL-safe wrapper for \ref ast_frfree, good for \ref RAII_VAR.
* \param frame Frame to free, or head of list to free.
*/
void ast_frame_dtor(struct ast_frame *frame);
/*! \brief Makes a frame independent of any static storage
* \param fr frame to act upon
* Take a frame, and if it's not been malloc'd, make a malloc'd copy
* and if the data hasn't been malloced then make the
* data malloc'd. If you need to store frames, say for queueing, then
* you should call this function.
* \return Returns a frame on success, NULL on error
* \note This function may modify the frame passed to it, so you must
* not assume the frame will be intact after the isolated frame has
* been produced. In other words, calling this function on a frame
* should be the last operation you do with that frame before freeing
* it (or exiting the block, if the frame is on the stack.)
*/
struct ast_frame *ast_frisolate(struct ast_frame *fr);
/*! \brief Copies a frame
* \param fr frame to copy
* Duplicates a frame -- should only rarely be used, typically frisolate is good enough
* \return Returns a frame on success, NULL on error
*/
struct ast_frame *ast_frdup(const struct ast_frame *fr);
void ast_swapcopy_samples(void *dst, const void *src, int samples);
/* Helpers for byteswapping native samples to/from
little-endian and big-endian. */
#if __BYTE_ORDER == __LITTLE_ENDIAN
#define ast_frame_byteswap_le(fr) do { ; } while(0)
#define ast_frame_byteswap_be(fr) do { struct ast_frame *__f = (fr); ast_swapcopy_samples(__f->data.ptr, __f->data.ptr, __f->samples); } while(0)
#else
#define ast_frame_byteswap_le(fr) do { struct ast_frame *__f = (fr); ast_swapcopy_samples(__f->data.ptr, __f->data.ptr, __f->samples); } while(0)
#define ast_frame_byteswap_be(fr) do { ; } while(0)
#endif
void ast_frame_dump(const char *name, struct ast_frame *f, char *prefix);
/*! \brief Appends a frame to the end of a list of frames, truncating the maximum length of the list */
struct ast_frame *ast_frame_enqueue(struct ast_frame *head, struct ast_frame *f, int maxlen, int dupe);
/*!
\brief Adjusts the volume of the audio samples contained in a frame.
\param f The frame containing the samples (must be AST_FRAME_VOICE and AST_FORMAT_SLINEAR)
\param adjustment The number of dB to adjust up or down.
\return 0 for success, non-zero for an error
*/
int ast_frame_adjust_volume(struct ast_frame *f, int adjustment);
/*!
\brief Sums two frames of audio samples.
\param f1 The first frame (which will contain the result)
\param f2 The second frame
\return 0 for success, non-zero for an error
The frames must be AST_FRAME_VOICE and must contain AST_FORMAT_SLINEAR samples,
and must contain the same number of samples.
*/
int ast_frame_slinear_sum(struct ast_frame *f1, struct ast_frame *f2);
/*!
* \brief Clear all audio samples from an ast_frame. The frame must be AST_FRAME_VOICE and AST_FORMAT_SLINEAR
*/
int ast_frame_clear(struct ast_frame *frame);
/*!
* \brief Copy the discription of a frame's subclass into the provided string
*
* \param f The frame to get the information from
* \param subclass Buffer to fill with subclass information
* \param slen Length of subclass buffer
* \param moreinfo Buffer to fill with additional information
* \param mlen Length of moreinfo buffer
* \since 11
*/
void ast_frame_subclass2str(struct ast_frame *f, char *subclass, size_t slen, char *moreinfo, size_t mlen);
/*!
* \brief Copy the discription of a frame type into the provided string
*
* \param frame_type The frame type to be described
* \param ftype Buffer to fill with frame type description
* \param len Length of subclass buffer
* \since 11
*/
void ast_frame_type2str(enum ast_frame_type frame_type, char *ftype, size_t len);
#if defined(__cplusplus) || defined(c_plusplus)
}
#endif
#endif /* _ASTERISK_FRAME_H */