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

Added to:
 * bridges/bridge_softmix.c
 * channels/chan_pjsip.c
 * include/asterisk/res_pjsip_session.h
 * main/channel.c
 * res/res_pjsip_session.c

There NO functional changes in this commit.

Change-Id: I06af034d1ff3ea1feb56596fd7bd6d7939dfdcc3

When both Asterisk and a UA send re-invites at the same time, both
send 491 "Transaction in progress" responses to each other and back
off a specified amount of time before retrying. When Asterisk
prepares to send its re-invite, it sets up the session's pending
media state with the new topology it wants, then sends the
re-invite.  Unfortunately, when it received the re-invite from the
UA, it partially processed the media in the re-invite and reset
the pending media state before sending the 491 losing the state it
set in its own re-invite.

Asterisk also was not tracking re-invites received while an existing
re-invite was queued resulting in sending stale SDP with missing
or duplicated streams, or no re-invite at all because we erroneously
determined that a re-invite wasn't needed.

There was also an issue in bridge_softmix where we were using a stream
from the wrong topology to determine if a stream was added.  This also
caused us to erroneously determine that a re-invite wasn't needed.

Regardless of how the delayed re-invite was triggered, we need to
reconcile the topology that was active at the time the delayed
request was queued, the pending topology of the queued request,
and the topology currently active on the session.  To do this we
need a topology resolver AND we need to make stream named unique
so we can accurately tell what a stream has been added or removed
and if we can re-use a slot in the topology.

Summary of changes:

 * bridge_softmix:
   * We no longer reset the stream name to "removed" in
     remove_all_original_streams().  That was causing  multiple streams
     to have the same name and wrecked the checks for duplicate streams.

   * softmix_bridge_stream_sources_update() was checking the old_stream
     to see if it had the softmix prefix and not considering the stream
     as "new" if it did.  If the stream in that slot has something in it
     because another re-invite happened, then that slot in old might
     have a softmix stream but the same stream in new might actually
     be a new one.  Now we check the new_stream's name instead of
     the old_stream's.

 * stream:
   * Instead of using plain media type name ("audio", "video", etc) as
     the default stream name, we now append the stream position to it
     to make it unique.  We need to do this so we can distinguish multiple
     streams of the same type from each other.

   * When we set a stream's state to REMOVED, we no longer reset its
     name to "removed" or destroy its metadata.  Again, we need to
     do this so we can distinguish multiple streams of the same
     type from each other.

 * res_pjsip_session:
   * Added resolve_refresh_media_states() that takes in 3 media states
     and creates an up-to-date pending media state that includes the changes
     that might have happened while a delayed session refresh was in the
     delayed queue.

   * Added is_media_state_valid() that checks the consistency of
     a media state and returns a true/false value. A valid state has:
     * The same number of stream entries as media session entries.
         Some media session entries can be NULL however.
     * No duplicate streams.
     * A valid stream for each non-NULL media session.
     * A stream that matches each media session's stream_num
       and media type.

   * Updated handle_incoming_sdp() to set the stream name to include the
     stream position number in the name to make it unique.

   * Updated the ast_sip_session_delayed_request structure to include both
     the pending and active media states and updated the associated delay
     functions to process them.

   * Updated sip_session_refresh() to accept both the pending and active
     media states that were in effect when the request was originally queued
     and to pass them on should the request need to be delayed again.

   * Updated sip_session_refresh() to call resolve_refresh_media_states()
     and substitute its results for the pending state passed in.

   * Updated sip_session_refresh() with additional debugging.

   * Updated session_reinvite_on_rx_request() to simply return PJ_FALSE
     to pjproject if a transaction is in progress.  This stops us from
     creating a partial pending media state that would be invalid later on.

   * Updated reschedule_reinvite() to clone both the current pending and
     active media states and pass them to delay_request() so the resolver
     can tell what the original intention of the re-invite was.

   * Added a large unit test for the resolver.

ASTERISK-29014

Change-Id: Id3440972943c611a15f652c6c569fa0e4536bfcb

Currently, the ps_contacts table's reg_server column in realtime database type is varchar(20).
This is fine for normal cases, but if the hostname is longer than 20, it returns error and then
failed to register the contact address of the peer.

Normally, 20 characters limitation for the hostname is fine, but with the cloud env.
So, increased the size to 255.

ASTERISK-29056

Change-Id: Iac52c8c35030303cfa551bb39f410b33bffc507d

Currently, it was not possible to create bridge with video_mode single.
This made hard to put the bridge in a vidoe_single mode.
So, added video_single option for Bridge creation using the ARI.
This allows create a bridge with video_mode single.

ASTERISK-29055

Change-Id: I43e720e5c83fc75fafe10fe22808ae7f055da2ae

There's a race condition with bridging where a bridge can be torn down
causing the bridge_channel's ast_channel to become NULL when it's still
needed. This particular case happened with attended transfers, but the
crash occurred when trying to publish a stasis message. Now, the
bridge_channel is locked, a ref to the ast_channel is obtained, and that
ref is passed down the chain.

Change-Id: Ic48715c0c041615d17d286790ae3e8c61bb28814

Building on ASTERISK-25854. When the device requests hold by sending SDP with attribute recvonly, asterisk places the session in sendonly mode. When the device later requests to resume the call by using a re-INVITE excluding SDP, asterisk needs to change the sendonly mode to sendrecv again.

Change-Id: I60341ce3d87f95869f3bc6dc358bd3e8286477a6

Change-Id: Id603b0b03b78eb84c7fca030a08b343c0d5973f9

This fixes a bug introduced mistakenly in ASTERISK-25665:
If leave-empty is enabled, a call may sometimes be removed from
a queue without recording it as abandoned.
This causes Asterisk to not generate an abandon event for that
call, and for the queue abandoned counter to be incorrect.

ASTERISK-29043 #close

Change-Id: I1a71b81df78adff59af587f1d8483cf57df430c7

If you run ast_coredumper --tarball-coredumps in the same directory
as the actual coredump, tar can fail because the link to the
actual coredump becomes recursive.  The resulting tarball will
have everything _except_ the coredump (which is usually what
you need)

There's also an issue that the directory name in the tarball
is the same as the coredump so if you extract the tarball the
directory it creates will overwrite the coredump.

So:

 * Made the link to the coredump use the absolute path to the
   file instead of a relative one.  This prevents the recursive
   link and allows tar to add the coredump.

 * The tarballed directory is now named <coredump>.output instead
   of just <coredump> so if you expand the tarball it won't
   overwrite the coredump.

Change-Id: I8b3eeb26e09a577c702ff966924bb0a2f9a759ea