The change contains a slightly adjusted patch that was on the issue
(submitted by kmoore).  A fix was made by adding in a bridge lock
while calling bridge_start/stop from the framehook callback.  Since
the framehook callback is not called from the bridging core the bridge
is not locked, but needs to be before calling bridge_start.

(closes issue ASTERISK-22749)
Reported by: Kinsey Moore
Review: https://reviewboard.asterisk.org/r/3066/
Patches:
     lock_inversion.diff uploaded by kmoore (license 6273)
........

Merged revisions 403767 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403768 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When a bridge transitions away from one tech to another, the tech going
away is provided a dummy bridge with no channels in it to tear down.
Currently this means that the teardown code exits prematurely and does
not tear anything down. This change tears down RTP bridging for the
channel provided in the leave bridge tech callback.

This also reverts the majority of r400403 since it is now redundant.

(closes issue ASTERISK-22628)
(closes issue ASTERISK-22676)
Reported by: John Bigelow
Reported by: Kevin Harwell
Tested by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2905/
Patches:
    native_rtp_fix.diff uploaded by Kinsey Moore (License 6273)
........

Merged revisions 402148 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402149 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The crash is caused by a race condition when switching between native RTP
and softmix bridging technologies.  In this situation, the bridging
technology is switched from native RTP to softmix, and then back to native
RTP fast enough that the softmix private data gets destroyed before the
softmix mixing thread gets started.

Thanks to Kinsey Moore for the crash analysis.

* Fix race condition when starting the softmix mixing thread and switching
to another bridge technology.

(closes issue ASTERISK-22678)
Reported by: John Bigelow
Patches:
      jira_asterisk_22678_v12.patch (license #5621) patch uploaded by rmudgett
Tested by: John Bigelow
........

Merged revisions 400849 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400850 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When a party leaves a bridge, there may be more participants in the bridge than expected.
As such, it is important not to make assumptions regarding the list of channels in a
bridge.

This change makes it so that when a party leaves a native RTP bridge, we unbridge it and
the party it was bridged with. Previously, the first and last channels in the list were
unbridged since it was assumed that these were the two channels that had been bridged. As
previously stated, a new party had been inserted into the bridge, so this logic did not
work properly.

(closes issue ASTERISK-22615)
reported by Matt Jordan

Review: https://reviewboard.asterisk.org/r/2899
........

Merged revisions 400403 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400452 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.

Review: https://reviewboard.asterisk.org/r/2879
........

Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3

These refleaks were causing bridged calls not to close their RTP ports. Thus
a call would leave open 4 ports (RTP for party A, RTCP for party A, RTP for party
B, and RTCP for party B). This led to an eventual depletion of available RTP
ports.
........

Merged revisions 399924 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399925 65c4cc65-6c06-0410-ace0-fbb531ad65f3

If bridge_softmix fails to be created because no timing source is present in
Asterisk, this will currently fail gracefully but with (most likely) a generic
error message by whatever module tried to create the softmix bridge. This
patch adds a more explicit warning so you can actually diagnose and fix the
problem.

Review: https://reviewboard.asterisk.org/r/2857/
........

Merged revisions 399353 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 399365 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399368 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Issuing hold/unhold would lead to odd behavior. Between two chan_sip devices,
a hold could cause an endless chain of updates while with pjsip a similar chain
would begin but then end somewhat randomly. This patch fixes that by no longer
tweaking the RTP glue on both sides of the call for every
HOLD/UNHOLD/UPDATE_RTP_PEER frame.

(issue ASTERISK-22217)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2794/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397578 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

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397494 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The cause code needs to be passed from the disconnecting channel to the
bridge peers if the disconnecting channel dissolves the bridge.

* Made the call to an app_agent_pool agent disconnect with the busy cause
code if the agent does not ack the call in time or hangs up before acking
the call.

(closes issue ASTERISK-22042)
Reported by: Matt Jordan

Review: https://reviewboard.asterisk.org/r/2772/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397472 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Added an option flags parameter to interval hooks.  Interval hooks now
can specify if the callback will affect the media path or not.

* Added an option flags parameter to the bridge action custom callback.
The action callback now can specify if the callback will affect the media
path or not.

* Made the holding bridge technology reexamine the participant idle mode
option whenever the entertainment is restarted.

* Fixed app_agent_pool waiting agents needlessly starting and stopping MOH
every second by specifying the heartbeat interval hook as not affecting
the media path.

* Fixed app_agent_pool agent alert from restarting the MOH after the alert
beep.  The agent entertainment is now changed from MOH to silence after
the alert beep.

* Fixed holding bridge technology to defer starting the entertainment.  It
was previously a mixture of immediate and deferred.

* Fixed holding bridge technology to immediately stop the entertainment.
It was previously a mixture of immediate and deferred.  If the channel
left the bridging system, any deferred stopping was discarded before
taking effect.

* Miscellaneous holding bridge technology rework coding improvements.

Review: https://reviewboard.asterisk.org/r/2761/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397294 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396783 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396512 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Suspend and unsuspend callbacks are added to the holding bridge so
that entertainment can be disabled and re-enabled when operations
would suspend a channel on the bridge (such as playback operations).
This fixes entertainment so that when those operations end, the
entertainment can pick back up and it also serves as an optimization.
Also, this patch fixes a bug caused by triggering ringing frames
immediately instead of pushing them to the queue which created a race
condition where sometimes parking with ringing during attended
transfers would cause the ringing to be interrupted by an unhold
frame.

(closes issue ASTERISK-22006)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2711/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396189 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Fix hold/unhold in bridge_native_rtp, use tech_pvt instead of bridge_pvt, reduce bridging attempts, and fix breaking native RTP bridges.

(closes issue ASTERISK-22128)

(closes issue ASTERISK-22104)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395866 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

* Fixed feature limits to not use special members of struct
ast_bridge_features.

* Fixed memory leak in off nominal paths of bridge_builtin_set_limits().

* Fixed off nominal path in ast_bridge_features_limits_construct() freeing
unallocated memory if it was not called by bridge_builtin_set_limits().

* Made bridge_builtin_interval_features.so unloadable.

* Simplified parking's use of its duration interval hook.

* Made BridgeWait S option not depend upon another module being loaded.

(closes issue ASTERISK-22107)
Reported by: Matt Jordan

Review: https://reviewboard.asterisk.org/r/2701/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395559 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395466 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

One more major refactoring to go.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395367 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395295 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395254 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch does the following:
 * It pulls out bridge_channel and puts it into its own translation unit
 * It adds public and protected headers for bridging_channel. Protected
   functions are appropriate only for the Bridging API and sub-classes of a
   bridge.

(issue ASTERISK-22130)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395253 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395227 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395205 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Fix some logic so native RTP bridge will occur when monitor, audiohooks, or framehooks are not present.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395203 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395188 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Created a native_dahdi bridging technology for use with the new bridging
API.

The new bridging technology is part of the chan_dahdi channel driver
because it is very specific to that driver.  Rather than include the new
code directly into chan_dahdi.c the new bridge technology is in its own
file and linked into chan_dahdi.so.  A large part of this change is the
mechanical process of moving declarations around so chan_dahdi.c can be
split up into more files later.

* Changed the bridging core to pass NULL frames into the channel
technologies instead of discarding them.  The channel technologies may
need the proding to determine if their configuration is still valid.

(closes issue ASTERISK-21886)
Reported by: Matt Jordan

Review: https://reviewboard.asterisk.org/r/2681/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395154 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This greatly modifies the operation of DTMF attended transfers so that
the full range of options from features.conf applies.

In addition, a new option has been added that allows for a transferer
to switch between bridges during a transfer before completing the
transfer.

(closes issue ASTERISK-21543)
reported by Matt Jordan

Review: https://reviewboard.asterisk.org/r/2654



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395151 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394825 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch adds more entertainment options to holding bridges and the
bridge_wait application. Also, holding bridges will now use music on
hold as the default entertainment option instead of none. The
parameters for app_bridgewait have changed to (role, options) from
the previous (options) and the options themselves have changed as
well (entertainment options are now contained in an enumerator, role
specification is handled by the role parameter, etc)

(closes issue ASTERISK-21923)
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/2679/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394731 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394470 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This process also involved a large amount of rework regarding how to redial
the Parker when a channel leaves a parking lot due to timeout. An attended
transfer channel variable has been added to attended transfers to extensions
that will eventually park (but haven't at the time of transfer) as well.
This resolves one of the two BUGBUG comments remaining in res_parking.

(issues ASTERISK-21877)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2638/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393704 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The OneTouchRecord feature has historically been a toggle.  This patch
adds the ability to make the OneTouchRecord hook optionally start/stop
recording only.  If OneTouchRecord is already doing what is requested then
only the invoker hears the courtesy tone and/or start/stop recording
message.

The new feature is written so we could easily add explicit start/stop
recording DTMF hooks for Monitor and MixMonitor.

The majority of the changes in bridge_builtin_features.c is a refactoring
of the OneTouchRecord code (Monitor and MixMonitor versions) so it is easy
to direct the toggle/start/stop functionality.

Review: https://reviewboard.asterisk.org/r/2655/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393612 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In addition to porting those features, they now enjoy greater feature parity
with one another. Specifically, AutoMixMon now has a start and stop
message that can be specified with TOUCH_MIXMONITOR_MESSAGE_START and
TOUCH_MIXMONITOR_MESSAGE_STOP.

(closes issue ASTERISK-21553)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2620/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393309 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This creates stasis messages that are sent during a blind or
attended transfer. The stasis messages also are converted to
AMI events.

Review: https://reviewboard.asterisk.org/r/2619

(closes issue ASTERISK-21337)
Reported by Matt Jordan



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393182 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Extract a useful routine from the softmix bridge technology for other
technologies.  Make other technologies use it if they can.

* Made native and 1-1 bridges write to all parties if the bridge channel
writing the frame into the bridge is NULL.  Softmix will also do the same
for frame types that make sense.

* Tweak the bridge write routine return value meaning and adjust the
bridge technologies to match.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392514 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The bridge frame queue functions need to return an error status if the
frame failed to be queued because of an error condition.  The main calls
that needed to return the status are:
ast_bridge_channel_queue_action_data() and
ast_bridge_channel_write_action_data().  The other return changes are
ripple effects.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392435 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch fixes two memory leaks:
 * A memory leak in packing channels into a multi-channel blob payload when
   publishing dial messages. The multi-channel blob payload does not steal
   the references - this approach was chosen because it works well with the
   RAII_VAR macro. Unfortunately, this does mean that you actually have to use
   the RAII_VAR macro (or manually deref it yourself)
 * RTP instances returned as a result of one of the glue operations are ref
   counted and have to be de-ref'd appropriately. We now do that, as saying
   that we should do it and then not would be silly.




git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391479 65c4cc65-6c06-0410-ace0-fbb531ad65f3