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

Fixes: error: ‘domain_name’ may be used uninitialized in this function

Found with gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008

Change-Id: I44413b49ea1205aa25538142161deb73883c79e8

OpenSSL can not tolerate if the packet sent out does not
match the length that it provided to the sender. This change
lies and says that each time the full packet was sent. If
a problem does occur then a retransmission will occur as
appropriate.

ASTERISK-28576

Change-Id: Id42455b15c9dc4eb987c8c023ece6fbf3c22a449

This patch fixes several issues reported by the lgtm code analysis tool:

https://lgtm.com/projects/g/asterisk/asterisk

Not all reported issues were addressed in this patch. This patch mostly fixes
confirmed reported errors, potential problematic code points, and a few other
"low hanging" warnings or recommendations found in core supported modules.
These include, but are not limited to the following:

* innapropriate stack allocation in loops
* buffer overflows
* variable declaration "hiding" another variable declaration
* comparisons results that are always the same
* ambiguously signed bit-field members
* missing header guards

Change-Id: Id4a881686605d26c94ab5409bc70fcc21efacc25

ASTERISK-28616

Change-Id: Iabe31ae38d01604284fcc5c2438d44e29a32ea4d

resource_events:stasis_app_message_handler() was locking the session,
then attempting to determine if the app had debug enabled which
locked the app_registry container.  res_stasis:__stasis_app_register
was locking the app_registry container then calling app_update
which caused app_handler (which locks the session) to run.
The result was a deadlock.

* Updated resource_events:stasis_app_message_handler() to determine
  if debug was set (which locks the app_registry) before obtaining the
  session lock.

* Updated res_stasis:__stasis_app_register to release the app_registry
  container lock before calling app_update (which locks the sesison).

ASTERISK-28423
Reported by Ross Beer

Change-Id: I58c69d08cb372852a63933608e4d6c3e456247b4

There exists a scenario where a thread can hold a lock on the
channels container while trying to lock a bridge. At the same
time another thread can hold the lock for said bridge while
attempting to retrieve a channel. This causes a deadlock.

This change fixes this scenario by retrieving a channel snapshot
instead of a channel, as information present in the snapshot
is all that is needed.

ASTERISK-28616

Change-Id: I68ceb1d62c7378addcd286e21be08a660a7cecf2

Found during some testing, there is a race condition between selecting an
appropriate bridge type for a call versus the applying of media on the callee's
session. In some instances a native bridge type would have been chosen, but
due to the callee's media not yet being established at bridge compatibility
check time the simple bridge type is picked instead.

When using chan_pjsip this initiates a topology change event. The topologies
are then compared for the two sessions. However, when the topology was created
for the caller its streams are initialized to "inactive". This topology is then
used as a base when creating the callee's topology, and streams. Soon after
the caller's topology's stream(s) get updated based on the sdp (get set to
sendrecv in the failing scenario).

Now when the topology change event is raised, and the two topologies are
compared, the comparison fails due to a stream state mismatch (sendrecv vs
inactive). And since they differ a reinvite is sent out (to the caller in
this case).

This patch makes it such that when the caller's topology is initially created
it gets created based on its configured endpoint's media topology. When the
endpoint's topology is created its stream's state(s) are initialized to
sendrecv instead of inactive. Subsequently, now when the callee's topology is
created its topology streams are now initialized to sendrecv. Thus when the
topology change event occurs due to the mentioned scenario the stream states
match for the given sessions, and the reinvite is not sent unless due to some
other valid mismatch.

Note, this patch only changes one pending media state's creation point. It's
possible other places *could* be changed, however for now it was deemed best
to only alter what's here.

Change-Id: I6ba3a6a75f64824a1b963044c37acbe951c389c7

If the "max_retries" option is set to 0 then upon failure no
further attemps are made, so explicitly document the behavior.

ASTERISK-28602

Change-Id: I1e30daae9dd6c49ce18744164214d3def505acbf

Calling ne_uri_parse allocates memory that needs to be freed with a
corresponding call to ne_uri_free.

ASTERISK-28572 #close

Change-Id: I8a6834da27000a6807d89cb7a157b2a88fcb5e61

This change ensures that the module isn't unloaded when a
WebSocket is open. Previously it was possible to unload the
module manually or during shutdown which could cause a crash
when any active WebSockets were terminated.

ASTERISK-28585

Change-Id: I85c71ab112f99875b586419a34c08c8b34c14c5c

When we created the External Media addition to ARI we created an
ExternalMedia object to be returned from the channels/externalMedia
REST endpoint.  This object contained the channel object that was
created plus local_address and local_port attributes (which are
also in the Channel variables).  At the time, we thought that
creating an ExternalMedia object would give us more flexibility
in the future but as we created the sample speech to text
application, we discovered that it doesn't work so well with ARI
client libraries that a) don't have the ExternalMedia object
defined and/or b) can't promote the embedded channel structure
to a first-class Channel object.

This change causes the channels/externalMedia REST endpoint to
return a Channel object (like channels/create and channels/originate)
instead of the ExternalMedia object.

Change-Id: If280094debd35102cf21e0a31a5e0846fec14af9

This was only supposed to be for testing, so now it can be
removed.

Change-Id: I3dfc2e776e70b3196aeed5688372ea80c0214b59

PostgreSQL 12 finally removed column adsrc from table pg_catalog.pg_attrdef
(column default values), which has been deprecated since version 8.0.
Since then, the official/correct/supported way to retrieve the column
default value from the catalog is function pg_catalog.pg_get_expr().

This change breaks compatibility with pre-8.0 PostgreSQL servers,
but has reached end-of-support more than a decade ago.
cdr_pgsql and res_config_pgsql still have support for pre-7.3
servers, but cleaning that up is perhaps a topic for a major release,
not this bugfix.

ASTERISK-28571

Change-Id: I834cb3addf1937e19e87ede140bdd16cea531ebe

When creating an unsolicited MWI aggregate subscription it was possible for
the subscription object to be double unref'ed. This patch removes the explicit
unref as it is not needed since the RAII_VAR will handle it at function end.

Less concerning there was also a bug that could potentially allow the aggregate
subscription object to be added to the unsolicited container twice. This patch
ensures it is added only once.

ASTERISK-28575

Change-Id: I9ccfdb5ea788bc0c3618db183aae235e53c12763

On shutdown it's possible for the unsolicited mwi container to be freed before
other dependent threads are done using it. This patch ensures this can no
longer happen by wrapping the container in an ao2_global object. The solicited
container was also changed too.

ASTERISK-28552

Change-Id: I8f812286dc19a34916acacd71ce2ec26e1042047

Both res_pjsip and res_pjsip_mwi made use of serializer pools. However, they
both implemented their own serializer pool functionality that was pretty much
identical in each of the source files. This patch removes the duplicated code,
and uses the new 'ast_serializer_pool' object instead.

Additionally res_pjsip_mwi enables a shutdown group on the pool since if the
timing was right the module could be unloaded while taskprocessor threads still
needed to execute, thus causing a crash.

Change-Id: I959b0805ad024585bbb6276593118be34fbf6e1d

Add a new dialplan function PJSIP_MOH_PASSTHROUGH that allows
the on-hold behavior to be controlled on a per-call basis

ASTERISK-28542 #close

Change-Id: Iebe905b2ad6dbaa87ab330267147180b05a3c3a8

There are some warning messages which are not informative without endpoint:
"No registered subscribe handler for event presence.winfo"
"No registered publish handler for event presence"

This patch adds an endpoint name to these messages.

Change-Id: Ia2811ec226d8a12659b4f9d4d224b48289650827

ASTERISK-28544 #close

Change-Id: I8e62c444d107674c298f472e3545661de8a80dce

Allow the list of files to be played to be provided explicitly in the
music class's configuration. The primary driver for this change is to
allow URLs to be used for MoH.

Change-Id: I9f43b80b43880980b18b2bee26ec09429d0b92fa

If a permanent contact URI associated with an AOR is invalid, we add a
Contact header to REGISTER responses with a NULL URI, causing a crash.

ASTERISK-28463 #close

Change-Id: Id2b643e58b975bc560aab1c111e6669d54db9102

The following message:

"Subscription request from endpoint <blah> rejected. Expiration of 0 is invalid"

Would sometimes spam the log with warnings if Asterisk restarted and a bunch
of clients sent unsubscribes. This patch changes it from a warning to a debug
message.

Change-Id: I841ec42f65559f3135e037df0e55f89b6447a467

When a stale item was being updated the object was being retrieved, but its
reference was not being decremented after the update. This patch makes it so
the object is now appropriately de-referenced.

ASTERISK-28523

Change-Id: I9d8173d3a0416a242f4eba92fa0853279c500ec7

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

According to RFC3550, ALL RTCP packets must be sent in a compond packet
of at least two individual packets, including SR/RR and SDES. REMB,
FIR, and NACK were not following this format, and as a result, would
fail the packet check in ast_rtcp_interpret. This was found from writing
unit tests for RTCP. The browser would accept the way we were
constructing these RTCP packets, but when sending directly from one
Asterisk instance to another, the above mentioned problem would occur.

Change-Id: Ieb140e9c22568a251a564cd953dd22cd33244605

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

This fix allows a realtime moh class to be unregistered from the command
line. This is useful when the contents of a directory referenced by a
realtime moh class have changed.
The realtime moh class is then reloaded on the next request and uses the
new directory contents.

ASTERISK-17808

Change-Id: Ibc4c6834592257c4bb90601ee299682d15befbce

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

The Channel resource has a new sub-resource "externalMedia".
This allows an application to create a channel for the sole purpose
of exchanging media with an external server.  Once created, this
channel could be placed into a bridge with existing channels to
allow the external server to inject audio into the bridge or
receive audio from the bridge.
See https://wiki.asterisk.org/wiki/display/AST/External+Media+and+ARI
for more information.

Change-Id: I9618899198880b4c650354581b50c0401b58bc46

After receiving a 200 OK with a declined stream in response to a T.38
initiated re-invite Asterisk would crash when attempting to dereference
a NULL session media object.

This patch checks to make sure the session media object is not NULL before
attempting to use it.

ASTERISK-28495
patches:
  ast-2019-004.patch submitted by Alexei Gradinari (license 5691)

Change-Id: I168f45f4da29cfe739acf87e597baa2aae7aa572

res_pjsip_mwi allows both solicited and unsolicited MWI subscription types.
While both can be set in the configuration for a given endpoint/aor, only
one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor
is configured to allow both types then the solicited subscription is rejected
when it comes in. However, there is a configuration option to override that
behavior:

mwi_subscribe_replaces_unsolicited

When set to "yes" then when a solicited subscription comes in instead of
rejecting it Asterisk is suppose to replace the unsolicited one if it exists.
Prior to this patch there was a bug in Asterisk that allowed the solicted one
to be added, but did not remove the unsolicited. As a matter of fact a new
unsolicited subscription got added everytime a SIP register was received.
Over time this eventually could "flood" a phone with SIP notifies.

This patch fixes that behavior to now make it work as expected. If configured
to do so a solicited subscription now properly replaces the unsolicited one.
As well when an unsubscribe is received the unsolicited subscription is
restored. Logic was also put in to handle reloads, and any configuration changes
that might result from that. For instance, if a solicited subscription had
previously replaced an unsolicited one, but after reload it was configured to
not allow that then the solicited one needs to be shutdown, and the unsolicited
one added.

ASTERISK-28488

Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1

Change-Id: Ic784be8500e5cb75dcb34bae9f03cfd93b6b34fb

Given the following request path and 2 handler paths...
Request: /channels/externalMedia
Handler: /channels/{channelId}      "wildcard"
Handler: /channels/externalmedia    "non-wildcard"

...if /channels/externalMedia was registered as a handler after
/channels/{channelId} as shown above, the request would automatically
match the wildcard handler and attempt to parse "externalMedia" into
the channelId variable which isn't what was intended.  It'd work
if the non-wildard entry was defined in rest-api/api-docs/channels.json
before the wildcard entry but that makes the json files
order-dependent which isn't a good thing.

To combat this issue, the search loop saves any wildcard match but
continues looking for exact matches at the same level.  If it finds
one, it's used.  If it hasn't found an exact match at the end of
the current level, the wildcard is used.  Regardless, after
searching the current level, the wildcard is cleared so it won't
accidentally match for a different object or a higher level.

BTW, it's currently not possible for more than 1 wildcard entry
to be defined for a level.  For instance, there couldn't be:
Handler: /channels/{channelId}
Handler: /channels/{channelName}
We wouldn't know which one to match.

Change-Id: I574aa3cbe4249c92c30f74b9b40e750e9002f925

In chan_sip, there was variable SIPFROMDOMAIN that allows to set
From header URI domain per channel. This patch introduces res_pjsip
variable SIPFROMDOMAIN for backward compatibility with chan_sip.

ASTERISK-28489

Change-Id: I715133e43172ce2a1e82093538dc39f9e99e5f2e

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

Change-Id: Ic476a56608b1820ca93dcf68d10cd76fc0b94141

The code for gathering contacts could result in the same contact
being retrieved and added to the list multiple times. The container
which stores the contacts to display will now only allow a contact
to be added to it once instead of multiple times.

ASTERISK-28228

Change-Id: I805185cfcec03340f57d2b9e6cc43c49401812df

Change-Id: Ib0a4b41e5ececbe633079e2d8c2b66c031d2d1f2

ASTERISK-28477 #close
Reported by: Dennis

ASTERISK-28478 #close
Reported by: Dennis

Change-Id: I77347ad46a86dc5b35ed68270cee56acefb4f475