The verification process will now load a full certificate chain retrieved
via the X5U URL instead of loading only the end user cert.
* Renamed crypto_load_cert_from_file() and crypto_load_cert_from_memory()
to crypto_load_cert_chain_from_file() and crypto_load_cert_chain_from_memory()
respectively.
* The two load functions now continue to load certs from the file or memory
PEMs and store them in a separate stack of untrusted certs specific to the
current verification context.
* crypto_is_cert_trusted() now uses the stack of untrusted certs that were
extracted from the PEM in addition to any untrusted certs that were passed
in from the configuration (and any CA certs passed in from the config of
course).
Resolves: #1272
UserNote: The STIR/SHAKEN verification process will now load a full
certificate chain retrieved via the X5U URL instead of loading only
the end user cert.
(cherry picked from commit ec2591c60b)
UserNote: A new STIR/SHAKEN verification option "ignore_sip_date_header" has
been added that when set to true, will cause the verification process to
not consider a missing or invalid SIP "Date" header to be a failure. This
will make the IAT the sole "truth" for Date in the verification process.
The option can be set in the "verification" and "profile" sections of
stir_shaken.conf.
Also fixed a bug in the port match logic.
Resolves: #1251Resolves: #1271
(cherry picked from commit 6e9c33caad)
Added "see-also" links to chan_websocket and ARI Outbound WebSocket and
added an example configuration for each.
(cherry picked from commit a743003e1e)
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
UserNote: New cache_size option for res_odbc to on a per class basis limit the
number of cached connections. Please reference the sample configuration
for details.
(cherry picked from commit e125410e5c)
This enables setting cache_type classes to a round-robin queueing system
rather than the historic stack mechanism.
This should result in lower risk of connection drops due to shorter idle
times (the first connection to go onto the stack could in theory never
be used again, ever, but sit there consuming resources, there could be
multiple of these).
And with a queue rather than a stack, dead connections are guaranteed to
be detected and purged eventually.
This should end up better balancing connection_cnt with actual load
over time, assuming the database doesn't keep connections open
excessively long from it's side.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
UserNote: When using res_odbc it should be noted that back-end
connections to the underlying database can now be configured to re-use
the cached connections in a round-robin manner rather than repeatedly
re-using the same connection. This helps to keep connections alive, and
to purge dead connections from the system, thus more dynamically
adjusting to actual load. The downside is that one could keep too many
connections active for a longer time resulting in resource also begin
consumed on the database side.
(cherry picked from commit 49d87e4f81)
Asterisk can now establish websocket sessions _to_ your ARI applications
as well as accepting websocket sessions _from_ them.
Full details: http://s.asterisk.net/ari-outbound-ws
Code change summary:
* Added an ast_vector_string_join() function,
* Added ApplicationRegistered and ApplicationUnregistered ARI events.
* Converted res/ari/config.c to use sorcery to process ari.conf.
* Added the "outbound-websocket" ARI config object.
* Refactored res/ari/ari_websockets.c to handle outbound websockets.
* Refactored res/ari/cli.c for the sorcery changeover.
* Updated res/res_stasis.c for the sorcery changeover.
* Updated apps/app_stasis.c to allow initiating per-call outbound websockets.
* Added CLI commands to manage ARI websockets.
* Added the new "outbound-websocket" object to ari.conf.sample.
* Moved the ARI XML documentation out of res_ari.c into res/ari/ari_doc.xml
UserNote: Asterisk can now establish websocket sessions _to_ your ARI applications
as well as accepting websocket sessions _from_ them.
Full details: http://s.asterisk.net/ari-outbound-ws
(cherry picked from commit 1c0d552155)
Since multiple Asterisk capabilities now need to create websocket clients
it makes sense to create a common set of utilities rather than making
each of those capabilities implement their own.
* A new configuration file "websocket_client.conf" is used to store common
client parameters in named configuration sections.
* APIs are provided to list and retrieve ast_websocket_client objects created
from the named configurations.
* An API is provided that accepts an ast_websocket_client object, connects
to the remote server with retries and returns an ast_websocket object. TLS is
supported as is basic authentication.
* An observer can be registered to receive notification of loaded or reloaded
client objects.
* An API is provided to compare an existing client object to one just
reloaded and return the fields that were changed. The caller can then decide
what action to take based on which fields changed.
Also as part of thie commit, several sorcery convenience macros were created
to make registering common object fields easier.
UserNote: A new module "res_websocket_client" and config file
"websocket_client.conf" have been added to support several upcoming new
capabilities that need common websocket client configuration.
(cherry picked from commit 36fc358bc9)
The added retry mechanism addresses an issue that arises when fragmented TCP
packets are received, each containing only a portion of an AudioSocket packet.
This situation can occur if the external service sending the AudioSocket data
has Nagle's algorithm enabled.
(cherry picked from commit 0f414f6a94)
Disable Nagle's algorithm by setting the TCP_NODELAY socket option.
This reduces latency by preventing delays caused by packet buffering.
(cherry picked from commit c0e8f4f63b)
When a call is transfered via dialplan behind a NAT, the
host portion of the Contact header in the 302 will no longer
be over-written with the external NAT IP and will retain the
hostname.
Fixes: #1141
(cherry picked from commit 0a24944001)
Incoming SIP MESSAGEs will now have their From header's display name
sanitized by replacing any characters < 32 (space) with a space.
Resolves: #GHSA-2grh-7mhv-fcfw
If the isup-oli was sent as a URI parameter, rather than a header
parameter, it was not being parsed. Make sure we parse both if
needed so the ANI2 is set regardless of which type of parameter
the isup-oli is sent as.
Resolves: #1220
(cherry picked from commit 2bb607f7b7)
Other Dial operations (dial, app_dial) use Q.850 cause 19 when a dial timeout occurs,
but the Dial command via ARI did not set an explicit reason. This resulted in a
CANCEL with Normal Call Clearing and corresponding ChannelDestroyed.
This change sets the hangup cause to AST_CAUSE_NO_ANSWER to be consistent with the
other operations.
Fixes: #963
UserNote: A Dial timeout on POST /channels/{channelId}/dial will now result in a
CANCEL and ChannelDestroyed with cause 19 / User alerting, no answer. Previously
no explicit cause was set, resulting in a cause of 16 / Normal Call Clearing.
(cherry picked from commit 4dc3ca4c9a)
Certain platforms (mainly BSD derivatives) have an additional length
field in `sockaddr_in6` and `sockaddr_in`.
`ast_sockaddr_from_pj_sockaddr()` does not take this field into account
when copying over values from the `pj_sockaddr` into the `ast_sockaddr`.
The resulting `ast_sockaddr` will have an uninitialized value for
`sin6_len`/`sin_len` while the other `ast_sockaddr` (not converted from
a `pj_sockaddr`) to check against in `ast_sockaddr_pj_sockaddr_cmp()`
has the correct length value set.
This has the effect that `ast_sockaddr_cmp()` will always indicate
an address mismatch, because it does a bitwise comparison, and all DTLS
packets are dropped even if addresses and ports match.
`ast_sockaddr_from_pj_sockaddr()` now checks whether the length fields
are available on the current platform and sets the values accordingly.
Resolves: #505
(cherry picked from commit c251afadb9)
stasis:
* Added stasis_app_is_registered().
* Added stasis_app_control_mark_failed().
* Added stasis_app_control_is_failed().
* Fixed res_stasis_device_state so unsubscribe all works properly.
* Modified stasis_app_unregister() to unsubscribe from all event sources.
* Modified stasis_app_exec to return -1 if stasis_app_control_is_failed()
returns true.
http:
* Added ast_http_create_basic_auth_header().
md5:
* Added define for MD5_DIGEST_LENGTH.
tcptls:
* Added flag to ast_tcptls_session_args to suppress connection log messages
to give callers more control over logging.
http_websocket:
* Add flag to ast_websocket_client_options to suppress connection log messages
to give callers more control over logging.
* Added username and password to ast_websocket_client_options to support
outbound basic authentication.
* Added ast_websocket_result_to_str().
(cherry picked from commit f8bc3ddeb9)
ari_ws_session_registry_dtor() wasn't checking that the container was valid
before running ao2_callback on it to shutdown registered sessions.
(cherry picked from commit 62e73f9bd8)
This commit adds the ability to make ARI REST requests over the same
websocket used to receive events.
For full details on how to use the new capability, visit...
https://docs.asterisk.org/Configuration/Interfaces/Asterisk-REST-Interface-ARI/ARI-REST-over-WebSocket/
Changes:
* Added utilities to http.c:
* ast_get_http_method_from_string().
* ast_http_parse_post_form().
* Added utilities to json.c:
* ast_json_nvp_array_to_ast_variables().
* ast_variables_to_json_nvp_array().
* Added definitions for new events to carry REST responses.
* Created res/ari/ari_websocket_requests.c to house the new request handlers.
* Moved non-event specific code out of res/ari/resource_events.c into
res/ari/ari_websockets.c
* Refactored res/res_ari.c to move non-http code out of ast_ari_callback()
(which is http specific) and into ast_ari_invoke() so it can be shared
between both the http and websocket transports.
UpgradeNote: This commit adds the ability to make ARI REST requests over the same
websocket used to receive events.
See https://docs.asterisk.org/Configuration/Interfaces/Asterisk-REST-Interface-ARI/ARI-REST-over-WebSocket/
(cherry picked from commit 6bc055416b)
Updated the AudioSocket protocol to allow sending DTMF frames.
AST_FRAME_DTMF frames are now forwarded to the server, in addition to
AST_FRAME_AUDIO frames. A new payload type AST_AUDIOSOCKET_KIND_DTMF
with value 0x03 was added to the protocol. The payload is a 1-byte
ascii representing the DTMF digit (0-9,*,#...).
UserNote: The AudioSocket protocol now forwards DTMF frames with
payload type 0x03. The payload is a 1-byte ascii representing the DTMF
digit (0-9,*,#...).
(cherry picked from commit ea657ec7c7)
- Correct wait timeout logic in the dialplan application.
- Include server address in log messages for better traceability.
- Allow dialplan app to exit gracefully on hangup messages and socket closure.
- Optimize I/O by reducing redundant read()/write() operations.
Co-authored-by: Florent CHAUVEAU <florentch@pm.me>
(cherry picked from commit e8209bf56b)
CLI 'pjsip show contact' does not show enough information.
One must telnet to AMI or write a script to ask Asterisk for example what the User-Agent is on a Contact
This feature adds the same details as PJSIPShowContacts to the CLI
Resolves: #643
(cherry picked from commit abc8c5c93a)
1. When one channel is placed on hold, the device state is set to ONHOLD
without checking other channels states.
In case of AST_CONTROL_HOLD set the device state as AST_DEVICE_UNKNOWN
to calculate aggregate device state of all active channels.
2. The current implementation incorrectly classifies channels in use.
The only channels that has the states: UP, RING and BUSY are considered as "in use".
A channel should be considered "in use" if its state is anything other than
DOWN or RESERVED.
3. Currently, if the number of channels "in use" is greater than device_state_busy_at,
the system does not set the state to BUSY. Instead, it incorrectly assigns an aggregate
device state.
The endpoint device state should be BUSY if the number of channels "in use" is greater
than or equal to device_state_busy_at.
Fixes: #1181
(cherry picked from commit 03cf8c62ad)
Resolves an issue where the tcp_keepalive_enable option was not properly enabled in the sample configuration due to an incorrect default flag setting.
Fixes: #1149
(cherry picked from commit c4123901e5)
This reverts commit f30ad96b3f.
The original change was not RFC compliant and caused issues because it
set the RTP marker bit in cases when it shouldn't be set. See the
linked issue #1135 for a detailed explanation.
Fixes: #1135.
(cherry picked from commit a47fe8f84f)
Issues:
* The bridging core allowed multiple bridges to be created with the same
unique bridgeId at the same time. Only the last bridge created with the
duplicate name was actually saved to the core bridges container.
* The bridging core was creating a stasis topic for the bridge and saving it
in the bridge->topic field but not increasing its reference count. In the
case where two bridges were created with the same uniqueid (which is also
the topic name), the second bridge would get the _existing_ topic the first
bridge created. When the first bridge was destroyed, it would take the
topic with it so when the second bridge attempted to publish a message to
it it either FRACKed or SEGVd.
* The bridge destructor, which also destroys the bridge topic, is run from the
bridge manager thread not the caller's thread. This makes it possible for
an ARI developer to create a new one with the same uniqueid believing the
old one was destroyed when, in fact, the old one's destructor hadn't
completed. This could cause the new bridge to get the old one's topic just
before the topic was destroyed. When the new bridge attempted to publish
a message on that topic, asterisk could either FRACK or SEGV.
* The ARI bridges resource also allowed multiple bridges to be created with
the same uniqueid but it kept the duplicate bridges in its app_bridges
container. This created a situation where if you added two bridges with
the same "bridge1" uniqueid, all operations on "bridge1" were performed on
the first bridge created and the second was basically orphaned. If you
attempted to delete what you thought was the second bridge, you actually
deleted the first one created.
Changes:
* A new API `ast_bridge_topic_exists(uniqueid)` was created to determine if
a topic already exists for a bridge.
* `bridge_base_init()` in bridge.c and `ast_ari_bridges_create()` in
resource_bridges.c now call `ast_bridge_topic_exists(uniqueid)` to check
if a bridge with the requested uniqueid already exists and will fail if it
does.
* `bridge_register()` in bridges.c now checks the core bridges container to
make sure a bridge doesn't already exist with the requested uniqueid.
Although most callers of `bridge_register()` will have already called
`bridge_base_init()`, which will now fail on duplicate bridges, there
is no guarantee of this so we must check again.
* The core bridges container allocation was changed to reject duplicate
uniqueids instead of silently replacing an existing one. This is a "belt
and suspenders" check.
* A global mutex was added to bridge.c to prevent concurrent calls to
`bridge_base_init()` and `bridge_register()`.
* Even though you can no longer create multiple bridges with the same uniqueid
at the same time, it's still possible that the bridge topic might be
destroyed while a second bridge with the same uniqueid was trying to use
it. To address this, the bridging core now increments the reference count
on bridge->topic when a bridge is created and decrements it when the
bridge is destroyed.
* `bridge_create_common()` in res_stasis.c now checks the stasis app_bridges
container to make sure a bridge with the requested uniqueid doesn't already
exist. This may seem like overkill but there are so many entrypoints to
bridge creation that we need to be safe and catch issues as soon in the
process as possible.
* The stasis app_bridges container allocation was changed to reject duplicate
uniqueids instead of adding them. This is a "belt and suspenders" check.
* The `bridge show all` CLI command now shows the bridge name as well as the
bridge id.
* Response code 409 "Conflict" was added as a possible response from the ARI
bridge create resources to signal that a bridge with the requested uniqueid
already exists.
* Additional debugging was added to multiple bridging and stasis files.
Resolves: #211
(cherry picked from commit 46c9f7db8e)
The verification check for missing or anonymous callerid was happening before
the endpoint's profile was retrieved which meant that the failure_action
parameter wasn't available. Therefore, if verification was enabled and there
was no callerid or it was "anonymous", the call was immediately terminated
instead of giving the dialplan the ability to decide what to do with the call.
* The callerid check now happens after the verification context is created and
the endpoint's stir_shaken_profile is available.
* The check now processes the callerid failure just as it does for other
verification failures and respects the failure_action parameter. If set
to "continue" or "continue_return_reason", `STIR_SHAKEN(0,verify_result)`
in the dialplan will return "invalid_or_no_callerid".
* If the endpoint's failure_action is "reject_request", the call will be
rejected with `433 "Anonymity Disallowed"`.
* If the endpoint's failure_action is "continue_return_reason", the call will
continue but a `Reason: STIR; cause=433; text="Anonymity Disallowed"`
header will be added to the next provisional or final response.
Resolves: #1112
(cherry picked from commit 71551013c4)
Between ast_ari_channels_external_media(), external_media_rtp_udp(),
and external_media_audiosocket_tcp(), the `variables` structure being passed
around wasn't being cleaned up properly when there was a failure.
* In ast_ari_channels_external_media(), the `variables` structure is now
defined with RAII_VAR to ensure it always gets cleaned up.
* The ast_variables_destroy() call was removed from external_media_rtp_udp().
* The ast_variables_destroy() call was removed from
external_media_audiosocket_tcp(), its `endpoint` allocation was changed to
to use ast_asprintf() as external_media_rtp_udp() does, and it now
returns an error on failure.
* ast_ari_channels_external_media() now checks the new return code from
external_media_audiosocket_tcp() and sets the appropriate error response.
Resolves: #1109
(cherry picked from commit 5267c17645)
Introduce a ChannelTransfer event and the ability to notify progress to
ARI. Implement emitting this event from the PJSIP channel instead of
handling the transfer in Asterisk when configured.
Introduce a dialplan function to the PJSIP channel to switch between the
"core" and "ari-only" behavior.
UserNote: Call transfers on the PJSIP channel can now be controlled by
ARI. This can be enabled by using the PJSIP_TRANSFER_HANDLING(ari-only)
dialplan function.
(cherry picked from commit 71eb8a262f)
This process was a bit different than the others because everything
is in the same file, there's an array that contains the command
names and their handler functions, and the last command was created
over 15 years ago.
* Dump a `git blame` of res/res_agi.c from BEFORE the handle_* prototypes
were changed.
* Create a command <> handler function xref by parsing the the agi_command
array.
* For each entry, grep the function definition line "static int handle_*"
from the git blame output and capture the commit. This will be the
commit the command was created in.
* Do a `git tag --contains <commit> | sort -V | head -1` to get the
tag the function was created in.
* Add a single since/version element to the command XML. Multiple versions
aren't supported here because the branching and tagging scheme changed
several times in the 2000's.
(cherry picked from commit f1df1cacf6)
Also updates the 'since' of applications/functions that existed before
XML documentation was introduced (1.6.2.0).
(cherry picked from commit b4156fecf0)
When an incoming request can't be matched to an endpoint, the "artificial"
auth object is used to create a challenge to return in a 401 response and we
emit a "No matching endpoint found" log message. If the client then responds
with an Authorization header but the request still can't be matched to an
endpoint, the verification will fail and, as before, we'll create a challenge
to return in a 401 response and we emit a "No matching endpoint found" log
message. HOWEVER, because there WAS an Authorization header and it failed
verification, we should have also been emitting a "Failed to authenticate"
log message but weren't because there was a check that short-circuited that
it if the artificial auth was used. Since many admins use the "Failed to
authenticate" message with log parsers like fail2ban, those attempts were not
being recognized as suspicious.
Changes:
* digest_check_auth() now always emits the "Failed to authenticate" log
message if verification of an Authorization header failed even if the
artificial auth was used.
* The verification logic was refactored to be clearer about the handling
of the return codes from verify().
* Comments were added clarify what return codes digest_check_auth() should
return to the distributor and the implications of changing them.
Resolves: #1095
An issue in config_auth.c:ast_sip_auth_digest_algorithms_vector_init() was
causing double allocations for the two supported_algorithms vectors to the
tune of 915 bytes. The leak only happens on startup and when a reload is done
and doesn't get bigger with the number of auth objects defined.
* Pre-initialized the two vectors in config_auth:auth_alloc().
* Removed the allocations in ast_sip_auth_digest_algorithms_vector_init().
* Added a note to the doc for ast_sip_auth_digest_algorithms_vector_init()
noting that the vector passed in should be initialized and empty.
* Simplified the create_artificial_auth() function in pjsip_distributor.
* Set the vector initialization count to 0 in config_global:global_apply().
* Do a git blame on the embedded XML application or function element.
* From the commit hash, grab the summary line.
* Do a git log --grep <summary> to find the cherry-pick commits in all
branches that match.
* Do a git patch-id to ensure the commits are all related and didn't get
a false match on the summary.
* Do a git tag --contains <commit> to find the tags that contain each
commit.
* Weed out all tags not ..0.
* Sort and discard any .0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the application or function
was defined.
The applications and functions defined in the following files were done by
hand because the XML was extracted from the C source file relatively recently.
* channels/pjsip/dialplan_functions_doc.xml
* main/logger_doc.xml
* main/manager_doc.xml
* res/res_geolocation/geoloc_doc.xml
* res/res_stir_shaken/stir_shaken_doc.xml
(cherry picked from commit 85a4ab8390)
* Do a git blame on the embedded XML managerEvent elements.
* From the commit hash, grab the summary line.
* Do a git log --grep <summary> to find the cherry-pick commits in all
branches that match.
* Do a git patch-id to ensure the commits are all related and didn't get
a false match on the summary.
* Do a git tag --contains <commit> to find the tags that contain each
commit.
* Weed out all tags not ..0.
* Sort and discard any .0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the application or function
was defined.
The events defined in res/res_pjsip/pjsip_manager.xml were done by hand
because the XML was extracted from the C source file relatively recently.
Two bugs were fixed along the way...
* The get_documentation awk script was exiting after it processed the first
DOCUMENTATION block it found in a file. We have at least 1 source file
with multiple DOCUMENTATION blocks so only the first one in them was being
processed. The awk script was changed to continue searching rather
than exiting after the first block.
* Fixing the awk script revealed an issue in logger.c where the third
DOCUMENTATION block contained a XML fragment that consisted only of
a managerEventInstance element that wasn't wrapped in a managerEvent
element. Since logger_doc.xml already existed, the remaining fragments
in logger.c were moved to it and properly organized.
(cherry picked from commit a47b8e2d40)
This should resolve the Prometheus error:
> Error scraping target: non-compliant scrape target
sending blank Content-Type and no
fallback_scrape_protocol specified for target.
Resolves: #1075
(cherry picked from commit fa286641fb)
Most of the configObjects and configOptions that are implemented with
ACO or Sorcery now have `<since>/<version>` elements added. There are
probably some that the script I used didn't catch. The version tags were
determined by the following...
* Do a git blame on the API call that created the object or option.
* From the commit hash, grab the summary line.
* Do a `git log --grep <summary>` to find the cherry-pick commits in all
branches that match.
* Do a `git patch-id` to ensure the commits are all related and didn't get
a false match on the summary.
* Do a `git tag --contains <commit>` to find the tags that contain each
commit.
* Weed out all tags not <major>.<minor>.0.
* Sort and discard any <major>.0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the API was last touched.
configObjects and configOptions elements implemented with the base
ast_config APIs were just not possible to find due to the non-deterministic
way they are accessed.
Also note that if the API call was on modified after it was added, the
version will be the one it was last modified in.
Final note: The configObject and configOption elements were introduced in
12.0.0 so options created before then may not have any XML documentation.
(cherry picked from commit a22dc33057)
The return code fom digest_check_auth wasn't explicitly being initialized.
The return code also wasn't explicitly set to CHALLENGE when challenges
were sent. When optimization was turned off (DONT_OPTIMIZE), the compiler
was setting it to "0"(CHALLENGE) which worked fine. However, with
optimization turned on, it was setting it to "1" (SUCCESS) so if there was
no incoming Authorization header, the function was returning SUCCESS to the
distributor allowing the request to incorrectly succeed.
The return code is now initialized correctly and is now explicitly set
to CHALLENGE when we send challenges.
(cherry picked from commit 317b830c1e)
* channels/pjsip/dialplan_functions_doc.xml: Added xmlns:xi to docs element.
* main/bucket.c: Removed XML completely since the "bucket" and "file" objects
are internal only with no config file.
* main/named_acl.c: Fixed the configFile element name. It was "named_acl.conf"
and should have been "acl.conf"
* res/res_geolocation/geoloc_doc.xml: Added xmlns:xi to docs element.
* res/res_http_media_cache.c: Fixed the configFile element name. It was
"http_media_cache.conf" and should have been "res_http_media_cache.conf".
(cherry picked from commit 3b53152624)
* Added the "since" element to the XML configObject and configOption elements
in appdocsxml.dtd.
* Added the "Since" section to the following CLI output:
```
config show help <module> <object>
config show help <module> <object> <option>
core show application <app>
core show function <func>
manager show command <command>
manager show event <event>
agi show commands topic <topic>
```
* Refactored the commands above to output their sections in the same order:
Synopsis, Since, Description, Syntax, Arguments, SeeAlso
* Refactored the commands above so they all use the same pattern for writing
the output to the CLI.
* Fixed several memory leaks caused by failure to free temporary output
buffers.
* Added a "since" array to the mustache template for the top-level resources
(Channel, Endpoint, etc.) and to the paths/methods underneath them. These
will be added to the generated markdown if present.
Example:
```
"resourcePath": "/api-docs/channels.{format}",
"requiresModules": [
"res_stasis_answer",
"res_stasis_playback",
"res_stasis_recording",
"res_stasis_snoop"
],
"since": [
"18.0.0",
"21.0.0"
],
"apis": [
{
"path": "/channels",
"description": "Active channels",
"operations": [
{
"httpMethod": "GET",
"since": [
"18.6.0",
"21.8.0"
],
"summary": "List all active channels in Asterisk.",
"nickname": "list",
"responseClass": "List[Channel]"
},
```
NOTE: No versioning information is actually added in this commit.
Those will be added separately and instructions for adding and maintaining
them will be published on the documentation site at a later date.
(cherry picked from commit 3e28ddce78)
* Refactored pjproject code to support the new algorithms and
added a patch file to third-party/pjproject/patches
* Added new parameters to the pjsip auth object:
* password_digest = <algorithm>:<digest>
* supported_algorithms_uac = List of algorithms to support
when acting as a UAC.
* supported_algorithms_uas = List of algorithms to support
when acting as a UAS.
See the auth object in pjsip.conf.sample for detailed info.
* Updated both res_pjsip_authenticator_digest.c (for UAS) and
res_pjsip_outbound_authentocator_digest.c (UAC) to suport the
new algorithms.
The new algorithms are only available with the bundled version
of pjproject, or an external version > 2.14.1. OpenSSL version
1.1.1 or greater is required to support SHA-512-256.
Resolves: #948
UserNote: The SHA-256 and SHA-512-256 algorithms are now available
for authentication as both a UAS and a UAC.
(cherry picked from commit 1933548d41)
Added a new option "qualify_2xx_only" to the res_pjsip AOR qualify
feature to mark a contact as available only if an OPTIONS request
returns a 2XX response. If the option is not specified or is false,
any response to the OPTIONS request marks the contact as available.
UserNote: The pjsip.conf AOR section now has a "qualify_2xx_only"
option that can be set so that only 2XX responses to OPTIONS requests
used to qualify a contact will mark the contact as available.
(cherry picked from commit 85f5a047c1)
