This removes unused code, event types, IE pltypes, and event IE types
where possible and makes several functions private that were once
public. This includes a renumbering of the remaining event and IE types
which breaks binary compatibility with previous versions. The last
remaining consumers of the old event system (or parts thereof) are
main/security_events.c, res/res_security_log.c, tests/test_cel.c,
tests/test_event.c, main/cel.c, and the CEL backends.
Review: https://reviewboard.asterisk.org/r/2703/
(closes issue ASTERISK-22139)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP/foo -- Local;1==Local;2 -- .... -- Local;1==Local;2 -- SIP/bar
Kick a ;1 channel and the chain toward SIP/foo goes away.
Kick a ;2 channel and the chain toward SIP/bar goes away.
This can leave a local channel chain between the kicked ;1 and ;2 channels
that are orphaned until you manually request one of those channels to
hangup or request the bridge to dissolve.
* Added ast_bridge_kick() as a companion to ast_bridge_remove(). The
functional difference is that ast_bridge_kick() may dissolve the bridge as
a result of the channel leaving the bridge.
* Made CLI "bridge kick <bridge> <channel>" use ast_bridge_kick() instead
of ast_bridge_remove() so the bridge can dissolve if needed.
* Renamed bridge_channel_handle_hangup() to ast_bridge_channel_kick() and
made it accessible to other files.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The horrid structure of the source in the utils directory strikes again.
Moved the _ast_mem_backtrace_buffer[] definition from the logical location
in utils.c to hashtab.c so the aelparse and conf2ael utilities can link.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change r395954 reordered some stasis object destruction, which should
have been fine. Unfortunately, it caused some hard to reproduce issues
related to objects being accessed after they had been destroyed. The
patch in r396329 fixed the destruction order problem; this patch
addresses the underlying issue. A few other stasis-related fixes were
also added.
* Add ref-bumps around areas where objects may get transitively
destroyed. (For example, where we lock a topic, unref a subscription,
which unrefs the topic, which explodes the topic when we try to
unlock it.)
* Wrote an extensive doxygen page about Stasis implementation,
relationships between objects, lifecycles of objects, how the
refcounting works, etc. Many other comments were added, corrected, or
cleaned up.
* Added an assert to the topic dtor to catch extra ref decrements.
* Fixed type used after destruction errors for graceful shutdown in
stasis_channels.c.
* I added two unit tests in an attempt to catch destruction order
issues. Since the underlying cause is a race condition, though, the
tests rarely failed even when the code was wrong.
* Fixed a leak in stasis_cache_pattern.c.
(closes issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2746/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This reworks the CLI commands used to access sounds information from
"sounds show[ soundid]" to "core show sounds" and
"core show sound <soundid>". This also reworks the "sounds reload" CLI
command to fall under normal module reloading ("module reload sounds").
Also, make trunk build when DEBUG_MALLOC is not enabled.
Review: https://reviewboard.asterisk.org/r/2745/
(closes issue ASTERISK-22141)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When asterisk has run out of memory (for whatever reason), the alloc
function logs a message. Logging requires memory. A recipe for
infinite recursion.
Stop the recursion by comparing the function call depth for sane values
before attempting another OOM log message.
Review: https://reviewboard.asterisk.org/r/2743/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
By their nature, the connected line and redirecting interception routines
are not supposed to affect the channel's media. Therefore, they should
not suspend and unsuspend the channel while running. The
suspend/unsuspend operations could be expensive depending upon the bridge
and channel technology involved.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396814 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Bridge API DTMF hook matching would not deal with DTMF end events
only. It required a DTMF begin event to start matching the DTMF hooks.
There are many places in Asterisk where code only generates DTMF end
events without the corresponding begin event. One such place is the AMI
action Atxfer.
* Fixed DTMF hook matching if there is a string of DTMF frames in the read
queue. We could potentially miss some of them before.
* Fixed AMI Atxfer action documentation.
(closes issue ASTERISK-22037)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2752/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The feature_attended_transfer test is failing due to Asterisk not
passing DTMF in the bridges created for internal attended transfers.
This sets the features initialization routine to set this flag by
default and adjusts the basic bridge and confbridge's use of the
bridging system accordingly as per Richard's suggestion instead of
adjusting this individual case. This change allows the necessary DTMF
to pass through the attended transfer bridge and complete the test
successfully.
Review: https://reviewboard.asterisk.org/r/2759/
(closes issue ASTERISK-22222)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents swap optimization, merges, and transfers involving Stasis
application bridges. It wouldn't be nice if the bridge you thought you
owned disappeared from under you.
Reported-by: Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Holding bridges can allow local channel move/swap optimization to the
bridge. However, we cannot allow it for the BridgeWait holding bridge
because the call will lose the channel roles and dialplan location as a
result.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396695 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Depending on certain conditions it was possible for the hashtab counting thread
to starve other threads, preventing them from executing in the expected fashion.
This change adds a sleep to allow the others to do what they need to do. While
this doesn't thrash the hashtab as much as previously, it at least works.
(closes issue ASTERISK-22276)
Reported by: Matt Jordan
........
Merged revisions 396619 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 396620 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396621 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch changes ARI bridging to allow other channel operations to
happen while the channel is bridged.
ARI channel operations are designed to queue up and execute
sequentially. This meant, though, that while a channel was bridged,
any other channel operations would queue up and execute only after the
channel left the bridge.
This patch changes ARI bridging so that channel commands can execute
while the channel is bridged. For most operations, things simply work
as expected. The one thing that ended up being a bit odd is recording.
The current recording implementation will fail when one attempts to
record a channel that's in a bridge. Note that the bridge itself may
be recording; it's recording a specific channel in the bridge that
fails. While this is an annoying limitation, channel recording is
still very useful for use cases such as voice mail, and bridge
recording makes up much of the difference for other use cases.
(closes issue ASTERISK-22084)
Review: https://reviewboard.asterisk.org/r/2726/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396568 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The debug logs added in r396528 neglected to account for suseconds_t
being an int.
See r392076 for more info.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These problems were all caught by a test in the Asterisk Test Suite that
originated some Local channels and attempted to move the ;2 half of the Local
channel into a bridge using the Bridge AMI action.
(1) When originating a channel, the Newchannel event is emitted quickly;
however, the ;2 channel will not have a pbx thread assigned to it until
after the outbound 'dialing' for the ;1 is complete. Thus, there is a period
of time where the outside world "knows" of the channel's existence and can
influence it but Asterisk has not yet started the dialplan execution thread.
If a Bridge AMI action is taken on the channel, the channel appears to be a
Dialed channel with no PBX thread; hence, the channel will be imparted into
the Bridge by first 'yanking' the channel. At the same time, a race condition
can occur after the yank (but before entering the bridge) when ;1 answers
and starts a PBX on the ;2. The end result currently is an assertion failure
in the Bridging API, as a channel with a PBX is imparted into the Bridge.
There's no way to prevent AMI from attempting to Bridge a channel
immediately after creation; likewise, holding the channel lock through the
entire Dial operation is unwise (and impossible). Instead of treating the
presence of a PBX thread as an error, we simply bail out of the adding the
channel to the bridge through ast_bridge_impart. The Bridge action will
then fail - but we avoid a situation where the channel is both executing
a PBX thread and simultaneously being given a separate thread in the
bridging system (which would be a "bad thing"). Since imparting a channel
with a PBX *can* occur and is not a programming error, the asserts have been
removed.
(2) When the first condition occurs, we have to take one of two actions: either
hangup the yanked channel as it did not enter the bridge, or deref it
because we don't own it. We can determine if we own it or not by testing
for the presence of the PBX thread. If we hung it up directly, we'd crash.
(3) bridge_find_channel does not increase the reference count of the
ast_bridge_channel object. The RAII_VAR usage in ast_bridge_add_channel
thus created a ticking time bomb in whatever bridge the channel moved into,
as the destructor for the ast_bridge_channel object would be called.
Review: https://reviewboard.asterisk.org/r/2741/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the thread servicing the dial request isn't created successfully, the
outgoing dial lock will still be held when the function returns. This patch
unlocks the lock on this off nominal path.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Disabling DEBUG_THREADS caused this test to fail on the 32-bit build agent.
Adding some debugging to see why it thinks the test is timing out.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a dial operation fails, the pbx_outgoing_attempt routine will exit without
first having unlocked the outgoing dial lock. This would be a "bad thing".
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This makes it so that we can detect failures to originate as with
earlier versions of Asterisk, which restores the Asterisk 11 behavior
for the originate manager action. This was causing the ACL tests for
SIP and IAX2 to fail since those tests expected originate failures
when ACLs would cause rejections. Also, this patch fixes crashes in
chan_sip when ACLs rejected peers during registration verification.
(closes issue ASTERISK-22212)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2753/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The lonely flag is an optional flag for bridge channels that will
make them leave a bridge when a channel leaves if only lonely
channels are in the bridge at that point. This is useful for things
like ending recording and playback channels when they cease to be
interacting with other channels in the bridge.
(closes issue ASTERISK-22117)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2721/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This code adds chan_dahdi the command 'dahdi create channels <range>'
(where <range> is a single <n>-<m> or 'new') and updates 'dahdi destroy
channel' with a similar 'dahdi destroy channels'. It allows DAHDI
channels and spans to be added after the initial channel load
(without destroying all other channels as in 'dahdi restart').
It also includes some fixes to the D-Channel / span destruction code
(r394552).
This change is intended to provide a hook for a script running from
udev once a span has been assigned ("registered") / unassigned
("unregistered") for its channels. The udev hook configures the span's
channels with dahdi_cfg -S, and can then ask Asterisk to create ethe
channels. See the scripts added to DAHDI-tools in 2.7.0.
Review: https://reviewboard.asterisk.org/r/1598/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396474 65c4cc65-6c06-0410-ace0-fbb531ad65f3