The channel is now going to get T.38 terminated when it leaves the
bridging system and the bridged peers are going to get T.38 terminated as
well.

ASTERISK-25582

Change-Id: I77a9205979910210e3068e1ddff400dbf35c4ca7

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

Currently if a channel is transferred out of a bridge, the BRIDGEPEER
variable (also BRIDGEPVTCALLID) remain set even once the channel is
out of the bridge. This patch removes these variables when leaving
the bridge.

ASTERISK-25600 #close
Reported by: Mark Michelson

Change-Id: I753ead2fffbfc65427ed4e9244c7066610e546da

When executing an action in a bridge it is possible for the
channel to be hung up without the bridge becoming aware of it.
This is most easily reproducible by hanging up when the bridge
is streaming DTMF due to a feature timeout. This change makes
it so after action execution the channel is checked to determine
if it has been hung up and if it has it is kicked from the bridge.

ASTERISK-25341 #close

Change-Id: I6dd8b0c3f5888da1c57afed9e8a802ae0a053062

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 performing a blonde transfer the code uses the old masquerade
mechanism to move a channel around. As a result of this certain information,
such as connected line, is moved between the channels involved. Upon
completion of the move a frame is queued which is supposed to update the
connected line information on the channel. This does not occur as the
code considers it a redundant update since the masquerade operation
updated the channel (but did not inform it of the new connected line
information). The code also does not queue a connected line update
to be handled by the thread handling the channel. Without this any
other channel that may be loosely involved does not know it is
talking to a different caller.

This change does the following to resolve this:

1. The indicated connected line information is cleared upon
completion of the masquerade operation when doing a blonde transfer.
This prevents the connected line update from being considered
redundant.

2. A connected line update frame is now queued upon the completion
of the masquerade operation so any other channel loosely involved
knows that there is a different caller.

ASTERISK-25157 #close
Reported by: Joshua Colp

Change-Id: Ibb8798184a1dab3ecd35299faecc420034adbf20

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

For some applications - such as SLA - a phone pressing hold should not behave
in the fashion that the Asterisk core would like it to. Instead, the hold
action has some application specific behaviour associated with it - such as
disconnecting the channel that initiated the hold; only playing MoH to channels
in the bridge if the channels are of a particular type, etc.

One way of accomplishing this is to use a framehook to intercept the
hold/unhold frames, raise an event, and eat the frame. Tasty. This patch
accomplishes that using a new dialplan function, HOLD_INTERCEPT.

In addition, some general cleanup of raising hold/unhold Stasis messages was
done, including removing some RAII_VAR usage.

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

ASTERISK-24922 #close
........

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


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

Attempting to execute DTMF in a confbridge while file playback (prompt,
announcement, etc) is occurring is not allowed. You have to wait until
the sound file has completed before entering DTMF. This patch fixes it
so that app_confbridge now monitors for dtmf key presses during menu
driven file playback. If a key is pressed playback stops and it executes
the matched menu option.

ASTERISK-24864 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4510/
........

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

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


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

Switch logger callid's from AO2 objects to simple integers.
This helps in two ways.  Copying integers is faster than
referencing AO2 objects, so this will result in a small
reduction in logger overhead.  This also erases the possibility
of an infinate loop caused by an invalid callid in
threadstorage.

ASTERISK-24833 #comment Committed callid conversion to trunk. 
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4466/


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

This change fixes two issues:

1. During a swap operation bridging added the new channel before having the swap channel
leave. This was not handled in bridge_native_rtp and could result in a channel not getting
reinvited back to Asterisk. After this change the swap channel will leave first and the
new channel will then join.

2. If a re-invite was received after a session had been established any upstream elements
(such as bridge_native_rtp) were not notified that they may want to re-evaluate things.
After this change an UPDATE_RTP_PEER control frame is queued when this situation occurs
and upstream can react.

AST-1524 #close

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

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


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

This patch addresses compilation errors on OS X. It's been a while, so
there's quite a few things.

 * Fixed __attribute__ decls in route.h to be portable.
 * Fixed htonll and ntohll to work when they are defined as macros.
 * Replaced sem_t usage with our ast_sem wrapper.
 * Added ast_sem_timedwait to our ast_sem wrapper.
 * Fixed some GCC 4.9 warnings using sig*set() functions.
 * Fixed some format strings for portability.
 * Fixed compilation issues with res_timing_kqueue (although tests still fail
   on OS X).
 * Fixed menuconfig /sbin/launchd detection, which disables res_timing_kqueue
   on OS X).

ASTERISK-24539 #close
Reported by: George Joseph

ASTERISK-24544 #close
Reported by: George Joseph

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

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


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

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

Any partially collected DTMF digits for a DTMF hook need to be pushed into
the bridge when a channel leaves the bridging system as if there were a
timeout.

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

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

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


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

* Made collecting DTMF digits for the DTMF feature hooks pass frames from
the bridge.

* Made collecting DTMF digits possible by other bridge hooks if there is a
need.

ASTERISK-24447 #close
Reported by: Richard Mudgett

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

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

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


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

Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.

A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade.  With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer.  Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.

* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.

* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.

* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.

ASTERISK-24356 #close
Reported by: rmudgett

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

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

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


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

On a SIP reinvite that changes media strams, the PJSIP channel driver was
flooding the log with "Asked to transmit frame type %s, while native
formats is %s" warnings.

* Fixes PJSIP not setting up translation paths when the formats change on
a reinvite.  AFS-63 was effectively reintroduced because of the media
formats work.  res_pjsip_sdp_rtp.c:set_caps()

* Improved the unexpected frame format WARNING message to include more
information.

* Added protective locking while altering formats on a channel.  Reworked
set_format() to simplify and protect the formats under manipulation.

* Restored some code that got lost in the media_formats work.
(channel.c:set_format() and res_pjsip_sdp_rtp.c:set_caps())

AFS-137 #close
Reported by: Mark Michelson

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

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


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

If a manager or CLI user attached a mixmonitor to a call running a dynamic
bridge feature while in a bridge, the feature would be interrupted and the
channel would be forcibly kicked out of the bridge (usually ending the call
during a simple 1 to 1 call). This would also occur during any similar action
that could set the unbridge soft hangup flag, so the fix for this was to
remove unbridge from the soft hangup flags and make it a separate thing all
together.

ASTERISK-24027 #close
Reported by: mjordan
Review: https://reviewboard.asterisk.org/r/3900/
........

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

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


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

Say you wanted to include variables in an application map and have those
variables substituted and passed along to the application being executed;
currently this does not happen.

This patch adds this ability to pass channel variable values to an
application before being executed.

ASTERISK-22608 #close
Reported by: Michael L. Young
patches:
  features_substitute_arguments_v2.diff
                                     uploaded by Michael L. Young (license 5026)

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


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

Ensure that three-way transfers can be reported even if featuremap is
non-NULL.
........

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


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

This fixes two reference leaks that would occur when TEST_FRAMEWORK was
enabled and features were successfully executed.
........

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


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

* Create a Stasis bridge sub-class to propagate linkedids and
accountcodes.

* Fixed the basic bridge sub-class to update peeraccount codes when the
number of channels in the bridge drops back down to two parties.

* Refactored ast_bridge_channel_update_accountcodes() to handle channels
joining/leaving the bridge.

* Fixed the basic bridge sub-class to not call the base bridge class pull
method twice.

AFS-105 #close
ASTERISK-23852 #close
Reported by: Richard Mudgett

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

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


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

This patch allows the current owner of a channel to define various
feature hooks to be made available once the channel has entered a
bridge. This includes any hooks that are setup on the
ast_bridge_features struct such as DTMF hooks, bridge event hooks
(join, leave, etc.), and interval hooks.

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


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

During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
 * AGI execution
 * Returning objects for ARI commands
 * During some Local channel operations
 * During some dialling operations
 * During variable setting
 * During some bridging operations
And more.

This patch does the following:
 - It removes a number of fields from channel snapshots. These fields were
   rarely used, were expensive to have on the snapshot, and hurt performance.
   This included formats, translation paths, Log Call ID, callgroup, pickup
   group, and all channel variables. As a result, AMI Status,
   "core show channel", "core show channelvar", and "pjsip show channel" were
   modified to either hit the live channel or not show certain pieces of data.
   While this is unfortunate, the performance gain from this patch is worth
   the loss in behaviour.
 - It adds a mechanism to publish a cached snapshot + blob. A large number of
   publications were changed to use this, including:
   - During Dial begin
   - During Variable assignment (if no AMI variables are emitted - if AMI
     variables are set, we have to make snapshots when a variable is changed)
   - During channel pickup
   - When a channel is put on hold/unhold
   - When a DTMF digit is begun/ended
   - When creating a bridge snapshot
   - When an AOC event is raised
   - During Local channel optimization/Local bridging
   - When endpoint snapshots are generated
   - All AGI events
   - All ARI responses that return a channel
   - Events in the AgentPool, MeetMe, and some in Queue
 - Additionally, some extraneous channel snapshots were being made that were
   unnecessary. These were removed.
 - The result of ast_hashtab_hash_string is now cached in stasis_cache. This
   reduces a large number of calls to ast_hashtab_hash_string, which reduced
   the amount of time spent in this function in gprof by around 50%.

#ASTERISK-23811 #close
Reported by: Matt Jordan

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

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


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

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

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

Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it.  Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation.  This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first.  In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.

Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.

(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........

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


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

Original commit message by mmichelson (asterisk 12 r403311):

"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."

The above was initially committed and then reverted at r403398.  The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed.  Fixed by unreffing the channels.

Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel.  Fixed by
unlocking "other->chan"

(closes issue ASTERISK-22709)
Reported by: John Bigelow
........

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


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

........

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


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

This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........

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


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

This adds a test suite event that indicates to tests when the attended transfer
three-way call feature is detected.

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

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


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

This particular debug message, during a stress test, was logged so
often that it appeared that there may be a memory leak in the logger
code. In actuality, there was no memory leak, but the logger thread
was having a hard time keeping up with the demands of the rest of the
system.

Since this debug message has no value at all, the best way to fix the
problem was to just remove the message.

(closes issue AST-1225)
reported by John Bigelow

Patches:
	spammy_log.diff uploaded by Mark Michelson (License #5049)
........

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


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

The Dial, Queue, and FollowMe applications need to inhibit the bridging
initial connected line exchange in order to support the 'I' option.

* Replaced the pass_reference flag on ast_bridge_join() with a flags
parameter to pass other flags defined by enum ast_bridge_join_flags.

* Replaced the independent flag on ast_bridge_impart() with a flags
parameter to pass other flags defined by enum ast_bridge_impart_flags.

* Since the Dial, Queue, and FollowMe applications are now the only
callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the
calling contract to require the initial COLP exchange to already have been
done by the caller.

* Made all callers of ast_bridge_impart() check the return value.  It is
important.  As a precaution, I also made the compiler complain now if it
is not checked.

* Did some cleanup in parking_tests.c as a result of checking the
ast_bridge_impart() return value.

An independent, but associated change is:
* Reduce stack usage in ast_indicate_data() and add a dropping redundant
connected line verbose message.

(closes issue ASTERISK-22072)
Reported by: Joshua Colp

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

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


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

When a channel with the OUTGOING flag leaves a bridge, and it will survive
being pulled from the bridge (either because it will execute dialplan,
go into another bridge, or live in a friendly autoloop), we have to clear
the OUTGOING flag. This is the signal to the CDR engine that this channel
is no longer a second class citizen, i.e., it is not "dialed".

The soft hangup flags are only half the picture. If a channel is being
moved from one bridge to another, the soft hangup flags aren't set; however,
the state of the bridge_channel will not be hung up. Since the channel does
not have one of the two hang up states, that implies that the channel is
still technically alive.

This patch modifies the check so that it checks both the soft hangup flags
as well as the bridge_channel state. If either suggests that the channel
is going to persist, we clear the OUTGOING flag.
........

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


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

Use a better means of waking up the bridge channel thread.
........

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


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