It is possible for topic->name to be NULL, this causes the allocation
reference to not be logged.  Use the name variable instead which has
been verified to be a non-empty.

Change-Id: I3d0031d03c8356e4808f00cdf2d5428712575883

This change adds support to the JITTERBUFFER dialplan function
for audio and video synchronization. When enabled the RTCP SR
report is used to produce an NTP timestamp for both the audio and
video streams. Using this information the video frames are queued
until their NTP timestamp is equal to or behind the NTP timestamp
of the audio. The audio jitterbuffer acts as the leader deciding
when to shrink/grow the jitterbuffer when adaptive is in use. For
both adaptive and fixed the video buffer follows the size of the
audio jitterbuffer.

ASTERISK-28533

Change-Id: I3fd75160426465e6d46bb2e198c07b9d314a4492

This change adds H.265/HEVC as a known codec and creates a cached
"h265" media format for use.

Note that RFC 7798 section 7.2 also describes additional SDP
parameters. Handling of these is not yet supported.

ASTERISK-28512

Change-Id: I26d262cc4110b4f7e99348a3ddc53bad0d2cd1f2

When modifying an already defined variable in some channel drivers they
add a new variable with the same name to the list, but that value is
never used, only the first one found.

Introduce ast_variable_list_replace() and use it where appropriate.

ASTERISK-23756 #close
Patches:
  setvar-multiplie.patch submitted by Michael Goryainov

Change-Id: Ie1897a96c82b8945e752733612ee963686f32839

Added unit tests for RTCP video stats. These tests include NACK, REMB,
FIR/FUR/PLI, SR/RR/SDES, and packet loss statistics. The REMB and FIR
tests are currently disabled due to a bug. We expect to receive a
compound packet, but the code sends this out as a single packet, which
the browser accepts, but makes Asterisk upset.

While writing these tests, I noticed an issue with NACK as well. Where
it is handling a received NACK request, it was reading in only the first
8 bits of following packets that were also lost. This has been changed
to the correct value of 16 bits.

Also made a minor fix to the data buffer unit test.

Change-Id: I56107c7411003a247589bbb6086d25c54719901b

This change removes the assumption that a frame will always have
a src set on it. This assumption is incorrect.

Given a scenario where an RTP packet is received with no payload
the resulting audio frame will have no samples. If this frame goes
through a signed linear translation path an interpolated frame can
be created (if generic packet loss concealment is enabled) that has
minimal data on it, including no src. If this frame is given to a
translation path a crash will occur due to the lack of src.

ASTERISK-28499

Change-Id: I024d10dd98207eb8a6b35b59880bcdf1090538f8

The new function takes in a pointer to an ast_sockaddr structure,
a hostname and an optional port and then dispatches parallel
"AAAA" and "A" record queries.  If an "AAAA" record is returned,
it's parsed into the ast_sockaddr structure along with the port
if it was supplied.  If no "AAAA" record was returned, the
first "A" record returned (if any) is parsed instead.

This is a synchronous call.  If you need asynchronous lookups,
use ast_dns_query_set_resolve_async and roll your own.

Change-Id: I194b0b0e73da94b35cc35263a868ffac3a8d0a95

There are 4 scenarios to consider when capturing audio from a channel
with an audiohook:

 1. There is no rx and no tx audio, so return nothing.
 2. There is rx but no tx audio, so return rx.
 3. There is tx but no rx audio, so return tx.
 4. There is rx and tx audio, so mix them and return.

The file passed as the primary argument to MixMonitor will be written to
in scenarios 2, 3, and 4. However, if you pass the r() and t() options
to MixMonitor, a frame will only be written to the r() file if there was
rx audio and a frame will only be written to the t() file if there was
tx audio.

If you subsequently take the r() and t() files and try to mix them, the
sides of the conversation will 'drift' and be non-representative of the
user experience.

This patch adds a new 'S' option to MixMonitor that injects a frame of
silence on either the r() side or the t() side of the channel so that
when later mixed, there is no such drift.

Change-Id: Ibf5ed73a811087727bd561a89a59f4447b4ee20e

Somehow it's possible for the srtp session object to be NULL even though the
Asterisk srtp object itself is valid. When this happened it would cause a
crash down in the srtp code when attempting to protect or unprotect data.

After looking at the code there is at least one spot that makes this situation
possible. If Asterisk fails to unprotect the data, and after several retries
it still can't then the srtp->session gets freed, and set to NULL while still
leaving the Asterisk srtp object around. However, according to the original
issue reporter this does not appear to be their situation since they found
no errors logged stating the above happened (which Asterisk does for that
situation).

An issue was found however, where a possible race condition could occur between
the pjsip incoming negotiation, and the receiving of RTP packets. Both places
could attempt to create/setup srtp for the same rtp instance at the same time.
This potentially could be the cause of the problem as well.

Given the above this patch adds locking around srtp setup for a given rtp, or
rtcp instance. NULL checks for the session have also been added within the
protect and unprotect functions as a precaution. These checks should at least
stop Asterisk from crashing if it gets in this situation again.

This patch also fixes one other issue noticed during investigation. When doing
a replace the old object was freed before creating the replacement. If the new
replacement object failed to create then the rtp/rtcp instance would now point
to freed srtp data which could potentially cause a crash as well when the next
attempt to reference it was made. This is now fixed so the old srtp object is
kept upon replacement failure.

Lastly, more logging has been added to help diagnose future issues.

ASTERISK-28472

Change-Id: I240e11cbb1e9ea8083d59d50db069891228fe5cc

When updating times on CDR or CEL records using the time at which
it is done can result in times being incorrect if the system is
heavily loaded and stasis message processing is delayed.

This change instead makes it so CDR and CEL use the time at which
the stasis messages that drive the systems are created. This allows
them to be backed up while still producing correct records.

ASTERISK-28498

Change-Id: I6829227e67aefa318efe5e183a94d4a1b4e8500a

There were still a few places in the code that could overflow when "packing"
a json object with a value outside the base type integer's range. For instance:

unsigned int value = INT_MAX + 1
ast_json_pack("{s: i}", value);

would result in a negative number being "packed". In those situations this patch
alters those values to a ast_json_int_t, which widens the value up to a long or
long long.

ASTERISK-28480

Change-Id: Ied530780d83e6f1772adba0e28d8938ef30c49a1

incorrect handling of UDPTL squence number wrap arounds causes
loss of packets every time the wrap around occurs

ASTERISK-28483 #close

Change-Id: I33caeb2bf13c574a1ebb81714b58907091d64234

The functions that build manager message headers do so in a way that
results in a single messages being split across multiple packets. While
this doesn't matter to the remote end, it makes network captures noisier
and harder to follow, and also means additional system calls.

With this patch, we build up more of the message content into the TLS
buffer before flushing to the network. This change is completely
internal to the manager code and does not affect any of the existing
API's consumers.

Change-Id: I50128b0769060ca5272dbbb5e60242d131eaddf9

When a module fails to register itself (usually a coding error
in the module), dlerror() can return NULL.  We weren't checking
for that in load_dlopen() before trying to strdup the error message
so a SEGV was thrown.  dlerror() is now surrounded with an S_OR
so we don't SEGV.

Change-Id: Ie0fb9316f08a321434f3f85aecf3c7d2ede8b956

When fixing ASTERISK~24212, a change was done so a scheduled callback could not
be removed while it was running. The caller of ast_sched_del would have to wait.

However, when the caller of ast_sched_del is the callback itself (however wrong
this might be), this new check would cause a deadlock: it would wait forever
for itself.

This changeset introduces an additional check: if ast_sched_del is called
by the callback itself, it is immediately rejected (along with an ERROR log and
a backtrace). Additionally, the AST_SCHED_DEL_UNREF macro is adjusted so the
after-ast_sched_del-refcall function is only run if ast_sched_del returned
success.

This should fix the following spurious race condition found in chan_sip:
- thread 1: schedule sip_poke_peer_now (using AST_SCHED_REPLACE)
- thread 2: run sip_poke_peer_now
- thread 2: blank out sched-ID (too soon!)
- thread 1: set sched-ID (too late!)
- thread 2: try to delete the currently running sched-ID

After this fix, an ERROR would be logged, but no deadlocks (in do_monitor) nor
excess calls to sip_unref_peer(peer) (causing double frees of rtp_instances and
other madness) should occur.

(Thanks Richard Mudgett for reviewing/improving this "scary" change.)

Note that this change does not fix the observed race condition: unlocked
access to peer->pokeexpire (and potentially other scheduled items in chan_sip),
causing AST_SCHED_DEL_UNREF to look at a changing id. But it will make the
deadlock go away. And in the observed case, it will not have adverse affects
(like memory leaks) because the scheduled item is removed through a different
path.

ASTERISK-28282

Change-Id: Ic26777fa0732725e6ca7010df17af77a012aa856

When manager debugging is turned on, this patch makes it so incoming AMI actions
are now also logged.

Change-Id: I8047524510e7ac97d99482b2448f8e368f29cd47

** 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

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

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

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

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

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

ASTERISK-28412

Change-Id: I9e85a60f3c81d46df16cfdd1c329ce63432cf32e

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

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

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

When compiling in dev mode, stasis statistics are enabled and can cause
a crash at shutdown due to the following:
- Containers are freed
- Topics and subscriptions remain
- When those topics and subscriptions are deallocated, they go to do
  things with the container

This changes the containers to global ao2 objects, and whenever needed
in the code, a reference must be obtained and checked before any
operations can be done.

ASTERISK-28353 #close

Change-Id: Ie7d5e907fcfcb4d65bd36d5e4eb923126fde8d33

Added RINGTIME, RINGTIME_MS, PROGRESSTIME, PROGRESSTIME_MS variables filled
at the earliest received PROGRESS or RINGING.
Added millisecond versions of DIALEDTIME and ANSWEREDTIME.

Added millisecond versions of ast_channel_get_up_time and
ast_channel_get_duration in channel.c.

ASTERISK-28363

Change-Id: If95f1a7d8c4acbac740037de0c6e3109ff6620b1

There is enough MWI functionality to warrant it having its own 'c' and header
files. This patch moves all current core MWI data structures, and functions
into the following files:

main/mwi.h
main/mwi.c

Note, code was simply moved, and not modified. However, this patch is also in
preparation for core MWI changes, and additions to come.

Change-Id: I9dde8bfae1e7ec254fa63166e090f77e4d3097e0

We changed the validation of autocomplete parameter in the "indications
remove" command to avoid continue the execution of the command after
asking for autocomplete out of range parameters.

ASTERISK-28391
Reported by: lmendes86

Change-Id: I92b24131fd02f2e3c7fec966eea6f7a663310d40

Currently, the "stasis show app" cli doesn't give detail
of subscription/subscriber information.
Added more printings to show details.

ASTERISK-28378

Change-Id: If25a6f14fe4f622bfb37462e891333da1fdf875f

Because hyphens are not matched literally in Asterisk dialplan, we need
to ignore them in our candidate extensions as well.

ASTERISK-17695 #close
Reported by: test011

Change-Id: I227f02301577b1633e8a55b9fe9dc149935c03f0

If the target of a Goto is a label that starts with a number, we
erroneously treat the leading digits as a priority.

ASTERISK-20182 #close
Reported by: Janu

Change-Id: Ia78408c0805a729103917247ecfc802f6fafc94b

When extconfig.conf file is parsed, the code previously searched for
character comma without verifying if error (null or blank).  This caused
a segmentation error.

Change-Id: Id76b452d8f330d11c2742c37232761ad71472a8b

Asterisk assumes that dlopen() will always run the constructor of a
shared library and every dlclose() will run its destructor. But dlopen()
may be permanent, meaning the constructor will only be run once, as is
the case with musl libc.

With a permanent dlopen() the Asterisk module loader does not work
correctly, because it's expectations regarding when the constructors and
destructors are run are not met. In fact a segmentation fault will occur
when the first module is "re-opened" that has AST_MODFLAG_GLOBAL_SYMBOLS
set (the dlopen() does not call the constructor, resource_being_loaded
is not set to NULL, then strlen is called with NULL instead of a string,
see issue ASTERISK-28319).

This commit adds code to the loader that will manually run the
constructors/destructors of the (non-builtin) modules where needed. To
achieve this a new ao2 container (linked list) is started and filled
with objects that contain the names of the modules and the pointers to
their respective info structs.

This behavior can be activated when configuring Asterisk
(--enable-permanent-dlopen). By default this is disabled, of course.

ASTERISK-28319 #close

Signed-off-by: Sebastian Kemper <sebastian_ml@gmx.net>
Change-Id: I86693a0ecf25d5ba81c73773a03df4abc3426875

Added topic_all container for centralizing the topic. This makes more
easier to managing the topics.

Added cli commands.
stasis show topics : It shows all registered topics.
stasis show topic <name> : It shows speicifed topic's detail info.

ASTERISK-28264

Change-Id: Ie86d125d2966f93de74ee00f47ae6fbc8c081c5f

It was difficult to check the channel's current application and
parameters using ARI for current channels. Added app_name, app_data
items to show the current application information.

ASTERISK-28343

Change-Id: Ia48972b3850e5099deab0faeaaf51223a1f2f38c

When notifying a manager session that new events were available
the same lock was used that was also held when doing things within
the session (such as sending events out). If the manager session
blocked for a period of time this would cause a back up of messages
in Stasis and would also block any other sessions from receiving
events.

This change adds a separate lock to the manager session which is
strictly used for notifying it that new events are available.

ASTERISK-28350

Change-Id: Ifbcac007faca9ad0231640f5e82a6ca9228f261b

Since the new names went in, the maximum taskprocessor name is too
short.  This patch increases the name field to a length to better
handle the new names.

Change-Id: I32f32d6926f25c8ef5a91303fd2988d2c2858877

Added ability to specifiy a wizard is read-only when applying
it to a specific object type.  This allows you to specify
create, update and delete callbacks for the wizard but limit
which object types can use them.

Added the ability to allow an object type to have multiple
wizards of the same type.  This is indicated when a wizard
is added to a specific object type.

Added 3 new sorcery wizard functions:

* ast_sorcery_object_type_insert_wizard which does the same thing
  as the existing ast_sorcery_insert_wizard_mapping function but
  accepts the new read-only and allot-duplicates flags and also
  returns the ast_sorcery_wizard structure used and it's internal
  data structure. This allows immediate use of the wizard's
  callbacks without having to register a "wizard mapped" observer.

* ast_sorcery_object_type_apply_wizard which does the same
  thing as the existing ast_sorcery_apply_wizard_mapping function
  but has the added capabilities of
  ast_sorcery_object_type_insert_wizard.

* ast_sorcery_object_type_remove_wizard which removes a wizard
  matching both its name and its original argument string.

* The original logic in __ast_sorcery_insert_wizard_mapping was moved
  to __ast_sorcery_object_type_insert_wizard and enhanced for the
  new capabilities, then __ast_sorcery_insert_wizard_mapping was
  refactored to just call __ast_sorcery_insert_wizard_mapping.

* Added a unit test to test_sorcery.c to test the read-only
  capability.

Change-Id: I40f35840252e4313d99e11dbd80e270a3aa10605