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

You can now add the "include_local_address" flag to an entry in
rtp.conf "[ice_host_candidates]" to include both the advertized
address and the local address in ICE negotiation:

[ice_host_candidates]
192.168.1.1 = 1.2.3.4,include_local_address

This causes both 192.168.1.1 and 1.2.3.4 to be advertized.

Change-Id: Ide492cd45ce84546175ca7d557de80d9770513db

Various fixes for issues caught by gcc 9.  Mostly snprintf
trying to copy to a buffer potentially too small.

ASTERISK-28412

Change-Id: I9e85a60f3c81d46df16cfdd1c329ce63432cf32e

This change fixes two bugs which both resulted in the packet loss
count exceeding 65,000.

The first issue is that the sequence number check to determine if
cycling had occurred was using the wrong variable resulting in the
check never seeing that cycling has occurred, throwing off the
packet loss calculation. It now uses the correct variable.

The second issue is that the packet loss calculation assumed that
the received number of packets in an interval could never exceed
the expected number. In practice this isn't true due to delayed
or retransmitted packets. The expected will now be updated to
the received number if the received exceeds it.

ASTERISK-28379

Change-Id: If888ebc194ab69ac3194113a808c414b014ce0f6

When multiple endpoints try to register close together using the same
AOR with qualify_frequency set, one contact would qualify immediately
while the other contacts would have to wait out the duration of the
timer before being able to qualify. Changing the conditional to check
the contact container count for a non-zero value allows all contacts to
qualify immediately.

Change-Id: I79478118ee7e0d6e76af7c354d66684220db9415

Added a conversion for umax (largest maximum sized integer allowed). Adjusted
the other current conversion functions (uint and ulong) to be derivatives of
the umax conversion since they are simply subsets of umax.

Also made the negative check move the pointer on spaces since strtoumax does it
anyways.

Change-Id: I56c2ef2629d49b524c8df58af12951c181f81f08

When we use early bridge with create and dial from stasis using Local channel
and the dialplan does not any entry the it is returned from core_local.c with
No such extension .

In such case asterisk locks up till the channel is not hangup with the error
Exceptionally long voice queue length

* Found that in such case app_control_dial fails on ast_call method and
  return -1
* Since it is called from stasis_app_send_command_async and return -1 does
  not cause resources to be freed and since no PBX exist it is not able to
  read from channel causing exceptionally long queue
* After putting this code found that the channel was releasing immediately
  and resources were freed.

ASTERISK-28399
Reported by: Abhay Gupta
Tested by: Abhay Gupta

Change-Id: I0a55c923fc6995559f808d63b9488762b4489318

When the gcc version is >= 8.2.1, we were already setting the
--fno-partial-inlining flag for Asterisk source files to get around
a gcc bug but we weren't passing the flag down to the bundled
builds of pjproject and jansson.

ASTERISK-28392

Change-Id: I99ede9bc35408ecd096f7d5369e8192d3dc75704

Updated ast_sip_create_rdata_with_contact and registrar_find_contact
to check the return from pjsip_parse_uri before attempting to
use the uri returned.

ASTERISK-28402
Reported-by: Ross Beer

Change-Id: I9810b3b163c45ed5a56ec743586e5ce107f13ba7

The dial bridge is meant to hold channels which have been created
and dialed in stasis. It handles the frames coming from them and raises
the appropriate events.

It was possible for the code to mistakenly place calls which came
from the dialplan into the dial bridge if they were not in an
answered state. These channels are not outgoing channels and
should not be placed into the dial bridge.

The code now checks to ensure that only stasis created channels are
placed into the dial bridge by checking that a PBX does not exist
on the channel.

ASTERISK-27756

Change-Id: Ideee69ff06c9a0b31f7ed61165f5c055f51d21b6

After a bridge has been deleted the stasis control will depart
the channel and might attempt to re-add it to the dial bridge.

The later can fail and this can lead to a situation that the stasis
control is unlinked but the after_bridge_cb_failed cb is executed trying
to access a dangling control object.

Fix it by calling the after_cb's before bridge_channel_impart_signal.

ASTERISK-26718

Change-Id: Ib4e8f70d7a21bd54afe3cb51cc6717ef7c355496

When producing a combined REMB value the normal behavior
is to have a REMB value which is unique for each sender
based on all of their receivers. This can result in one
sender having low bitrate while all the rest are high.

This change adds "all" variants which produces a bridge
level REMB value instead. All REMB reports are combined
together into a single REMB value that is the same for
each sender.

ASTERISK-28401

Change-Id: I883e6cc26003b497c8180b346111c79a131ba88c

The transport-cc draft is a mechanism by which additional information
about packet reception can be provided to the sender of packets so
they can do sender side bandwidth estimation. This is accomplished
by having a transport specific sequence number and an RTCP feedback
message. This change implements this in the receiver direction.

For each received RTP packet where transport-cc is negotiated we store
the time at which the RTP packet was received and its sequence number.
At a 1 second interval we go through all packets in that period of time
and use the stored time of each in comparison to its preceding packet to
calculate its delta. This delta information is placed in the RTCP
feedback message, along with indicators for any packets which were not
received.

The browser then uses this information to better estimate available
bandwidth and adjust accordingly. This may result in it lowering the
available send bandwidth or adjusting how "bursty" it can be.

ASTERISK-28400

Change-Id: I654a2cff5bd5554ab94457a14f70adb71f574afc

The total time logic will now be executed on calls which
do not pass any media.

ASTERISK-28143

Change-Id: I24726bd29d7e467fc721ca265363417234b22855