Change-Id: I045e420d5e73e60639079246e810da6ae21ae22b

* In main/config.c, AST_INCLUDE_GLOB is fixed to '1' making the #ifdefs
  pointless.

* In utils/extconf.c, AST_INCLUDE_GLOB is never defined so there is a
  lot of dead code.

Change-Id: I1bad1a46d7466ddf90d52cc724e997195495226c

When REF_DEBUG and AO2_DEBUG are both enabled we closed the refs log
before we shutdown astobj2_container.  This caused the AO2_DEBUG
container registration container to be reported as a leak.

Change-Id: If9111c4c21c68064b22c546d5d7a41fac430430e

This issue related to setting of holdtime, announcements, member delays.
It works well if we set the member delays to "0" and no announcements
and no holdtime.This issue will happen if we set member delays to "1",
"2"... or announcements or holdtime and hangs up the call during
processing it.

And here is the reason:
(At the step of answering a phone.)
It takes care any holdtime, announcements, member delays,
or other options after a call has been answered if it exists.

Normally, After the call has been aswered,
and we wait for the processing one of the cases of the member delays
or hold time or announcements finished, "if (ast_check_hangup(peer))"
will be not executed, then queue will be updated at update_queue().
Here, pending member will be removed.

However, after the call has been aswered,
if we hangs up the call during one of the cases of the member delays
or hold time or announcements, "if (ast_check_hangup(peer))"
will be executed.
outgoing = NULL and at hangupcalls, pending members will not be removed.

* This fixed patch will remove the pending member from container
before hanging up the call with outgoing is NULL.

ASTERISK-27920

Reported by: Cao Minh Hiep
Tested by: Cao Minh Hiep

Change-Id: Ib780fbf48ace9d2d8eaa1270b9d530a4fc14c855

Fixed an issue that resulted in "Allocation failed" each time an ARI
request was made to start playing MOH on a bridge.

In bridge_moh_create() we were attaching the after bridge callbacks to
chan which is the ;1 channel of the unreal channel pair.  We should have
attached them to the ;2 channel which is pushed into the bridge by
ast_unreal_channel_push_to_bridge().  The callbacks are called when the
specific channel leaves the bridging system.  Since the ;1 channel is
never put into a bridge the callbacks never get called.  The callbacks
then never remove the moh_wrapper from the app_bridges_moh container.  As
a result we cannot find the channel associated with the wrapper to start
MOH because it has hungup.  This is the reason causing the reported issue.

* Rather than using after bridge callbacks to cleanup, we now have
moh_channel_thread() doing the cleanup when the channel hangs up.

* Fixed moh_channel_thread() accumulating control frames on the stasis
bridge MOH channel until MOH is stopped.  Control frames are no longer
accumulated while MOH is playing.

* Fixed channel ref counting issue.  stasis_app_bridge_moh_channel() may
or may not return a channel ref.  As a result ast_ari_bridges_start_moh()
wouldn't know it may have a channel ref to release.
stasis_app_bridge_moh_channel() will now return a ref with the channel it
returns.

* Eliminated RAII_VAR in bridge_moh_create().

ASTERISK-26094 #close

Change-Id: Ibff479e167b3320c68aaabfada7e1d0ef7bd548c

When networks experience disruptions, there can be large gaps of time
between receiving packets. When strictrtp is enabled, this created
issues where a flood of packets could come in and be seen as an attack.
Another option - seqno - has been added to the strictrtp option that
ignores the time interval and goes strictly by sequence number for
validity.

Change-Id: I8a42b8d193673899c8fc22fe7f98ea87df89be71

On SQL error there is not diagnostic information about this error.
There is only
WARNING res_odbc.c: SQL Execute error -1!

The function ast_odbc_print_errors calls a SQLGetDiagField to get the number
of available diagnostic records, but the SQLGetDiagField returns 0.
However SQLGetDiagRec could return one diagnostic records in this case.

Looking at many example of getting diagnostics error information
I found out that the best way it's to use only SQLGetDiagRec
while it returns SQL_SUCCESS.

Also this patch adds calls of ast_odbc_print_errors on SQL_ERROR
to res_config_odbc.

ASTERISK-28065 #close

Change-Id: Iba5ae5470ac49ecd911dd084effbe9efac68ccc1

The default is 600 seconds.
Also added timeouts to the *TestGroups.json files.

Change-Id: I8ab6a69e704b6a10f06a0e52ede02312a2b72fe0

With tls and udp enabled asterisk generates a warning about sending
message via udp instead of tls.
sip notify command via cli works as expected and without warning.

asterisk has to set the connection information accordingly to connection
and not on presumption

ASTERISK-28057 #close

Change-Id: Ib43315aba1f2c14ba077b52d8c5b00be0006656e

Use json_vsprintf from versions which contain fix for va_copy leak.

Apply fixes from jansson master:
* va_copy leak fix.
* Avoid potential invalid memory read in json_pack.
* Rename variable that shadowed another.

Change-Id: I7522e462d2a52f53010ffa1e7d705c666ec35539

This change raises a testsuite event to provide what port
Asterisk has actually allocated for RTP. This ensures that
testsuite tests can remove any assumption of ports and instead
use the actual port in use.

ASTERISK-28070

Change-Id: I91bd45782e84284e01c89acf4b2da352e14ae044

When writing an RTCP report to json the code attempts to pack the "ssrc" and
"source_ssrc" unsigned integer values as a signed int value type. This of course
means if the ssrc's unsigned value is greater than that which can fit into a
signed integer value it gets converted to a negative number. Subsequently, the
negative value goes out in the json report.

This patch now packs the value as a json_int_t, which is the widest integer type
available on a given system. This should make it so the value no longer
overflows.

Note, this was caught by two failing tests hep/rtcp-receiver/ and
hep/rtcp-sender.

Change-Id: I2af275286ee5e795b79f0c3d450d9e4b28e958b0

The append_mailbox function wasn't calculating the correct length
to pass to ast_alloca and it wasn't handling the case where context
might be empty.

Found by the Address Sanitizer.

Change-Id: I7eb51c7bd18a7a8dbdba261462a95cc69e84f161

does_id_conflict() was passing a pointer to an int to a callback
that expected a pointer to a size_t.

Found by the Address Sanitizer.

Change-Id: I0ff542067eef63a14a60301654d65d34fe2ad503

ast_rtp_new free'd rtp upon failure, but rtp_engine.c would also call
the destroy callback.  Remove call to ast_free from ast_rtp_new, leave
it to rtp_engine.c to initiate the full cleanup.  Add error detection
for the ssrc_mapping vector initialization.  In rtp_allocate_transport
set rtp->s = -1 in the failure path where we close that FD to ensure we
don't try closing it twice.

ASTERISK-27854 #close

Change-Id: Ie02aecbb46228ca804e24b19cec2bb6f7b94e451

'rtpchecksums' and 'rtcpinterval' are not being reset to their defaults
if they are not present in the updated configuration file.

Change-Id: I1162e40199314d46cf3225d5e1271c4c81176670

app_voicemail wasn't properly cleaning up the stasis cache or the
mwi topic pool when the module was unloaded or when a user was
deleted as a result of a reload.  This resulted in leaks in both
areas.

* app_voicemail now calls ast_delete_mwi_state_full when it frees
  a user structure and ast_delete_mwi_state_full in turn now calls
  the new stasis_topic_pool_delete_topic function to clear the topic
  from the pool.

Change-Id: Ide23144a4a810e7e0faad5a8e988d15947965df8

The HTTP request processing in res_http_websocket allocates additional
space on the stack for various headers received during an Upgrade request.
An attacker could send a specially crafted request that causes this code
to overflow the stack, resulting in a crash.

* No longer allocate memory from the stack in a loop to parse the header
values.  NOTE: There is a slight API change when using the passed in
strings as is.  We now require the passed in strings to no longer have
leading or trailing whitespace.  This isn't a problem as the only callers
have already done this before passing the strings to the affected
function.

ASTERISK-28013 #close

Change-Id: Ia564825a8a95e085fd17e658cb777fe1afa8091a

There's been a long standing leak when using topic pools.  The
topics in the pool get cleaned up when the last pool reference is
released but you can't remove a topic specifically.  If you reloaded
app_voicemail for instance, and mailboxes went away, their topics
were left in the pool.

* Added stasis_topic_pool_delete_topic() so modules can clean up
  topics from pools.
* Registered the topic pool containers so it can be examined from
  the CLI when AO2_DEBUG is enabled.  They'll be named
  "<topic_pool_name>-pool".

Change-Id: Ib7957951ee5c9b9b4482af7b9b4349112d62bc25