We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@182810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
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
- 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
channel to remove the theoretical race condition that the channel could get
bridged before the channel's jitterbuffer gets configured. This was pointed
out by PCadach on IRC. Thanks!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@39964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
allocated. These changes caused crashes when using a channel type that did
not support the jitterbuffer. Instead of fixing why it's crashing, I'm going
to implement this in a better way next week. The way I did it caused a
jitterbuffer to be allocated on every channel where the channel type supported
jitterbuffers, even if they were disabled.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
so that channels not using a jitterbuffer don't waste as much memory
- ensure that the channel drivers that use jitterbuffers can handle a failure
from configuring a jitterbuffer on a new channel because of a memory
allocation error
- On passing through these channel drivers, configure the jitterbuffer before
starting the PBX thread instead of afterwards. If the pbx fails to start for
whatever reason, this would have caused a crash.
- Also on passing, move the increase of the usecount to after all of the
possible failure conditions in the function
- fix a place where ast_update_use_count() was not called
- ensure that the owner channel pointer of the channel pvt strcutures is set to
NULL in failure conditions
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a new implementation of a fixed size jitterbuffer, as well as support for the
existing adaptive jitterbuffer implementation. (issue #3854, Slav Klenov)
Thank you very much to Slav Klenov of Securax and all of the people involved
in the testing of this feature for all of your hard work!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@31052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
update iax2_indicate to pass control frame payload to the connected channel
add an API call for sending an indication with payload, and use it for control frames with payload
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@26417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
const-ify some more APIs
remove 'type' field from ast_channel, in favor of the one in the channel's tech structure
allow string field module users to specify the 'chunk size' for pool allocations
update chan_alsa to be compatible with recent const-ification patches
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@9060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
