When unsubscribing from an endpoint technology a FRACK
would occur due to incorrect reference counting. This fixes
that issue, along with some other issues.

Fixed a typo in get_subscription when calling ao2_find as it
needed to pass the endpoint ID and not the entire object.

Fixed scenario where a subscription would get returned when
it shouldn't have been when searching based on endpoint
technology.

A doulbe unreference has also been resolved by only explicitly
releasing the reference held by tech_subscriptions.

ASTERISK-28237 #close
Reported by: Lucas Tardioli Silveira

Change-Id: Ia91b15f8e5ea68f850c66889a6325d9575901729

In multidomain environments, it is desirable to create
PJSIP endpoints with the domain info in the endpoint name
in pjsip_endpoint.conf.  This resulted in an error with
registrations, NOTIFY, and OPTIONS packet generation.

This commit will detect if there is an @ in the endpoint
identifier and generate the URI accordingly so NOTIFY and
OPTIONS From headers will generate correctly.

ASTERISK-28393

Change-Id: I96f8d01dfdd5573ba7a28299e46271dd4210b619

RTCP ICE candidates use a base address derived from the RTP
candidate. The port on the base address was not being updated to
the RTCP port.

This change sets the base port to the RTCP port and all is well.

ASTERISK-29433

Change-Id: Ide2d2115b307bfd3c2dfbc4d187515d724519040

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

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

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

Change-Id: I2f76867ce02ec611964925159be099de83346e38

Added support for a basic AEAP configuration read from aeap.conf.
Also added 2 CLI commands for showing individual configurations as
well as all of them: aeap show server <id> and aeap show servers.

Only one configuration option is required at the moment, and that one is
server_url. It must be a websocket URL. The other option, codecs, is
optional and will be used over the codecs specified on the endpoint if
provided.

https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=45482453

Change-Id: I567ac5148c92b98d29d2ad83421b416b75ffdaa3

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

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

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

Some configuration items for a transport do not result in
the underlying transport changing, but instead are just
state we keep ourselves and use. It is perfectly reasonable
to change these items.

These include local_net and external_* information.

ASTERISK-29354

Change-Id: I027857ccfe4419f460243e562b5f098434b3d43a

When an SSRC change occurs the timestamps are likely
to change as well. As a result we need to reset the
timestamp mapping done in the calc_rxstamp function
so that they map properly from timestamp to real
time.

This previously occurred but due to packet
retransmission support the explicit setting
of the marker bit was not effective.

ASTERISK-29352

Change-Id: I2d4c8f93ea24abc1030196706de2d70facf05a5a

This change embeds the MODULEINFO block of modules
into the core XML documentation. This provides a shared
mechanism for use by both menuselect and Asterisk for
information and a definitive source of truth.

ASTERISK-29335

Change-Id: Ifbfd5c700049cf320a3e45351ac65dd89bc99d90

Some modules have a different support level documented in their
MODULEINFO XML and Asterisk module definition. This change
brings the two in sync for the modules which were not matching.

ASTERISK-29336

Change-Id: If2f819103d4a271e2e0624ef4db365e897fa3d35

Change-Id: I75152cece8a00b7523d542e5ac22796f9595692b
Signed-off-by: Jaco Kroon <jaco@uls.co.za>

see RFC 4855:
parameter names are case-insensitive both in media type strings and
in the default mapping to the SDP a=fmtp attribute.

This change is required for H.263+ because some implementations are
known to use even mixed-case. This does not fix ASTERISK~29268 because
H.264 was not fixed. This approach here lowers/uppers both parameter
names and parameter values. H.264 needs a different approach because
one of its parameter values is not case-insensitive:
sprop-parameter-sets is Base64.

Change-Id: Idf2a73457be231647aed3c87b1da197afba86892

ao2_replace() bumps the reference count of the object that is doing the
replacing, which is not what we want. We just want to drop the old ref
on the old object and update the pointer to point to the new object.

Pointed out by George Joseph in #asterisk-dev

Change-Id: Ie8167ed3d4b52b9d1ea2d785f885e8c27206743d

For RTCP to work, we update the ssrc to be the one corresponding to
the native bridge while active.  However when the bridge ends we
should generate a new SSRC as the sequence numbers will not continue
from the native bridge left off.

ASTERISK-29300 #close

Change-Id: I23334b6934d2bf6490bda4bbf6414d96b8d17d10

Some sorcery objects actually contain dynamic content
that can change despite the underlying configuration
itself not changing. A good example of this is the
res_pjsip_endpoint_identifier_ip module which allows
specifying hostnames. While the configuration may not
change between reloads the DNS information of the
hostnames can.

This change adds the ability for a sorcery object to be
marked as having dynamic contents which is then taken
into account when reloading by the sorcery file based
config module. If there is an object with dynamic content
then a reload will be forced while if there are none
then the existing behavior of not reloading occurs.

ASTERISK-29321

Change-Id: I9342dc55be46cc00204533c266a68d972760a0b1

Although the dlg session count was incremented in a pjsip servant
thread, there's no guarantee that the last thread to unref this
progress object was one.  Before we decrement, we need to make
sure that this is either a servant thread or that we push the
decrement to a serializer that is one.

Because pjsip_dlg_dec_session requires the dialog lock, we don't
want to wait on the task to complete if we had to push it to a
serializer.

Change-Id: I8ff2d5d94be3ff04298394070434e22a7d3cbc41

When registering it can be useful to see the source IP address and
port in cases where multiple devices are using the same endpoint
or when anonymous is in use.

ASTERISK-29325

Change-Id: Ie178a6f55f53f8473035854c411bc3d056e0a2e0

When Asterisk sends a reinvite negotiating T38 faxing, it's possible a
crash can occur if the response contains a m=image and zero port. The
reinvite callback code now checks session_media to see if it is null or
not before trying to access the udptl variable on it.

ASTERISK-29305

Change-Id: I1dfc51c5fa586e38579ede4bc228edee213ccaa9

Fixed:
* RFC 4629 does not allow the value "0" for MPI, K, and N.
* Allow value "0" for PAR.
* BPP is printed only when specified because "0" has a meaning.

New:
* Added CPCF and MaxBR.
* Some implementations provide CIF without MPI: a=fmtp:xx CIF;F=1
  Although a violation of RFC 3555 section 3, we can support that.

Changed:
* Resorts the CIFs from large to small which partly fixes ASTERISK~29267.

Change-Id: I95a650c715007b8dde11a77cb37d9c6c123a441e

When sending a SIP response to an incoming REGISTER request
we don't want to change the Contact header as it will
contain the Contacts registered to the AOR and not our own
Contact URI.

ASTERISK-29235

Change-Id: I35a0723545281dd01fcd5cae497baab58720478c

This change will check is the remote ICE session got reset or not by
checking the offered ufrag and password with session. If the remote ICE
reset session then Asterisk reset its local ufrag and password to reject
binding request with Old ufrag and Password.

ASTERISK-29266

Change-Id: I9c55e79a7af98a8fbb497d336b828ba41bc34eeb

If set_outbound_initial_authentication_credentials() fails,
handle_client_registration() bails early without creating or
sending a register message.

[set_outbound_initial_authentication_credentials() failures
can occur during the process of retrieving an oauth access
token.]

The return from handle_client_registration is ignored, so
returning an error doesn't do any good.

This is a real problem when the registration request is a
re-register, because then the registration will still be
marked 'active' despite the re-register never being sent at all.

So instead, log a warning but let the registration be created
and sent (and probably fail) and follow the normal registration
failed retry/abort logic.

ASTERISK-29315 #close

Change-Id: I2e03b1ea7fba1fa1a8279086aa4b17679e7fa7fa

If the remote Station ID contains invalid UTF-8 characters
the asterisk fails to publish the Stasis and ReceiveFax status messages.

json.c: Error building JSON from '{s: s, s: s}': Invalid UTF-8 string.
0: /usr/sbin/asterisk(ast_json_vpack+0x98) [0x4f3f28]
1: /usr/sbin/asterisk(ast_json_pack+0x8c) [0x4f3fcc]
2: /usr/sbin/asterisk(ast_channel_publish_varset+0x2b) [0x57aa0b]
3: /usr/sbin/asterisk(pbx_builtin_setvar_helper+0x121) [0x530641]
4: /usr/lib64/asterisk/modules/res_fax.so(+0x44fe) [0x7f27f4bff4fe]
...
stasis_channels.c: Error creating message

json.c: Error building JSON from '{s: s, s: s, s: s, s: s, s: s, s: s, s: o}': Invalid UTF-8 string.
0: /usr/sbin/asterisk(ast_json_vpack+0x98) [0x4f3f28]
1: /usr/sbin/asterisk(ast_json_pack+0x8c) [0x4f3fcc]
2: /usr/lib64/asterisk/modules/res_fax.so(+0x5acd) [0x7f27f4c00acd]
...
res_fax.c: Error publishing ReceiveFax status message

This patch replaces the invalid UTF-8 Station IDs with an empty string.

ASTERISK-29312 #close

Change-Id: Ieb00b6ecf67db3bfca787649caa8517f29d987db

Although refer_progress_notify() always runs in the progress
serializer, the pjproject evsub module itself can cause the
subscription to be destroyed which then triggers
refer_progress_on_evsub_state() to clean it up.  In this case,
it's possible that refer_progress_notify() could get the
subscription pulled out from under it while it's trying to use
it.

At one point we tried to have refer_progress_on_evsub_state()
push the cleanup to the serializer and wait for its return before
returning to pjproject but since pjproject calls its state
callbacks with the dialog locked, this required us to unlock the
dialog while waiting for the serialized cleanup, then lock it
again before returning to pjproject. There were also still some
cases where other callers of refer_progress_notify() weren't
using the serializer and crashes were resulting.

Although all callers of refer_progress_notify() now use the
progress serializer, we decided to simplify the locking so we
didn't have to unlock and relock the dialog in
refer_progress_on_evsub_state().

Now, refer_progress_notify() holds the dialog lock for its
duration and since pjproject also holds the dialog lock while
calling refer_progress_on_evsub_state() (which does the cleanup),
there should be no more chances for the subscription to be
cleaned up while still being used to send NOTIFYs.

To be extra safe, we also now increment the session count on
the dialog when we create a progress object and decrement
the count when the progress is destroyed.

ASTERISK-29313

Change-Id: I97a8bb01771a3c85345649b8124507f7622a8480