This change adds a deferred queue to bridging. If a bridge
technology determines that a frame can not be written and
should be deferred it can indicate back to bridging to do so.
Bridging will then requeue any deferred frames upon a new
channel joining the bridge.
This change has been leveraged for T.38 request negotiate
control frames. Without the deferred queue there is a race
condition between the bridge receiving the T.38 request
negotiate and the second channel joining and being in the
bridge. If the channel is not yet in the bridge then the T.38
negotiation fails.
A unit test has also been added that confirms that a T.38
request negotiate control frame is deferred when no other
channel is in the bridge and that it is requeued when a new
channel joins the bridge.
ASTERISK-26923
Change-Id: Ie05b08523f399eae579130f4a5f562a344d2e415
An earlier patch blocked the ast_bridge_impart() call until the channel
either entered the target bridge or it failed. Unfortuantely, if the
target bridge is stasis and the imprted channel is not a stasis channel,
stasis bounces the channel out of the bridge to come back into the bridge
as a proper stasis channel. When the channel is bounced out, that
released the block on ast_bridge_impart() to continue. If the impart was
a result of a transfer, then it became a race to see if the swap channel
would get hung up before the imparted channel could come back into the
stasis bridge. If the imparted channel won then everything is fine. If
the swap channel gets hung up first then the transfer will fail because
the swap channel is leaving the bridge.
* Allow a chain of ast_bridge_impart()'s to happen before any are
unblocked to prevent the race condition described above. When the channel
finally joins the bridge or completely fails to join the bridge then the
ast_bridge_impart() instances are unblocked.
ASTERISK-25947
Reported by: Richard Mudgett
ASTERISK-24649
Reported by: John Bigelow
ASTERISK-24782
Reported by: John Bigelow
Change-Id: I8fef369171f295f580024ab4971e95c799d0dde1
Local channel optimization could cause DTMF digits to be duplicated.
Pending DTMF end events would be posted to a bridge when the local channel
optimizes out and is replaced by the channel further down the chain. When
the real digit ends, the channel would get another DTMF end posted to the
bridge.
A -- LocalA;1/n -- LocalA;2/n -- LocalB;1 -- LocalB;2 -- B
1) LocalA has the /n flag to prevent optimization.
2) B is sending DTMF to A through the local channel chain.
3) When LocalB optimizes out it can move B to the position of LocalB;1
4) Without this patch, when B swaps with LocalB;1 then LocalB;1 would
settle an owed DTMF end to the bridge toward LocalA;2.
5) When B finally ends its DTMF it sends the DTMF end down the chain.
6) Without this patch, A would hear the DTMF digit end when LocalB
optimizes out and when B ends the original digit.
ASTERISK-25582
Change-Id: I1bbd28b8b399c0fb54985a5747f330a4cd2aa251
During an attended transfer a thread is started that handles imparting the
bridge channel. From the start of the thread to when the bridge channel is
ready exists a gap that can potentially cause problems (for instance, the
channel being swapped is hung up before the replacement channel enters the
bridge thus stopping the transfer). This patch adds a condition that waits
for the impart thread to get to a point of acceptable readiness before
allowing the initiating thread to continue.
ASTERISK-24782
Reported by: John Bigelow
Change-Id: I08fe33a2560da924e676df55b181e46fca604577
When code imparts a channel into a bridge to swap with another channel, a
ref needs to be held on the swap channel to ensure that it cannot
dissapear before finding it in the bridge.
* The ast_bridge_join() swap channel parameter now always steals a ref for
the swap channel. This is the only change to the bridge framework's
public API semantics.
* bridge_channel_internal_join() now requires the bridge_channel->swap
channel to pass in a ref.
ASTERISK-24649
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4354/
........
Merged revisions 430975 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original issue noted that the bridge is orphaned when res_parking.so
is not loaded and a call uses the dial kK flags.
A similar issue happens when only one of the park flags is used. In this
case you have the bridge with one or the other channel left in it. The
channel and bridge will stay around until the channel hangs up.
* Fixed the initial bridge channel push failure to act as if the channel
were kicked out of the bridge. The bridge then decides if it needs to be
dissolved.
(closes issue ASTERISK-22629)
Reported by: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/2928/
........
Merged revisions 401424 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
DTMF start/end and hold/unhold events have state because a DTMF begin
event and hold event must be ended by something.
The following cases need to be handled when a channel is moved around in
the system.
* When a channel leaves a bridge it may owe a DTMF end event to the
bridge.
* When a channel leaves a bridge it may owe an UNHOLD event to the bridge.
(This case is explicitly ignored because things like transfers need
explicit control over this.)
* When a channel leaves the bridging system it may need to simulate a DTMF
end event to the channel.
* When a channel leaves the bridging system it may need to simulate an
UNHOLD event to the channel.
The patch also fixes the following:
* Fixes playing a file and restarting MOH using the latest MOH class used.
(closes issue ASTERISK-22043)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2791/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397577 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
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
Alexander Traud
Joshua Colp
Richard Mudgett
Kevin Harwell
Jonathan Rose
Matthew Jordan