This changes the way that we handle adding changes to CHANGES and
UPGRADE.txt. The reason for this is because whenever someone needed to
make a change to one of these files and someone else had already done
so, you would run into merge conflicts. With this new setup, there will
never be merge conflicts since all changes will be documented in the
doc/<file>-staging directory. The release script is now responsible for
merging all of these changes into the appropriate files.

There is a special format that these files have to follow in order to be
parsed. The files do not need to have a meaningful name, but it is
strongly recommended. For example, if you made a change to pjsip, you
may have something like this "res_pjsip_relative_title", where
"relative_title" is something more descriptive than that. Inside each
file, you will need a subject line for your change, followed by a
description. There can be multiple subject lines. The file may look
something like this:

   Subject: res_pjsip
   Subject: Core

   A description that explains the changes made and why. The release
   script will handle the bulleting and section separators!

   You can still separate with new lines within your
   description.

The headers ("Subject" and "Master-Only") are case sensative, but the
value for "Master-Only" ("true" or "True") is not.

For more information, check out the wiki page:
https://wiki.asterisk.org/wiki/display/AST/CHANGES+and+UPGRADE.txt

ASTERISK-28111 #close

Change-Id: I19cf4b569321c88155a65e9b0b80f6d58075dd47

chan_sip will always ignore 183 responses that do not contain SDP
however, chan_pjsip will currently always translate it into a
183 with SDP.  This new flag allows chan_pjsip to have the same
behavior as chan_sip.

ASTERISK-28322 #close

Change-Id: If81cfaa17c11b6ac703e3d71696f259d86c6be4a

Added the ability to move between Stasis applications within Stasis.
This can be done by calling 'move' in an application, providing (at
minimum) the channel's id and the application to switch to. If the
application is not registered or active, nothing will happen and the
channel will remain in the current application, and an event will be
triggered to let the application know that the move failed. The event
name is "ApplicationMoveFailed", and provides the "destination" that the
channel was attempting to move to, as well as the usual channel
information. Optionally, a list of arguments can be passed to the
function call for the receiving application. A full example of a 'move'
call would look like this:

client.channels.move(channelId, app, appArgs)

The control object used to control the channel in Stasis can now switch
which application it belongs to, rather than belonging to one Stasis
application for its lifetime. This allows us to use the same control
object instead of having to tear down the current one and create
another.

ASTERISK-28267 #close

Change-Id: I43d12b10045a98a8d42541889b85695be26f288a

Change-Id: Ieb332d018ae3f2fc82b9465381fde0f299af1611

This module allows presence subscriptions to voicemail boxes.  This
allows common BLF keys to act as voicemail waiting indicators.

ASTERISK-28301

Change-Id: I62a246c24f3d7d432e33e22d7a4a57c15c292fdd

To prevent one subsystem's taskprocessors from causing others
to stall, new capabilities have been added to taskprocessors.

* Any taskprocessor name that has a '/' will have the part
  before the '/' saved as its "subsystem".
  Examples:
  "sorcery/acl-0000006a" and "sorcery/aor-00000019"
  will be grouped to subsystem "sorcery".
  "pjsip/distributor-00000025" and "pjsip/distributor-00000026"
  will bn grouped to subsystem "pjsip".
  Taskprocessors with no '/' have an empty subsystem.

* When a taskprocessor enters high-water alert status and it
  has a non-empty subsystem, the subsystem alert count will
  be incremented.

* When a taskprocessor leaves high-water alert status and it
  has a non-empty subsystem, the subsystem alert count will be
  decremented.

* A new api ast_taskprocessor_get_subsystem_alert() has been
  added that returns the number of taskprocessors in alert for
  the subsystem.

* A new CLI command "core show taskprocessor alerted subsystems"
  has been added.

* A new unit test was addded.

REMINDER: The taskprocessor code itself doesn't take any action
based on high-water alerts or overloading.  It's up to taskprocessor
users to check and take action themselves.  Currently only the pjsip
distributor does this.

* A new pjsip/global option "taskprocessor_overload_trigger"
  has been added that allows the user to select the trigger
  mechanism the distributor uses to pause accepting new requests.
  "none": Don't pause on any overload condition.
  "global": Pause on ANY taskprocessor overload (the default and
  current behavior)
  "pjsip_only": Pause only on pjsip taskprocessor overloads.

* The core pjsip pool was renamed from "SIP" to "pjsip" so it can
  be properly grouped into the "pjsip" subsystem.

* stasis taskprocessor names were changed to "stasis" as the
  subsystem.

* Sorcery core taskprocessor names were changed to "sorcery" to
  match the object taskprocessors.

Change-Id: I8c19068bb2fc26610a9f0b8624bdf577a04fcd56

Event type filtering is now enabled, and configurable per application. An app is
now able to specify which events are sent to the application by configuring an
allowed and/or disallowed list(s). This can be done by issuing the following:

PUT /applications/{applicationName}/eventFilter

And then enumerating the allowed/disallowed event types as a body parameter.

ASTERISK-28106

Change-Id: I9671ba1fcdb3b6c830b553d4c5365aed5d588d5b

At AstriCon, there was a strong desire for the ability to completely
bypass dialplan when using ARI. This is possible through the automatic
creation of a context and a couple of extensions whenever an application
is started.

For example, if you have an application named 'ari-example', a context
named 'stasis-ari-example' will be automatically created whenever this
application is started as long as one does not already exist. Two
extensions (a match-all extension for Stasis and a 'h' extension) are
created within this context. Any endpoint that registers to Asterisk
within this context will send all calls to the corresponding Stasis
application. When the application is destroyed, the context is removed.

ASTERISK-28104 #close

Change-Id: Ie35bd93075e05b05e3ae129a83c9426931b7ebac

Testing revealed that the cache added no benefit but that it could
consume excessive memory.

Two new index related functions were created:
ast_sounds_get_index_for_file() and ast_media_index_update_for_file()
which restrict index updating to specific sound files.

The original ast_sounds_get_index() and ast_media_index_update()
calls are still available but since they no longer cache the results
internally, developers should re-use an index they may already have
instead of calling ast_sounds_get_index() repeatedly.  If information
for only a single file is needed, ast_sounds_get_index_for_file()
should be called instead of ast_sounds_get_index().

The media_index directory scan code was elimininated in favor of
using the existing ast_file_read_dirs() function.

Since there's no more cache, ast_sounds_index_init now only
registers the sounds cli commands instead of generating the
initial index and subscribing to stasis format register/unregister
messages.

"sounds" is no longer a valid target for the "module reload"
command.

Both the sounds cli commands and the sounds ari resources were
refactored to only call ast_sounds_get_index() once per invocation
and to use ast_sounds_get_index_for_file() when a specific sound
file is requested.

Change-Id: I1cef327ba1b0648d85d218b70ce469ad07f4aa8d

You can now define an "aliases" context in voicemail.conf
whose entries point to actual mailboxes.  These can be used anywhere
the mailbox is specified.

Example:
[general]
aliasescontext = myaliases

[default]
1234 = yadayada

[myaliases]
4321@devices = 1234@default

Now you can use 4321@devices to refer to the 1234@default mailbox.

This can be useful to provide channel drivers with constant
mailbox specifications such as <extension>@devices leaving
app_voicemail to control exactly which mailbox the alias points to.
Now, only voicemail has to be reloaded to make changes instead of
individual channel drivers which are usually more expensive to
reload.

Change-Id: I395b9205c91523a334fe971be0d1de4522067b04

The commit I2f97ebfa79969a36a97bb7b9afd5b6268cf1a07d removed sending out
the ContactStatus AMI event when a contact is updated.
Thist change broke things which rely on old behavior.

This patch adds a new PJSIP global configuration option
'send_contact_status_on_update_registration' to be able to preserve old
ContactStatus behavior.
By default new behavior, i.e. the ContactStatus event will not be sent when a
device refreshes its registration.

Change-Id: I706adf7584e7077eb6bde6d9799ca408bc82ce46

This is how features behaved up through Asterisk 11, but was changed
when the new bridging framework was implemented in Asterisk 12.

Reported by rrittgarn in #asterisk.

Change-Id: I72cf86223947a8118c75f46e2c603dbc11e3125b

* The bridging core no longer uses the stasis cache for bridge
  snapshots.  The latest bridge snapshot is now stored on the
  ast_bridge structure itself.

* The following APIs are no longer available since the stasis cache
  is no longer used:
    ast_bridge_topic_cached()
    ast_bridge_topic_all_cached()

* A topic pool is now used for individual bridge topics.

* The ast_bridge_cache() function was removed since there's no
  longer a separate container of snapshots.

* A new function "ast_bridges()" was created to retrieve the
  container of all bridges.  Users formerly calling
  ast_bridge_cache() can use the new function to iterate over
  bridges and retrieve the latest snapshot directly from the
  bridge.

* The ast_bridge_snapshot_get_latest() function was renamed to
  ast_bridge_get_snapshot_by_uniqueid().

* A new function "ast_bridge_get_snapshot()" was created to retrieve
  the bridge snapshot directly from the bridge structure.

* The ast_bridge_topic_all() function now returns a normal topic
  not a cached one so you can't use stasis cache functions on it
  either.

* The ast_bridge_snapshot_type() stasis message now has the
  ast_bridge_snapshot_update structure as it's data.  It contains
  the last snapshot and the new one.

* cdr, cel, manager and ari have been updated to use the new
  arrangement.

Change-Id: I7049b80efa88676ce5c4666f818fa18ad1985369

Channels no longer use the Stasis cache for channel snapshots. Instead
they are stored in a hash table in stasis_channels which reduces the
number of Stasis messages created and allows better storage.

As a result the following APIs are no longer available since the stasis
cache is no longer used:
ast_channel_topic_cached()
ast_channel_topic_all_cached()

The ast_channel_cache_all() and ast_channel_cache_by_name() functions
now return an ao2_container of ast_channel_snapshots rather than
a container of stasis_messages therefore you can't (and don't need
to) call stasis_cache functions on it.

The ast_channel_topic_all() function now returns a normal topic not
a cached one so you can't use stasis cache functions on it either.

The ast_channel_snapshot_type() stasis message now has the
ast_channel_snapshot_update structure as it's data. It contains the
last snapshot and the new one.

ast_channel_snapshot_get_latest() still returns the latest snapshot.

The latest snapshot is now stored on the channel itself to eliminate
cache hits when Stasis messages that have the snapshot as a payload
are created.

ASTERISK-28102

Change-Id: I9334febff60a82d7c39703e49059fa3a68825786

We've been seeing crashes in libbfd when we attempt to generate
a stack trace from multiple threads.  It turns out that libbfd
is NOT thread-safe.  It can cache the bfd structure and give it to
multiple threads without protecting itself.  To get around this,
we've added a global mutex around the bfd functions and also have
refactored the use of those functions to be more efficient and
to provide more information about inlined functions.

Also added a few more tests to test_pbx.c.  One just calls
ast_assert() and the other calls ast_log_backtrace().  Neither are
run by default.

WARNING:  This change necessitated changing the return value of
ast_bt_get_symbols() from an array of strings to a VECTOR of
strings.  However, the use of this function outside Asterisk is not
likely.

ASTERISK-28140

Change-Id: I79d02862ddaa2423a0809caa4b3b85c128131621

New dialplan function PJSIP_PARSE_URI added to parse an URI and return
a specified part of the URI.

This is useful when need to get part of the URI instead of cutting it
using a CUT function.

For example to get 'user' part of Remote URI
${PJSIP_PARSE_URI(${CHANNEL(pjsip,remote_uri)},user)}

ASTERISK-28144 #close

Change-Id: I5d828fb87f6803b6c1152bb7b44835f027bb9d5a

If multiple [globals] sections are used (for example via separate
included files), only the first one is processed.  This can result in
lost global variables when using a modular extensions.conf.

ASTERISK-28146 #close

Change-Id: Iaac810c0a7c4d9b1bf8989fcc041cdb910ef08a0

This patch adds new options 'trust_connected_line' and 'send_connected_line'
to the endpoint.

The option 'trust_connected_line' is to control if connected line updates
are accepted from this endpoint.

The option 'send_connected_line' is to control if connected line updates
can be sent to this endpoint.

The default value is 'yes' for both options.

Change-Id: I16af967815efd904597ec2f033337e4333d097cd

This officially deprecates chan_sip in Asterisk 17+.  A warning is
printed upon startup or module load to tell users that they should
consider migrating.  chan_sip is still built by default but the default
modules.conf skips loading it at startup.

Very important to note we are not scheduling a time where chan_sip will
be removed.  The goal of this change is to accurately inform end users
of the current state of chan_sip and encourage movement to the fully
supported chan_pjsip.

Change-Id: Icebd8848f63feab94ef882d36b2e99d73155af93

Change-Id: Ib8db4e14187f5c11ecbff532df17d30c5d36fa3e

When networks experience disruptions, there can be large gaps of time
between receiving packets. When strictrtp is enabled, this created
issues where a flood of packets could come in and be seen as an attack.
Another option - seqno - has been added to the strictrtp option that
ignores the time interval and goes strictly by sequence number for
validity.

Change-Id: I8a42b8d193673899c8fc22fe7f98ea87df89be71

The documentation already specified EVENT_FLAG_DIALPLAN for this
event, but the implementation was using EVENT_FLAG_CALL.

Using EVENT_FLAG_DIALPLAN allows AMI clients to opt out of receiving
this highly verbose event.

ASTERISK-28033

Change-Id: I45b3119f30e4dbc17b49831f2b1a4f2c1beadafe

Change includes move to netsock2 library.

ASTERISK-27164
Reported-by: Adam Secombe

Change-Id: Ia9e8dc3d153de7a291dbda4bd87fc827dd2bb846

This patch adds regular expression support to make the identify section's
match_header option more useful when attempting to match complex headers
like the 'To' or 'From' headers.  The 'From' header has variable
components such as the tag parameter that you cannot predict.  To specify
a regular expression put slashes around the regular expression in place of
the header value.

[identify-alice]
type=identify
endpoint=alice
match_header=From: /<sip:alice@127\\.0\\.0\\.1>/

* Added regex support to match_header so you could match a 'To' header
among other complex headers.

Fixed reported crashes when trying to match special headers like 'Contact'.
The identify section's match_header method used code that assumed you were
matching a generic header.  Any other type of header could cause a crash
if the header structure variant did not match the generic header enough.

* Made use code that will work for any header type instead of code
specific to generic headers.

Other fixes while in the area:

* Made check all headers of the requested name.
* Added some more sanity checks to the configured identify matching
options when applying the configuration.

ASTERISK-27548

Change-Id: I27dfd4ff5e2259b906640e3c330681b76b4ed1f1

Change-Id: Ib3111b151d37cbda40768cf2a8a9c6cf6c5c7cbd

I have removed the STATIC_BUILD option immediately as it has not
been maintained in many years and is non-functional.

ASTERISK-27965

Change-Id: I64783d017b86dba9ee3c7bcfb97e59889a3f76d7

A new option 'suppress_q850_reason_headers' has been added to the
endpoint object. Some devices can't accept multiple Reason headers and
get confused when both 'SIP' and 'Q.850' Reason headers are received.
This option allows the 'Q.850' Reason header to be suppressed.
The default value is 'no'.

ASTERISK-27949
Reported-by: Ross Beer

Change-Id: I54cf37a827d77de2079256bb3de7e90fa5e1deb1

pjproject by default currently will follow media forked during an INVITE
on outbound calls if the To tag is different on a subsequent response as
that on an earlier response.  We handle this correctly.  There have
been reported cases where the To tag is the same but we still need to
follow the media.  The pjproject patch in this commit adds the
capability to sip_inv and also adds the capability to control it at
runtime.  The original "different tag" behavior was always controllable
at runtime but we never did anything with it and left it to default to
TRUE.

So, along with the pjproject patch, this commit adds options to both the
system and endpoint objects to control the two behaviors, and a small
logic change to session_inv_on_media_update in res_pjsip_session to
control the behavior at the endpoint level.

The default behavior for "different tags" remains the same at TRUE and
the default for "same tag" is FALSE.

Change-Id: I64d071942b79adb2f0a4e13137389b19404fe3d6
ASTERISK-27936
Reported-by: Ross Beer

Add predial handler support to app_queue.  app_dial (ASTERISK_19548) and
app_originate (ASTERISK_26587) have the ability to execute predial
handlers on caller and callee channels.  This patch adds predial handlers
to app_queue and uses the same options as Dial and Originate (b and B).
The caller routine gets executed when the caller first enters the queue.
The callee routine gets executed for each queue member when they are about
to be called.

ASTERISK-27912

Change-Id: I5acf5c32587ee008658d12e8a8049eb8fa4d0f24

ConfBridge can now send events to participants via in-dialog MESSAGEs.
All current Confbridge events are supported, such as ConfbridgeJoin,
ConfbridgeLeave, etc.  In addition to those events, a new event
ConfbridgeWelcome has been added that will send a list of all
current participants to a new participant.

For all but the ConfbridgeWelcome event, the JSON message contains
information about the bridge, such as its id and name, and information
about the channel that triggered the event such as channel name,
callerid info, mute status, and the MSID labels for their audio and
video tracks. You can use the labels to correlate callerid and mute
status to specific video elements in a webrtc client.

To control this behavior, the following options have been added to
confbridge.conf:

bridge_profile/enable_events:  This must be enabled on any bridge where
events are desired.

user_profile/send_events:  This must be set for a user profile to send
events.  Different user profiles connected to the same bridge can have
different settings.  This allows admins to get events but not normal
users for instance.

user_profile/echo_events:  In some cases, you might not want the user
triggering the event to get the event sent back to them.  To prevent it,
set this to false.

A change was also made to res_pjsip_sdp_rtp to save the generated msid
to the stream so it can be re-used.  This allows participant A's video
stream to appear as the same label to all other participants.

Change-Id: I26420aa9f101f0b2387dc9e2fd10733197f1318e

When an AMI client connects, it cannot determine if a user was talking
prior to a transition in the user speaking state (which would generate
a ConfbridgeTalking event). This patch causes app_confbridge to track the
talking state and make this state available via ConfBridgeList.

ASTERISK-27877 #close

Change-Id: I19b5284f34966c3fda94f5b99a7e40e6b89767c6

Analog phones dial overlap dialing and it is chan_dahdi's job to read the
numbers.  It has three timeout constants that this commit converts to
channel-level configuration options:

* firstdigit_timeout: Default time (ms) to detect first digit

* interdigit_timeout: Default time (ms) to detect following digits

* matchdigit_timeout: Default time (ms) to wait in case of ambiguous
match.  This happens when the dialed digits match a number in the current
context but are also the prefix of another number.

Change-Id: Ib728fa900a4f6ae56d1ed810aba61b6593fb7213

SendText now accepts new channel variables that can be used
to override the To and From display names and set the Content-Type
of a message.  Since you can now set Content-Type, other text/*
content types are now valid.

Change-Id: I648b4574478119f95de09d9f08e9595831b02830

Core bridging and, more specifically, bridge_softmix have been
enhanced to relay received frames of type TEXT or TEXT_DATA to all
participants in a softmix bridge.  res_pjsip_messaging and
chan_pjsip have been enhanced to take advantage of this so when
res_pjsip_messaging receives an in-dialog MESSAGE message from a
user in a conference call, it's relayed to all other participants
in the call.

res_pjsip_messaging already queues TEXT frames to the channel when
it receives an in-dialog MESSAGE from an endpoint and chan_pjsip
will send an MESSAGE when it gets a TEXT frame.  On a normal
point-to-point call, the frames are forwarded between the two
correctly.  bridge_softmix was not though so messages weren't
getting forwarded to conference bridge participants.  Even if they
were, the bridging code had no way to tell the participants who
sent the message so it would look like it came from the bridge
itself.

* The TEXT frame type doesn't allow storage of any meta data, such
as sender, on the frame so a new TEXT_DATA frame type was added that
uses the new ast_msg_data structure as its payload.  A channel
driver can queue a frame of that type when it receives a message
from outside.  A channel driver can use it for sending messages
by implementing the new send_text_data channel tech callback and
setting the new AST_CHAN_TP_SEND_TEXT_DATA flag in its tech
properties.  If set, the bridging/channel core will use it instead
of the original send_text callback and it will get the ast_msg_data
structure. Channel drivers aren't required to implement this.  Even
if a TEXT_DATA enabled driver uses it for incoming messages, an
outgoing channel driver that doesn't will still have it's send_text
callback called with only the message text just as before.

* res_pjsip_messaging now creates a TEXT_DATA frame for incoming
in-dialog messages and sets the "from" to the display name in the
"From" header, or if that's empty, the caller id name from the
channel.  This allows the chat client user to set a friendly name
for the chat.

* bridge_softmix now forwards TEXT and TEXT_DATA frames to all
participants (except the sender).

* A new function "ast_sendtext_data" was added to channel which
takes an ast_msg_data structure and calls a channel's
send_text_data callback, or if that's not defined, the original
send_text callback.

* bridge_channel now calls ast_sendtext_data for TEXT_DATA frame
types and ast_sendtext for TEXT frame types.

* chan_pjsip now uses the "from" name in the ast_msg_data structure
(if it exists) to set the "From" header display name on outgoing text
messages.

Change-Id: Idacf5900bfd5f22ab8cd235aa56dfad090d18489

This patch adds support to send in-dialog SIP NOTIFY commands on
chan_pjsip channels, similar to the functionality recently added
for chan_sip (ASTERISK_27461).

This extends res_pjsip_notify to allow for in-dialog messages.

ASTERISK-27697

Change-Id: If7f3151a6d633e414d5dc319d5efc1443c43dd29

Add an option to make app_originate not wait for the created channel
to answer.

Change-Id: I7fc2facd77079abc6321f44e8bcd4e39298de2ae
Requested-by: Frederic Steinfels <fst@highdefinition.ch>
Signed-off-by: Russell Bryant <russell@russellbryant.net>

If the two formats on a channel are equal, we don't transcode and since
the generic plc needs slin to work, it doesn't get invoked.

* A new configuration option "genericplc_on_equal_codecs" was added
  to the "plc" section of codecs.conf to allow generic packet loss
  concealment even if no transcoding was originally needed.
  Transcoding via SLIN is forced in this case.

ASTERISK-27743

Change-Id: I0577026a179dea34232e63123254b4e0508378f4

This allows asterisk to be compiled with MALLOC_DEBUG to load modules
built without MALLOC_DEBUG.  Now pre-compiled third-party modules will
still work regardless of MALLOC_DEBUG being enabled or not.

Change-Id: Ic07ad80b2c2df894db984cf27b16a69383ce0e10

The pool cache gets in the way of finding use after free errors of memory
pool contents.  Tools like valgrind and MALLOC_DEBUG don't know when a
pool is released because it gets put into the cache instead of being
freed.

* Added the "cache_pools" option to pjproject.conf.  Disabling the option
helps track down pool content mismanagement when using valgrind or
MALLOC_DEBUG.  The cache gets in the way of determining if the pool
contents are used after free and who freed it.

To disable the pool caching simply disable the cache_pools option in
pjproject.conf and restart Asterisk.

Sample pjproject.conf setting:
[startup]
cache_pools=no

* Made current users of the caching pool factory initialization and
destruction calls call common routines to create and destroy cached pools.

ASTERISK-27704

Change-Id: I64d5befbaeed2532f93aa027a51eb52347d2b828