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

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

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

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

ASTERISK-28234
Reported-by: Kirsty Tyerman

Change-Id: I5d6e6b52dbe51415046bb3953fd16f5b421bc2e1

Fixes an error occurring in function pgsql_reconnect() caused when value of
hostname is blank. Which in turn will cause the connection string to look
like this: "host= port=xx", which creates a sintax error. This fix now checks
if the corresponding values for host, port, dbname, and user are blank. Note
that since this is a reconnect function the database library will replace any
missing value pairs with default ones.

ASTERISK-28435

Change-Id: I0a921f99bbd265768be08cd492f04b30855b8423

The change #10017 "Handle fax gateway being started more than once"
introdiced a bug which leads to segfault in res_fax_spandsp.

The res_fax_spandsp module does not support reserving sessions, so
fax_session_reserve returns a fax session with state AST_FAX_STATE_INACTIVE.

The fax_gateway_start does not create a real fax session if the fax session
is already present and the state is not AST_FAX_STATE_RESERVED.
But the "reserved" session created for res_fax_spandsp has state
AST_FAX_STATE_INACTIVE, so fax_gateway_start not starting.

Then when fax_gateway_framehook is called and gateway T.38 state is
NEGOTIATED the call of gateway->s->tech->write(gateway->s, f) leads to
segfault, because session tech_pvt is not set, i.e. the tech session
was not initialized/started.

This patch adds check also on AST_FAX_STATE_INACTIVE to the "reserved"
session created for res_fax_spandsp will start.

This patch also adds extra check and log ERROR if tech_pvt is not set
before call tech->write.

ASTERISK-27981 #close

Change-Id: Ife3e65e5f18c902db2ff0538fccf7d28f88fa803

This patch adds a channel name to output of CLI 'fax show session'
and also expands the channel name field up to 30 characters on
CLI 'fax show sessions'

Change-Id: Id059c43ff41811f5e76712b83fb63b8f246da953

One of the change files doesn't conform to the format that the release
scripts need in order to parse it.

Change-Id: Ie0b634cf27e4cbc671b9fe92993b6f2ecf60254c

After some definitions have been moved to asterisk/mwi.h the files
channels/chan_dahdi.h channels/sig_pri.c are missing this new
include.

ASTERISK-28427 #close

Change-Id: Ia8cc595eeda653324643f40dcd9799d4c3f0ac91

This patch adds the 'p' option.
The extension entered will be considered complete when a # is entered.

Change-Id: If77c40c9c8b525885730821e768f5dea71cf04c1

When monitoring Asterisk instances, it's often useful to know when an
outbound registration fails, as this often maps to the notion of a trunk
and having a trunk fail is usually a "bad thing". As such, this patch
adds monitoring metrics that track the state of PJSIP outbound registrations.
It does this by looking for the Registry events coming across the Stasis
system topic, and publishing those as metrics to Prometheus. Note that
while this may support other outbound registration types (IAX2, SIP, etc.)
those haven't been tested. Your mileage may vary.

(And why are you still using IAX2 and SIP? It's 2019 folks. Get with the
program.)

This patch also adds Sorcery observers to handle modifications to the
underlying PJSIP outbound registration objects. This is useful when a
reload is triggered that modifies the properties of an outbound registration,
or when ARI push configuration is used and an object is updated or
deleted. Because we rely on properties of the registration object to
define the metric (label key/value pairs), we delete the relevant metric when
we notice that something has changed and wait for a new Stasis message to
arrive to re-create the metric.

ASTERISK-28403

Change-Id: If01420e38530fc20b6dd4aa15cd281d94cd2b87e

This patch adds a few CLI commands to the res_prometheus module to aid
system administrators setting up and configuring the module. This includes:

* prometheus show status: Display basic statistics about the Prometheus
  module, including its essential configuration, when it was last scraped,
  and how long the scrape took. The last two bits of information are useful
  when Prometheus isn't generating metrics appropriately, as it will at
  least tell you if Asterisk has had its HTTP route hit by the remote
  server.

* prometheus show metrics: Dump the current metrics to the CLI. Useful for
  system administrators to see what metrics are currently available without
  having to cURL or go to Prometheus itself.

ASTERISK-28403

Change-Id: Ic09813e5e14b901571c5c96ebeae2a02566c5172

This patch adds basic Asterisk bridge statistics to the res_prometheus
module. This includes:

* asterisk_bridges_count: The current number of bridges active on the
  system.

* asterisk_bridges_channels_count: The number of channels active in a
  bridge.

In all cases, enough information is provided with each bridge metric
to determine a unique instance of Asterisk that provided the data, along
with the technology, subclass, and creator of the bridge.

ASTERISK-28403

Change-Id: Ie27417dd72c5bc7624eb2a7a6a8829d7551788dc

This patch adds basic Asterisk endpoint statistics to the res_prometheus
module. This includes:

* asterisk_endpoints_state: The current state (unknown, online, offline)
  for each defined endpoint.

* asterisk_endpoints_channels_count: The current number of channels
  associated with a given endpoint.

* asterisk_endpoints_count: The current number of defined endpoints.

In all cases, enough information is provided with each endpoint metric
to determine a unique instance of Asterisk that provided the data, as well
as the underlying technology and resource definition.

ASTERISK-28403

Change-Id: I46443963330c206a7d12722d08dcaabef672310e

Using timestamp with signed int will cause timestamps exceeding max value
to be negative.
This causes the jitterbuffer to do passthrough of the packet.

ASTERISK-28421

Change-Id: I9dabd0718180f2978856c50f43aac4e52dc3cde9

This patch adds basic Asterisk channel statistics to the res_prometheus
module. This includes:

* asterisk_calls_sum: A running sum of the total number of
  processed calls

* asterisk_calls_count: The current number of calls

* asterisk_channels_count: The current number of channels

* asterisk_channels_state: The state of any particular channel

* asterisk_channels_duration_seconds: How long a channel has existed,
  in seconds

In all cases, enough information is provided with each channel metric
to determine a unique instance of Asterisk that provided the data, as
well as the name, type, unique ID, and - if present - linked ID of each
channel.

ASTERISK-28403

Change-Id: I0db306ec94205d4f58d1e7fbabfe04b185869f59

This patch fixes three compatibility issues for Darwin compatible builds:

(1) Use BSD compatible command line option for sed

For some versions of BSD sed, the -r command line option is unknown.
Both GNU and BSD sed support the -E command line option for enabling
extended regular expressions; as such, this patch replaces the -r
option with -E.

(2) Look for '_' in pjproject generated symbols

In Darwin comaptible systems, the symbols generated for pjproject may be
prefixed with an '_'. When exporting these to a symbol file, the invocation
to sed has to optionally look for a prefix of said '_' character.

(3) Use -all_load/-noall_load when linking

The flags -whole-archive/-no-whole-archive are not supported by the
linker, and must instead be replaced with -all_load/-noall_load.

Change-Id: I58121756de6a0560a6e49ca9d6bf9566a333cde3

Prometheus is the defacto monitoring tool for containerized applications.
This patch adds native support to Asterisk for serving up Prometheus
compatible metrics, such that a Prometheus server can scrape an Asterisk
instance in the same fashion as it does other HTTP services.

The core module in this patch provides an API that future work can build
on top of. The API manages metrics in one of two ways:
(1) Registered metrics. In this particular case, the API assumes that
    the metric (either allocated on the stack or on the heap) will have
    its value updated by the module registering it at will, and not
    just when Prometheus scrapes Asterisk. When a scrape does occur,
    the metrics are locked so that the current value can be retrieved.
(2) Scrape callbacks. In this case, the API allows consumers to be
    called via a callback function when a Prometheus initiated scrape
    occurs. The consumers of the API are responsible for populating
    the response to Prometheus themselves, typically using stack
    allocated metrics that are then formatted properly into strings
    via this module's convenience functions.

These two mechanisms balance the different ways in which information is
generated within Asterisk: some information is generated in a fashion
that makes it appropriate to update the relevant metrics immediately;
some information is better to defer until a Prometheus server asks for
it.

Note that some care has been taken in how metrics are defined to
minimize the impact on performance. Prometheus's metric definition
and its support for nesting metrics based on labels - which are
effectively key/value pairs - can make storage and managing of metrics
somewhat tricky. While a naive approach, where we allow for any number
of labels and perform a lot of heap allocations to manage the information,
would absolutely have worked, this patch instead opts to try to place
as much information in length limited arrays, stack allocations, and
vectors to minimize the performance impacts of scrapes. The author of
this patch has worked on enough systems that were driven to their knees
by poor monitoring implementations to be a bit cautious.

Additionally, this patch only adds support for gauges and counters.
Additional work to add summaries, histograms, and other Prometheus
metric types may add value in the future. This would be of particular
interest if someone wanted to track SIP response types.

Finally, this patch includes unit tests for the core APIs.

ASTERISK-28403

Change-Id: I891433a272c92fd11c705a2c36d65479a415ec42

Fixed #2191:
  - Stricter double timer entry scheduling prevention.
  - Integrate group lock in SIP transport, e.g: for add/dec ref,
    for timer scheduling.

ASTERISK-28161
Reported-by: Ross Beer

Change-Id: I2e09aa66de0dda9414d8a8259a649c4d2d96a9f5