ASTERISK-27775 #close
Reported by: AvayaXAsterisk

Change-Id: Iad158e908e34675ad98f74d09c5e73024e50c257

This patch fixes some wrongly formatted documentation for the AgentLogin
application. A couple of "see also" links should contain only the function
name, and no parameters.

Change-Id: I3f788b47dce3292e311f8a9856938d59a0bd0661

If you do a "make all" when building Asterisk the xml documentation
produced will be missing certain AMI events where their
documentation is located not at the top of the c source file but
embedded further down next to the event's manager_event()
registration call.  See main/manager_mwi.c for an example.

"make full" does produce the correct documentation so we're changing
it in the build script.  A separate commit/issue will address the
problem with "make all".

ASTERISK-28507
Reported by: David Lee

Change-Id: I4a22635d6eef99eacecc0efb69e28360eebdb86c

Some body generators, such as dialog-info+xml, require storing state
information which is then conveyed in the NOTIFY request itself. Up
until now there was no way for such body generators to persist this
information.

Two new API calls have been added to allow body generators to set and
get persisted data. This data is persisted out alongside the normal
persistence information and allows the body generator to restore
state information or to simply use this for normal storage of state.
State is stored in the form of JSON and it is up to the body
generator to interpret this as needed.

The dialog-info+xml body generator has been updated to take advantage
of this to persist the version number.

ASTERISK-27759

Change-Id: I5fda56c624fd13c17b3c48e0319b77079e9e27de

Adds source port matching support when IP matching is used:

  [example]
  type = identify
  match = 1.2.3.4:5060/32, 1.2.3.4:6000/32, asterisk.org:4444

If the IP matches but the source port does not, we reject and search for
alternatives. SRV lookups are still performed if enabled (srv_lookups = yes),
unless the configured FQDN includes a port number in which case just a host
lookup is performed.

ASTERISK-28639 #close
Reported by: Mitch Claborn

Change-Id: I256d5bd5d478b95f526e2f80ace31b690eebba92

The change to add setting hangupsource to sig_pri_queue_hangup()
made in https://gerrit.asterisk.org/c/asterisk/+/12857 casued
deadlocks when a hangup request was received from the core at the
same time a hanguprequest was received from the remote end via the
D channel.

Although the PRI's channel private structure was being unlocked
before setting the hangupsource, the PRI's own lock was still being
held during the process.  If channel actions were also coming from
the core, a deadlock on the PRI could result.  This deadlock could
then escalate to the entire DAHDI subsystem via DAHDI's global
interface list lock, especially if someone used the PRI CLI commands.

Fix:

* We now unlock the PRI as well as the PRI's channel private
  structure before setting the hangupsource, then relock both
  afterwards.

ASTERISK-28605
Reported by: Dirk Wendland

Change-Id: Id74aaa5d4e3746063dbe9deed188eb65193cb9c9

Dialplan has to be careful about passing an empty device list or empty
positions in the list.  As a result, dialplan has to check for these
conditions before using ChanIsAvail.  Simplify dialplan by making
ChanIsAvail handle these conditions gracefully.

* Made tolerate empty positions in the device list.

* Simplified the code and eliminated some unnecessary indention.

ASTERISK-28638

Change-Id: I9e4b67e2cbf26b2417c2d03485b8568e898931d3

When a topic is created for an object, its name is only
<object>:<uniqueid>
For example:
bridge:cb68b3a8-fce7-4738-8a17-d7847562f020

When a topic is added to a pool, its name has the pool's topic
name prepended.  For example:
bridge:all/bridge:cb68b3a8-fce7-4738-8a17-d7847562f020

The topic_pool_entry's name however, is only what was passed
in to stasis_topic_pool_get_topic which is
bridge:cb68b3a8-fce7-4738-8a17-d7847562f020
That's actually correct because the entry is qualified by the
pool that's in.

When you're ready to delete the entry from the pool, you retrieve
the tropic name from the object but since it now has the pool's
topic name prepended, it won't be found in the pool container.

Fix:

* Modified stasis_topic_pool_delete_topic() to skip past the
pool topic's name, if it was prepended to the topic name,
before searching the container for a pool entry.

ASTERISK-28633
Reported by: Joeran Vinzens

Change-Id: I4396aa69dd83e4ab84c5b91b39293cfdbcf483e6

* Made BridgeAdd not hangup the call if there is a problem.
* Reduced message level from warning to verbose for normal exception
cases.
* Added a loop safety check to BridgeAdd.
* Made BridgeAdd set BRIDGERESULT with the status when dialplan is
resumed.

Change-Id: I374d39b8a3edcc794eeb5c6b9f31a01424cdc426

Dialplan has to be careful about passing an empty destination list or
empty positions in the list.  As a result, dialplan has to check for
these conditions before using Dial.  Simplify dialplan by making Dial
handle these conditions gracefully.

* Made tolerate empty positions in the dialed device list.

* Reduced some message log levels from notice to verbose.

ASTERISK-28638

Change-Id: I6edc731aff451f8bdfaee5498078dd18c3a11ab9

Dialplan has to be careful about passing an empty destination list or
empty positions in the list.  As a result, dialplan has to check for
these conditions before using Page.  Simplify dialplan by making Page
handle these conditions gracefully.

* Made tolerate empty positions in the paged device list.

* Reduced some warnings associated with the 's' option to verbose
messages.  The warning level for those messages really serves no purpose
as that is why the 's' option exists.

ASTERISK-28638

Change-Id: I95b64a6d6800cd1a25279c88889314ae60fc21e3

The Bridge application was inconsistent if the channel to bridge with is
not specified.  If no parameters are given then a warning is issued and
the current channel is hung up.  If options are given but no channel is
specified then a warning is issued and the current channel is not hung up.

* Made the Bridge application give a verbose message instead of a warning
if the channel to bridge with is not specified and made not hang up the
current channel.  As a result dialplan no longer needs to check if a
channel name is passed before calling Bridge and simply needs to check the
BRIDGERESULT channel variable instead.  This is something you likely want
your dialplan to do anyway.

* Fixed up L() option warning message.  It is up to the caller to
determine if the channel is hung up because of the warning.  Dial() hangs
up the current channel while Bridge() does not.

Change-Id: I44349a8dc3912397f28852777de04f19e7bb9c73

Change-Id: Ica5f38ccd8cdc077aef14d0c50425e0b29ac7e0a

Why log a warning for something your dialplan explicitly asked for?

Change-Id: I167b90daf4c7d75dd4b7ef94849f6cef05aa43a7

ast_sorcery_changeset_create() is not commutative and will fail to detect
differences between two variable lists depending on what changed, so switch to
ast_variable_lists_match().

ASTERISK-28492 #close
Reported by: Jean-Denis Girard

Change-Id: I7b3256983ddfaa2138d3de92a444a53b5193a4e1

ASTERISK-28673 #close
Reported by: Jonathan Harris

Change-Id: I591afdec669622bfa19243aabec31b579652c92f

When TLS is in use, checking the readiness of the underlying FD is insufficient
for determining if there is data available to be read. So before polling the
FD, check if there is any buffered data in the TLS layer and use that first.

ASTERISK-28562 #close
Reported by: Robert Sutton

Change-Id: I95fcb3e2004700d5cf8e5ee04943f0115b15e10d

This patch adds a new flag "inhibitConnectedLineUpdates" to the 'addChannel'
operation in the Bridges REST API. When set, this flag avoids generating COLP
frames when the specified channels enter the bridge.

ASTERISK-28629

Change-Id: Ib995d4f0c6106279aa448b34b042b68f0f2ca5dc

The db_init() function ultimately calls db_sync() which signals the
condition before it is initialized.

Change-Id: Id4a4e025b637bc4ac7d90557fcb71d56598892ab