Correct typos of the following word families:

themselves
support
received

ASTERISK-29714

Change-Id: Ibd0a7996d5801c754d3d44fba31fe788a13dba95

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

* 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

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

Add 'Section:' headings and use '-' for bullet points.

Change-Id: I7e2be35601ac8fea53b90d926da564512b6716e4

Change-Id: Ia155ce2a53d61556aa4685524d1b48cfacfa3a8b

Change-Id: Ia1b2b386505b3102136dab02c45eaaf09f0f89c5

Change-Id: I1a00ca22d59d6b6d2166aa56f0e9338a33e5ac60

Copied UPGRADE.txt -> UPGRADE-16.txt
Created new UPGRADE.txt

Updated ARI stubs version to 17.

Change-Id: I4210e53f8022a2a68c7653595bdd13fbebac41ee

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

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

* app_fax (replaced by res_fax).
* res_config_sqlite (replaced by res_config_sqlite3).
* res_monitor (replaced by app_mixmonitor).

This is related to ASTERISK~23657 but does not resolve that ticket.
Resolving that ticket would require complete removal of res_monitor.

ASTERISK-27671 #close

Change-Id: I16a3edd61fc1abd4a7b2e9357693ed663f62dd49

This removes the embedded copy of editline from the Asterisk source
tree, making a system copy of libedit mandatory in Asterisk 16+.

ASTERISK-27634 #close

Change-Id: Iedb64ad92acb78419f3caefedaa2bb7cd2a1a33f

The type=identify endpoint identification method can match by IP address
and by SIP header.  However, the SIP header matching has limited
usefulness because you cannot specify the SIP header matching priority
relative to the IP address matching.  All the matching happens at the same
priority and the order of evaluating the identify sections is
indeterminate.  e.g., If you had two type=identify sections where one
matches by IP address for endpoint alice and the other matches by SIP
header for endpoint bob then you couldn't predict which endpoint is
matched when a request comes in that matches both.

* Extract the SIP header matching criteria into its own "header" endpoint
identification method so the user can specify the relative priority of the
SIP header and the IP address matching criteria in the global
endpoint_identifier_order option.  The "ip" endpoint identification method
now only matches by IP address.

ASTERISK-27491

Change-Id: I9df142a575b7e1e3471b7cda5d3ea156cef08095

There has been an open issue against cdr_syslog (ASTERISK~14441) about
a race condition for 7.5 years that has never been addressed. Because
this module is effectively unmaintained and currently broken, there is
no sense in keeping it around.

If logging CDRs to syslog is a desirable feature, it would probably be
better to write the logs directly to the syslog server via socket
instead of using the facilities provided by openlog/syslog/closelog.
Doing so would address the race condition referenced in the associated
issue.

Change-Id: Ic77b94cd97f355a9cf5b1d3f3444964a6e0ba5dc

A couple of places were setting the status to "UNKNOWN" when qualifies were
being disabled. Instead this should be set to the "CREATED" status that
represents when a contact is given (uri available), but the qualify frequency
is set to zero so we don't know the status.

This patch updates the relevant places with "CREATED". It also updates the
"CREATED" status description (value shown in CLI/AMI/ARI output) to a value
of "NonQualified"/"NonQual" as this description is hopefully less confusing.

ASTERISK-27467

Change-Id: Id67509d25df92a72eb3683720ad2a95a27b50c89

* Mark the module deprecated.
* Disable the module by default.
* Produce a warning the first time a macro is used.
* Note deprecation related options in app_dial and app_queue.

ASTERISK-27350

Change-Id: I560ea043bacdbc5534a17d97854273d52c2f1bdc

Change-Id: I4ca2f07ed62d77f1fdd10c3b216f6a28dd75720c

AMI goes from 3.2.0 to 4.0.0
ARI goes from 2.0.0 to 3.0.0

Copied UPGRADE.txt -> UPGRADE-15.txt
Created new UPGRADE.txt
Removed a log file that was accidentally checked in a while ago

Change-Id: I1c794f910038459b13e16f9c3a12c44e56f142f7

This adds support for parsing timelen values from config files.  This
includes support for all flags which apply to PARSE_INT32.  Support for
this parser is added to ACO via the OPT_TIMELEN_T option type.

Fixes an issue where extra characters provided to ast_app_parse_timelen
were ignored, they now cause an error.

Testing is included.

ASTERISK-27117 #close

Change-Id: I6b333feca7e3f83b4ef5bf2636fc0fd613742554

This API was not actively maintained, was not added to new modules
(such as res_pjsip), and there exist better alternatives to acquire the
same information, such as the ARI.

Change-Id: I4b2185a83aeb74798b4ad43ff8f89f971096aa83

This has not worked for some time and is no longer actively maintained.

Change-Id: I5110b0db69c152761b58fa025cb0a53b0e544d99

ASTERISK-26846 #close

Change-Id: I541a1602ff55ab73684e9f8002edb9e0e745d639

This commit adds support for RFC 5761: Multiplexing RTP Data and Control
Packets on a Single Port. Specifically, it enables the feature when
using chan_pjsip.

A new option, "rtcp_mux" has been added to endpoint configuration in
pjsip.conf. If set, then Asterisk will attempt to use rtcp-mux with
whatever it communicates with. Asterisk follows the rules set forth in
RFC 5761 with regards to falling back to standard RTCP behavior if the
far end does not indicate support for rtcp-mux.

The lion's share of the changes in this commit are in
res_rtp_asterisk.c. This is because it was pretty much hard wired to
have an RTP and an RTCP transport. The strategy used here is that when
rtcp-mux is enabled, the current RTCP transport and its trappings (such
as DTLS SSL session) are freed, and the RTCP session instead just
mooches off the RTP session. This leads to a lot of specialized if
statements throughout.

ASTERISK-26732 #close
Reported by Dan Jenkins

Change-Id: If46a93ba1282418d2803e3fd7869374da8b77ab5

QueueLog did not log ringnoanswer when the caller abandoned call
before first timeout. It was impossible to get agent membername
and ringing duration for this short calls. After some discusions
it seems that the best way is to add new event RINGCANCELED,
which is generated after caller hangup during ringing.

ASTERISK-26665

Change-Id: Ic70f7b0f32fc95c9378e5bcf63865519014805d3

Support for referring to DAHDI channels by logical names was added in
(FIXME: when? Asterisk 11? 1.8?) and was intended to be part of support
of refering to channels by name.

While technically usable, it has never been properly supported in
dahdi-tools, as using it would require many changes at the Asterisk
level. Instead logical mapping was added at the kernel level.

Thus it seems that refering to DAHDI channels by name is not really used
by anyone, and therefore should probably be removed.

Change-Id: I7d50bbfd9d957586f5cd06570244ef87bd54b485

Previously, when reloading the members of a queue, the members added statically
(i.e. defined in queues.conf) would see their "ringinuse" value updated but not
the members added dynamically.

This change makes dynamic members ringuse value to be updated on reload.

Note that it's impossible to add a dynamic member with a specific ringinuse
value. For both static and dynamic members, the ringinuse value can always be
changed later on with command like "queue set ringinuse" or with the AMI action
"QueueMemberRingInUse". So it's possible this commit could break a user workflow
if he was changing the ringinuse value of dynamic members via such commands and
was also relying on the fact that a queue reload would not update the dynamic
members ringinuse value.

ASTERISK-26330

Change-Id: I3745cc9a06ba7e02c399636f1ee9e58c04081f3f

This allows asterisk to compiled with LOW_MEMORY to load modules built
without LOW_MEMORY.

ASTERISK-26398 #close

Change-Id: I24b78ac9493ab933b11087a8b6794f3c96d4872d

Change-Id: I35b5f6657670cfa8985796fa1e1fe86ad299efdc

Dial events up to this point have come in two flavors
* A Dial event with no status to indicate that dialing has begun
* A Dial event with a status to indicate that dialing has ended

With this change, Dial events have been expanded to also give
intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS".
This is especially useful for ARI dialing, as it gives the application
writer the opportunity to place a channel into an early bridge when
early media is detected.

AMI handles these in-progress dial events by sending a new event called
"DialState" that simply indicates that dial state has changed but has
not ended. ARI never distinguished between DialBegin and DialEnd, so no
change was made to the event itself.

Another change here relates to dial forwards. A forward-related event
was previously only sent when a channel was successfully able to forward
a call to a new channel. With this set of changes, if forwarding is
blocked, we send a Dial event with a forwarding destination but no
forwarding channel, since we were prevented from creating one. This is
again useful for ARI since application writers can now handle call
forward attempts from within their own application.

ASTERISK-25925 #close
Reported by Mark Michelson

Change-Id: I42cbec7730d84640a434d143a0d172a740995543

Previously you could add [!dnid] to the SIP dial string to alter the To:
header. This change allows you to alter the From header as well.

SIP dial string extra options now look like this:

    [![touser[@todomain]][![fromuser][@fromdomain]]]

INCOMPATIBLE CHANGE: If you were using an exclamation mark in your To:
header, that is no longer possible.

ASTERISK-25803 #close

Change-Id: I2457e9ba7a89eb1da22084bab5a4d4328e189db7

- The maximum_number_of_words was previously documented as being
the number of words that when exceeded, would result in the AMD
application returning that the audio represents a machine.

This was inconsistent with its actual functionality - it was
a number of words that when REACHED, would result in determination
as a machine.

This update corrects the functionality to match the previously
documented functionality.  This is a backwards incompatible change
in configuration file, and has been added to UPGRADE.txt as a result.

The sample configuration file and application defaults have been updated
so that the default value is now 2, which reflects the same default
functionality as previous versions.

- Update documentation for silence_threshold, which previously implied
that it was measuring time, rather than noise averages in the sample.

- Update the comments in amd.conf.sample.

ASTERISK-25639 #close
Change-Id: I4b1451e5dc9cb3cb06d59b6ab872f5275ba79093