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.
* Update Dial() documentation for IAX2 to include syntax for RSA
public key names.
* Add additional details to a couple warnings to provide more context
when an undecodable frame is received.
Resolves: #1206
This fixes crashes/hangs I noticed with Asterisk 20.3.0 and 20.13.0 and quickly found out,
that the AEL module doesn't do proper cleanup when it fails to load.
This happens for example when there are syntax errors and AEL fails to compile in which case pbx_load_module()
returns an error but load_module() doesn't then unregister CLI cmds and the application.
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
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().
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.
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
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
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 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/
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
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,*,#...).
- 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>
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
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
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
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.
* 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
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
Commit 3cab4e7ab4 introduced a
regression by causing the wrong pointers to be used in certain
(more complex) cases. We now take care to ensure the exact
same pointers are used as before that commit, and simplify
by eliminating the unnecessary second for loop.
Resolves: #1147
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
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.
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.
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`
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`
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
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`.
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
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
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
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
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.
