Reported by: pep
This change adds an announce_thread responsible for playing announcements to an existing conference. This allows all announcing to be immediately stopped if necessary but more importantly allows other threads that need to play something to not block. There are multiple benefits to this, but the actual bug is for solving the scenario for a channel to be unusable after hang up for the entire duration of the parting announcement. The parting announcement can be extremely long depending on what the user recorded upon joining the conference.
Reviewed by Russell on Review Board:
http://reviewboard.digium.com/r/25/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@156178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
if an attended transfer occurred during the call. I traced the cause to
the CDR on one of the channels being NULL. murf suggested a check in
the end bridge callback to be sure the CDR is non-NULL before proceeding,
so that's what I'm adding.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@156167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
console option to be after the code that reads options from asterisk.conf.
This resolves a situation where Asterisk can start taking up 100% when
misconfigured.
(Thanks to Bryce Porter (x86 on IRC) for letting me log in to his system to
figure out what was causing the 100% CPU problem.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@156164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is invoked, that the channel on which the callback was called
is locked. This patch corrects an instance in chan_agent where
a channel's indicate callback is called directly without first
locking the channel.
This was leading to some observed locking issues in chan_local,
but considering that all channel drivers operate under the
same expectations, the generic fix in chan_agent is the right
way to go.
AST-126
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@155861 65c4cc65-6c06-0410-ace0-fbb531ad65f3
context. The truth is that you can only set this in the general section
or per mailbox. Thus I am updating the sample config file to be more
accurate.
Thanks to sasargen on IRC for bringing up this issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@155011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of code to change, unless the structure is locked to ensure a consistent
state.
(closes issue #13717)
Reported by: kowalma
Patches:
20081102__bug13717.diff.txt uploaded by Corydon76 (license 14)
Tested by: kowalma
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@154365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dial and queue... I wasted some time (stupidly) trying
to get the one-touch parking stuff working, because it
didn't occur to me that I had to also have the corresponding
options in the dial command! Duh! (In all this time, I never
set this up before!)
So, to keep some poor fool from suffering the same fate,
I made the features.conf.sample file mention the corresponding
opts in dial/queue; and the docs for dial/app specifically
mention the corresponding decls in the feature.conf file.
I hope this doesn't spoil some vast, eternal plan...
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
per call (which could otherwise lead to inconsistent status reports).
(closes issue #13216)
Reported by: ruddy
Patches:
20081014__bug13216.diff.txt uploaded by Corydon76 (license 14)
Tested by: ruddy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
match the trailing \0 of a string) we need to check that first, otherwise
we end up with incorrect results. Fix suggested by reporter.
(closes issue #13787)
Reported by: meitinger
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
deadlock when someone tries to initiate a module reload from the AMI just
as Asterisk is starting.
(closes issue #13778)
Reported by: hotsblanc
Fix suggested by hotsblanc
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@151905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem was that if someone parked a call, the callee and caller would both get assigned the builtin transfer feature, which would not only be potentially giving someone the ability to transfer themselves when they shouldn't have it, but would also dissallow reinviting the media off of the call.
(closes issue #12854)
Reported by: davidw
Patches:
parkingfix4.diff.txt uploaded by otherwiseguy
Tested by: davidw, otherwiseguy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@151763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A comment was made in bug #13726
"3. The same mistake as in (2) is done in a few other places in the code that check for: #if defined(HAVE_ZAPTEL) || defined(HAVE_DAHDI)
Harmless, but still incorrect."
In the case of main/asterisk.c, this is not incorrect because without HAVE_ZAPTEL defined, we're missing
the include for ioctl and the namespace that defines DAHDI_TIMERCONFIG which is still required when
using Zaptel with the 1.4 branch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@151167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We'll create a bogus channel for the function call and destroy it when we're done. If we have trouble allocating the bogus channel then we're not going to try executing the function call at all and run the risk of crashing.
(closes issue #13715)
reported by: makoto
patch by: bweschke
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
bridge with peer completely GONE.
I moved the channel find call up to cover the
whole peer CDR reset code segment. This appears
to solve the crash without changing the logic
at all.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Don't always define HAVE_ZAPTEL_CHANALARMS (since we check if it's defined..)
Minor cleanup to make things clear.
(closes issue #13726)
Reported by: tzafrir
Patches:
dahdi_def.diff uploaded by tzafrir (license 46)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I was mistakenly under the assumption that dialplan functions
*always* required that a channel be present. I need to go
home earlier, I think :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the manager's GetVar handler if an invalid channel has
been specified. Several dialplan functions, including
CHANNEL and SIP_HEADER, do not check for NULL-ness of
the channel being passed in.
(closes issue #13715)
Reported by: makoto
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ABE-1628 and RYM-150398 and AST-103 in internal Digium
bug trackers.
These fixes address a really subtle memory corruption
problem that would happen in machines heavily loaded
in production environments. The corruption would
always take the form of the STMT object getting
nulled out and one of the unixODBC calls would
crash trying to access statement->connection.
It isn't fully proven yet, but the server has
now been running 2.5 days without appreciable
memory growth, or any gain of %cpu, and no
crashes. Whether this is the problem or not
on that server, these fixes are still warranted.
As it turns out, **I** introduced these errors
unwittingly, when I corrected another crash earlier.
I had formed the build_query routine, and failed
to remove mutex_unlock calls in 3 places in the
transplanted code. These unlocks would only
happen in error situations, but unlocking the
mutex early set the code up for a catastrophic
failure, it appears. It would happen only once
every 100K-200K or more calls, under heavy load...
but that is enough.
If another crash occurs, with the same MO,
I'll come back and remove my confession from the log, and
we'll keep searching, but the fact that we
have Asterisk dying from an asynchronous
wiping of the STMT object, only on some connection
error, and that the server has lived for 2.5
days on this code without a crash, sure make
it look like this was the problem!
Also, in several points, Statement handles are
set to NULL after SQLFreeHandle. This was mainly
for insurance, to guarantee a crash. As it turns
out, the code does not appear to be attempting
to use these freed pointers.
Asterisk owes a debt of gratitude to Federico Alves
and Frediano Ziglio for their untiring efforts in
finding this bug, among others.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150056 65c4cc65-6c06-0410-ace0-fbb531ad65f3
