Age | Commit message (Collapse) | Author | Files | Lines |
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@200991 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a smoother present.
(closes issue #15105)
Reported by: bamby
Patches:
process-vad-correctly.diff uploaded by bamby (license 430)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195206 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182807 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
runtime global namespace. Along the way, change the prefixes on some internal-only API calls to use a common prefix.
With these changes, for a module to export symbols into the global namespace, it must have *both* the AST_MODFLAG_GLOBAL_SYMBOLS flag and a linker script that allows the linker to leave the symbols exposed in the module's .so file (see res_odbc.exports for an example).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182802 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
During some code analysis, I found that calling ast_rtp_codec_setpref() on an ast_rtp session does not work as expected; it does not adjust the smoother that may on the RTP session, in fact it summarily drops it, even if it has data in it, even if the current format's framing size has not changed. This is not good.
This patch changes this behavior, so that if the packetization size for the current format changes, any existing smoother is safely updated to use the new size, and if no smoother was present, one is created. A new API call for smoothers, ast_smoother_reconfigure(), was required to implement these changes.
Review: http://reviewboard.digium.com/r/184/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180372 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
and glibc.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160207 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
frame in a freed ast_filestream. This patch makes use of the
ao2 functions to make sure that we do not free an ast_filestream
structure until the embedded ast_frame has been "freed" as well.
(closes issue #13496)
Reported by: fst-onge
Patches:
filestream_frame_1_4.diff uploaded by putnopvut (license 60)
Tested by: putnopvut
Closes AST-89
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@158126 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
used anywhere and causes build errors if building under
dev-mode with TRACE_FRAMES selected in menuselect.
(closes issue #13362)
Reported by: snuffy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139521 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
compiling before...
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114211 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
still be
referenced, leading to memory corruption and eventual crashes. This code change ensures
that the dsp is freed when we are finished with the frame. This change is very similar
to a change Russell made with translators back a month or so ago.
(closes issue #11999)
Reported by: destiny6628
Patches:
11999.patch uploaded by putnopvut (license 60)
Tested by: destiny6628, victoryure
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114207 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111280 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(small "pops")
after (about 200ms later) an "incorrectly" sized frame was received.
While it would be very nice to keep this as optimized as possible, it makes no sense
for the smoother to be dropping random bits of audio like this. Isn't that the
whole point of a smoother?
Closes issue #12093.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111245 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11958)
Reported by: norman
Patches:
20080209__bug11958.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106552 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
would do any good. Fix the real bug, which is to do the check to see if the
frame came from a translator at the beginning of ast_frame_free(), instead of
at the end. This ensures that it always gets checked, even if none of the
parts of the frame are malloc'd, and also ensures that we aren't looking at
free'd memory in the case that it is a malloc'd frame.
(closes issue #11792, reported by explidous, patched by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@99081 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the caller's codec is in our codec list, move it to the top to avoid transcoding.
(closes issue #10500)
Reported by: stevedavies
Patches:
iax-prefer-current-codec.patch uploaded by stevedavies (license 184)
iax-prefer-current-codec.1.4.patch uploaded by stevedavies (license 184)
Tested by: stevedavies, pj, sheldonh
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@99004 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@98943 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98082 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the smoother.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70360 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70198 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@51311 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
disabled
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@49536 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@49461 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to frame.c to avoid build-killing compiler warnings.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@49020 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
initializers (they default to zero anyway)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@49006 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
allocations that were done for caching purposes, so they don't look like memory leaks
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@48987 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r47859 | file | 2006-11-20 14:50:21 -0500 (Mon, 20 Nov 2006) | 2 lines
Don't forget to byte swap if we are exiting the smoother feed early. (issue #8287 reported by arturs)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@47860 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@47338 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
consistent with "category verb arguments"
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@47051 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
original patch by andrew, updated by mithraen)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@46154 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@43933 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Maximum values were incorrect, which is why this is being put in 1.4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@43674 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
variable. It couldn't actually happen, though.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@43477 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43264 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
option for setting our own packetization as apposed to just doing
what is asked.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43243 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43212 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41974 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@41958 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@41595 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@41278 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- 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: http://svn.digium.com/svn/asterisk/trunk@40722 f38db490-d61c-443f-a65b-d21fe96a405b
|