If a hostname is specified for stunaddr in rtp.conf, periodic DNS resolution
is enabled based on the TTL returned in the DNS results. If the TTL returned
is 0, it means that the next time the IP address is needed, it must be
looked up again. I.E. Don't cache. Historically (and incorrectly) however,
res_rtp_asterisk stopped the periodic resolution and never re-resolved the
hostname again.
Besides what's mentioned in the user notes...
* Additional debugging was added in various STUN/DNS functions.
* The `rtp show settings` CLI command shows more detailed STUN info.
* Some debugging was added to dns_core.c and dns_recurring.c.
UserNote: A new `stunaddr_reresolve_ttl_0` parameter has been added to rtp.conf
that allows control over what happens when a STUN server hostname lookup
returns a TTL of 0. The values can be set as follows:
- 'no': This is the historical (and current default) behavior of not doing
any further lookups and continuing to use the last successful result until
Asterisk is restarted or rtp.conf is reloaded.
- 'yes': Use the last cached result for the current call but trigger
re-resolution in the background for the benefit of future calls.
If the result of the background lookup is a ttl > 0, periodic resolution
will be restarted otherwise the next call will use the new cached value
and will trigger a background lookup again.
UserNote: A new CLI command `rtp resolve stun hostname` has been added
that will force a resolution of the STUN hostname and (re)start periodic
resolution if the result has a TTL > 0.
Resolves: #1858
Add rtp_port_start and rtp_port_end options to PJSIP endpoint
configuration, allowing each endpoint to use a dedicated RTP port
range instead of the global rtp.conf setting.
This is useful for scenarios where different endpoints need isolated
port ranges, such as firewall rules per trunk, multi-tenant systems,
or network QoS policies tied to port ranges.
The implementation adds ast_rtp_instance_new_with_port_range() to the
RTP engine API, which sets the port range on the instance before the
engine allocates the transport. The default RTP engine
(res_rtp_asterisk) checks for per-instance overrides in
rtp_allocate_transport() and falls back to the global range when
none is set.
Both options must be set together, with values >= 1024 and
rtp_port_end > rtp_port_start. Setting both to 0 (the default)
preserves existing behavior.
Resolves: https://github.com/asterisk/asterisk-feature-requests/issues/71
UserNote: PJSIP endpoints now support rtp_port_start and
rtp_port_end options to configure a dedicated RTP port range per
endpoint, overriding the global rtp.conf setting.
UpgradeNote: An alembic database migration has been added to add
the rtp_port_start and rtp_port_end columns to the ps_endpoints
table. Run "alembic upgrade head" to apply the schema change.
DeveloperNote: New public API: ast_rtp_instance_new_with_port_range()
creates an RTP instance with a per-instance port range.
ast_rtp_instance_get_port_start() and ast_rtp_instance_get_port_end()
allow RTP engines to query the override. Third-party RTP engines can
use these getters to support per-instance port ranges.
Several issues are resolved:
* Internally, floats were used for timestamp values but this could result
in wrapping so they've been changed to doubles.
* Historically, the default CEL eventtime format is `<seconds>.<microseconds>`
with `<microseconds>` always being 6 digits. This should have continued to be
the case but res_cdrel_custom wasn't checking the `dateformat` setting in
cel.conf and was defaulting to `%F %T`. res_cdrel_custom now gets the default
date format from cel.conf, which will be whatever the `dateformat` parameter
is set to or `<seconds>.<microseconds>` if not set.
* The timeval field formatter for both CDR and CEL wasn't handling custom
strftime format strings correctly. This is now fixed so you should be able
to specifiy custom strftime format strings for the CEL `eventtime` and CDR
`start`, `answer` and `end` fields. For example: `eventtime(%FT%T%z)`.
Resolves: #1844Resolves: #1845
Add uri prefix based acl support to the built in http server.
This allows an acl to be added per uri prefix (ie '/metrics'
or '/ws') to restrict access.
Add user based acl support for ARI. This adds new acl options
to the user section of ari.conf to restrict access on a per
user basis.
resolves: #1799
UserNote: A new section, type=restriction has been added to http.conf
to allow an uri prefix based acl to be configured. See
http.conf.sample for examples and more information.
The user section of ari.conf can now contain an acl configuration
to restrict users access. See ari.conf.sample for examples and more
information
There is a LOT of work in this commit but the TL;DR is that it takes
CEL processing from using 38% of the CPU instructions used by a call,
which is more than that used by the call processing itself, down to less
than 10% of the instructions.
So here's the deal... cdr_custom, cdr_sqlite3_custom, cel_custom
and cel_sqlite3_custom all shared one ugly trait...they all used
ast_str_substitute_variables() or pbx_substitute_variables_helper()
to resolve the dialplan functions used in their config files. Not only
are they both extraordinarily expensive, they both require a dummy
channel to be allocated and destroyed for each record written. For CDRs,
that's not too bad because we only write one CDR per call. For CELs however,
it's a disaster.
As far as source code goes, the modules basically all did the same thing.
Unfortunately, they did it badly. The config files simply contained long
opaque strings which were intepreted by ast_str_substitute_variables() or
pbx_substitute_variables_helper(), the very functions that ate all the
instructions. This meant introducing a new "advanced" config format much
like the advanced manager event filtering added to manager.conf in 2024.
Fortunately however, if the legacy config was recognizable, we were able to
parse it as an advanced config and gain the benefit. If not, then it
goes the legacy, and very expensive, route.
Given the commonality among the modules, instead of making the same
improvements to 4 modules then trying to maintain them over time, a single
module "res_cdrel_custom" was created that contains all of the common code.
A few bonuses became possible in the process...
* The cdr_custom and cel_custom modules now support JSON formatted output.
* The cdr_sqlite_custom and cel_sqlite3_custom modules no longer have
to share an Sqlite3 database.
Summary of changes:
A new module "res/res_cdrel_custom.c" has been created and the existing
cdr_custom, cdr_sqlite3_custom, cel_custom and cel_sqlite3_custom modules
are now just stubs that call the code in res_cdrel_custom.
res_cdrel_custom contains:
* A common configuration facility.
* Getters for both CDR and CEL fields that share the same abstraction.
* Formatters for all data types found in the ast_cdr and ast_event
structures that share the same abstraction.
* Common writers for the text file and database backends that, you guessed it,
share the same abstraction.
The result is that while there is certainly a net increase in the number of
lines in the code base, most of it is in the configuration handling at
load-time. The run-time instruction path length is now significanty shorter.
```
Scenario Instructions Latency
=====================================================
CEL pre changes 38.49% 37.51%
CEL Advanced 9.68% 6.06%
CEL Legacy (auto-conv to adv) 9.95% 6.13%
CEL Sqlite3 pre changes 39.41% 39.90%
CEL Sqlite3 Advanced 25.68% 24.24%
CEL Sqlite3 Legacy (auto conv) 25.88% 24.53%
CDR pre changes 4.79% 2.95%
CDR Advanced 0.79% 0.47%
CDR Legacy (auto conv to adv) 0.86% 0.51%
CDR Sqlite3 pre changes 4.47% 2.89%
CEL Sqlite3 Advanced 2.16% 1.29%
CEL Sqlite3 Legacy (auto conv) 2.19% 1.30%
```
Notes:
* We only write one CDR per call but every little bit helps.
* Sqlite3 still takes a fair amount of resources but the new config
makes a decent improvement.
* Legacy configs that we can't auto convert will still take the
"pre changes" path.
If you're interested in more implementation details, see the comments
at the top of the res_cdrel_custom.c file.
One minor fix to CEL is also included...Although TenantID was added to the
ast_event structure, it was always rendered as an empty string. It's now
properly rendered.
UserNote: Significant performance improvements have been made to the
cdr_custom, cdr_sqlite3_custom, cel_custom and cel_sqlite3_custom modules.
See the new sample config files for those modules to see how to benefit
from them.
To address potential security issues, the httpstatus page is now disabled
by default and the echoed query string and cookie output is html-escaped.
Resolves: #GHSA-v6hp-wh3r-cwxh
UpgradeNote: To prevent possible security issues, the `/httpstatus` page
served by the internal web server is now disabled by default. To explicitly
enable it, set `enable_status=yes` in http.conf.
This adds a 'prio' setting to ensure that call priority is respected across multiple queues.
Using 'yes' could cause high-priority callers to be skipped if a caller
in another queue had a longer wait time, regardless of priority.
Resolves: #1637
UserNote: The 'force_longest_waiting_caller' option now supports a 'prio' setting.
When set to 'prio', calls are offered by priority first, then by wait time.
* 3d positions were being rendered without an enclosing `<gml:pos>`
element resulting in invalid XML.
* There was no way to set the `id` attribute on the enclosing `tuple`, `device`
and `person` elements.
* There was no way to set the value of the `deviceID` element.
* Parsing of degree and radian UOMs was broken resulting in them appearing
outside an XML element.
* The UOM schemas for degrees and radians were reversed.
* The Ellipsoid shape was missing and the Ellipse shape was defined multiple
times.
* The `crs` location_info parameter, although documented, didn't work.
* The `pos3d` location_info parameter appears in some documentation but
wasn't being parsed correctly.
* The retransmission-allowed and retention-expiry sub-elements of usage-rules
were using the `gp` namespace instead of the `gbp` namespace.
In addition to fixing the above, several other code refactorings were
performed and the unit test enhanced to include a round trip
XML -> eprofile -> XML validation.
Resolves: #1667
UserNote: Geolocation: Two new optional profile parameters have been added.
* `pidf_element_id` which sets the value of the `id` attribute on the top-level
PIDF-LO `device`, `person` or `tuple` elements.
* `device_id` which sets the content of the `<deviceID>` element.
Both parameters can include channel variables.
UpgradeNote: Geolocation: In order to correct bugs in both code and
documentation, the following changes to the parameters for GML geolocation
locations are now in effect:
* The documented but unimplemented `crs` (coordinate reference system) element
has been added to the location_info parameter that indicates whether the `2d`
or `3d` reference system is to be used. If the crs isn't valid for the shape
specified, an error will be generated. The default depends on the shape
specified.
* The Circle, Ellipse and ArcBand shapes MUST use a `2d` crs. If crs isn't
specified, it will default to `2d` for these shapes.
The Sphere, Ellipsoid and Prism shapes MUST use a `3d` crs. If crs isn't
specified, it will default to `3d` for these shapes.
The Point and Polygon shapes may use either crs. The default crs is `2d`
however so if `3d` positions are used, the crs must be explicitly set to `3d`.
* The `geoloc show gml_shape_defs` CLI command has been updated to show which
coordinate reference systems are valid for each shape.
* The `pos3d` element has been removed in favor of allowing the `pos` element
to include altitude if the crs is `3d`. The number of values in the `pos`
element MUST be 2 if the crs is `2d` and 3 if the crs is `3d`. An error
will be generated for any other combination.
* The angle unit-of-measure for shapes that use angles should now be included
in the respective parameter. The default is `degrees`. There were some
inconsistent references to `orientation_uom` in some documentation but that
parameter never worked and is now removed. See examples below.
Examples...
```
location_info = shape="Sphere", pos="39.0 -105.0 1620", radius="20"
location_info = shape="Point", crs="3d", pos="39.0 -105.0 1620"
location_info = shape="Point", pos="39.0 -105.0"
location_info = shape=Ellipsoid, pos="39.0 -105.0 1620", semiMajorAxis="20"
semiMinorAxis="10", verticalAxis="0", orientation="25 degrees"
pidf_element_id = ${CHANNEL(name)}-${EXTEN}
device_id = mac:001122334455
Set(GEOLOC_PROFILE(pidf_element_id)=${CHANNEL(name)}/${EXTEN})
```
This commit introduces a new redirect handling module that provides
infrastructure for following SIP 3xx redirect responses. The redirect
functionality respects the endpoint's redirect_method setting and only
follows redirects when set to 'uri_pjsip'. This infrastructure can be
used by any PJSIP module that needs to handle 3xx redirect responses.
callgroup and pickupgroup may only be specified for FXO-signaled channels;
however, the chan_dahdi sample config had these options uncommented in
the [channels] section, thus applying these settings to all channels,
resulting in warnings. Comment these out so there are no warnings with
an unmodified sample config.
Resolves: #1552
The LOCAL_OPTIMIZE_BEGIN, STREAM_BEGIN, STREAM_END, and DTMF CEL
events were not all documented in the CEL configuration file or the
manager documentation for the CEL event.
This change moves the PJSIP module from the threadpool API
to the taskpool API. PJSIP-specific implementations for
task usage have been removed and replaced with calls to
the optimized taskpool implementations instead. The need
for a pool of serializers has also been removed as
taskpool inherently provides this. The default settings
have also been changed to be more realistic for common
usage.
UpgradeNote: The threadpool_* options in pjsip.conf have now
been deprecated though they continue to be read and used.
They have been replaced with taskpool options that give greater
control over the underlying taskpool used for PJSIP. An alembic
upgrade script has been added to add these options to realtime
as well.
This conf file should be suffixed .sample so that make installs it
at compile time. Otherwise res_phoneprov complains at runtime as to
its absence and refuses to start.
Fixes: #1626
The Call Completion Supplementary Service feature is rarely used but many of
it's functions are called by app_dial and channel.c "just in case". These
functions lock and unlock the channel just to see if CCSS is enabled on it,
which it isn't 99.99% of the time.
UserNote: A new "enabled" parameter has been added to ccss.conf. It defaults
to "yes" to preserve backwards compatibility but CCSS is rarely used so
setting "enabled = no" in the "general" section can save some unneeded channel
locking operations and log message spam. Disabling ccss will also prevent
the func_callcompletion and chan_dahdi modules from loading.
DeveloperNote: A new API ast_is_cc_enabled() has been added. It should be
used to ensure that CCSS is enabled before making any other ast_cc_* calls.
With recent enhancements to chan_websocket, the original plain-text
implementation of control messages and events is now too limiting. We
probably should have used JSON initially but better late than never. Going
forward, enhancements that require control message or event changes will
only be done to the JSON variants and the plain-text variants are now
deprecated but not yet removed.
* Added the chan_websocket.conf config file that allows setting which control
message format to use globally: "json" or "plain-text". "plain-text" is the
default for now to preserve existing behavior.
* Added a dialstring option `f(json|plain-text)` to allow the format to be
overridden on a call-by-call basis. Again, 'plain-text' is the default for
now to preserve existing behavior.
The JSON for commands sent by the app to Asterisk must be...
`{ "command": "<command>" ... }` where `<command>` is one of `ANSWER`, `HANGUP`,
`START_MEDIA_BUFFERING`, etc. The `STOP_MEDIA_BUFFERING` command takes an
additional, optional parameter to be returned in the corresponding
`MEDIA_BUFFERING_COMPLETED` event:
`{ "command": "STOP_MEDIA_BUFFERING", "correlation_id": "<correlation id>" }`.
The JSON for events sent from Asterisk to the app will be...
`{ "event": "<event>", "channel_id": "<channel_id>" ... }`.
The `MEDIA_START` event will now look like...
```
{
"event": "MEDIA_START",
"connection_id": "media_connection1",
"channel": "WebSocket/media_connection1/0x5140001a0040",
"channel_id": "1761245643.1",
"format": "ulaw",
"optimal_frame_size": 160,
"ptime": 20,
"channel_variables": {
"DIALEDPEERNUMBER": "media_connection1/c(ulaw)",
"MEDIA_WEBSOCKET_CONNECTION_ID": "media_connection1",
"MEDIA_WEBSOCKET_OPTIMAL_FRAME_SIZE": "160"
}
}
```
Note the addition of the channel variables which can't be supported
with the plain-text formatting.
The documentation will be updated with the exact formats for all commands
and events.
Resolves: #1546Resolves: #1563
DeveloperNote: The chan_websocket plain-text control and event messages are now
deprecated (but remain the default) in favor of JSON formatted messages.
See https://docs.asterisk.org/Configuration/Channel-Drivers/WebSocket for
more information.
DeveloperNote: A "transport_data" parameter has been added to the
channels/externalMedia ARI endpoint which, for websocket, allows the caller
to specify parameters to be added to the dialstring for the channel. For
instance, `"transport_data": "f(json)"`.
This change moves the PJSIP module from the threadpool API
to the taskpool API. PJSIP-specific implementations for
task usage have been removed and replaced with calls to
the optimized taskpool implementations instead. The need
for a pool of serializers has also been removed as
taskpool inherently provides this. The default settings
have also been changed to be more realistic for common
usage.
UpgradeNote: The threadpool_* options in pjsip.conf have now
been deprecated though they continue to be read and used.
They have been replaced with taskpool options that give greater
control over the underlying taskpool used for PJSIP. An alembic
upgrade script has been added to add these options to realtime
as well.
This change introduces a new API called taskpool. This is a pool
of taskprocessors. It provides the following functionality:
1. Task pushing to a pool of taskprocessors
2. Synchronous tasks
3. Serializers for execution ordering of tasks
4. Growing/shrinking of number of taskprocessors in pool
This functionality already exists through the combination of
threadpool+taskprocessors but through investigating I determined
that this carries substantial overhead for short to medium duration
tasks. The threadpool uses a single queue of work, and for management
of threads it involves additional tasks.
I wrote taskpool to eliminate the extra overhead and management
as much as possible. Instead of a single queue of work each
taskprocessor has its own queue and at push time a selector chooses
the taskprocessor to queue the task to. Each taskprocessor also
has its own thread like normal. This spreads out the tasks immediately
and reduces contention on shared resources.
Using the included efficiency tests the number of tasks that can be
executed per second in a taskpool is 6-12 times more than an equivalent
threadpool+taskprocessor setup.
Stasis has been moved over to using this new API as it is a heavy consumer
of threadpool+taskprocessors and produces a lot of tasks.
UpgradeNote: The threadpool_* options in stasis.conf have now been deprecated
though they continue to be read and used. They have been replaced with taskpool
options that give greater control over the underlying taskpool used for stasis.
DeveloperNote: The taskpool API has been added for common usage of a
pool of taskprocessors. It is suggested to use this API instead of the
threadpool+taskprocessor approach.
In many asterisk-based systems, the pause reason is used to separate
pauses by type,and logically, changing the reason defines two intervals
that should be accounted for separately. The introduction of a new
option allows me to separate the intervals of operator inactivity in
the log by the event of unpausing.
UserNote: Add new global option 'log_unpause_on_reason_change' that
is default disabled. When enabled cause addition of UNPAUSE event on
every re-PAUSE with reason changed.
This patch resolves two issues in Sorcery objectset handling with multiple
backends:
1. Prevent duplicate objects:
When an object exists in more than one backend (e.g., a contact in both
'astdb' and 'realtime'), the objectset previously returned multiple instances
of the same logical object. This caused logic failures in components like the
PJSIP registrar, where duplicate contact entries led to overcounting and
incorrect deletions, when max_contacts=1 and remove_existing=yes.
This patch ensures only one instance of an object with a given key is added
to the objectset, avoiding these duplicate-related side effects.
2. Ensure missing objects are created:
When using multiple writable backends, a temporary backend failure can lead
to objects missing permanently from that backend.
Currently, .update() silently fails if the object is not present,
and no .create() is attempted.
This results in inconsistent state across backends (e.g. astdb vs. realtime).
This patch introduces a new global option in sorcery.conf:
[general]
update_or_create_on_update_miss = yes|no
Default: no (preserves existing behavior).
When enabled: if .update() fails with no data found, .create() is attempted
in that backend. This ensures that objects missing due to temporary backend
outages are re-synchronized once the backend is available again.
Added a new CLI command:
sorcery show settings
Displays global Sorcery settings, including the current value of
update_or_create_on_update_miss.
Updated tests to validate both flag enabled/disabled behavior.
Fixes: #1289
UserNote: Users relying on Sorcery multiple writable backends configurations
(e.g., astdb + realtime) may now enable update_or_create_on_update_miss = yes
in sorcery.conf to ensure missing objects are recreated after temporary backend
failures. Default behavior remains unchanged unless explicitly enabled.
If Caller ID is disabled for an FXS port, then we should not send any
Caller ID spill on the line, as we have no Caller ID information that
we can/should be sending.
Resolves: #1394
Fixes: #1280
UserNote: Enabling the tracking of the
STREAM_BEGIN and the STREAM_END event
types in cel.conf will log media files and
music on hold played to each channel.
The STREAM_BEGIN event's extra field will
contain a JSON with the file details (path,
format and language), or the class name, in
case of music on hold is played. The DTMF
event's extra field will contain a JSON with
the digit and the duration in milliseconds.
In the original implementation, both CANCEL and NO ANSWER states were
consolidated under the NO ANSWER disposition. This patch introduces a
separate CANCEL disposition, with an optional configuration switch to
enable this new disposition.
Resolves: #1323
UserNote: A new CDR option "canceldispositionenabled" has been added
that when set to true, the NO ANSWER disposition will be split into
two dispositions: CANCEL and NO ANSWER. The default value is 'no'
users.conf was deprecated in Asterisk 21 and is now being removed
for Asterisk 23, in accordance with the Asterisk deprecation policy.
This consists of:
* Removing integration with app_directory, app_voicemail, chan_dahdi,
chan_iax2, and AMI.
* users.conf was also partially used for res_phoneprov, and this remaining
functionality is consolidated to a separate phoneprov_users.conf,
used only by res_phoneprov.
Resolves: #1292
UpgradeNote: users.conf has been removed and all channel drivers must
be configured using their specific configuration files. The functionality
previously in users.conf for res_phoneprov is now in phoneprov_users.conf.
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
This update adds support for a new QUEUE_RAISE_PENALTY format: rN
When QUEUE_RAISE_PENALTY is set to rN (e.g., r4), only members whose current penalty
is greater than or equal to the defined min_penalty and less than or equal to max_penalty
will have their penalty raised to N.
Members with penalties outside the min/max range remain unchanged.
Example behaviors:
QUEUE_RAISE_PENALTY=4 → Raise all members with penalty < 4 (existing behavior)
QUEUE_RAISE_PENALTY=r4 → Raise only members with penalty in [min_penalty, max_penalty] to 4
Implementation details:
Adds parsing logic to detect the r prefix and sets the raise_respect_min flag
Modifies the raise logic to skip members outside the defined penalty range when the flag is active
UserNote: This change introduces QUEUE_RAISE_PENALTY=rN, allowing selective penalty raises
only for members whose current penalty is within the [min_penalty, max_penalty] range.
Members with lower or higher penalties are unaffected.
This behavior is backward-compatible with existing queue rule configurations.
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.
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.
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
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.
UserNote: A new asterisk.conf option 'disable_remote_console_shell' has
been added that, when set, will prevent remote consoles from executing
shell commands using the '!' prefix.
Resolves: #GHSA-c7p6-7mvq-8jq2
Full details: http://s.asterisk.net/dc679ec3
The previous proof-of-concept showed that the cpp_map_name_id alternate
storage backed performed better than all the others so this final PR
adds only that option. You still need to enable it in menuselect under
the "Alternate Channel Storage Backends" category.
To select which one is used at runtime, set the "channel_storage_backend"
option in asterisk.conf to one of the values described in
asterisk.conf.sample. The default remains "ao2_legacy".
UpgradeNote: With this release, you can now select an alternate channel
storage backend based on C++ Maps. Using the new backend may increase
performance and reduce the chances of deadlocks on heavily loaded systems.
For more information, see http://s.asterisk.net/dc679ec3
Adds support for Call Waiting Deluxe options to enhance
the current call waiting feature.
As part of this change, a mechanism is also added that
allows a channel driver to queue an audio file for Dial()
to play, which is necessary for the announcement function.
ASTERISK-30373 #close
Resolves: #271
UserNote: Call Waiting Deluxe can now be enabled for FXS channels
by enabling its corresponding option.
Add log-caller-id-name option to log Caller ID Name in queue log
This patch introduces a new global configuration option, log-caller-id-name,
to queues.conf to control whether the Caller ID name is logged when a call enters a queue.
When log-caller-id-name=yes, the Caller ID name is logged
as parameter 4 in the queue log, provided it’s allowed by the
existing log_restricted_caller_id rules. If log-caller-id-name=no (the default),
the Caller ID name is omitted from the logs.
Fixes: #1091
UserNote: This patch adds a global configuration option, log-caller-id-name, to queues.conf
to control whether the Caller ID name is logged as parameter 4 when a call enters a queue.
When log-caller-id-name=yes, the Caller ID name is included in the queue log,
Any '|' characters in the caller ID name will be replaced with '_'.
(provided it’s allowed by the existing log_restricted_caller_id rules).
When log-caller-id-name=no (the default), the Caller ID name is omitted.
Commands in the "[startup_commands]" section of cli.conf have historically run
after all core and module initialization has been completed and just before
"Asterisk Ready" is printed on the console. This meant that if you
wanted to debug initialization of a specific module, your only option
was to turn on debug for everything by setting "debug" in asterisk.conf.
This commit introduces options to allow you to run CLI commands earlier in
the asterisk startup process.
A command with a value of "pre-init" will run just after logger initialization
but before most core, and all module, initialization.
A command with a value of "pre-module" will run just after all core
initialization but before all module initialization.
A command with a value of "fully-booted" (or "yes" for backwards
compatibility) will run as they always have been...after all
initialization and just before "Asterisk Ready" is printed on the console.
This means you could do this...
```
[startup_commands]
core set debug 3 res_pjsip.so = pre-module
core set debug 0 res_pjsip.so = fully-booted
```
This would turn debugging on for res_pjsip.so to catch any module
initialization debug messages then turn it off again after the module is
loaded.
UserNote: In cli.conf, you can now define startup commands that run before
core initialization and before module initialization.
This adds the Last Number Redial feature to
simple switch.
UserNote: Users can now redial the last number
called if the lastnumredial setting is set to yes.
Resolves: #437
* 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.
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.
Fixes: #1007
UserNote: use the p option of AddQueueMember() for paused member state.
Optionally, use the r(reason) option to specify a custom reason for the pause.
Added a new option "unknown_tn_attest_level" to allow Identity
headers to be sent when a callerid TN isn't explicitly configured
in stir_shaken.conf. Since there's no TN object, a private_key_file
and public_cert_url must be configured in the attestation or profile
objects.
Since "unknown_tn_attest_level" uses the same enum as attest_level,
some of the sorcery macros had to be refactored to allow sharing
the enum and to/from string conversion functions.
Also fixed a memory leak in crypto_utils:pem_file_cb().
Resolves: #921
UserNote: You can now set the "unknown_tn_attest_level" option
in the attestation and/or profile objects in stir_shaken.conf to
enable sending Identity headers for callerid TNs not explicitly
configured.
Normally, when one party in a call sends Asterisk an SDP with
a "sendonly" or "inactive" attribute it means "hold" and causes
Asterisk to start playing MOH back to the other party. This can be
problematic if it happens at certain times, such as in a 183
Progress message, because the MOH will replace any early media you
may be playing to the calling party. If you set this option
to "yes" on an endpoint and the endpoint receives an SDP
with "sendonly" or "inactive", Asterisk will NOT play MOH back to
the other party.
Resolves: #979
UserNote: The new "suppress_moh_on_sendonly" endpoint option
can be used to prevent playing MOH back to a caller if the remote
end sends "sendonly" or "inactive" (hold) to Asterisk in an SDP.
