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 5f9cd260ac)
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 cc92adc5fb)
Adds two files to the contrib/systemd/ directory that can be installed
to periodically run "malloc trim" on Asterisk. These files do nothing
unless they are explicitly moved to the correct location on the system.
Users who are experiencing Asterisk memory issues can use this service
to potentially help combat the problem. These files can also be
configured to change the start time and interval. See systemd.timer(5)
and systemd.time(7) for more information.
UserNote: Service and timer files for systemd have been added to the
contrib/systemd/ directory. If you are experiencing memory issues,
install these files to have "malloc trim" periodically run on the
system.
(cherry picked from commit 6925b0118e)
Under certain circumstances the context/extens/prio are stored in the
after_bridge_goto_info. This info is used when the bridge is broken by
for hangup of the other party. In the situation that the bridge is
broken by an AMI Redirect this info is not used but also not removed.
With the result that when the channel is put back in a bridge and the
bridge is broken the execution continues at the wrong
context/extens/prio.
Resolves: #1144
(cherry picked from commit f9e5b9aa01)
When queueing a channel to be hung up a cause code can be
specified in one of two ways:
1. ast_queue_hangup_with_cause
This function takes in a cause code and queues it as part
of the hangup request, which ultimately results in it being
set on the channel.
2. ast_channel_hangupcause_set + ast_queue_hangup
This combination sets the hangup cause on the channel before
queueing the hangup instead of as part of that process.
In the #2 case the ChannelHangupRequest event would not contain
the cause code. For consistency if a cause code has been set
on the channel it will now be added to the event.
Resolves: #1197
(cherry picked from commit ca341910e7)
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.
(cherry picked from commit f843f24be4)
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.
(cherry picked from commit aacabb48ee)
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 234ca964e5)
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 4e07d3d50f)
Add the capability to audiohook for float type volume adjustments. This allows for adjustments to volume smaller than 6dB. With INT adjustments, the first step is 2 which converts to ~6dB (or 1/2 volume / double volume depending on adjustment sign). 3dB is a typical adjustment level which can now be accommodated with an adjustment value of 1.41.
This is accomplished by the following:
Convert internal variables to type float.
Always use ast_frame_adjust_volume_float() for adjustments.
Cast int to float in original functions ast_audiohook_volume_set(), and ast_volume_adjust().
Cast float to int in ast_audiohook_volume_get()
Add functions ast_audiohook_volume_get_float, ast_audiohook_volume_set_float, and ast_audiohook_volume_adjust_float.
This update maintains 100% backward compatibility.
Resolves: #1171
(cherry picked from commit 874fde5924)
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 c44e7e85ec)
- 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 218c64c4eb)
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 51f9e1f1ba)
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 ad178d155d)
With `sounds_search_custom_dir = yes` we first look to see if a sound file
is present in the "custom" sound directory before looking in the standard
sound directories. We should not be issuing a WARNING log message if a
sound cannot be found in the "custom" directory.
Resolves: https://github.com/asterisk/asterisk/issues/1170
(cherry picked from commit df8c32f092)
Gosub and Goto were not displaying their syntax correctly on the docs
site. This change adds a new way to specify an optional context, an
optional extension, and a required priority that the xml stylesheet can
parse without having to know which optional parameters come in which
order. In Asterisk, it looks like this:
parameter name="context" documentationtype="dialplan_context"
parameter name="extension" documentationtype="dialplan_extension"
parameter name="priority" documentationtype="dialplan_priority" required="true"
The stylesheet will ignore the context and extension parameters, but for
priority, it will automatically inject the following:
[[context,]extension,]priority
This is the correct oder for applications such as Gosub and Goto.
(cherry picked from commit 11684bc0d3)
Commit e86f937e added AMI documentation to the module but the cherry-pick
from master to the 20 branch pulled in an xpointer reference to the
`user_agent` config option which doesn't actually exist in 20. This causes
asterisk to fail to start because it can't load the core-en_US.xml
documentation file. The CI cherry-pick tests should have caught this but
there was bug in the cherry-picker that was causing the commits to be
cherry-picked to the wrong branch. Just removing the xpointer reference
resolves the issue.
(cherry picked from commit 92e02c1574)
* Outdated information has been removed.
* New links added.
* Placeholder added for link to change logs.
Going forward, the release process will create HTML versions of the README
and change log and will update the link in the README to the current
change log for the branch...
* In the development branches, the link will always point to the current
release on GitHub.
* In the "releases/*" branches and the tarballs, the link will point to the
ChangeLogs/ChangeLog-<version>.html file in the source directory.
* On the downloads website, the link will point to the
ChangeLog-<version>.html file in the same directory.
Resolves: #1131
(cherry picked from commit 9f4b52bf2b)
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 53f3ac7925)
The `CreateConfig` manager action now ensures that a config file can
only be created in the AST_CONFIG_DIR unless `live_dangerously` is set.
Resolves: #1122
(cherry picked from commit 266440ab20)
Recent python versions complain when backslashes in strings create invalid
escape sequences. This causes issues for strings used as regex patterns like
`'^List\[(.*)\]$'` where you want the regex parser to treat `[` and `]`
as literals. Double-backslashing is one way to fix it but simply converting
the string to a raw string `re.match(r'^List\[(.*)\]$', text)` is easier
and less error prone.
(cherry picked from commit cc267af3e1)
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 5565d00eb4)
Found via `codespell -q 3 -S "./CREDITS,*.po" -L abd,asent,atleast,cachable,childrens,contentn,crypted,dne,durationm,enew,exten,inout,leapyear,mye,nd,oclock,offsetp,ot,parm,parms,preceeding,pris,ptd,requestor,re-use,re-used,re-uses,ser,siz,slanguage,slin,thirdparty,varn,varns,ues`
(cherry picked from commit aa20bfcf99)
Found via `codespell -q 3 -S "./CREDITS" -L abd,asent,atleast,childrens,contentn,crypted,dne,durationm,exten,inout,leapyear,nd,oclock,offsetp,ot,parm,parms,requestor,ser,slanguage,slin,thirdparty,varn,varns,ues`
(cherry picked from commit d2bcdb71f8)
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 6cf62b6032)
GitHub strikes again. Apparently the github.ref context variable only
contains the PR number if the workflow is triggered by "pull_request" so
since we just changed the trigger to "pull_request_target" the variable
no longer contains the PR number and is therefore not unique and can't be
used as a concurrency group id. We now use
`github.triggering_actor-github.head_ref`.
(cherry picked from commit 32b0b47348)
Due to a potential race condition via ARI when hanging up a channel hangup with cause
while also deleting a bridge containing that channel, the bridge delete can over-write
the hangup cause code resulting in Normal Call Clearing instead of the set value.
With this change, bridge deletion will only set the hangup code if it hasn't been
previously set.
Resolves: #1124
(cherry picked from commit a39f3d5adb)
After careful review, we believe we can now use the "pull_request_target"
workflow trigger instead of "pull_request" which required a separate
privliged workflow to add labels and comments to PRs when they are submitted
or updated. This allows us to greatly streamline our workflows and remove
unneeded ones.
* The OnPRChanged workflow was...
* Renamed to OnPRCheck
* Changed to trigger on pull_request_target and the "recheckpr" label.
* Changed to simply call reusable workflows in asterisk-ci-actions.
* Changed to use better concurrency groups.
* The OnPRCPCheck and OnPRMergeApproved workflows were also...
* Changed to simply call reusable workflows in asterisk-ci-actions.
* Changed to use better concurrency groups.
* The NightlyTest and CreateDocs were also tweaked
(cherry picked from commit 1f56d5fe7e)
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 0b6a3df331)
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 873c247f75)
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 5e4fca062c)
Apparently you can't use `${{ github.event.number }}` in a concurrency
block in a job that calls a reusable workflow. :(
(cherry picked from commit 00af359ea9)
Nothing ever sets the `AST_GENERATOR_FD`, so this block of code will
never execute. It also is the only place where the `generate` callback
is called with the channel lock held which made it difficult to reason
about the thread safety of `ast_generator`s.
In passing, also note that `AST_AGENT_FD` isn't used either.
(cherry picked from commit 0883e5e44d)
