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

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

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

The function leave_voicemail checks if expungeonhangup is set,
but does not check if IMAP stream is closed,
so it could call imap function with NULL stream.
This leads to segfault.

ASTERISK-28505 #close

Change-Id: Ib66c57c1f1ba97774e447b36349198e2626a8d7c

Because keypad() is exported by libtinfo, it needs to be explicitly
added to the linker options.

ASTERISK-28487 #close

Change-Id: I6c2ad5b95f422c263d078b5c0e84c111807dffc6

Change-Id: I52be64c8f6af2bbe15148a856d1f10cb113e1e94
(cherry picked from commit c6558e09)

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

To make throttling by label fully active, the "throttle" option
has to be specified with a specific label.

You can now specify "skip_gate" in the Gerrit comments when you
do a +2 code review to tell Jenkins not to actually run the
gate.  You'd do this if you plan to manually merge the change.

Also updated the "printenv" debug output to better sort multi-line
comments.

Change-Id: I4c0b1085acec4805f2ca207eebac50aad81f27e2

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

Originally, the eligible nodes for a job were labelled only by
"swdev-docker".  So basically any node could run any job.  We had
found that allowing a node to run more than 1 gate at a time was
problematic so we limited the nodes to processing 1 job at a time.
With the creation of the Asterisk 17 branches however, we now have
so many active branches that getting checks and gates through in
a timely manner is problematic when a node can run only 1 job
at a time.

Now the nodes are also labelled by the job type they can run.
For instance: "asterisk-check", "asterisk-gate", etc.  With the
"Throttle Concurrent Builds" plugin, we can now allow a node to
run more than 1 job BUT throttle by job type.  For instance:
  Allow 2 jobs but only 1 asterisk-gate at a time.
Now a node can run 2 checks or 1 check and 1 gate or 1 gate but
not 2 gates at a time.

Change-Id: I2032bf6afbcec5c341d9b852214c0c812d3d6db5

You now select voicemail backends like normal dialplan applications, so
there is no longer a need for their own menuselect category.

Reported by snuff-work in #asterisk-dev

Change-Id: Idfa4c9c8349726074318a9e6b68d24c374521005

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

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

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

Change-Id: I8b8ed97001446fab0c14d7c89391ee572fb29dd6

Change-Id: Ib0a4b41e5ececbe633079e2d8c2b66c031d2d1f2

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

We don't support non-core modules for Certified releases but we
were enabling them for CI builds which was causing lots of test
failures.  Now we don't.

Change-Id: I0b3254c08a2479f3d39151690350cce5ce5ad766

ASTERISK-28477 #close
Reported by: Dennis

ASTERISK-28478 #close
Reported by: Dennis

Change-Id: I77347ad46a86dc5b35ed68270cee56acefb4f475