When doing an attended transfer it's possible for the transferer, after
receiving an accepted response from Asterisk, to send a BYE to Asterisk,
which can then be processed before Asterisk has time to start and/or
complete the transfer process. This of course causes the transfer to not
complete successfully, thus dropping the call.

This patch makes it so any BYEs received from the transferer, after the REFER,
that initiate a session end are deferred until the transfer is complete. This
allows the channel that would have otherwise been hung up by Asterisk to
remain available throughout the transfer process.

ASTERISK-27053 #close

Change-Id: I43586db79079457d92d71f1fd993be9a3b409d5a

Reported by Sylvain Boily via asterisk-dev mailing list.

Change-Id: Idc7623f335aea3e144dd369ba383b9a757480a9d

Add some #if defined checks which allow building against LibreSSL.
These patchess come from OpenBSD ports:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/telephony/asterisk/patches/

ASTERISK-27043 #close
Reported by: OpenBSD ports

Change-Id: I2f6c08a5840b85ad4d2b75370b947ddde7a9a572

FreeBSD does not include a crypt.h include file. Definitions for
crypt() and crypt_r() are in unistd.h

ASTERISK-27042 #close

Change-Id: Ib307ee5e384870c6af50efa89fb73722dd0c3a7e

The chan_pjsip module uses a calculation approach for
determining device state. This means that in situations
where we would expect device state to change we need to
tell the core to query. A scenario that was missed is
when early media was signaled.

This change adds the notification for the core to
query device state when we are told that early media
is being provided.

ASTERISK-27039

Change-Id: Iafebfd152894966344ff2e950a3cee9f59a3eb6f

Reported by Lonnie Abelbeck <lonnie@abelbeck.com> via private e-mail.

Change-Id: Icc80f12b8d8d591e14a8e0ed9f1c02cbd193a89b

Change-Id: If4817d26a8974610827624fb8a4e56d681d6bf97

PJSIP support in Asterisk differs from chan_sip in that it
allows media to be sent as-is without transcoding provided
the codecs were negotiated in the SDP. This is allowed
according to the RFC. Support for this differs quite a lot
though and some endpoints do not handle it well.

This change extends the 'asymmetric_rtp_codec' option to
also cover this case. When set to no (the default) the code
behaves as chan_sip does - the best codec is selected and
we will only ever send that, unless we change what we are
sending if the remote side changes. When set to yes we
will send media as-is without transcoding if the codec
has been negotiated in the SDP.

ASTERISK-26996

Change-Id: Ib1647f6902a0843e8c435946f831c2159e8d1d51

When a frame destined for a MulticastRTP channel does not have timing
information (such as when an 'originate' is done), we generate the RTP
timestamps ourselves without regard to the number of samples we are
about to send.

Instead, use the same method as res_rtp_asterisk and 'predict' a
timestamp given the number of samples. If the difference between the
timestamp that we generate and the one we predict is within a specific
threshold, use the predicted timestamp so that we end up with timestamps
that are consistent with the number of samples we are actually sending.

Change-Id: I2bf0db3541b1573043330421cbb114ff0f22ec1f

This introduces the ability for PJSIP code to specify filtering flags
when retrieving PJSIP contacts. The first flag for use causes the
query code to only retrieve contacts that are not unreachable. This
change has been leveraged by both the Dial() process and the
PJSIP_DIAL_CONTACTS dialplan function so they will now only attempt
calls to contacts which are not unreachable.

ASTERISK-26281

Change-Id: I8233b4faa21ba3db114f5a42e946e4b191446f6c

ASTERISK-26419 introduced a bug when calling ast_audiohook_write_list in
ast_write. It would free the frame given to ast_write if the frame returned
by ast_audiohook_write_list was different than the given one. The frame give
to ast_write should never be freed within that function. It is the caller's
resposibility to free the frame after writing (or when it its done with it).
By freeing it within ast_write this of course led to some memory corruption
problems.

This patch makes it so the frame given to ast_write is no longer freed within
the function. The frame returned by ast_audiohook_write_list is now subsequently
used in ast_write and is freed later. It is freed either after translate if the
frame returned by translate is different, or near the end of ast_write prior to
function exit.

ASTERISK-26973 #close

Change-Id: Ic9085ba5f555eeed12f6e565a638c3649695988b

Before this patch, when a user hung up during a Background, we would
stuff 0xff into a char and attempt a dialplan lookup of it. This caused
problems for some realtime engines which interpreted the value as the
beginning of an invalid UTF-8 sequence.

ASTERISK-19291 #close
Reported by: Andrew Nowrot

Change-Id: I8ca6da93252d61c76ebdb46a4aa65e73ca985358

ASTERISK-27025

Change-Id: Id736b0aa4ec6b6b0f04663d64fa8d151f81fdbed

ASTERISK-27021 #close
Reported by: Tim Morgan

Change-Id: I0ac061f040093e806c3b1f4e2340864f3ce4dd75

In review 4843 (ASTERISK-24858), we added a hack that forced a smoother
creation when sending signed linear so that the byte order was adjusted
during transmission. This was needed because smoother flags were lost
during the new format work that was done in Asterisk 13.

Rather than rolling that same hack into res_rtp_multicast, re-introduce
smoother flags so that formats can dictate their own options.

Change-Id: I77b835fba0e539c6ce50014a984766f63cab2c16

A previous commit added plumbing to bridge_softmix to allow for an SFU
experience with Asterisk. This commit adds an option to app_confbridge
that allows for a confbridge to actually make use of the SFU video mode.

SFU mode is implemented in a "set it and forget it" kind of way. That
is, when the bridge is created, if SFU mode is enabled, then the video
mode gets set to SFU and cannot be changed. Future improvements may
allow for a hybrid experience (e.g. forward multiple video streams,
specifically those of the most recent talkers), but for this addition,
no such capability is present.

Change-Id: I87bbcb63dec6dbbb42488f894871b86f112b2020

This sets up the "plumbing" in bridge_softmix to
be able to accommodate Asterisk asking as an SFU
(selective forwarding unit) for conferences.

The way this works is that whenever a channel enters or leaves a
conference, all participants in the bridge get sent a stream topology
change request. The topologies consist of the channels' original
topology, along with video destination streams corresponding to each
participants' source video streams. So for instance, if Alice, Bob, and
Carol are in the conference, and each supplies one video stream, then
the topologies for each would look like so:

Alice:
Audio,
Source video(Alice),
Destination Video(Bob),
Destination video (Carol)

Bob:
Audio,
Source video(Bob)
Destination Video(Alice),
Destination video (Carol)

Carol:
Audio,
Source video(Carol)
Destination Video(Alice),
Destination video (Bob)

This way, video that arrives from a source video stream can then be
copied out to the destination video streams on the other participants'
channels.

Once the bridge gets told that a topology on a channel has changed, the
bridge constructs a map in order to get the video frames routed to the
proper destination streams. This is done using the bridge channel's
stream_map.

This change is bare-bones with regards to SFU support. Some key features
are missing at this point:

* Stream limits. This commit makes no effort to limit the number of
  streams on a specific channel. This means that if there were 50 video
  callers in a conference, bridge_softmix will happily send out topology
  change requests to every channel in the bridge, requesting 50+
  streams.

* Configuration. The plumbing has been added to bridge_softmix, but
  there has been nothing added as of yet to app_confbridge to enable SFU
  video mode.

* Testing. Some functions included here have unit tests.
  However, the functionality as a whole has only been verified by
  hand-tracing the code.

* Selectivenss. For a "selective" forwarding unit, this does not
  currently have any means of being selective.

* Features. Presumably, someone might wish to only receive video from
  specific sources. There are no external-facing functions at the moment
  that allow for users to select who they receive video from.

* Efficiency. The current scheme treats all video streams as being
  unidirectional. We could be re-using a source video stream as a
  desetnation, too. But to simplify things on this first round, I did it
  this way.

Change-Id: I7c44a829cc63acf8b596a337b2dc3c13898a6c4d

Rather than removing format_mp3 from ALL_C_MODS (which caused format_mp3
to not show up in menuselect), use .PHONY targets when the necessary
source files are not present.

ASTERISK-23951
Reported by: Tzafrir Cohen

Change-Id: I0a7512c51acc9e86043671795020b0de725bd9e8

Some of the test names were actually reserved words (true, false,
int, null, string, bool).  When the jenkins test results analyzer
does its thing it tries to create a map using the test names as
keys and fails because they're reserved words.

Added "type_" to those test names.

Change-Id: I90d809f46969c78a1c605b736ff0635196a2cf1b

During the channel flag audit an incorrect change was
done. The flag should be cleared on the second channel.

ASTERISK-26469

Change-Id: I770c5a389550a2fb5a6ade942fccbb2e1d9199c8