| Age | Commit message (Collapse) | Author |
|---|
|
This change protects accesses of res_parking such that it can unload
safely once transient uses of its registered functions are complete.
The parking API has been restructured such that its consumers do not
have access to the vtable exposed by the parking provider, but instead
route through stubs to prevent consumers from holding on to function
pointers.
This adds calls to all the parking unload functions and moves
application loading and unloading into functions in
parking_applications.c similar to the rest of the parts of res_parking.
Review: https://reviewboard.asterisk.org/r/2763/
(closes issue ASTERISK-22142)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This removes usage of the event system for CEL backend data
distribution and strips unused pieces out of the event system.
Review: https://reviewboard.asterisk.org/r/2732/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
|
|
dissolving.
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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396857 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If you've mistakenly put a space before typing in a command, the
leading space will be included as part of the command, and the command
parser will not find the corresponding command. This patch rectifies
that situation by stripping the leading spaces on commands.
Review: https://reviewboard.asterisk.org/r/2709/
Patch-by: Tilghman Lesher
........
Merged revisions 396745 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 396746 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396747 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
AST_BRIDGE_REC_CHANNEL_1, and AST_BRIDGE_IGNORE_SIGS.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396734 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 resolves several deadlocks in chan_sip relating to usage of
ast_channel_bridge_peer and improves accessibility of lock debugging
function calls.
Review: https://reviewboard.asterisk.org/r/2756/
(closes issue ASTERISK-22215)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396723 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396713 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
|
|
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
|
|
Review: https://reviewboard.asterisk.org/r/2566/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396505 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Changed ast_manager_build_bridge_state_string() to assume an empty
prefix string just like ast_manager_build_channel_state_string().
* Created ast_manager_build_bridge_state_string_prefix() to work just like
ast_manager_build_channel_state_string_prefix().
* Made BridgeMerge AMI event use To/From prefixes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does three things:
1. It provides a Surrogate channel technology with a consolidated
"implementation detail flag" on the channel technology. This tells
consumers of Stasis that the creation of this channel is an implementation
detail in Asterisk and can be ignored (if they so choose). This
consolidates the conference recorder/announcer flags as well - these flags
had no additional meaning beyond "ignore this channel please".
2. It modifies allocation of a channel in two ways:
(a) If a channel technology can be determined from the name, we set it
directly in the allocation routine. This prevents the initial
publication of the message from going out with a NULL channel technology
where possible. This lets Stasis consumers get the right channel
technology on the first publication.
(b) It reorganizes allocation to make use of the 'finalized' property on the
channel. This was already used to know that a channel had completely
finished its construction in the masquerade routine; now we also use it
to know whether or not the setting of certain channel properties is
occurring during or post construction. The various set routines were
modified accordingly as well.
3. The masquerade event is now dead, Jim. It no longer served any purpose
whatsoever - if you perform a call pickup you'll get a Pickup event;
if you perform an attended transfer you will still get those events; if you
steal a channel to put it elsewhere you'll get the corresponding NewExten or
BridgeEnter events.
Review: https://reviewboard.asterisk.org/r/2740
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Backtraces are allocated outside of the usual memory tracking performed by
MALLOC_DEBUG. This allows them to be used by the memory tracking enabled
by that build option; however, it also means that when backtraces are
disposed of they have to be done so outside of the re-defined free.
This patch undef's free prior to disposing of the allocated backtrace when
a backtrace is appended as a result of 'core show locks'.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396391 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This prevents unreal channel optimization during the prequalification
phase when either channel is involved in DTMF emulation. This prevents
a situation where an emulated digit would be missed because the
emulation was never completed.
Review: https://reviewboard.asterisk.org/r/2747/
(closes issue ASTERISK-22214)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Depending on when a Surrogate channel replaces an existing channel, it is
possible to get a Dial message for the Surrogate channel. When this occurs, no
CDR will exist for the channel as Surrogate channels are ignored. Safely handle
the case when a CDR doesn't exist for a Dial message.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396371 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch implements the controls from ARI recordings. The controls
are:
* DELETE /recordings/live/{recordingName} - stop recording and
discard it
* POST /recordings/live/{recordingName}/stop - stop recording
* POST /recordings/live/{recordingName}/pause - pause recording
* POST /recordings/live/{recordingName}/unpause - resume recording
* POST /recordings/live/{recordingName}/mute - mute recording (record
silence to the file)
* POST /recordings/live/{recordingName}/unmute - unmute recording.
Since this underlying functionality did not already exist, is was
added to app.c by a set of control frames, similar to how playback
control works. The pause/mute control frames are toggles, even though
the ARI controls are idempotent, to be consistent with the playback
control frames.
(closes issue ASTERISK-22181)
Review: https://reviewboard.asterisk.org/r/2697/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The Stasis changes in r395954 had an unanticipated side effect: messages
published directly to an _all topic does not get forwarded to the
corresponding caching topic.
This patch fixes that by changing how caching topics forward messages,
and how the caching pattern forwards are setup.
For the caching pattern, the all_topic is forwarded to the
all_topic_cached. This forwards messages published directly to the
all_topic to all_topic_cached.
In order to avoid duplicate messages on all_topic_cached, caching topics
were changed to no longer forward uncached messages. Subscribers to an
individual caching topic should only expect to receive cache updates,
and subscription change messages. Since individual caching topics are
new, this shouldn't be a problem.
There are a few minor changes to the pre-cache split behavior.
* For topics changed to use the caching pattern, the all_topic_cached
will forward snapshots in addition to cache updates. Since
subscribers by design ignore unexpected messages, this should be
fine.
* Caching topics that don't use the caching pattern no longer forward
non-cache updates. This makes no difference for the current caching
topics.
* mwi_topic_cached, channel_by_name_topic and
presence_state_topic_cached have no subscribers
* device_state_topic_cached's only subscriber only processes cache
udpates
(issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2738
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Fix refcount bugs and a possible locking problem in the CDR engine
relating to use of ao2_iterators.
Review: https://reviewboard.asterisk.org/r/2724/
(closes issue ASTERISK-22126)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
We try to keep the system running even when all available memory is
spent.
Review: https://reviewboard.asterisk.org/r/2734/
........
Merged revisions 396279 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 396287 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Dial and Queue would previously apply a new set of features whenever
bridging. These options would be based purely on the options supplied
to the dial/queue applications. This patch changes the function those
applications use to bridge calls so that the features will be added
to the set of existing features for each channel rather than having
them override the existing features.
(closes issue ASTERISK-22209)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2713/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Roles are now cleared with each entry into a bridge with addChannel.
If the roles parameter is present, the role specified will be applied
to all channels being added with the addChannel command.
(closes issue ASTERISK-21973)
Reported by: Matt Jordan
https://reviewboard.asterisk.org/r/2691/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The new res_ari_asterisk.so module presents several config options
from asterisk main. Unfortunately, they aren't exported, so the module
won't load on Linux.
This patch renames the variables, adding the ast_ prefix so they will
be exported.
Review: https://reviewboard.asterisk.org/r/2737
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The AMI message router is owned wholly by manager.c. Previously, each of the
manager_{item} source files had their own message router and they unsubscribed
from each; once they moved over to using a single message router only a single
unsubscribe became necessary.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In tracking down some unit tests failures, I ended up reading the fine
print[1] regarding Jansson's thread safety.
In short:
1. Ref-counting is non-atomic.
2. json_dumps() and friends are not thread safe.
This patch adds locking where necessary to our ast_json_* wrapper API,
with documentation in json.h describing the thread safety limitations of
the API.
[1]: http://www.digip.org/jansson/doc/2.4/portability.html#thread-safety
Review: https://reviewboard.asterisk.org/r/2716/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
occurring.
* BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable.
* There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place.
(closes issue ASTERISK-22193)
reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/2712
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This moves ast_str_container_alloc, ast_str_container_add,
ast_str_container_remove, and related private functions into
strings.c/h since they really don't belong in astobj2.c/h.
As a result of this move, utils also had to be updated.
Review: https://reviewboard.asterisk.org/r/2719/
(closes issue ASTERISK-22041)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396105 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This commit is smaller than the initial review placed on review board. This is because
a change to allow for channel drivers to access parking functionality externally was
committed and invalidated quite a few of the changes initially made.
(closes issue ASTERISK-22039)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2717
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396099 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
* It moves the pickup code out of features.c and into pickup.c
* It removes the vast majority of dead code out of features.c. In particular,
this includes the parking code.
(issue ASTERISK-22134)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Some regex implementations won't compile an empty string. Assuming that
it's equivalent of a regex that will match anything, use ".?" instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
* It adds support for externally initiated parking requests. In particular,
chan_skinny has a protocol level message that initiates a call park.
This patch now supports that option, as well as the protocol specific
mechanisms in chan_dahdi/sig_analog and chan_mgcp.
* A parking bridge features virtual table has been added that provides
access to the parking functionality that the Bridging API needs. This
includes requests to park an entire 'call' (with little or no additional
information, thank you chan_skinny), perform a blind transfer to a parking
extension, determine if an extension is a parking extension, as well as the
actual "do the parking" request from the Bridging API.
* Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new
functions
* The removal of some - but not all - dead parking code from features.c
This also fixed blind transferring a multi-party bridge to a parking lot (which
was implemented, but had at least one code path where using the parking features
kK might not have worked)
Review: https://reviewboard.asterisk.org/r/2710
(closes issue ASTERISK-22134)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
