Some configure scripts used both AC_HELP_STRING and its replacement
AS_HELP_STRING. For consistency and to avoid obsolete warnings, those were
changed to AS_HELP_STRING.

ASTERISK-26046

Change-Id: I8aad4fd2bdee40aa2a31ce3339a1eb33ff4f5b0f

Fix compile error introduced by the patch for
ASTERISK-26045

Change-Id: I5b02876266f2824f4cec2b54d6ff4db5de5778d3

ASTERISK-26119 #close

Change-Id: Iecbf7d0f360a021147344c4e83ab242fd1e7512c

Announcer channels were not being destroyed because the
stasis_app_control structure that referenced them was not being
destroyed. The control structure was not being destroyed because it was
not being unlinked from its container. It was not being unlinked from
its container because the after bridge callback for the announcer
channel was not being run. The after bridge callback was not being run
because the after bridge datastore was not being removed from the
channel on destruction. The channel was not being destroyed because the
hangup that used to destroy the channel was now only reducing the
reference count to one. The reference count of the channel was only
being reduced to one because the stasis_app_control structure was
holding the final reference...

The control structure used to not keep a reference to the channel, so
that loop described above did not happen.

The solution is to manually remove the control structure from its
container when the playback on a bridge is complete.

ASTERISK-26083 #close
Reported by Joshua Colp

Change-Id: I0ddc0f64484ea0016245800b409b567dfe85cfb4

The internal HTTP/WebSocket server supports both TCP and TLS, which can be
activated separately via the file http.conf. The source code intends to re-use
the TCP parameter 'bindaddr' for TLS, even if 'tlsbindaddr' is not specified
explicitly. This did not work because of a typo. This change resolves this typo.

ASTERISK-26126 #close

Change-Id: I5efb0409ae12044dfb3495b6b97b6d40a8c9c51f

* In unload_module(), reordered destroying things to minimize the window
that the global transports container could be used by other threads on
shutdown.  When shutting down you need to stop things in the opposite
order of creation.

* Put the global transports container into an AO2_GLOBAL_OBJ_STATIC to
eliminate the crash potential by other threads using the container on
shutdown.

* Made struct monitored_transport.sip_received not use
ast_atomic_fetchadd_int() since it is used as a boolean value that is only
set TRUE.  It was previously incremented for every received SIP message
and could theoretically overflow.

* In monitored_transport_state_callback(), allocated the monitored
transport object without a lock since the lock was unused.

* In keepalive_global_loaded(), removed releasing the transports container
if the keepalive_thread could not be started.  I set it up to be tried
again if the user reloads the configuration.

Change-Id: I8d12d16ef564290fa6d25a32334bb5ce8fdf87ff

Change-Id: Iabaa2e5dccf0762c258101ea0eb1487cf6959ad1

Change-Id: Ic9928208b9957e09866abe3d9649030942ec52b3

Change-Id: I68a2128bcba4830985d2d441e70dfd1ac5bd712b

With CLI "core show settings", simply the parameter maxfiles of the file
asterisk.conf was shown. If that parameter was not set, nothing was displayed
although the environment might have set a default number itself. Or if maxfiles
were not granted (completely), still maxfiles was shown. Now, the maximum number
of possible file descriptors in the environment is shown.

ASTERISK-26097

Change-Id: I2df5c58863b5007b34b77adbe28b885dfcdf7e0b

This reverts commit 5bfef2a8 as it
caused fax test failures.

ASTERISK-25629

Change-Id: I79de974dc4f63a1cafe0d2509169fd9a6b3cbaf4

With menuselect "DEBUG_FD_LEAKS" and CLI "core show fd", both the maximum max
and current max of possible file descriptors were shown. Both show the same
value always. Not to confuse users, just the current maximum is shown now.

ASTERISK-26097

Change-Id: I49cf7952d73aec9e3f6a88942842c39be18380fa

CEL wrongly assumed that a channel would only have a single dial
event on it. This is incorrect. Particularly in a queue each
call attempt to a member will result in a dial event, adding
a new dial status in CEL without removing the old one. This
would cause the container to grow with only one dial status
being removed when the channel went away. The other dial status
entries would remain leaking memory.

This change fixes the memory leak by ensuring that only one dial
status will only ever exist for each channel.

The behavior during the scenario where multiple events are received
has also been improved. For failure cases the first failure will
be the dial status. If an answer dial status is received, though,
it will take priority and the dial status for the channel will be
answer.

Memory usage has also been decreased by storing the minimal
amount of information and the code has been cleaned up slightly.

ASTERISK-25262 #close

Change-Id: I5944eb923db17b6a0faa7317ff6abc9307c009fe

ARI was recently outfitted with operations to create and dial channels.
This leads to the ability to try funny stuff. You could create a channel
and then immediately try to play back media on it. You could create a
channel, dial it, and while it is ringing attempt to make it continue in
the dialplan.

This commit attempts to fix this by adding a channel state check to
operations that should not be able to operate on outbound channels that
have not yet answered. If a channel is in an invalid state, we will send
a 412 response.

ASTERISK-26047 #close
Reported by Mark Michelson

Change-Id: I2ca51bf9ef2b44a1dc5a73f2d2de35c62c37dfd8

The retrieve_cache_control_directives test has been failing occasionally
in Jenkins. The apparent failure occurs when attempting to validate the
expiration of the retrieved file.

After reproducing, the problem was pretty clear. At the beginning of the
test, the current time is retrieved. The seconds value of this timestamp
is X. When the file is retrieved, res_http_media_cache calculates the
expiration and in doing so retrieves the current time. In most cases,
since the test executes quickly, it will also retrieve a timestamp with
X seconds. However, if the test starts very near to when the timestamp
seconds are set to increment, res_http_media_cache may retrieve a
timestamp with X+1 seconds instead.

The test attempted to account for this by allowing a tolerance of 1
second when validating the expiration. However, the problem was that the
comparisons being used in the validation used > and < operations. This
meant that values that fell within the tolerance (because they equaled
the upper bound of the tolerance) would fail.

The solution is to use >= and <= operators in the expiration validation.

However, I estimated that while the one second tolerance should be
fine on most machines, it would still be possible on a very slow machine
to end up falling outside the one second tolerance. So I have also
relaxed the tolerance of expiration validation to be three seconds
instead.

The final change here is to add a debug message when validating
expiration so that we can see what values are being compared.

ASTERISK-25959 #close
Reported by Joshua Colp

Change-Id: Ic1a0e10722c1c5d276d5a4d6a67136d6ec26c247

ASTERISK-18995 #close

Change-Id: I98518bd28fc8f95668b3fe27d2cab45045ff3f7a

Scenario: Caller blonde transfer
Bob calls Charlie who answers.
Bob puts Charlie on hold and calls Alice.
Before Alice answers, Bob transfers Charlie to Alice.

Charlie's channel triggers an assert because he gets an "ANSWERED"
event even though he never dialed anything. With recent changes to dial
events, this is now a valid scenario so the assert needed to be removed.

ASTERISK-26103 #close

Change-Id: I2679b517b696e7952ab7fb29403df9140e7d1de2

bridge_native_rtp can call into an RTP-capable channel driver in order
for the driver to update information about who the channel is
communicating with. For SIP channel drivers, this means deactivating
RTCP and sending a reinvite so that the endpoints can communicate
directly.

bridge_native_rtp does the right thing and has the channel locked when
calling into the channel driver. chan_pjsip can't alter session
properties in this thread, though. chan_pjsip queues a task on the
session serializer in order to update properties there.

The problem is that this queued task was not locking the channel. This
meant that the queued task could attempt to deactivate RTCP at the same
time that the channel thread was attempting to process an incoming RTCP
packet. This could lead to a crash.

This patch fixes the issue by locking the channel in the queued task
when altering RTP properties.

ASTERISK-26092 #close
Reported by Niklas Larsson

Change-Id: I3464e226a3c41f6b915f97891e07fa1599e2a159