If an AMI user without the "system" authorization calls the
Originate AMI command with the Originate application,
the second Originate could run the "System" command.

Action: Originate
Channel: Local/1111
Application: Originate
Data: Local/2222,app,System,touch /tmp/owned

If the "system" authorization isn't set, we now block the
Originate app as well as the System, Exec, etc. apps.

ASTERISK-28580
Reported by: Eliel Sardañons

Change-Id: Ic4c9dedc34c426f03c8c14fce334a71386d8a5fa

Change-Id: I9f44a3d5085ea7880fad1a3883a4820907e29ea3
(cherry picked from commit 95213b01)

Change-Id: Ib4b6e4887695f230ea7a5b0c879b29fc5a13be4f
(cherry picked from commit d60f23ec)
(cherry picked from commit ce8a23fd)
(cherry picked from commit f0d1ce50)

The original clone depth of 10 was causing the need to rebase
changes whose parent was older than the 10 commits.  The clone
depth has been increased to 100.

Workspace cleanup was only happening for successful builds which
wasn't enough to keep the 8G workspace in-memory drives on the
docker slaves from filling up.  Now the workspaces are cleaned up
after every build regardless of success/failure.  If you need to
preserve builds temporarily, you can log into Jenkins/Manage
Jenkins/Configure System and change the CLEANUP_WS_* environment
variable for the job type you're troubleshooting to "FALSE".

Change-Id: I0d7366e87cea714e5dbc9488caf718802fce75ca

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

ASTERISK_28143 attempted to fix an issue where calls with no audio would never
timeout. It did so by adding AST_FRAME_NULL as a frame type to process in its
calculations. Unfortunately these frames seem to show up at irregular time
intervals. This resulted in app_amd returning prematurely most of the time.

* Removed AST_FRAME_NULL from the calculations
* Added a check to see how much time has actually passed since app_amd began

ASTERISK-28608

Change-Id: I642a21b02d389b17e40ccd5357754b034c3daa42

Upon a short PRI disconnection, libpri may maintain Q.921 layer 'up' and
may thus not send PRI_EVENT_DCHAN_DOWN / PRI_EVENT_DCHAN_UP events.
If pri_event_alarm() clears DCHAN_UP status bit upon alarm detection
and no Q.921 reconnection sequence occurs, chan_dahdi will keep
seeing span status "Down" at the end of alarm.

This patch modifies pri_event_alarm() in order to keep DCHAN_UP bit
unchanged. libpri will send a PRI_EVENT_DCHAN_DOWN event if it detects
a disconnection of Q.921 layer and this will clear DCHAN_UP if required.

ASTERISK-28615

Change-Id: Ibe27df4971fd4c82cc6850020bce4a8b2692c996

ASTERISK-28614

Change-Id: I183501297ae1dc294ae56b34acac9b0343eb2664

The current code sets alert levels starting from index 1.
Need to set on whole pool starting from index 0.

Change-Id: I5decbb43160954fb9a512f04302637fc666b6f5d

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

If the last line of a file does not have a terminating EOL sequence, we
potentially add garbage to the value returned from the FILE() function.

There is no overflow potential here as we are reading from a buffer of a
known size, we are just reading too much of it.

ASTERISK-26481 #close

Change-Id: I50dd4fcf416fb3c83150040a1a79a59d9eb1ae01

MOH continues to play to a channel if that channel was on hold prior to
entering a softmix bridge. MOH will not stop even if the original "holder"
attempts an unhold.

For the most part a softmix bridge ignores holds, so a participating channel
shouldn't join while on hold. This patch checks to see if the channel joining
the softmix bridge is currently on hold. If so then it indicates an unhold.

ASTERISK-28618

Change-Id: I66ccd4efc80f5b4c3dd68186b379eb442916392b

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

When user wants to send json data, the default Content-Type header
is incorect (application/x-www-form-urlencoded). This patch allows
to set any custom headers so the Content-Type header can be
overriden. User can set multiple headers by multiple calls of
curlopt(). This approach is not consistent with other parameters,
but is more readable in dialplan than one call with multiple
headers.

ASTERISK-28613

Change-Id: I4dd68c3f4e25362ef941d73a3861f58348dcfbf9

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

The following modules needed tweaks for API changes.

addons/cdr_mysql.c
addons/chan_ooh323.c
apps/app_meetme.c

ASTERISK-28604

Change-Id: Ib40e513ae55b5114be035cdc929abb6a8ce2d06d

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

ASTERISK-28590 #close

Change-Id: I51abce00c04d0a06550bda5205580705185b9c1c