This reverts commit f42d22d3.

Unfortunately, using a bridge to manage T.38 state will cause severe deadlocks
in core_unreal/chan_local. Local channels attempt to reach across both their
peer and the peer's bridge to inspect T.38 state. Given the propensity of
Local channel chains, managing the locking situation in such a scenario is
practically infeasible.

Change-Id: I932107387c13aad2c75a7a4c1e94197a9d6d8a51

When 4875e5ac was merged, it fixed several issues with a direct media bridge
transitioning to handling a T.38 fax. However, it uncovered a race condition
caused by the bridging core. When a channel involved in a T.38 fax leaves a
bridge, the frame queued by the channel driver that should inform the far side
that it is no longer in a T.38 fax may not make it across the bridge. The
bridging framework is *extremely* aggressive in tearing down the bridge, and
control frames that are currently in flight *may* get dropped.

This patch adds a new module to the bridging framework, bridge_t38. This module
maintains some notion of the T.38 state for the two channels in a bridge. When
the bridge detects that it is being torn down or when one of the two channels
leaves, it informs the respective channel(s) that they should stop faxing. This
ensures that channels switch back to audio if they survive and are ejected out
of a bridge while faxing.

ASTERISK-25582

Change-Id: If5b0bb478eb01c4607c9f4a7fc17c7957d260ea0

ASTERISK-25533 #close

Change-Id: Ie1a9d1a6511b3f1a56b93d04475fbf8a4e40010a

Currently, if a blank musiconhold.conf is used, musiconhold will fail
to start for a channel going into a holding bridge with an anticipation
of getting music on hold. That being the case, no frames will be written
to the channel and that can pose a problem for blind transfers in PJSIP
which may rely on frames being written to get past the REFER framehook.
This patch makes holding bridges start a silence generator if starting
music on hold fails and makes it so that if no music on hold functions
are installed that the ast_moh_start function will report a failure so
that consumers of that function will be able to respond appropriately.

ASTERISK-25271 #close

Change-Id: I06f066728604943cba0bb0b39fa7cf658a21cd99
(cherry picked from commit 8458b8d4)

The bridge_native_rtp module adds a frame hook to channels which are in
a native RTP bridge. This frame hook is used to intercept when a hold
or unhold frame traverses the bridge so native RTP can be stopped or
started as appropriate. This is expected but exposes a specific bug
when attended transfers are involved.

Upon completion of an attended transfer an unhold frame is queued up
to take one of the channels involved off hold. After this is done
the channel is moved between bridges.

When the frame hook is involved in this case for the unhold it
releases the channel lock and acquires the bridge lock. This
allows the bridge core to step in and move the channel
(potentially changing the bridging techology) from another thread.
Once completed the bridge lock is released by the bridge core.
The frame hook is then able to acquire the bridge lock and
wrongfully starts native RTP again, despite the channel no longer
being in the bridge or needing to start native RTP. In fact at
this point the frame hook is no longer attached to the channel.

This change makes it so the native RTP bridge data is available to
the frame hook when it is invoked. Whether the frame hook has
been detached or not is stored on the native RTP bridge data and
is checked by the frame hook before starting or stopping native
RTP bridging. If the frame hook has been detached it does nothing.

ASTERISK-25240 #close

Change-Id: I13a73186a05f4e5a764f81e5cd0ccec1ed1891d2

Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:

* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
  remove passing the version in with the macro. Other facilities
  than 'core show file version' make use of the file names, such as
  setting a debug level only on a specific file. As such, the act of
  registering source files with the Asterisk core still has use. The
  macro rename now reflects the new macro purpose.

* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Remove the "core show file version" CLI command. Without the file
    version, it is no longer useful.
  - Remove the ast_file_version_find function. The file version is no
    longer tracked.
  - Rename ast_register_file_version/ast_unregister_file_version to
    ast_register_file/ast_unregister_file, respectively.

* main/manager: Remove value from the Version key of the ModuleCheck
  Action. The actual key itself has not been removed, as doing so would
  absolutely constitute a backwards incompatible change. However, since
  the file version is no longer tracked, there is no need to attempt to
  include it in the Version key.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action
  - Removal of the "core show file version" CLI command

Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e

With this patch, chan_pjsip/res_pjsip now sets the native formats to the
codecs negotiated by a call.

* The changes in chan_pjsip.c and res_pjsip_sdp_rtp.c set the native
formats to include all the negotiated audio codecs instead of only the
initial preferred audio codec and later the currently received audio
codec.

* The audio frame handling in channel.c:ast_read() is more streamlined and
will automatically adjust to changes in received frame formats.  The new
policy is to remove translation and pass the new frame format to the
receiver except if the translation was to a signed linear format.  A more
long winded version is commented in ast_read() along with some caveats.

* The audio frame handling in channel.c:ast_write() is more streamlined
and will automatically adjust any needed translation to changes in the
frame formats sent.  Frame formats sent can change for many reasons such
as a recording is being played back or the bridged peer changed the format
it sends.  Since it is a normal expectation that sent formats can change,
the codec mismatch warning message is demoted to a debug message.

* Removed the short circuit check in
channel.c:ast_channel_make_compatible_helper().  Two party bridges need to
make channels compatible with each other.  However, transfers and moving
channels among bridges can result in otherwise compatible channels having
sub-optimal translation paths if the make compatible check is short
circuited.  A result of forcing the reevaluation of channel compatibility
is that the asterisk.conf:transcode_via_slin and codecs.conf:genericplc
options take effect consistently now.  It is unfortunate that these two
options are enabled by default and negate some of the benefits to the
changes in channel.c:ast_read() by forcing translation through signed
linear on a two party bridge.

* Improved the softmix bridge technology to better control the translation
of frames to the bridge.  All of the incoming translation is now normally
handled by ast_read() instead of splitting any translation steps between
ast_read() and the slin factory.  If any frame comes in with an unexpected
format then the translation path in ast_read() is updated for the next
frame and the slin factory handles the current frame translation.

This is the final patch in a series of patches aimed at improving
translation path choices.  The other patches are on the following reviews:
https://reviewboard.asterisk.org/r/4600/
https://reviewboard.asterisk.org/r/4605/

ASTERISK-24841 #close
Reported by: Matt Jordan

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

Merged revisions 434671 from http://svn.asterisk.org/svn/asterisk/branches/13


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

* Made code easier to follow in bridge_softmix.c:analyse_softmix_stats()
and made some debug messages more helpful.

* Made some debug and warning messages more helpful in
channel.c:set_format().

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

Merged revisions 434617 from http://svn.asterisk.org/svn/asterisk/branches/13


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

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

Merged revisions 434508 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When a channel enters the bridging system it is first made compatible with
the bridge and then the bridge technology makes the channel compatible
with the technology.  For all but the DAHDI native and softmix bridge
technologies the make channel compatible with the bridge step is an
effective noop because the other technologies allow all audio formats.
For the DAHDI native bridge technology it doesn't matter because it is not
an initial bridge technology and chan_dahdi allows only one native format
per channel.  For the softmix bridge technology, it is a noop at best and
harmful at worst because the wrong translation path could be setup if the
channel's native formats allow more than one audio format.

This is an intermediate patch for a series of patches aimed at improving
translation path choices.

* Removed code dealing with the unnecessary step of making the channel
compatible with the bridge.

ASTERISK-24841
Reported by: Matt Jordan

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

Merged revisions 434424 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When more than one call using the same codec type enters into a softmix bridge
and no audio is present for a channel the bridge optimizes the out frame by
using the same one for all channels with the same codec type. Unfortunately,
when that number (channels with same codec type) dropped to <= 1 the codec
was not dereferenced. At least not until all parties left the bridge. Thus in
the case of G.729 the license was not released. This patch ensures that the
codec is dereferenced immediately when the optimization no longer applies.

ASTERISK-24797 #close
Reported by: Luke Hulsey
Review: https://reviewboard.asterisk.org/r/4429/
........

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

Merged revisions 432175 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Add ast_module_shutdown_ref for use by modules that can
only be unloaded during graceful shutdown.

When REF_DEBUG is enabled:
* Add an empty ao2 object to struct ast_module.
* Allocate ao2 object when the module is loaded.
* Perform an ao2_ref in each place where mod->usecount is manipulated.
* ao2_cleanup on module unload.

ASTERISK-24479 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4141/
........

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

Merged revisions 431663 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Change the "Locally bridged"/"Remotely bridged" messages from dbg/2 to verb/4.

Tested-by: George Joseph

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

Merged revisions 430225 from http://svn.asterisk.org/svn/asterisk/branches/13


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

After r425242 the fax/sip/directmedia_reinvite_t38 test started failing due to
the surviving channel not being re-INVITEd back from T.38 to audio. This patch
fixes that bug - a deeper explanation of what happened follows.

When two RTP channels are in a native bridge, the bridging layer will
investigate each via the get_rtp_info glue callback. This callback returns the
native bridge preference of the channel *at that moment in time* (that part is
key). At different points during the bridging, the native bridging layer will
inform the RTP capable channels of the status of the bridge via the update_peer
glue callback.

In a T.38 scenario with audio direct media, the sequence of events will often
look like the following:
 * SIP/A and SIP/B both have audio and enter a native bridge.
 * Asterisk re-INVITEs audio between SIP/A and SIP/B directly (via an
   update_peer callback).
 * SIP/A sends a re-INVITE to T.38, which causes Asterisk to send a re-INVITE
   to T.38 to SIP/B. Assuming everyone 200 OKs the process, the UDPTL stack
   receives UDPTL packets in Asterisk from both endpoints. From the perspective
   of the channels, we are now in a local bridge for T.38, even though we are
   technically still in a remote bridge in bridge_native_rtp. (YAY!)
 * When one side hangs up, bridge_native_rtp is told to stop bridging. It then
   re-evaluates the channels and asks them how they are bridged - and since
   T.38 is enabled, they reply with a Local bridge (which is correct), but is
   wrong because the audio portion is still technically in a remote bridge.
 * Asterisk releases the surviving channel, whose audio is *not* re-INVITED
   back to Asterisk as bridge_native_rtp incorrectly assumes that it was in a
   local bridge.

Ironically, prior to r425242, this used to work mostly due to a fluke in the
bridging layer.

The purpose of the get_rtp_info callback shouldn't be modified: it should tell
the bridging layer what kind of bridge the channel prefers at that moment in
time. If you have T.38 enabled, that *must* be a local bridge, as the UDPTPL
stack must be in the media path. As such, this patch does not modify that
part of the code.

However, we have to tell the channels to re-evaluate themselves when they come
out of a native bridge, since we can no longer trust the get_rtp_info callbacks
when the native bridge is being stopped. Something else may have changed in the
channels, and they may now be lying to us. As such, this patch makes it so that
we unilaterally tell the channels that they are no longer bridged via the
update_peer callback. This is actually what the channels expect anyway: code in
both chan_sip and chan_pjsip's callbacks look at the T.38 state and - if they
were in T.38 - send a re-INVITE to get the audio back to Asterisk.

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

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

Merged revisions 427583 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The feature_automonitor() and feature_automixmonitor() functions were not
locking the channel around ast_get_chan_features_general_config().
Accessing the channel datastore list without the channel locked is a good
way to corrupt the list or follow the pointer chain into oblivion.
........

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

Merged revisions 426552 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When a native RTP bridge that is remotely bridging its participants switches
to a softmix bridge, it may not properly re-INVITE the media for one or both
participants back to Asterisk. This is due to the current bridge_native_rtp
code only re-INVITEs if it believes the channel will survive the bridge
operation. Currently, that code is failing, as it expects the channels to
have a soft hangup flag set on it indicating that a redirect has occurred
or that the channel is going to leave the bridge. (The code did not take into
account a smart bridge operation).

This patch also renames a few things to be more reflective of the underlying
types.

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

ASTERISK-24327 #close
........

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

Merged revisions 425761 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When a smart bridge operation occurs and a bridge transitions from one
technology to another the old technology is provided the channels formerly
in it and told that they are leaving. Unfortunately the bridge provided
along with them is incomplete. The bridge, despite there being channels in it,
contains none. This forces technology implementations to have additional
logic when channels are leaving or to store their own duplicated
state.

This change makes the bridge more complete so it contains the expected
channels. Now that the bridge is complete special logic within
bridge_native_rtp is no longer needed and has been removed.

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

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

Merged revisions 425243 from http://svn.asterisk.org/svn/asterisk/branches/13


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

* Clarified some read/write format comments.

* Fixed a doxygen tag typo.
........

Merged revisions 423423 from http://svn.asterisk.org/svn/asterisk/branches/13


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

In the old times media formats were represented using a bit field. This was
fast but had a few limitations.
 1. Asterisk was limited in how many formats it could handle.
 2. Formats, being a bit field, could not include any attribute information.
    A format was strictly its type, e.g., "this is ulaw".
This was changed in Asterisk 10 (see
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for
notes on that work) which led to the creation of the ast_format structure.
This structure allowed Asterisk to handle attributes and bundle information
with a format.

Additionally, ast_format_cap was created to act as a container for multiple
formats that, together, formed the capability of some entity. Another
mechanism was added to allow logic to be registered which performed format
attribute negotiation. Everywhere throughout the codebase Asterisk was
changed to use this strategy.

Unfortunately, in software, there is no free lunch. These new capabilities
came at a cost.

Performance analysis and profiling showed that we spend an inordinate
amount of time comparing, copying, and generally manipulating formats and
their related structures. Basic prototyping has shown that a reasonably
large performance improvement could be made in this area. This patch is the
result of that project, which overhauled the media format architecture
and its usage in Asterisk to improve performance.

Generally, the new philosophy for handling formats is as follows:
 * The ast_format structure is reference counted. This removed a large amount
   of the memory allocations and copying that was done in prior versions.
 * In order to prevent race conditions while keeping things performant, the
   ast_format structure is immutable by convention and lock-free. Violate this
   tenet at your peril!
 * Because formats are reference counted, codecs are also reference counted.
   The Asterisk core generally provides built-in codecs and caches the
   ast_format structures created to represent them. Generally, to prevent
   inordinate amounts of module reference bumping, codecs and formats can be
   added at run-time but cannot be removed.
 * All compatibility with the bit field representation of codecs/formats has
   been moved to a compatibility API. The primary user of this representation
   is chan_iax2, which must continue to maintain its bit-field usage of formats
   for interoperability concerns.
 * When a format is negotiated with attributes, or when a format cannot be
   represented by one of the cached formats, a new format object is created or
   cloned from an existing format. That format may have the same codec
   underlying it, but is a different format than a version of the format with
   different attributes or without attributes.
 * While formats are reference counted objects, the reference count maintained
   on the format should be manipulated with care. Formats are generally cached
   and will persist for the lifetime of Asterisk and do not explicitly need
   to have their lifetime modified. An exception to this is when the user of a
   format does not know where the format came from *and* the user may outlive
   the provider of the format. This occurs, for example, when a format is read
   from a channel: the channel may have a format with attributes (hence,
   non-cached) and the user of the format may last longer than the channel (if
   the reference to the channel is released prior to the format's reference).

For more information on this work, see the API design notes:
  https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite

Finally, this work was the culmination of a large number of developer's
efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the
work in the Asterisk core, chan_sip, and was an invaluable resource in peer
reviews throughout this project.

There were a substantial number of patches contributed during this work; the
following issues/patch names simply reflect some of the work (and will cause
the release scripts to give attribution to the individuals who work on them).

Reviews:
 https://reviewboard.asterisk.org/r/3814
 https://reviewboard.asterisk.org/r/3808
 https://reviewboard.asterisk.org/r/3805
 https://reviewboard.asterisk.org/r/3803
 https://reviewboard.asterisk.org/r/3801
 https://reviewboard.asterisk.org/r/3798
 https://reviewboard.asterisk.org/r/3800
 https://reviewboard.asterisk.org/r/3794
 https://reviewboard.asterisk.org/r/3793
 https://reviewboard.asterisk.org/r/3792
 https://reviewboard.asterisk.org/r/3791
 https://reviewboard.asterisk.org/r/3790
 https://reviewboard.asterisk.org/r/3789
 https://reviewboard.asterisk.org/r/3788
 https://reviewboard.asterisk.org/r/3787
 https://reviewboard.asterisk.org/r/3786
 https://reviewboard.asterisk.org/r/3784
 https://reviewboard.asterisk.org/r/3783
 https://reviewboard.asterisk.org/r/3778
 https://reviewboard.asterisk.org/r/3774
 https://reviewboard.asterisk.org/r/3775
 https://reviewboard.asterisk.org/r/3772
 https://reviewboard.asterisk.org/r/3761
 https://reviewboard.asterisk.org/r/3754
 https://reviewboard.asterisk.org/r/3753
 https://reviewboard.asterisk.org/r/3751
 https://reviewboard.asterisk.org/r/3750
 https://reviewboard.asterisk.org/r/3748
 https://reviewboard.asterisk.org/r/3747
 https://reviewboard.asterisk.org/r/3746
 https://reviewboard.asterisk.org/r/3742
 https://reviewboard.asterisk.org/r/3740
 https://reviewboard.asterisk.org/r/3739
 https://reviewboard.asterisk.org/r/3738
 https://reviewboard.asterisk.org/r/3737
 https://reviewboard.asterisk.org/r/3736
 https://reviewboard.asterisk.org/r/3734
 https://reviewboard.asterisk.org/r/3722
 https://reviewboard.asterisk.org/r/3713
 https://reviewboard.asterisk.org/r/3703
 https://reviewboard.asterisk.org/r/3689
 https://reviewboard.asterisk.org/r/3687
 https://reviewboard.asterisk.org/r/3674
 https://reviewboard.asterisk.org/r/3671
 https://reviewboard.asterisk.org/r/3667
 https://reviewboard.asterisk.org/r/3665
 https://reviewboard.asterisk.org/r/3625
 https://reviewboard.asterisk.org/r/3602
 https://reviewboard.asterisk.org/r/3519
 https://reviewboard.asterisk.org/r/3518
 https://reviewboard.asterisk.org/r/3516
 https://reviewboard.asterisk.org/r/3515
 https://reviewboard.asterisk.org/r/3512
 https://reviewboard.asterisk.org/r/3506
 https://reviewboard.asterisk.org/r/3413
 https://reviewboard.asterisk.org/r/3410
 https://reviewboard.asterisk.org/r/3387
 https://reviewboard.asterisk.org/r/3388
 https://reviewboard.asterisk.org/r/3389
 https://reviewboard.asterisk.org/r/3390
 https://reviewboard.asterisk.org/r/3321
 https://reviewboard.asterisk.org/r/3320
 https://reviewboard.asterisk.org/r/3319
 https://reviewboard.asterisk.org/r/3318
 https://reviewboard.asterisk.org/r/3266
 https://reviewboard.asterisk.org/r/3265
 https://reviewboard.asterisk.org/r/3234
 https://reviewboard.asterisk.org/r/3178

ASTERISK-23114 #close
Reported by: mjordan
  media_formats_translation_core.diff uploaded by kharwell (License 6464)
  rb3506.diff uploaded by mjordan (License 6283)
  media_format_app_file.diff uploaded by kharwell (License 6464) 
  misc-2.diff uploaded by file (License 5000)
  chan_mild-3.diff uploaded by file (License 5000) 
  chan_obscure.diff uploaded by file (License 5000) 
  jingle.diff uploaded by file (License 5000) 
  funcs.diff uploaded by file (License 5000) 
  formats.diff uploaded by file (License 5000) 
  core.diff uploaded by file (License 5000) 
  bridges.diff uploaded by file (License 5000) 
  mf-codecs-2.diff uploaded by file (License 5000) 
  mf-app_fax.diff uploaded by file (License 5000) 
  mf-apps-3.diff uploaded by file (License 5000) 
  media-formats-3.diff uploaded by file (License 5000) 

ASTERISK-23715
  rb3713.patch uploaded by coreyfarrell (License 5909)
  rb3689.patch uploaded by mjordan (License 6283)
  
ASTERISK-23957
  rb3722.patch uploaded by mjordan (License 6283) 
  mf-attributes-3.diff uploaded by file (License 5000) 

ASTERISK-23958
Tested by: jrose
  rb3822.patch uploaded by coreyfarrell (License 5909) 
  rb3800.patch uploaded by jrose (License 6182)
  chan_sip.diff uploaded by mjordan (License 6283) 
  rb3747.patch uploaded by jrose (License 6182)

ASTERISK-23959 #close
Tested by: sgriepentrog, mjordan, coreyfarrell
  sip_cleanup.diff uploaded by opticron (License 6273)
  chan_sip_caps.diff uploaded by mjordan (License 6283) 
  rb3751.patch uploaded by coreyfarrell (License 5909) 
  chan_sip-3.diff uploaded by file (License 5000) 

ASTERISK-23960 #close
Tested by: opticron
  direct_media.diff uploaded by opticron (License 6273) 
  pjsip-direct-media.diff uploaded by file (License 5000) 
  format_cap_remove.diff uploaded by opticron (License 6273) 
  media_format_fixes.diff uploaded by opticron (License 6273) 
  chan_pjsip-2.diff uploaded by file (License 5000) 

ASTERISK-23966 #close
Tested by: rmudgett
  rb3803.patch uploaded by rmudgetti (License 5621)
  chan_dahdi.diff uploaded by file (License 5000) 
  
ASTERISK-24064 #close
Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose
  rb3814.patch uploaded by rmudgett (License 5621) 
  moh_cleanup.diff uploaded by opticron (License 6273) 
  bridge_leak.diff uploaded by opticron (License 6273) 
  translate.diff uploaded by file (License 5000) 
  rb3795.patch uploaded by rmudgett (License 5621) 
  tls_fix.diff uploaded by mjordan (License 6283) 
  fax-mf-fix-2.diff uploaded by file (License 5000) 
  rtp_transfer_stuff uploaded by mjordan (License 6283) 
  rb3787.patch uploaded by rmudgett (License 5621) 
  media-formats-explicit-translate-format-3.diff uploaded by file (License 5000) 
  format_cache_case_fix.diff uploaded by opticron (License 6273) 
  rb3774.patch uploaded by rmudgett (License 5621) 
  rb3775.patch uploaded by rmudgett (License 5621) 
  rtp_engine_fix.diff uploaded by opticron (License 6273) 
  rtp_crash_fix.diff uploaded by opticron (License 6273) 
  rb3753.patch uploaded by mjordan (License 6283) 
  rb3750.patch uploaded by mjordan (License 6283) 
  rb3748.patch uploaded by rmudgett (License 5621) 
  media_format_fixes.diff uploaded by opticron (License 6273) 
  rb3740.patch uploaded by mjordan (License 6283) 
  rb3739.patch uploaded by mjordan (License 6283) 
  rb3734.patch uploaded by mjordan (License 6283) 
  rb3689.patch uploaded by mjordan (License 6283) 
  rb3674.patch uploaded by coreyfarrell (License 5909) 
  rb3671.patch uploaded by coreyfarrell (License 5909) 
  rb3667.patch uploaded by coreyfarrell (License 5909) 
  rb3665.patch uploaded by mjordan (License 6283) 
  rb3625.patch uploaded by coreyfarrell (License 5909) 
  rb3602.patch uploaded by coreyfarrell (License 5909) 
  format_compatibility-2.diff uploaded by file (License 5000) 
  core.diff uploaded by file (License 5000) 
  


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

Whenever possible, audiohooks and framehooks will now be copied over
to the channel that the masquerading channel gets cloned into. This
should occur for all audiohooks and most framehooks. As a result,
in Asterisk 12.5 and up, the AUDIOHOOK_INHERIT function is now
deprecated and its behavior is essentially the new default for all
audiohooks, plus some additional audiohooks/framehooks.

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

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


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

This patch is a re-do of r414122.

When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft
hangup flags have a catastrophic effect on the pbx core if they leak out from
the bridge layer: the channel gets hung up. With the number of threads
involved in a blind transfer, and with the initial patch, it was likely that
this would occur. This caused a large number of test failures

This patch is nearly identical with the one proposed in r414122, save for the
following changes:
 - We explicitly clear the UNBRIDGE flag when setting an after goto on a
   channel in a bridge
 - Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it

https://reviewboard.asterisk.org/r/3585/
........

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


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

The bridge_native_rtp module currently uses the bridge result of the first
channel that joins a bridge as the ultimate result. This means that if the
first channel has direct media enabled but the second does not a direct
media bridge will still occur.

This change makes it so that both sides are taken into account. If either
side forbids the bridge or responds with a local bridge result then
either a generic or local bridge occurs.

ASTERISK-23541 #close
Reported by: Justin E

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

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


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

This patch addresses some aesthetic issues in Asterisk. These are all just
minor tweaks to improve the look of the CLI when used in a variety of
settings. Specifically:
 * A number of chatty verbose messages were removed or demoted to DEBUG
   messages. Verbose messages with a verbosity level of 5 or higher were -
   if kept as verbose messages - demoted to level 4. Several messages
   that were emitted at verbose level 3 were demoted to 4, as announcement
   of dialplan applications being executed occur at level 3 (and so the
   effects of those applications should generally be less).
 * Some verbose messages that only appear when their respective 'debug'
   options are enabled were bumped up to always be displayed.
 * Prefix/timestamping of verbose messages were moved to the verboser
   handlers. This was done to prevent duplication of prefixes when the
   timestamp option (-T) is used with the CLI.
 * Verbose magic is removed from messages before being emitted to
   non-verboser handlers. This prevents the magic in multi-line verbose
   messages (such as SIP debug traces or the output of DumpChan) from
   being written to files.
 * _Slightly_ better support for the "light background" option (-W) was
   added. This includes using ast_term_quit in the output of XML
   documentation help, as well as changing the "Asterisk Ready" prompt to
   bright green on the default background (which stands a better chance of
   being displayed properly than bright white).

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



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

The Test Suite caught a few problems, undoing until those are resolved


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

This patch fixes issues with direct media bridges that occur after a blind
transfer. These issues were caught by the (currently failing)
pjsip/transfers/blind_transfer/caller_direct_media test.

The test currently fails primarily for two reasons:
(1) When Bob and Charlie (the transfer target and the transfer destination)
    enter a bridge together, the framehook remains on the transfer target
    channel until both channels are in the bridge. As it consumes voice frames,
    the initial bridge type is a simple bridge. The framehook is removed when
    both channels are in the bridge; however, this does not currently cause the
    bridging framework to re-evaluate the bridge. This patch adds a
    AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a
    framehook is removed so the bridge can re-evaluate itself.

(2) When a channel leaves a native RTP bridge, it may be leaving due to being
    hung up. Sending a re-INVITE to a channel that is about to be hung up is
    not nice - in fact, there's a good chance we'll send the BYE request before
    the channel has had a chance to send back a 200 OK. To be somewhat nicer,
    this patch adds a function to channel.h that allows the bridging framework
    to query for exactly why a channel is leaving a bridge via the channel's
    soft hangup flags. This allows it to only send the re-INVITE if there's a
    chance the channel will survive the native bridging experience.

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

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


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

In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.

This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.

ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close

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

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


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

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

In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.

This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.

ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close

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

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


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

This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
........

Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

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

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


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

Add an option to enable a periodic beep to be played into a call if it
is being recorded.  If enabled, it uses the PERIODIC_HOOK() function
internally to play the 'beep' prompt into the call at a specified
interval.  This option is provided for both Monitor() and
MixMonitor().

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


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

Playing back a file to a channel in an ARI bridge would attempt to wait until
the playback concluded before returning. The method used involved signaling the
waiting thread in the ARI custom playback function.

The problem with this is that there were some corner cases that were not accounted for:
* If a bridge channel could not be found, then we never would attempt the playback but
  would still attempt to wait for the playback to complete.
* If the bridge playfile action failed to queue, we would still attempt to wait for the
  playback to complete.
* If the bridge playfile action were queued but some circumstance caused the playback
  not to occur (the bridge dies, the channel is removed from the bridge), then we would
  never be notified.

The solution to this is to move the waiting logic into the bridge code. A new bridge
API function is added to queue a synchronous action on a bridge. The waiting thread
is notified when the queued frame has been freed, either due to an error occurring
or due to successful playback. As a failsafe, the waiting thread has a 10 minute
timeout just in case there is a frame leak somewhere.

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

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


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

It is possible for a channel to be masqueraded out of a bridge which
means it may no longer have RTP glue to check upon leaving said bridge.
If this situation occurred (it's possible at least during dial and call
pickup) then Asterisk would crash. This change makes sure the glue is
checked before use.

(closes issue AST-1290)
Reported by: John Bigelow
........

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


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

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