The PBX core maintains two hash tables for hints: a container of the
actual hints (hints), along with a container of devices that are watching that
hint (hintdevices). When a dialplan reload occurs, each hint in the hints
container is destroyed; this requires a lookup in the container of devices to
find the device => hint mapping object. In the current code, this performs an
ao2_callback, iterating over each of the device to hint objects in the
hintdevices container. For a large number of hints, this is extremely
expensive: dialplan reloads with 20000 hints could take several minutes
in just this phase.

This patch improves the performance of this step in the dialplan reloads
by caching which devices are watching a hint on the hint object itself.
Since we don't want to create a circular reference, we just cache the
name of the device. This allows us to perform a smarter ao2_callback on
the hintdevices container during hint removal, hashing on the name of the
device and returning an iterator to the matching names. The overall
performance improvement is rather large, taking this step down to a number of
seconds as opposed to minutes.

In addition, this patch also registers the hint containers in the PBX
core with the astobj2 library. This allows for reasonable debugging to
hash collisions in those containers.

ASTERISK-25040 #close
Reported by: Matt Jordan

Change-Id: Iedfc97a69d21070c50fca42275d7b3e714e59360

The sample pjsip.conf has a few comment lines that are missing the
semicolons at the start of the comment, causing the config to fail
load.

Change-Id: I776a38c916a7df7ee3e072fd0b21dbf4cc457352

Scenario:
Alice calls Bob. Bob performs a blond transfer to Carol. Carol rejects
the incoming call (or some other immediate circumstance causes Carol not
to answer the call)

What occurs in this case is that when the bridge between Alice and Bob
breaks, Alice is told to masquerade into Bob's channel that had placed
the call to Carol. The actual masquerade goes down without a hitch.
However, a channel fixup callback that attempts to publish dial events
over Stasis has a crash. The reason for this crash is that the datastore
on Bob's channel that placed the outbound call to Carol only had a bare
pointer to Carol's channel. Since Carol rejected the incoming call,
Carol's channel has been hung up and freed, meaning accessing her
channel results in a crash.

The fix here is simple. The dial fixup code has been altered to hold
references to the involved channels and to drop those references when
freeing data.

ASTERISK-25025 #close
Reported by Chet Stevens

Change-Id: I54eedda207b8ec7a69263353b43abe5746aea197

The build system now scans additional sources when generating
moduleinfo for menuselect.  Unfortunately the extra sources
for format_mp3 only exist if downloaded.

Use the Makefile macro 'wildcard' to allow moduleinfo generator
to ignore sources that do not exist.

Change-Id: I596604713b7345ce994f32197f8f6bfd9bcf4170

The res_ari_device_states module depends on res_stasis_device_state,
not res_stasis_device_states.

Change-Id: I26e02ad37f9e36bcc859867e2fad1b90452ec3de

Some telco switches occasionally ignore ISDN RESTART requests.  The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request.  If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco.  The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.

chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code.  Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards.  I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.

* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.

ASTERISK-25034 #close
Reported by: Richard Mudgett

Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65

When the PJSIP pjsip_regc_send function is invoked and an error
status returned the caller currently decrements the reference count
of the client state that it just incremented, assuming the
registration callback would not have been invoked. In practice
this is not correct. If the failure happens after the transaction
has been set up the callback will still be invoked. This will
cause the reference count to be incorrectly decremented twice, once
by the registration callback and second by the caller of
pjsip_regc_send.

This change makes it so that whether the callback is invoked or
not is known by the caller of pjsip_regc_send. Depending on
this it can know whether it is responsible for decrementing the
reference count of the client state or not.

ASTERISK-25037 #close
Reported by: Joshua Colp

Change-Id: I749dc12f3a22115c49c5d7d95ff42a5fa45319de

The patch in 0b6410c4 did correctly fix a memory leak of the DTLS
structures in the RTP engine. However, when a 'core reload' is issued, a
double free of the memory pointed to by the char *'s in the DTLS
configuration struct can occur, as ast_rtp_dtls_cfg_free does not set
the pointers to NULL when they are freed.

This patch sets those pointers to NULL, preventing a second call to
ast_rtp_dtls_cfg_free from corrupting memory.

ASTERISK-25022

Change-Id: I820471e6070a37e3c26f760118c86770e12f6115

A previous set of patches (see: ASTERISK-22790 & ASTERISK-23231) made it so
a v.27 modem was not allowed to have a minimum transmission rate of 2400 bits
per second. This reverts all or some of those patches since according to the
v.27ter standard a rate of 2400 bits per second is also supported.

One of the original patches also added 9600 bits per second support for v.27.
This patch also removes that since v.27ter only supports 2400/4800 bits per
second.

Also, since Asterisk specifically supports v.27ter the enum was renamed to
better reflect this.

ASTERISK-24955 #close
Reported by: Matt Jordan

Change-Id: I4b9dfb6bf7eff08463ab47ee1a74224f27cae733

This function allows code to run ao2_ref against the real
object associated with a weakproxy.  It is useful when
all of the following conditions are true:
* You have a pointer to weakproxy.
* You do not have or need a pointer to the real object.
* You need to ensure the real object exists and is not
  destroyed during a process.

In this case it's wasteful to store a pointer to the real
object just for the sake of releasing it later.

Change-Id: I38a319b83314de75be74207a8771aab269bcca46

Odd behaviors have been observed during outbound registrations. The most
common problem witnessed has been one where a request with
authentication credentials cannot be created after receiving a 401
response. Other behaviors include apparently processing an incorrect SIP
response.

Inspecting the code led to an apparent issue with regards to how we
handle transactions in outbound registration code. When a response to a
REGISTER arrives, we save a pointer to the transaction and then push a
task onto the registration serializer. Between the time that we save the
pointer and push the task, it's possible for the transaction to be
destroyed due to a timeout. It's also possible for the address to be
reused by the transaction layer for a new transaction.

To allow for authentication of a REGISTER request to be authenticated
after the transaction has timed out, we now hold a reference to the
original REGISTER request instead of the transaction. The function for
creating a request with authentication has been altered to take the
original request instead of the transaction where the original request
was sent.

ASTERISK-25020
Reported by Mark Michelson

Change-Id: I756c19ab05ada5d0503175db9676acf87c686d0a

Change-Id: Ic8322f04e37842848ad72cf2871bd0378f67c4ac

Merge "chan_pjsip: Creating Channel Causes Asterisk to Crash When Duplicate AOR             Sections Exist in pjsip.conf"

* changes:
  res_pjsip: Remove incorrect MODULEINFO from presence_xml.c.
  Git Migration: Create doc/rest-api when needed.

ARI modules that are generated by 'make ari-stubs' are all dependent on
res_ari_model.  Additionally some of the same modules depend on one or more
res_stasis_* modules.

ASTERISK-25027 #close
Reported by: Corey Farrell

Change-Id: I8e07fe7e81fedacb87232f2b6f8b5f47927b4153

Remove incorrect MODULEINFO block and unneeded header includes
from presence_xml.c.

ASTERISK-25027
Reported by: Corey Farrell

Change-Id: I977c609ab9d1fe05373027c4138900f6985990eb

Create the directory './doc/rest-api' at the start of 'make ari-stubs'
to prevent an error when documentation is generated.  The directory is
also added to git ignores.

ASTERISK-25027
Reported by: Corey Farrell

Change-Id: Iaccc7f0138501c23aa78feaca2f3cce9e68cbc1b

* Add AST_DEVMODE to BUILDOPTS
* Use BUILDOPTS to generate AST_BUILDOPT_SUM.
* Remove loop that defined AST_MODULE_*

These changes ensure that only ABI effecting options are considered for
AST_BUILDOPT_SUM.  This also reduces unneeded full system rebuilds caused
by enabling or disabling one module that another is dependent on.

ASTERISK-25028 #close
Reported by: Corey Farrell

Change-Id: I2c516d93df9f6aaa09ae079a8168c887a6ff93a2

This switches files used to generate other sources to use the new
ASTERISK_REGISTER_FILE macro.

ASTERISK-25026 #close
Reported by: Corey Farrell

Change-Id: Ieb2537b83421cad07c8955e5f90c405ccf079740

Flags are 64 bits.  Without LLU suffix the value of 1<<31 is negative.
Although it doesn't have an effect on the current implementation, it will
be problem if more flags are added.

Change-Id: Ic290c81cfbbbf062872392d99d3322932cc49487

            Sections Exist in pjsip.conf

This patch modifies the current loading strategy of the pjsip configuration. If
duplicate sections (e.g. sections containing the same [id/type]) are defined in
[pjsip.conf], the loader will consider the configuration for the given type as
invalid when the duplicate section is encountered. The entire configuration
(including what was previously loaded) for the duplicate [id/type] sections
will be rejected and destroyed, an error message is logged and the load
processing for the given stops.

ASTERISK-24996
Reported By: Ashley Sanders

Change-Id: I35090ca4cd40f1f34881dfe701a329145c347aef

Change-Id: I51179e2a83937423676da522b766f1126de4059e

When problems occur regarding outbound registrations, it currently
is difficult to debug. Most off-nominal paths had warning messages,
but sometimes we want to know what's going on before hitting the
off-nominal path. This patch adds lots of debugging output that
should give a clearer picture of what is happening with regards
to outbound registrations.

ASTERISK-25020
Reported by Mark Michelson

Change-Id: I577bde7860be0a6c872b5bcb4d5047340bf45d45

ao2 ref leak in res_rtp_asterisk.c when a DTLS policy is created.
The resources are linked into a table, but the original alloc refs
are never released. ast_strdup leak in rtp_engine.c. If
ast_rtp_dtls_cfg_copy() is called twice on the same destination struct,
a pointer to an alloc'd string is overwritten before the string is free'd.

ASTERISK-25022
Reported by: one47

Change-Id: I62a8ceb8679709f6c3769136dc6aa9a68202ff9b