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
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
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
* 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 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
Most hook callbacks did not need the bridge parameter. The pointer value
could become invalid if the channel is moved to another bridge while it is
executing.
* Fixed some issues in feature_attended_transfer() as a result.
* Reduce the bridge inhibit count in
attended_transfer_properties_shutdown() after it has restored the bridge
channel hooks.
* Removed basic bridge requirement on feature_blind_transfer(). It does
not require the basic bridge like feature_attended_transfer().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes arguments for BridgeWait from BridgeWait(role, options) to
BridgeWait(bridge_name, role, options). Now multiple holding bridges may
be created and referenced by this application.
(closes issue ASTERISK-21922)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2642/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Matthew Jordan
Jonathan Rose
Mark Michelson