The main bug being addressed here is a problem introduced when two SIP
channels using SIP INFO dtmf have their media directly bridged. So, when a
DTMF END frame comes into Asterisk from an incoming INFO message, Asterisk
would try to emulate a digit of some length by first sending a DTMF BEGIN
frame and sending a DTMF END later timed off of incoming audio. However,
since there was no audio coming in, the DTMF_END was never generated. This
caused DTMF based features to no longer work.
To fix this, the core now knows when a channel doesn't care about DTMF BEGIN
frames (such as a SIP channel sending INFO dtmf). If this is the case, then
Asterisk will not emulate a digit of some length, and will instead just pass
through the single DTMF END event.
Channel drivers also now get passed the length of the digit to their digit_end
callback. This improves SIP INFO support even further by enabling us to put
the real digit duration in the INFO message instead of a hard coded 250ms.
Also, for an incoming INFO message, the duration is read from the frame and
passed into the core instead of just getting ignored.
(issue #8597, maybe others...)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@51311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I don't know when the bug was introduced, but with the typical usage
c->fin = FRAMECOUNT_INC(c->fin)
the frame counters stay to 0.
affects trunk as well (fix coming).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@48566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Encapsulate RTP timers in the rtp structure so we have one for video and one for audio
The video one is not used in 1.4, really. Will be used for RTP keepalives when we can send
something that video phones support in the RTP stream.
I now this is a big architectual change at this stage for 1.4, but decided it was needed
to avoid future bug reports.
- Document the RTP NAT keepalive option in sip.conf.sample
Issue 7679 in the bug tracker. Please test.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@48199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
expand stringfields API a bit to allow reusing the stringfield pool on a structure when needed, and remove some unnecessary code when the structure was being freed
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@45408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
reduce standard thread stack size slightly to allow the pthreads library to allocate the stack+data and not overflow a power-of-2 allocation in the kernel and waste memory/address space
add a new stack size for 'background' threads (those that don't handle PBX calls) when LOW_MEMORY is defined
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@44378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
for uses in cases where you *know* that it will do no good. This patch was
inspired by file for use in some work of his on mixmonitor/chanspy.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are some situations in Asterisk where ast_frame and/or iax_frame
structures are rapidly allocatted and freed (at least 50 times per second
for one call).
This code significantly improves the performance of ast_frame_header_new(),
ast_frdup(), ast_frfree(), iax_frame_new(), and iax_frame_free() by keeping
a thread-local cache of these structures and using frames from the cache
whenever possible instead of calling malloc/free every time.
This commit also converts the ast_frame and iax_frame structures to use the
linked list macros.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r40994 | russell | 2006-08-24 15:41:26 -0400 (Thu, 24 Aug 2006) | 11 lines
Fix a few issues related to the handling of channel variables
- in pbx_builtin_serialize_variables(), the variable list traversal would stop
on a variables with empty name/values, which is not appropriate
- When removing the GROUP variables, use AST_LIST_REMOVE_CURRENT instead of
AST_LIST_REMOVE
- During masquerading, when copying the variables list from one channel to the
other, using AST_LIST_INSERT_TAIL is not valid for appending a whole list.
It leaves the tail pointer of the list invalid. Introduce a new macro,
AST_LIST_APPEND_LIST that appends a list properly.
(issue #7802, softins)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
also, keep trying to dlclose() a module until it actually goes away, since it may have other modules it brought in when it was loaded (thanks PCadach for pointing this problem out to me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- add ast_asprintf() and ast_vasprintf()
- tweak doxygen comments
- simplify the definition of a flag macro
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40775 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- instead of defining a free() wrapper in a bunch of files, define it as
ast_free() in utils.h and remove the copies from all the files.
- centralize and abstract the code used for doing thread storage. The code
lives in threadstorage.h, with one function being implemented in utils.c.
This new API includes generic thread storage as well as special functions
for handling thread local dynamic length string buffers.
- update ast_inet_ntoa() to use the new threadstorage API
- update ast_state2str() to use the new threadstorage API
- update ast_cli() to use the new threadstorage API
- Modify manager_event() to use thread storage. Instead of using a buffer of
4096 characters as the workspace for building the manager event, use a thread
local dynamic string. Now there is no length limitation on the length of the
body of a manager event.
- Significantly simplify the handling of ast_verbose() ...
- Instead of using a static char buffer and a lock to make sure only one
thread can be using ast_verbose() at a time, use a thread local dynamic
string as the workspace for preparing the verbose message. Instead of
locking around the entire function, the only locking done now is when the
message has been built and is being deliviered to the list of registered
verbose message handlers.
- This function was doing a strdup() on every message passed to it and
keeping a queue of the last 200 messages in memory. This has been
completely removed. The only place this was used was that if there were
any messages in the verbose queue when a verbose handler was registered,
all of the messages in the queue would be fed to it. So, I just made sure
that the console verbose handler and the network verbose handler (for
remote asterisk consoles) were registered before any verbose messages.
pbx_gtkconsole and pbx_kdeconsole will now lose a few verbose messages at
startup, but I didn't feel the performance hit of this message queue was
worth saving the initial verbose output for these very rarely used modules.
- I have removed the last three arguments to the verbose handlers, leaving
only the string itself because they aren't needed anymore. For example,
ast_verbose had some logic for telling the verbose handler to add
a newline if the buffer was completely full. Now that the buffer can grow
as needed, this doesn't matter anymore.
- remove unused function, ast_verbose_dmesg() which was to dispatch the
message queue
- Convert the list of verbose handlers to use the linked list macros.
- add missing newline characters to a few ast_verbose() calls
- convert the list of log channels to use the linked list macros in logger.c
- fix close_logger() to close all of the files it opened for logging
- update ast_log() to use a thread local dynamic string for its workspace
for preparing log messages instead of a buffer of size BUFSIZ (8kB on my
system) allocated on the stack. The dynamic string in this case is limited
to only growing to a maximum size of BUFSIZ.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@39272 65c4cc65-6c06-0410-ace0-fbb531ad65f3
int to string or string to int operations.
"pure" essentially says that this function has no side effects aside from its
result, and the result depends on nothing else other than its arguments and
global variables. "const" is a more strict form of "pure", where the function
also doesn't access any global variables.
From the gcc manual: "Such a function can be subject to common subexpression
elimination and loop optimization just as an arithmetic operator would be."
This also tells the compiler that it is safe to call the function fewer times
than the code says to, given the same arguments, since the result will always
be the same.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Fix some breakage I introduced a while ago that made the timestamps option
not functional for CLI verbose output.
- Remove the use of the timestamps option for log output, since it was not
functional.
- clarify text referring to the timestamps option so that it is clear that it
only applies to CLI verbose output
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
make read/write/hold work on samples, not bytes
add an API call to find out how many samples are available in a slinfactory
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
fix prototype for a channel walking function to use a const input pointer
use existing channel walk by name prefix instead of reproducing that code in this app
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38389 65c4cc65-6c06-0410-ace0-fbb531ad65f3
if the channel is already in the autoservice list.
Why is this a valid case to return -1, you ask? Well, there should never be
any code where it is not clear if the channel is in autoservice or not because
trying to read frames from a channel that is in the autoservice list will lead
to bad results because more than one thread will be waiting on frames to arrive
on the channel and then trying to read them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38076 65c4cc65-6c06-0410-ace0-fbb531ad65f3
inet_ntoa, which uses thread specific data (aka thread local storage) instead
of stack allocatted buffers to store the result.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38042 65c4cc65-6c06-0410-ace0-fbb531ad65f3