By default Asterisk reports the PJSIP version in a SOFTWARE attribute
of every STUN packet it sends. This may not be desired in a production
environment, and RFC5389 recommends making the use of the SOFTWARE
attribute a configurable option:

https://datatracker.ietf.org/doc/html/rfc5389#section-16.1.2

This patch adds a `stun_software_attribute` yes/no option to make it
possible to omit the SOFTWARE attribute from STUN packets.

ASTERISK-29434

Change-Id: Id3f2b1dd9584536ebb3a1d7e8395fd8b3e46860b

RFC7616 and RFC8760 allow more than one WWW-Authenticate or
Proxy-Authenticate header per realm, each with different digest
algorithms (including new ones like SHA-256 and SHA-512-256).
Thankfully however a UAS can NOT send back multiple Authenticate
headers for the same realm with the same digest algorithm.  The
UAS is also supposed to send the headers in order of preference
with the first one being the most preferred.  We're supposed to
send an Authorization header for the first one we encounter for a
realm that we can support.

The UAS can also send multiple realms, especially when it's a
proxy that has forked the request in which case the proxy will
aggregate all of the Authenticate headers and then send them all
back to the UAC.

It doesn't stop there though... Each realm can require a
different username from the others.  There's also nothing
preventing each digest algorithm from having a unique password
although I'm not sure if that adds any benefit.

So now... For each Authenticate header we encounter, we have to
determine if we support the digest algorithm and, if not, just
skip the header.  We then have to find an auth object that
matches the realm AND the digest algorithm or find a wildcard
object that matches the digest algorithm. If we find one, we add
it to the results vector and read the next Authenticate header.
If the next header is for the same realm AND we already added an
auth object for that realm, we skip the header. Otherwise we
repeat the process for the next header.

In the end, we'll have accumulated a list of credentials we can
pass to pjproject that it can use to add Authentication headers
to a request.

NOTE: Neither we nor pjproject can currently handle digest
algorithms other than MD5.  We don't even have a place for it in
the ast_sip_auth object. For this reason, we just skip processing
any Authenticate header that's not MD5.  When we support the
others, we'll move the check into the loop that searches the
objects.

Changes:

 * Added a new API ast_sip_retrieve_auths_vector() that takes in
   a vector of auth ids (usually supplied on a call to
   ast_sip_create_request_with_auth()) and populates another
   vector with the actual objects.

 * Refactored res_pjsip_outbound_authenticator_digest to handle
   multiple Authenticate headers and set the stage for handling
   additional digest algorithms.

 * Added a pjproject patch that allows them to ignore digest
   algorithms they don't support.  This patch has already been
   merged upstream.

 * Updated documentation for auth objects in the XML and
   in pjsip.conf.sample.

 * Although res_pjsip_authenticator_digest isn't affected
   by this change, some debugging and a testsuite AMI event
   was added to facilitate testing.

Discovered during OpenSIPit 2021.

ASTERISK-29397

Change-Id: I3aef5ce4fe1d27e48d61268520f284d15d650281

RFC 4235 Section 4.1.6 describes XML elements that should be
sent to subscribed endpoints to identify the local and remote
participants in the dialog.

This patch adds this functionality to PJSIP by iterating through the
ringing channels causing the NOTIFY, and inserts the channel info
into the dialog so that information is properly passed to the endpoint
in dialog-info+xml.

ASTERISK-24601
Patch submitted: Joshua Elson
Modified by: Joseph Nadiv and Sean Bright
Tested by: Joseph Nadiv

Change-Id: I20c5cf5b45f34d7179df6573c5abf863eb72964b

Hitherto, VoiceMail() played a non-customizable beep tone to indicate
the caller could leave a message. In some cases, the beep may not
be desired, or a different tone may be desired.

To increase flexibility, a new option allows customization of the tone.
If the t option is specified, the default beep will be overridden.
Supplying an argument will cause it to use the specified file for the tone,
and omitting it will cause it to skip the beep altogether. If the option
is not used, the default behavior persists.

ASTERISK-29349

Change-Id: I1c439c0011497e28a28067fc1cf1e654c8843280

Although Asterisk can receive and propogate flash events, it currently
provides no mechanism for doing anything with them itself.

This AMI event allows flash events to be processed by Asterisk.
Additionally, AST_CONTROL_FLASH is included in a switch statement
in channel.c to avoid throwing a warning when we shouldn't.

ASTERISK-29380

Change-Id: Ie17ffe65086e0282c88542e38eed6a461ec79e81

Some ATAs send hook flash events as application/hook-flash, rather than a DTMF
event. Now, we also recognize hook-flash as a flash event.

ASTERISK-29370

Change-Id: I1c3b82a040dff3affcd94bad8ce33edc90c04725

In some cases it was possible for a STUN packet to be destroyed
prematurely or even destroyed partially multiple times.

This patch provided by Teluu fixes the lifetime of these
packets and ensures they aren't partially destroyed multiple
times.

https://github.com/pjsip/pjproject/pull/2709

ASTERISK-29377

Change-Id: Ie842ad24ddf345e01c69a4d333023f05f787abca

AST_CONTROL_FLASH isn't accounted for in a switch statement in file.c
where it should be ignored. Adding this to the switch ensures a
warning isn't thrown on RFC2833 flash events, since nothing's amiss.

ASTERISK-29372

Change-Id: I4fa549bfb7ba1894a4044de999ea124877422fbc

ASTERISK-29358 #close

Change-Id: I050daff67066873df4e8fc7f4bd977c1ca06e647

STIR/SHAKEN encodes using base64 URL format. Currently, we just use
base64. New functions have been added that convert to and from base64
encoding.

The origid field should also be an UUID. This means there's no reason to
have it as an option in stir_shaken.conf, as we can simply generate one
when creating the Identity header.

https://wiki.asterisk.org/wiki/display/AST/OpenSIPit+2021

Change-Id: Icf094a2a54e87db91d6b12244c9f5ba4fc2e0b8c

We're getting the serial number of the certificate from openssl and
freeing it with ast_free(), but it needs to be freed with OPENSSL_free()
instead. Now we duplicate the string and free the one from openssl with
OPENSSL_free(), which means we can still use ast_free() on the returned
string.

https://wiki.asterisk.org/wiki/display/AST/OpenSIPit+2021

Change-Id: Ia6e1a4028c1933a0e1d204b769ebb9f5a11f00ab

During OpenSIPit, we found out that the public certificates must be of
type X.509. When reading in public keys, we use the corresponding X.509
functions now.

We also discovered that we needed a better naming scheme for the
certificates since certificates with the same name would cause issues
(overwriting certs, etc.). Now when we download a public certificate, we
get the serial number from it and use that as the name of the cached
certificate.

The configuration option public_key_url in stir_shaken.conf has also
been renamed to public_cert_url, which better describes what the option
is for.

https://wiki.asterisk.org/wiki/display/AST/OpenSIPit+2021

Change-Id: Ia00b20835f5f976e3603797f2f2fb19672d8114d

Enhancements:

 * The MessageSend dialplan application now takes an optional
   third argument that can set the message's "To" field on
   outgoing messages.  It's an alternative to using the
   MESSAGE(to) dialplan function.

   NOTE: No channel driver currently implements this field.  A
   follow-on commit for res_pjsip_messaging will implement it for
   the chan_pjsip channel driver.

 * To prevent confusion with the first argument, currently named
   "to", it's been renamed to "destination". Its function,
   creating the request URI, hasn't changed.

 * The documentation for MessageSend was updated to be
   more clear about the parameters and how they interact
   the MESSAGE() dialplan function.

 * With the rename of MessageSend's first parameter, and the fact
   that message.c references <info> elements in chan_sip.c,
   res_pjsip_messaging.c and res_xmpp, they each needed
   documentation updates to use MessageDestinationInfo instead of
   MessageToInfo.

 * appdocsxml.dtd was updated to include a missing element
   declaration for "dataType".  This was showing up as an error
   in Eclipse's dtd editor.

 * Despite the changes in this commit, there should be
   no impact to current users of MessageSend.

Change-Id: I6fb5b569657a02866a66ea352fd53d30d8ac965a

Change-Id: Idbd61ff77545f4a78b06a5064b55112e774b70e6

When a stream topology is provided to chan_local when dialing
it filters the audio formats down. This operation did not skip
streams which were removed (that have no formats) resulting in
calling being aborted.

This change causes such streams to be skipped.

ASTERISK-29407

Change-Id: I1de8b98727cb2d10f4bc287da0b5fdcb381addd6

We assume that a timestamp value of 0 represents an 'uninitialized'
timestamp, but 0 is a valid value. Add a simple wrapper to be able to
differentiate between whether the value is set or not.

This also removes the fix for ASTERISK~28812 which should not be
needed if we are checking the last timestamp appropriately.

ASTERISK-29030 #close

Change-Id: Ie70d657d580d9a1f2877e25a6ef161c5ad761cf7

ASTERISK-27477 #close

Change-Id: I68f6715bba92a525149e35d142a49377a34a1193

Up/down sampling changes the number of samples produced by a translation.
This must be taken into account when checking the codec's buffer size.

ASTERISK-29328

Change-Id: I9aebe2f8788e00321a7f5c47aa97c617f39e9055

Some versions of SVN seemingly don't follow the redirect
to https.

Change-Id: Ia7c76c18cb620bcf56f08e1211a7d80d321fe253

Change-Id: I2f76867ce02ec611964925159be099de83346e38

There is a possibility, when bridge_channel_write_frame() is
called, that the bridge_channel->chan will be NULL.  The first
thing bridge_channel_write_frame() does though is call
ast_channel_is_multistream() which had no check for a NULL
channel and therefore caused a segfault. Since it's still
possible for bridge_channel_write_frame() to write the frame to
the other channels in the bridge, we don't want to bail before we
call ast_channel_is_multistream() but we can just skip the
multi-channel stuff.  So...

bridge_channel_write_frame() only calls ast_channel_is_multistream()
if bridge_channel->chan is not NULL.

As a safety measure, ast_channel_is_multistream() now returns
false if the supplied channel is NULL.

ASTERISK-29379
Reported-by: Vyrva Igor
Reported-by: Ross Beer

Change-Id: Idfe62dbea8c69813ecfd58e113a6620dc42352ce

Only use an XPath query once per module, then just navigate the DOM for
everything else.

Change-Id: Ia0336a7185f9180ccba4b6f631a00f9a22a36e92

The channels, bridges and endpoints scrape functions were
grabbing their respective global containers, getting the
count of entries, allocating metric arrays based on
that count, then iterating over the container.  If the
global container had new objects added after the count
was taken and the metric arrays were allocated, we'd run
out of metric entries and attempt to write past the end
of the arrays.

Now each of the scape functions clone their respective
global containers and all operations are done on the
clone.  Since the clone is stable between getting the
count and iterating over it, we can't run past the end
of the metrics array.

ASTERISK-29130
Reported-By: Francisco Correia
Reported-By: BJ Weschke
Reported-By: Sébastien Duthil

Change-Id: If0c8e40853bc0e9429f2ba9c7f5f358d90c311af

Using the information from the MODULEINFO XML we can
now output useful information at the end of module
loading for deprecated modules. This includes the
version it was deprecated in, the version it will be
removed in, and the replacement if available.

ASTERISK-29339

Change-Id: I2080dab97d2186be94c421b41dabf6d79a11611a

For some input to the standard deviation algorithm extremely large,
and wrong numbers were being calculated.

This patch uses a new formula for correctly calculating both the
running mean and standard deviation for the given inputs.

ASTERISK-29364 #close

Change-Id: Ibc6e18be41c28bed3fde06d612607acc3fbd621f

The calculated minimum lost packets represents the lowest number of
lost packets missed during an RTCP report interval. Zero of course
is the lowest, but the idea is that this value contain the lowest
number of lost packets once some have been missed.

This patch checks to make sure the number of lost packets over an
interval is not zero before checking and setting the minimum value.

Also, this patch updates the rtp lost packet test to check for
packet loss over several reports vs one.

Change-Id: I07d6e21cec61e289c2326138d6bcbcb3c3d5e008

This patch makes the drop_packets_data object static.

Change-Id: If4f9b21fa0c47d41a35b6b05941d978efb4da87b

Flash in RTP is conveyed the same as DTMF, just with a
specific digit. In Asterisk however we do flash as a
single control frame.

This change makes it so that only on end do we provide
the flash control frame to the core. Previously we would
provide a flash control frame on both begin and end,
causing flash to work improperly.

ASTERISK-29373

Change-Id: I1accd9c6e859811336e670e698bd8bd124f33226

This patch makes it so when Asterisk is compiled in DEVMODE a CLI
command is available that allows someone to drop incoming RTP
packets. The command allows for dropping of packets once, or on a
timed interval (e.g. drop 10 packets every 5 seconds). A user can
also specify to drop packets by IP address.

Change-Id: I25fa7ae9bad6ed68e273bbcccf0ee51cae6e7024

Change-Id: I058af496021ff870ccec2d8cbade637b348ab80b

Added a TIME_UNIT enumeration, and a function that converts a
string to one of the enumerated values. Also, added functions
that create and initialize a timeval object using a specified
value, and unit type.

Change-Id: Ic31a1c3262a44f77a5ef78bfc85dcf69a8d47392

ASTERISK-28356 #close

Change-Id: I53a1bfdd3113d620bea88349019173a2f3f0ae39

I missed the changes in 18 and master in the previous review.

ASTERISK-24434 #close

Change-Id: Ieb132b2a998ce96daa9c9acf26535a974b895876

Change-Id: Iff0e713f2120d8dce8e1e26924b99ed17f9d9dff

ASTERISK-24631 #close

Change-Id: I8bf8776906a72ee02f24de6a85345940b9ff6b6f

Also removed the sample documentation, and some oddly-placed
documentation about the timeout argument to the Queue() application
itself. There is a large section on the timeout behavior below.

ASTERISK-26614 #close

Change-Id: I8f84e8304b50305b7c4cba2d9787a5d77c3a6217

The 'core' console (ie: asterisk -c) does read logger.conf and does
use the dateformat= option.

Whereas 'remote' consoles (ie: asterisk -r -T) does not read logger.conf
and uses a hard coded dateformat option for printing received verbose messages:
  main/logger.c: static char dateformat[256] = "%b %e %T"

This change will load logger.conf for each remote console session and
use the dateformat= option to set the per-line timestamp for verbose messages

Change-Id: I3ea10990dbd920e9f7ce8ff771bc65aa7f4ea8c1
ASTERISK-25358: #close
Reported-by: Igor Liferenko

ASTERISK-27542 #close

Change-Id: If0b9719380a25533d2aed1053cff845dc3a4854a

When the check for equal topologies was added to reschedule_reinvite()
it was assumed that both the pending and active media states would
actually have non-NULL topologies.  We since discovered this isn't
the case.

We now only test for equal topologies if both media states have
non-NULL topologies.  The logic had to be rearranged a bit to make
sure that we cloned the media states if their topologies were
non-NULL but weren't equal.

ASTERISK-29215

Change-Id: I61313cca7fc571144338aac826091791b87b6e17