app_voicemail utilized the stasis cache when polling mailboxes for MWI. This
caused a memory leak (items were not being appropriately removed from the
cache), and subsequent slowdown in system processing. This patch removes the
stasis cache dependency, thus alleviating the memory leak. It does this by
utilizing the new MWI API that better manages state lifetime.

ASTERISK-28443
ASTERISK-27121

Change-Id: Ie89fedaca81ea1fd03d150d9d3a1ef3d53740e46

The MWI core recently got some new API calls that make tracking MWI state
lifetime more reliable. This patch updates those modules that subscribe to
specific MWI topics to use the new API. Specifically, these modules now
subscribe to both MWI topics and MWI state.

ASTERISK-28442

Change-Id: I32bef880b647246823dbccdf44a98d384fcabfbd

** Note **

This patch is meant to be the minimum needed in order for the MWI core to use
the now underlying stasis_state module. As such it does not completely remove
its reliance on the stasis_cache. Doing so has allowed current consumers to
not have to change, and update those code paths for this patch. When time
allows, subsequent patches can/will be made to those consumers to take advantage
of some of the new MWI API included here. Thus, eventually and ultimately
removing MWI dependency on the stasis_cache.

** End Note **

This patch makes it so the MWI core now takes advantage of the new stasis_state
API. Consumers of MWI should no longer need to depend upon stasis topic pooling,
and the stasis cache directly. Similar functionality and implementation details
have now been pushed into the stasis_state module. However, all MWI state should
be accessed via the MWI API itself.

As such a few new methods, and constructs have been added to the MWI core that
facilitate consumer publishing, subscribing, and iterating over MWI state data.

* ast_mwi_subscriber *

Created via ast_mwi_add_subscriber, a subscriber subscribes to a given mailbox
in order to receive updates about the given mailbox. Adding a subscriber will
create the underlying topic, and associated state data if those do not already
exist for it. The topic, and last known state data is guaranteed to exist for
the lifetime of the subscriber.

* ast_mwi_publisher *

Before publishing to a particular topic a publisher should be created. This can
be achieved by using ast_mwi_add_publisher. Publishing to a mailbox should then
be done using one of the MWI publish functions. This ensures the message is
published to the appropriate topic, and the last known state is maintained.

* ast_mwi_observer *

Add an observer in order to watch for particular MWI module related events. For
instance if a submodule needs to know when a subscription is added to any
mailbox an observer can be added to watch for that.

* other *

Urgent message count is now part of the published MWI state object. Also state
can be iterated over using defined callbacks.

ASTERISK-28442

Change-Id: I93f935f9090cd5ddff6d4bc80ff90703c05cf776

Regular stasis unsubscribes can handle NULL subscription objects. This patch
makes it so stasis state unsubscribes handles NULL's as well.

ASTERISK-28442

Change-Id: Ic3648e8df043a85b77cff085e9ff10356028e479

Fixes a crash in chan_dahdi occurring on 32-bit systems. A previous
patch introduced a variable of type unassigned long long which is 64-bits.
Casting it as 'ast_json_int_t' along with JSON type 'I' makes it work
with 32-bit systems.

ASTERISK-28457

Change-Id: I9cef6b5f2d826fc5c93f2f6a1c997c4e3e6c93fe

The variable 'endpoint_caps' in function 'set_caps' is not used, so remove.

ASTERISK-28458

Change-Id: Ia8766d05a0738aecb29dd018302c2dafca5cab34

This new module describes an API that can be thought of as a combination of
stasis topic pools, and caching. Except, hopefully done in a more efficient
and less memory "leaky" manner.

The API defines methods, and data structures for managing, and tracking
published message state through stasis. By adding a subscriber or publisher,
consumers can more easily track the lifetime of the contained state. For
instance, when no more publishers and/or subscribers have need of the topic,
and associated state its data is removed from the managed container.

* stasis_state_manager *

The manager stores and well, manages state data. Each state is an association
of a unique stasis topic, and the last known published stasis message on that
topic. There is only ever one managed state object per topic. For each topic
all messages are forwarded to an "all" topic also maintained by the manager.

* stasis_state_subscriber *

Topic and state can be created, or referenced within the manager by adding a
stasis_state_subscriber. When adding a subscriber if no state currently exists
new managed state is immediately created. If managed state already exists then
a new subscriber is created referencing that state. The managed state is
guaranteed to live throughout the subscriber's lifetime. State is only removed
from the manager when no other entities require it.

* stasis_state_publisher *

Topic and state can be created, or referenced within the manager by also adding
a stasis_state_publisher. When adding a publisher if no state currently exists
new managed state is created. If managed state already exists then a new
publisher is created referencing that state. The managed state is guaranteed to
live throughout the publisher's lifetime. State is only removed from the
manager when no other entities require it.

* stasis_state_observer *

Some modules may wish to watch for, and react to managed state events. By
registering a state observer, and implementing handlers for the desired
callbacks those modules can do so.

* other *

Callbacks also exist that allow consumers to iterate over all, or some of the
managed state.

ASTERISK-28442

Change-Id: I7a4a06685a96e511da9f5bd23f9601642d7bd8e5

Changes made to apps/Makefile to optionally build all three app_voicemail
variations at the same time: 1) file (default), 2) odbc, and 3) imap.
This functionality was requested by users. modules.conf.sample warns the
user to make sure only one voicemail is loaded at a time.

Change-Id: Iba3cd8ffb4b7e8b1c64a11dd383e1eafcd3ed0e7

Where possble, hostname and port has been added to error
messages, mostly on the server side.

ASTERISK-26006
Reported by: Oleksandr Natalenko

Change-Id: Iff4f897277bc36ce8c5b493b71d0a4a7b74e62f0

Most SSL/TLS error messages coming from pjproject now have either
the peer address:port or peer hostname, depending on what was
available at the time and code location where the error was
generated.

ASTERISK-28444
Reported by: Bernhard Schmidt

Change-Id: I41770e8a1ea5e96f6e16b236692c4269ce1ba91e

Currently, DELETE /ari/channels/<channelID> supports only few hangup reasons.
It's good enough for simple use, but when it needs to set the detail reason,
it comes challenges.
Added reason_code query parameter for that.

ASTERISK-28385

Change-Id: I1cf1d991ffd759d0591b347445a55f416ddc3ff2

A few more format truncation issues addressed.

Change-Id: I047f373169caaca0eec4889d3c0e5e10f130017a

Now AMD algorithm will not ignore AST_FRAME_NULL, As I think using manual
wait time instead of `framelength` is enough to fix timeout / TOOLONG issue.

ASTERISK-28419 #close

Change-Id: I16ea2d6295bc99b975e8c092e5f9fbd9214debdb

According T.38 Gateway 'Use case 3'
https://wiki.asterisk.org/wiki/display/AST/T.38+Gateway
T.38 Gateway should send T.38 negotiation request to called endpoint
if FAX preamble (using V.21 detector) generated by called endpoint.
But it does not, because fax_gateway_detect_v21 constructs T.38
negotiation request, but forwards it only to other channel,
not to the channel on which FAX preamble is detected.

Some SIP endpoints could be improperly configured to rely on the other side
to initiate T.38 re-INVITEs.

With this patch the T.38 Gateway tries to negotiate with both sides
by sending T.38 negotiation request to both endpoints supported T.38.

Change-Id: I73bb24799bfe1a48adae9c034a2edbae54cc2a39

We were using the presence of /usr/lib64 to determine where
shared libraries should be installed.  This only existed on
Redhat based systems and was safe.  If it existed, use it,
otherwise use /usr/lib.

Unfortunately, Ubuntu 19 decided to create a /usr/lib64 BUT
NOT INCLUDE IT IN THE DEFAULT ld.so.conf.  So if anything is
installed there, it won't work.

The new method, just looks for $ID in /etc/os-release and if it's
centos or fedora, uses /usr/lib64 and if ubuntu, uses /usr/lib.

NOTE:  This applies only to the CI scripts.  Normal asterisk
build and install is not affected.

Change-Id: Iad66374b550fd89349bedbbf2b93f8edd195a7c3

There is WARNING "no samples for ..." on each Playtones.
The function ast_playtones_start calls ast_activate_generator,
which calls ast_prod.
The function ast_prod calls ast_write with empty audio frame.
In this case it's spam log.

Change-Id: Id4ac309489d9ff281bad02abdef341cecdede660

Fixed format-truncation issues in chan_dahdi.c and
sig_analog.c.  Since they're related to fields provided
by dahdi-tools we can't change the buffer sizes so we're just
checking the return from snprintf and printing an errior if we
overflow.

Change-Id: Idc1f3c1565b88a7d145332a0196074b5832864e5

When a channel already in a conference bridge is attended transfered
to another extension, or when an existing call is attended
transferred into a conference bridge, we now generate ConfbridgeJoin
and ConfbridgeLeave events for the entering and departing channels.

Change-Id: Id7709cfbceb26fbcb828b2d0d2a6b2fbeaf028e1

Relies on https://github.com/asterisk/third-party/pull/4

Change-Id: Iec9cad42cb4ae109a86a3d4dae61e8bce4424ce3

This change adds support for larger TLS certificates by allowing
OpenSSL to fragment the DTLS packets according to the configured
MTU. By default this is set to 1200.

This is accomplished by implementing our own BIO method that
supports MTU querying. The configured MTU is returned to OpenSSL
which fragments the packet accordingly. When a packet is to be
sent it is done directly out the RTP instance.

ASTERISK-28018

Change-Id: If2d5032019a28ffd48f43e9e93ed71dbdbf39c06

AttendedTransfer queues up attended transfer to the given extension.

This application can be useful with Custom Dynamic Features.
For example to make attended transfer to a predefined number.

features.conf
;;;
[applicationmap]
my_atxfer => *7,self,GoSub,"my_atxfer,s,1",default
;;;

extensions.conf
;;;
[globals]
DYNAMIC_FEATURES=my_atxfer
TRANSFER_CONTEXT=my_transfer

[my_atxfer]
exten => s,1,AttendedTransfer(1234567890)
   same => n,Return()

[my_transfer]
include => default
;;;

This application also can be used to completly redefine Attended transfer
feature using dialplan. For example:

features.conf
;;;
[featuremap]
atxfer => *7

[applicationmap]
custom_atxfer => *2,self,GoSub,"custom_atxfer,s,1",default
;;;

extensions.conf
;;;
[globals]
DYNAMIC_FEATURES=custom_atxfer
TRANSFER_CONTEXT=my_transfer

[custom_atxfer]
exten => s,1,
   same => n,Playback(pbx-transfer)
   same => n,Read(dest,dial,10,i,3,3)
   same => n,AttendedTransfer(${dest})
   same => n,Return()

[my_transfer]
include => default
;;;

Change-Id: Ie5cfa455d0813cffd5c85a6fb117f07d8f0b903b

We have seen some rare case of segmentation fault in hangup function
and we could notice that channel pointer was NULL.  Debug log shows
that there is a 200 OK answer and SIP timeout at the same time.  It
looks that while the SIP session was being destroyed due to timeout
call hangup due to answer event lead to race condition and channel
is being destroyed from two different places.  The check ensures we
check it not to be NULL before freeing it.

ASTERISK-25371

Change-Id: I19f6566830640625e08f7b87bfe15758ad33a778

BlindTransfer redirects all channels currently bridged to the
caller channel to the specified destination.

This application can be useful with Custom Dynamic Features.
For example to make blind transfer to a predefined number.

features.conf
;;;
[applicationmap]
my_blindxfer => *6,self,GoSub,"my_blindxfer,s,1",default
;;;

extensions.conf
;;;
[globals]
DYNAMIC_FEATURES=my_blindxfer

[my_blindxfer]
exten => s,1,BlindTransfer(1234567890,default)
   same => n,Return()
;;;

This application also can be used to completly redefine Blind transfer
feature using dialplan. For example:

features.conf
;;;
[featuremap]
blindxfer =>

[applicationmap]
custom_blindxfer => ##,self,GoSub,"custom_blindxfer,s,1",default
;;;

extensions.conf
;;;
[globals]
DYNAMIC_FEATURES=custom_blindxfer

[custom_blindxfer]
exten => s,1,
   same => n,Playback(pbx-transfer)
   same => n,Read(dest,dial,10,i,3,3)
   same => n,BlindTransfer(${dest},default)
   same => n,Return()
;;;

Change-Id: I9d55e7f69ccfd4472dec00d62771d6de8803215a