Added a new option to HANGUPCAUSE to access additional information about hangup reason. Reason headers from pjsip could be read using 'tech_extended' cause type.
The DAHDI_CHANNEL function allows for getting/setting certain properties about DAHDI channels from the dialplan.
channelstorage_cpp fast lookup without lock (get_by_name_exact/get_by_uniqueid) leads to UAF during hangupFix some doxygen, typos and whitespace
rtp_engine.c: Add exception for comfort noise payload.
safe_asterisk: Fix logging and sorting issue.
func_hangupcause.c: Add access to Reason headers via HANGUPCAUSE()
res_pjsip_geolocation: Add support for Geolocation loc-src parameter
manager.c: Fix presencestate object leak
chan_dahdi: Add DAHDI_CHANNEL function.
safe_asterisk: Resolve a POSIX sh problem and restore globbing behavior.
res_audiosocket: add message types for all slin sample rates
Author: Sean Bright Date: 2025-10-22
== with the POSIX sh test utility is UB.$(find … | sort).Resolves: #1554
Author: George Joseph Date: 2025-10-17
Re-enabled "TTY=9" which was erroneously disabled as part of a recent security fix and removed another logging "fix" that was added.
Also added a sort to the "find" that enumerates the scripts to be sourced so they're sourced in the correct order.
Resolves: #1539
Author: Sven Kube Date: 2025-10-10
Extend audiosocket messages with types 0x11 - 0x18 to create asterisk frames in slin12, slin16, slin24, slin32, slin44, slin48, slin96, and slin192 format, enabling the transmission of audio at a higher sample rates. For audiosocket messages sent by Asterisk, the message kind is determined by the format of the originating asterisk frame.
UpgradeNote: New audiosocket message types 0x11 - 0x18 has been added for slin12, slin16, slin24, slin32, slin44, slin48, slin96, and slin192 audio. External applications using audiosocket may need to be updated to support these message types if the audiosocket channel is created with one of these audio formats.
Author: George Joseph Date: 2025-10-08
Some of the tests in process_text_message() were still comparing to the websocket message payload instead of the "command" string.
Resolves: #1525
Author: Igor Goncharovsky Date: 2025-09-04
As soon as SIP call may end with several Reason headers, we want to make all of them available through the HAGUPCAUSE() function. This implementation uses the same ao2 hash for cause codes storage and adds a flag to make difference between last processed sip message and content of reason headers.
UserNote: Added a new option to HANGUPCAUSE to access additional information about hangup reason. Reason headers from pjsip could be read using 'tech_extended' cause type.
Author: George Joseph Date: 2025-10-01
When we retrieve a channel from a C++ map, we actually get back a wrapper object that points to the channel then right after we retrieve it, we bump its reference count. There's a tiny chance however that between those two statements a delete and/or unref might happen which would cause the wrapper object or the channel itself to become invalid resulting in a SEGV. To avoid this we now perform a read lock on the driver around those statements.
Resolves: #1491
Author: Max Grobecker Date: 2025-09-21
This adds support for the Geolocation 'loc-src' parameter to res_pjsip_geolocation. The already existing config option 'location_source` in res_geolocation is documented to add a 'loc-src' parameter containing a user-defined FQDN to the 'Geolocation:' header, but that option had no effect as it was not implemented by res_pjsip_geolocation.
If the location_source configuration option is not set or invalid, that parameter will not be added (this is already checked by res_geolocation).
This commits adds already documented functionality.
Author: Sven Kube Date: 2025-09-22
When handling SIP transfers via ARI, there is no protocol_id in case of a blind transfer.
Resolves: #1467
Author: Bastian Triller Date: 2025-09-21
Author: Sven Kube Date: 2025-09-18
When handling SIP transfers via ARI, the referred_by field in
transfer_ari_state may be null, since SIP REFER requests are not
required to include a Referred-By header. Without this check, a null
value caused the transfer to fail and triggered a NOTIFY with a 500
Internal Server Error.
Author: phoneben Date: 2025-09-11
Add NULL check for word_list before calling word_in_list() Add NULL checks for channel snapshots from ast_multi_channel_blob_get_channel()
Resolves: #1425
Author: Sean Bright Date: 2025-09-17
Resolves: #1422
Author: Naveen Albert Date: 2025-09-11
Add a dialplan function that can be used to get/set properties of DAHDI channels (as opposed to Asterisk channels). This exposes properties that were not previously available, allowing for certain operations to now be performed in the dialplan.
Resolves: #1455
UserNote: The DAHDI_CHANNEL function allows for getting/setting certain properties about DAHDI channels from the dialplan.
Author: Naveen Albert Date: 2025-09-10
get_token can return NULL, but process_token uses this result without checking for NULL; as elsewhere, check for a NULL result to avoid possible NULL dereference.
Resolves: #1419
Author: Nathan Monfils Date: 2025-09-08
ast_presence_state allocates subtype and message. We straightforwardly need to clean those up.
Author: Sean Bright Date: 2025-09-10
Part of #1440.
Author: Naveen Albert Date: 2025-09-09
Resolves: #1436
Author: Ben Ford Date: 2025-09-09
In a previous commit, a change was made to ast_rtp_codecs_payload_code_tx_sample_rate to check for differing sample rates. This ended up returning an invalid payload int for comfort noise. A check has been added that returns early if the payload is in fact supposed to be comfort noise.
Fixes: #1340
Author: Naveen Albert Date: 2025-09-09
"dialplan eval function" has been using a dummy channel for function evaluation, much like many of the unit tests. However, sometimes, this can cause issues for functions that are not expecting dummy channels. As an example, ast_channel_tech(chan) is NULL on such channels, and ast_channel_tech(chan)->type consequently results in a NULL dereference. Normally, functions do not worry about this since channels executing dialplan aren't dummy channels.
While some functions are better about checking for these sorts of edge cases, use a real channel with a dummy technology to make this CLI command inherently safe for any dialplan function that could be evaluated from the CLI.
Resolves: #1434