pjproject returns the dialog locked and with a reference. However,
in Asterisk the method that handles this decrements the reference
and removes the lock prior to returning. This makes it possible,
under some circumstances, for another thread to free said dialog
before the thread that created it attempts to use it again. Of
course when the thread that created it tries to use a freed dialog
a crash can occur.

This patch makes it so Asterisk now returns the newly created
dialog both locked, and with an added reference. This allows the
caller to de-reference, and unlock the dialog when it is safe to
do so.

In the case of a new SIP Invite the lock, and reference are now
held for the entirety of the new invite handling process.
Otherwise it's possible for the dialog, or its dependent objects,
like the transaction, to disappear. For example if there is a TCP
transport error.

ASTERISK-29057 #close

Change-Id: I5ef645a47829596f402cf383dc02c629c618969e
(cherry picked from commit 6baa4b53)

If Asterisk sends out and INVITE and receives a challenge with a
different nonce value each time, it will continually send out INVITEs,
even if the call is hung up. The endpoint must be configured for
outbound authentication in order for this to occur. A limit has been set
on outbound INVITEs so that, once reached, Asterisk will stop sending
INVITEs and the transaction will terminate.

ASTERISK-29013

Change-Id: I2d001ca745b00ca8aa12030f2240cd72363b46f7

* Wildcards in #includes are now properly expanded

* Implement operators for Section class to allow sorting

ASTERISK-29142 #close

Change-Id: I9b9cd95f4cbe5c24506b75d17173c5aa1a83e5df

ASTERISK-29144

Change-Id: I2a72c072083b4492a223c6f9d73d21f4f424db62

ASTERISK-29146

Change-Id: Ib04bdad87d729f805f5fc620ef9952f58ea96d41

ASTERISK-29145

Change-Id: I9af705f2b9725c53141aef5d0ff512a1800f073c

RFC 8760 added new digest-access-authentication schemes. Testing
revealed that chan_sip does not pick MD5 if several schemes are offered
by the User Agent Server (UAS). This change does not implement any of
the new schemes like SHA-256. This change makes sure, MD5 is picked so
UAS with SHA-2 enabled, like the service www.linphone.org/freesip, can
still be used. This should have worked since day one because SIP/2.0
already envisioned several schemes (see RFC 3261 and its augmented BNF
for 'algorithm' which includes 'token' as third alternative; note: if
'algorithm' was not present, MD5 is still assumed even in RFC 7616).

Change-Id: I61ca0b1f74b5ec2b5f3062c2d661cafeaf597fcd

Version: gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Warning:
  say.c:2371:24: error: ‘%d’ directive output may be truncated writing
    between 1 and 11 bytes into a region of size 10
    [-Werror=format-truncation=]
  2371 |     snprintf(buf, 10, "%d", num);
  say.c:2371:23: note: directive argument in the range [-2147483648, 9]

That's not possible though, as the if() starts out checking for (num < 0),
making this Warning a false positive.

(Also replaced some else<TAB>if with else<SP>if while in the vicinity.)

Change-Id: Ic7a70120188c9aa525a6d70289385bfce878438a

This patch initializes a couple of local variables to some default values.
Interestingly, in the 'pj_status_t dlg_status' case the value not being
initialized caused memory to grow, and not be recovered, in the off nominal
path (at least on my machine).

Change-Id: I22ee65e1e1bff8efacea8a167c6c8428898523f7

Ubuntu 20.10 does not come with GMime 2.6. Ubuntu 16.04 LTS does not
come with GMime 3.0. aptitude ignores any missing package. Therefore,
it installs the correct package(s). However, in Ubuntu 18.04 LTS and
Ubuntu 20.04 LTS, both versions are installed alongside although only
one is really needed.

Change-Id: Ic58aa9f2e131d94671f286f17dbd61e1ccbabcb7

Note to maintainers: Lua 5.4, Lua 5.3, and Lua 5.2 have not been tested
at runtime with pbx_lua. Until then, use the lowest available version
of Lua, if you enabled the module pbx_lua at all.

Change-Id: Ie5270448b11fcb4e2a53d899e4fe7fea793ce7e0

Commit 44bb0858 ("debugging: Add enough
to choke a mule") accidentally removed calls to
ast_sip_message_apply_transport when it was attempting to just add
debugging code.

The kiss of death was saying that there were no functional changes in
the commit comment.

This makes outbound calls that use the 'flow' transport mechanism fail,
since this call is used to relay headers into the outbound INVITE
requests.

ASTERISK-29124 #close

Change-Id: I0f3e32c2e8ac415e30b1d29966d75a1546f0526a

ASTERISK-29136 #close

Change-Id: I3186536d65a50014c8da4780c9224919caa81440

Add missing comment mark from stock configuration.

ASTERISK-29123 #close

Change-Id: I4f94eb4544166bca8af4c17fd11edee3c6980620

This changes the outgoing offer call preference
default option to match the behavior of previous
versions of Asterisk.

The additional advanced codec negotiation options
have also been removed from the sample configuration
and marked as reserved for future functionality in
XML documentation.

The codec preference options have also been fixed to
enforce local codec configuration.

ASTERISK-29109

Change-Id: Iad19347bd5f3d89900c15ecddfebf5e20950a1c2

ASTERISK-28430 #close

Change-Id: Ib556b0a0c95cca939e956886214ec8d828d89606

When handling a send_message request to a non-existing endpoint, the response's
body is overriden and not properly freed.

ASTERISK-29108

Change-Id: Ie1d3d70065f80793445b60f5e4a7eb31b4b9c5c8

Added debug logging categories that allow a user to output debug
information based on a specified category. This lets the user limit,
and filter debug output to data relevant to a particular context,
or topic. For instance the following categories are now available for
debug logging purposes:

  dtls, dtls_packet, ice, rtcp, rtcp_packet, rtp, rtp_packet,
  stun, stun_packet

These debug categories can be enable/disable via an Asterisk CLI command.

While this overrides, and outputs debug data, core system debugging is
not affected by this patch. Statements still output at their appropriate
debug level. As well backwards compatibility has been maintained with
past debug groups that could be enabled using the CLI (e.g. rtpdebug,
stundebug, etc.).

ASTERISK-29054 #close

Change-Id: I6e6cb247bb1f01dbf34750b2cd98e5b5b41a1849

In the event that the desired extension already exists,
ast_add_extension2_lockopt() will free the 'data' it is passed before
returning an error, so we should not be freeing it ourselves.

Additionally, there were two places where ast_add_extension2_lockopt()
could return an error without also freeing the 'data' pointer, so we
add that.

ASTERISK-29097 #close

Change-Id: I904707aae55169feda050a5ed7c6793b53fe6eae

app_confbridge now has the ability to set the estimated bitrate on an
SFU bridge.  To use it, set a bridge profile's remb_behavior to "force"
and set remb_estimated_bitrate to a rate in bits per second.  The
remb_estimated_bitrate parameter is ignored if remb_behavior is something
other than "force".

Change-Id: Idce6464ff014a37ea3b82944452e56cc4d75ab0a

ASTERISK-26424 #close

Change-Id: I797ad0ed302d0b3d2c90543eff5b7207ed08ecf0

Stop advertising RFC2833 support on the rtp_engine when DTMF mode is
auto but no tel_event was found inside SDP file.

On an incoming call create_rtp will be called and when session->dtmf is
set to AST_SIP_DTMF_AUTO, the AST_RTP_PROPERTY_DTMF will be set without
looking at the SDP file.

Once get_codecs gets called we move the DTMF mode from RFC2833 to INBAND
but continued to advertise RFC2833 support.

This meant the native_rtp bridge would falsely consider the two channels
as compatible. In addition to changing the DTMF mode we now set or
remove the AST_RTP_PROPERTY_DTMF.

The property is checked in ast_rtp_dtmf_compatible and called by
native_rtp_bridge_compatible.

ASTERISK-29051 #close

Change-Id: I1e0c1e324598a437932c0b7836bcb626aba8e287

ASTERISK-29099

Change-Id: I45636679c0fb5a5f59114c8741626631a604e8a6

Check result of ast_translator_build_path against NULL before dereferencing.

ASTERISK-29091

Change-Id: Ia3538ea190bd371f70c9dd49984b021765691b29

Arming response to both AST_SIP_SESSION_BEFORE_REDIRECTING and
AST_SIP_SESSION_BEFORE_MEDIA causes 302 to to be handled twice,
resulting in to 181 being generated.

Change-Id: I866e5461564644ffb8a5e12b6f1330b50a7b63ab

Change-Id: I41e77a04e4a523f4ed61a7a20b738ffd42be441e

ASTERISK-28311 #close

Change-Id: Ib1ce8fc1a8752751f5bf3615c59245532dfd9aa2

When constructing a stream name based on the media type
and position the allocated name was not being freed
causing a leak.

Change-Id: I52510863b24a2f531f0a55b440bb2c81844029de

Because we use shared thread-local cURL instances, we need to ensure
that the state of the cURL instance is correct before each invocation.

In the case of custom headers, we were not resetting cURL's internal
HTTP header pointer which could result in a crash if subsequent
requests do not configure custom headers.

ASTERISK-29085 #close

Change-Id: I8b4ab34038156dfba613030a45f10e932d2e992d

Only track our sample offset if we are playing a non-announcement file,
otherwise we will skip that number of samples when we start playing the
first MoH file.

ASTERISK-24329 #close

Change-Id: Ib6b3c84fcaa1063889ab38ba7e7fc50050a3ccfc

The ast_sip_dialog_get_session function returns the session
with reference count increased. This was not taken into
account and was causing sessions to remain around when they
should not be.

ASTERISK-29089

Change-Id: I430fa721b0a824311a59effec6056e9ec528e3e8

Sometimes not play MOH on bridge.

ASTERISK-29081
Reported-by: Michal Hajek <michal.hajek@daktela.com>

Change-Id: I760c73e0c9be1d340303b5d1c18a00c4759e8232

ast_trace() was always emitting messages when it's level was set to -1
because it was ignoring scope_level.

Change-Id: I849c8f4f4613899c37f82be0202024e7d117e506

ASTERISK-29083 #close

Change-Id: I9ea25fba3ba8f63a47886894bd966e0f08d5e003

The module description needs to be on the same line as the
AST_MODULE_INFO or it is not parsed correctly.

Change-Id: I9ba11df1415369790e8656fcb527bb2749373c21

When a channel joins a bridge, we do topology change requests on all
existing channels to add the new participant to them.  However the
announcer channel will return an error because it doesn't support
topology in the first place.  Unfortunately, there doesn't seem to be a
reliable way to tell if the error is expected or not so the error is
ignored for all channels.  If the request fails on a "real" channel,
that channel just won't get the new participant's video.

Change-Id: Ic95db4683f27d224c1869fe887795d6b9fdea4f0

Change-Id: Id4852c26e9c412af8e37b5dd3c15da9453ad3276

Implemention of History-Info capable of interworking with Diversion
Header following RFC7544

ASTERISK-29027 #close

Change-Id: I2296369582d4b295c5ea1e60bec391dd1d318fa6

ASTERISK-28416 #close

Change-Id: I069420875ebdbcaada52d92599a5f7de3cb2cdf4

The recent 491 changes introduced a check to determine if the active
and pending topologies were equal and to suppress the re-invite if they
were. When a re-invite is sent for a COLP-only change, the pending
topology is NULL so that check doesn't happen and the re-invite is
correctly sent. Of course, sending the re-invite sets the pending
topology.  If a 491 is received, when we resend the re-invite, the
pending topology is set and since we didn't request a change to the
topology in the first place, pending and active topologies are equal so
the topologies-equal check causes the re-invite to be erroneously
suppressed.

This change checks if the topologies are equal before we run the media
state resolver (which recreates the pending topology) so that when we
do the final topologies-equal check we know if this was a topology
change request.  If it wasn't a change request, we don't suppress
the re-invite even though the topologies are equal.

ASTERISK-29014

Change-Id: Iffd7dd0500301156a566119ebde528d1a9573314