Severity

Trivial

Versions

18, 20, master

Components/Modules

res_musiconhold

Operating Environment

ubuntu

Frequency of Occurrence

None

Issue Description

CommUnity UCaaS submission - moh_files_generator releases channel lock while still accessing channel moh state.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Feature Description

Adds an option to res_musiconhold that allows the last audio file in the list to be looped perpetually, rather than starting over at the beginning again.

Imported from JIRA: https://issues.asterisk.org/jira/browse/ASTERISK-30462

Improvement Description

This adds several master-only APIs to res_pjsip_pubsub that are necessary for future features that rely on functionality not currently supported by res_pjsip_pubsub.

Imported from: https://issues.asterisk.org/jira/browse/ASTERISK-30485

Feature Description

Currently, pulse and tone dialing are enabled on all FXS lines and there is no way to control this at all.

Adds a "dialmode" option to DAHDI that can be set to four different options:

1. both (default)
2. pulse
3. dtmf or tone
4. none

This allows for specifying, on a per-line basis, which types of signaling methods are allowed on FXS lines. Additionally, the dialmode can be updated during a call.

Imported from: https://issues.asterisk.org/jira/browse/ASTERISK-29992

Feature Description

The time zone used for Caller ID generation is currently hardcoded to the system time zone, and cannot be specified by modules using the Caller ID function. This makes it possible to optionally specify a tz format timezone.

Severity

Minor

Versions

20, 18

Components/Modules

Resources/res_sorcery_memory_cache

Operating Environment

CentOS 8.5

Frequency of Occurrence

Constant

Issue Description

The pointer returned by ast_strdup had never been freed.
Imported from: https://issues.asterisk.org/jira/browse/ASTERISK-30429

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Major

Versions

master,20,19,18,16

Components/Modules

chan_spy, channels

Operating Environment

Right now, testing with branch 18, but this should be on all versions.

Frequency of Occurrence

Frequent

Issue Description

The ChanSpy() channel iterator holds references to channels for the duration of the listening/spying. These referenced channels will get destroyed first when the channel iteration resumes (when done listening to that one channel). This is a problem for the CEL HANGUP event, because all channels still in the iterator will not get any HANGUP reporting until this resumption: anyone relying on CEL HANGUP time for call duration statistics will get wrong values.

A.k.a. CEL HANGUP times can be wrong (late) and appear "batched".

Components

• ChanSpy -- iterates over all channels using (e.g. ast_channel_iterator_by_name_new) -- keeps the iterator until the spying is done:

  • asterisk/apps/app_chanspy.c

    Lines 956 to 964 in 1a7866b

    	iter = ast_channel_iterator_by_name_new(ast_channel_name(unique_chan), 0);
    	ast_channel_unref(unique_chan);
    	} else {
    	iter = ast_channel_iterator_by_name_new(spec, strlen(spec));
    	}
    	} else if (!ast_strlen_zero(exten)) {
    	iter = ast_channel_iterator_by_exten_new(exten, context);
    	} else {
    	iter = ast_channel_iterator_all_new();

  • asterisk/apps/app_chanspy.c

    Lines 994 to 999 in 1a7866b

    	for (autochan = next_channel(iter, chan);
    	autochan;
    	prev = autochan->chan,
    	ast_autochan_destroy(autochan),
    	autochan = next_autochan ?: next_channel(iter, chan),
    	next_autochan = NULL) {

  • asterisk/apps/app_chanspy.c

    Line 1146 in 1a7866b

    res = channel_spy(chan, autochan, &volfactor, fd, user_options, flags, exitcontext);

  • asterisk/apps/app_chanspy.c

    Line 1184 in 1a7866b

    iter = ast_channel_iterator_destroy(iter);

• CEL hangup events -- are generated because of a publish by the ast_channel destructor:

  • asterisk/main/channel.c

    Lines 2206 to 2213 in 1a7866b

    	ast_set_flag(ast_channel_flags(chan), AST_FLAG_DEAD);
    	if (ast_channel_internal_is_finalized(chan)) {
    	/* A channel snapshot should not be in the process of being staged now. */
    	ast_assert(!ast_test_flag(ast_channel_flags(chan), AST_FLAG_SNAPSHOT_STAGE));
    	ast_channel_lock(chan);
    	ast_channel_publish_final_snapshot(chan);

  • asterisk/main/stasis_channels.c

    Lines 948 to 950 in 1a7866b

    	ast_channel_snapshot_set(chan, NULL);
    	stasis_publish(ast_channel_topic(chan), message);

  • asterisk/main/cel.c

    Lines 910 to 921 in 1a7866b

    	was_hungup = ast_test_flag(&old_snapshot->flags, AST_FLAG_DEAD) ? 1 : 0;
    	is_hungup = ast_test_flag(&new_snapshot->flags, AST_FLAG_DEAD) ? 1 : 0;
    	if (!was_hungup && is_hungup) {
    	struct ast_json *extra;
    	struct cel_dialstatus *dialstatus = get_dialstatus(new_snapshot->base->uniqueid);
    	extra = ast_json_pack("{s: i, s: s, s: s}",
    	"hangupcause", new_snapshot->hangup->cause,
    	"hangupsource", new_snapshot->hangup->source,
    	"dialstatus", dialstatus ? dialstatus->dialstatus : "");
    	cel_report_event(new_snapshot, AST_CEL_HANGUP, event_time, NULL, extra, NULL);

To get accurate HANGUP timings from CEL, channel destruction should never be delayed for more than a short while.

But because some components (ChanSpy) can hold references to channels that are hung up, destruction can be delayed for an indetermined amount of time.

This results in inaccurate CEL HANGUP timestamps: those who rely on CEL HANGUP time for call duration statistics will get wrong values

Scenario

At t=0, we might have three channels:

• channelA, ref (1)
• channelB, ref (1)
• channelC, ref (1)

At t=1 we start spying on channels using ChanSpy. The channels (hash) container is filtered and turned into a (list) container (multi_container ()) holding a snapshot of then active channels that match the filter: the multi_iterator (). This list/iterator is returned to the application (chanspy):

• channelA, +1 ref (=2) (__ao2_link() -> rb_ao2_new_node() -> "Container node creation")
• channelB, +1 ref (=2)
• channelC, +1 ref (=2)

At t=1, we traverse the iterator. We might decide to skip channelA and start spying on channelB:

• channelA, +1 ref /* Bump ref of returned object */ ("Next iterator object."), replace last_node (NULL), last_node = channelA, return channelA
• ignore channelA: -1 ref, get next
• channelB, +1 ref /* Bump ref of returned object */ ("Next iterator object."), replace last_node (channelA, -1 ref), last_node = channelB
• start listening on channelB (channel_spy)

At this point, the references look like this:

• channelA, +1-1-1 ref (=1)
• channelB, +1 ref (=3)
• channelC, +0 ref (=2)

Now, at t=2, channelA and channelC hang up:

• channelA, -1 ref (=0) -> destroying
• channelB, +0 ref (=3)
• channelC, -1 ref (=1)

First at t=3, when either the spying channel hangs up, or the spyee hangs up, do we exit channel_spy and do we resume looking at the multi_iterator:

• channelC, -1 ref (=0) -> destroying

This causes the channelC destroying event to fire at t=3 instead of t=2. And that means that the reported CEL time for the hangup event is wrong.

Solutions

• Either the CEL HANGUP event should not be fired by the channel destructor,
• or no component should be allowed to hold references to channels that are hung up (read: channel iterators should be short-lived).

Someone should make a design decision on this. I would say the least impactful is to make the chanspy iterator short-lived, by copying the IDs of the channels and iterating over the channel IDs instead.

But if we can make the HANGUP event fire sooner by moving the AST_FLAG_DEAD+publish to something earlier, that works for me too.

Cheers,
Walter Doekes
OSSO B.V.

(*) The channel iteration:

ast_channel_iterator_by_name_new() -> ast_channel_callback() -> ao2_callback_data() -> __ao2_callback_data() -> internal_ao2_traverse()

• asterisk/main/astobj2_container.c

  Lines 260 to 273 in 1a7866b

  	if ((flags & (OBJ_MULTIPLE | OBJ_NODATA)) == OBJ_MULTIPLE) {
  	/* we need to return an ao2_iterator with the results,
  	* as there could be more than one. the iterator will
  	* hold the only reference to a container that has all the
  	* matching objects linked into it, so when the iterator
  	* is destroyed, the container will be automatically
  	* destroyed as well.
  	*/
  	multi_container = ao2_t_container_alloc_list(AO2_ALLOC_OPT_LOCK_NOLOCK, 0, NULL,
  	NULL, "OBJ_MULTIPLE return container creation");
  	if (!multi_container) {
  	return NULL;
  	}
  	if (!(multi_iterator = ast_calloc(1, sizeof(*multi_iterator)))) {

• asterisk/main/astobj2_container.c

  Line 356 in 1a7866b

  __ao2_link(multi_container, node->obj, flags, tag, file, line, func);

(an ao2_container list is created to hold the filtered channels)

next_channel() -> ast_channel_iterator_next() -> ao2_iterator_next() -> __ao2_iterator_next():

• asterisk/main/astobj2_container.c

  Lines 603 to 604 in 1a7866b

  	/* Bump ref of returned object */
  	__ao2_ref(ret, +1, tag ?: "Next iterator object.", file, line, func);

• asterisk/apps/app_chanspy.c

  Lines 994 to 999 in 1a7866b

  	for (autochan = next_channel(iter, chan);
  	autochan;
  	prev = autochan->chan,
  	ast_autochan_destroy(autochan),
  	autochan = next_autochan ?: next_channel(iter, chan),
  	next_autochan = NULL) {

(channels are popped from the ao2_container list, but not as immediate as we would like)

Relevant log output

Many charlies, some of whom are too late:

[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9b8021a58 'SIP/charlie-0000004c' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa01eb458 'SIP/charlie-0000004b' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa027a608 'SIP/charlie-0000004e' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa0263a48 'SIP/charlie-0000004d' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9c001f878 'SIP/charlie-0000004f' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa022a6c8 'SIP/charlie-0000005b' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa0222048 'SIP/charlie-0000005d' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9dc01e7c8 'SIP/charlie-0000005e' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9e8020238 'SIP/charlie-0000005f' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa01a34c8 'SIP/charlie-00000041' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc98000cc68 'SIP/charlie-00000042' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc97c00c418 'SIP/charlie-00000044' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc99c01f868 'SIP/charlie-00000047' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa01cb7a8 'SIP/charlie-00000046' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa01e3208 'SIP/charlie-00000049' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9bc021b18 'SIP/charlie-00000050' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9c8021078 'SIP/charlie-00000052' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa02a91b8 'SIP/charlie-00000053' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9d00211c8 'SIP/charlie-00000056' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9e800a908 'SIP/charlie-0000000e' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa009c888 'SIP/charlie-0000000c' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa00ed368 'SIP/charlie-0000001f' destroying
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fcaa028ec78 'SIP/alice-00000060' destroying
[May  8 11:50:15] DEBUG[149070][C-0000001a] channel.c: Channel 0x7fcaa014ee18 'SIP/alice-00000031' destroying
[May  8 11:50:15] DEBUG[149081][C-0000001a] channel.c: Channel 0x7fc98800bad8 'SIP/alice-00000034' destroying
[May  8 11:50:15] DEBUG[149080][C-00000023] channel.c: Channel 0x7fcaa01e0d98 'SIP/bob-00000043' destroying
[May  8 11:50:15] DEBUG[149100][C-00000023] channel.c: Channel 0x7fc98400cb18 'SIP/bob-00000045' destroying
[May  8 11:50:15] DEBUG[149096][C-0000002a] channel.c: Channel 0x7fcaa0294298 'SIP/charlie-00000051' destroying
[May  8 11:50:15] DEBUG[149110][C-0000002a] channel.c: Channel 0x7fc9c4020f38 'SIP/charlie-00000054' destroying

Singling out a single Charlie:

[May  8 11:49:49] VERBOSE[149117][C-00000031] app_chanspy.c: Spying on channel SIP/alice-00000034
[May  8 11:50:07] DEBUG[149106][C-00000026] channel.c: Channel 0x7fc9b8021a58 'SIP/charlie-0000004c' hanging up.  Refs: 3
[May  8 11:50:15] VERBOSE[149117][C-00000031] app_chanspy.c: Done Spying on channel SIP/alice-00000034
[May  8 11:50:15] DEBUG[149117][C-00000031] channel.c: Channel 0x7fc9b8021a58 'SIP/charlie-0000004c' destroying

As seen, the destroying is late.

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Improvement Description

https://community.asterisk.org/t/stream-labels-in-sdp/96875/5

Bridge creation from the ARI does not allow for the bridge to be configured to allow SDP labels to be sent i.e.

a=label:example-1683802292.2456

Confbridge enables this option when events are enabled.

Adding support for this allows a client to match media streams to the originating channels

Feature Description

When an SDP negotiation has finished during an initial INVITE transaction and the SDP was sent using a reliable 1xx response, session modifications are allowed in the early media state by sending UPDATEs (RFC 6337 contains many details, especially section 3.2).

Asterisk does not allow this yet, but there are use cases in which session modifications in the early media state are necessary.

Feature Description

This patch is motivated by our need to access SIP reason header information from dialplan. To use current mechanisms as much as possible, but not to change current behavior, we decided to add new parameter value 'tech2' to dialplan function HANGUPCAUSE() function and use existing struct ast_control_pvt_cause_code for storing and transporting Reason header data.

New field tech2_offset is added to struct ast_control_pvt_cause_code. It allows to store 2 strings in struct field 'code'.
If tech2_offset > 0 then second string starts on that offset, otherwise second string is not present.
Dialplan function HANGUPCAUSE() is modified to accept parameter value 'tech2' and return the second string from proper
ast_control_pvt_cause_code structure.

Reason header processing in res_pjsip_rfc3326.c is updated to send found reason header value to current channel and also to bridged peer channel in ast_control_pvt_cause_code structure.

Severity

Major

Versions

18

Components/Modules

chan_pjsip,res_pjsip

Operating Environment

Debian Buster

Frequency of Occurrence

Constant

Issue Description

Issue:

• Modern client like LinPhone or a brand new Yealink... no issue with SIP TLS on PJSIP
• Older useragent Polycom Soundstation 550 cannot communicate with PJSIP, but can with CHAN_SIP
• Older useragent (but not THAT old!) Polycom VVX 500 cannot communicate with PJSIP but can with CHAN_SIP

Attachment: TLS-Working --
tls-working.txt
This is the Client Hello from LinPhone 5 and the resulting Server Hello from Asterisk... the rest of the TLS session goes without a hitch... phone can make/receive calls... everything is fine.

Attachment: TLS-Not-Working -- This is the Client Hello from Polycom Soundpoint 550,
tls-notworking.txt

and Asterisk/PJSIP responds with

Transport Layer Security
    TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
        Content Type: Alert (21)
        Version: TLS 1.2 (0x0303)
        Length: 2
        Alert Message
            Level: Fatal (2)
            Description: Handshake Failure (40)

And the following is printed in the Asterisk Console:

[2023-05-17 22:47:38.379-0500] WARNING[1532]:                      SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <337092801> <SSL routines-tls_post_process_client_hello-no shared cipher> len: 0 peer: 192.168.50.200:47481

If the Polycom Soundpoint client is untouched, Asterisk restarted without pjsip, and use chan_sip instead, this phone registers and places calls with no issues.

Additionally. Here's the Client Hello and Server Hello from the same Polycom 550 and Asterisk, but using chan_sip
older-tls-working-chan_sip.txt

pjsip.conf

[transport-tcp-tls]
type                       = transport
symmetric_transport        = yes
protocol                   = tls
allow_reload               = no
bind                       = 0.0.0.0:5061
tos                        = cs3
cos                        = 3
cert_file                  = /full/path/to/file
priv_key_file             =  /full/path/to/file
method                     = tlsv1_2

openssl.cnf
openssl.cnf.txt
And

# openssl ciphers -v
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES256-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES256-SHA    TLSv1 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-RSA-AES128-SHA    TLSv1 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(256) Mac=AEAD
RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
PSK-AES256-GCM-SHA384   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(256) Mac=AEAD
PSK-CHACHA20-POLY1305   TLSv1.2 Kx=PSK      Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(128) Mac=AEAD
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
PSK-AES128-GCM-SHA256   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(256)  Mac=SHA384
ECDHE-PSK-AES256-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(256)  Mac=SHA1
SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1
SRP-AES-256-CBC-SHA     SSLv3 Kx=SRP      Au=SRP  Enc=AES(256)  Mac=SHA1
RSA-PSK-AES256-CBC-SHA384 TLSv1 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA384
DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK   Au=PSK  Enc=AES(256)  Mac=SHA384
RSA-PSK-AES256-CBC-SHA  SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-PSK-AES256-CBC-SHA  SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
PSK-AES256-CBC-SHA384   TLSv1 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA384
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA256
ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA1
SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(128)  Mac=SHA1
SRP-AES-128-CBC-SHA     SSLv3 Kx=SRP      Au=SRP  Enc=AES(128)  Mac=SHA1
RSA-PSK-AES128-CBC-SHA256 TLSv1 Kx=RSAPSK   Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK   Au=PSK  Enc=AES(128)  Mac=SHA256
RSA-PSK-AES128-CBC-SHA  SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-PSK-AES128-CBC-SHA  SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
PSK-AES128-CBC-SHA256   TLSv1 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA256
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1

Relevant log output

See Above

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Trivial

Versions

GIT

Components/Modules

Core

Operating Environment

N/A

Frequency of Occurrence

None

Issue Description

Remove the, now obsolete, .gitreview file from the root of the project.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Feature Description

A previous patch from last year added internal support for full Caller ID to the Asterisk core. This now updates chan_dahdi to take advantage of this support.

Imported from: ASTERISK-30331

Severity

Minor

Versions

16.29.0, 18.15.0, 20.0.0

Components/Modules

res_pjsip, res_pjsip_outbound_registration

Operating Environment

Debian 11

Frequency of Occurrence

Constant

Issue Description

The Deutsche Telekom requires certain headers in SIP requests which are based on draft-dawes-sipcore-mediasec-parameter. This draft requires different headers in requests sent after a 401 as compared to 494. Specifically, in requests sent after a 401 response, the Security-Client header must still be present (see section 6.1 in the draft) while in requests after a 494 it should not be present.

The original mediasec implementation didn't consider that.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Minor

Versions

all

Components/Modules

func_curl

Operating Environment

Ubuntu 22

Frequency of Occurrence

Constant

Issue Description

using func_curl from dialplan and adding a header that already exists duplicates it and leave the request in a bad format

Example

exten = _X.,1,Set(CURLOPT(httpheader)=Authorization: basic TEST)
 same =     n,Set(CURLOPT(httpheader)=Content-Type: application/json)
 same =     n,Set(CALLERID(num)=${CURL(https://${SERVERDOMAIN}/test)}))
 same =     n,Set(CURLOPT(httpheader)=Authorization: basic TEST)
 same =     n,Set(CURLOPT(httpheader)=Content-Type: application/json)
 same =     n,Set(CALLERID(num)=${CURL(https://${SERVERDOMAIN}/test)}))

one solution could be use AST_LIST_HEAD_INIT(list); in acf_curl_helper after the unlock if this is ok for you I will make a patch here

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Blocker

Versions

20.3.0

Components/Modules

res_srtp

Operating Environment

Alma Linux 9
Red Hat Enterprise 9
Oracle Linux 9
Rocky Linux 9

Frequency of Occurrence

Constant

Issue Description

Asterisk crash on startup, when module res_srtp is loading.
Issue ocur when using latest libsrtp (2.3.0).

If I build libsrtp 1.5 (rpm rebuild from EL8), issue not ocur.

Relevant log output

Loading res_srtp.so.
[May 26 12:52:12] WARNING[1277916]: res_srtp.c:1238 res_srtp_init: Failed to initialize libsrtp
[May 26 12:52:12] ERROR[1277916]: loader.c:2524 load_modules: *** Failed to load module res_srtp.so
[May 26 12:52:12] ERROR[1277916]: asterisk.c:4039 check_init: Module initialization failed.  ASTERISK EXITING!

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Minor

Versions

18,20,master

Components/Modules

codec_ilbc

Operating Environment

Fedora 37
ilbc-3.0.4-3.fc37.x86_64

Frequency of Occurrence

Constant

Issue Description

ilbc 3.0 has api changes that prevent codec_ilbc from building

Relevant log output

[CC] codec_ilbc.c -> codec_ilbc.o
codec_ilbc.c: In function ‘lintoilbc_new’:
codec_ilbc.c:79:9: error: implicit declaration of function ‘initEncode’ [-Werror=implicit-function-declaration]
   79 | initEncode(&tmp->enc, mode);
      | ^~~~~~~~~~
codec_ilbc.c: In function ‘ilbctolin_framein’:
codec_ilbc.c:130:17: error: implicit declaration of function ‘initDecode’ [-Werror=implicit-function-declaration]
  130 | initDecode(&tmp->dec, mode, USE_ILBC_ENHANCER);
      | ^~~~~~~~~~
codec_ilbc.c:139:17: error: implicit declaration of function ‘iLBC_decode’ [-Werror=implicit-function-declaration]
  139 | iLBC_decode(tmpf, plc_mode ? f->data.ptr + x : NULL, &tmp->dec, plc_mode);
      | ^~~~~~~~~~~
codec_ilbc.c: In function ‘lintoilbc_frameout’:
codec_ilbc.c:184:17: error: implicit declaration of function ‘iLBC_encode’ [-Werror=implicit-function-declaration]
  184 | iLBC_encode((ilbc_bytes *) pvt->outbuf.BUF_TYPE, tmpf, &tmp->enc);
      | ^~~~~~~~~~~
cc1: all warnings being treated as errors

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Minor

Versions

20.2.1

Components/Modules

CLI

Operating Environment

Stock Ubuntu 22.04.2 LTS (Jammy Jellyfish)

Frequency of Occurrence

Constant

Issue Description

Can't enter any of UFT-8 character in the CLI prompt - it just beeps. If I change AST_EDITOR to 'vi' mode then I have:

*CLI> \U+FFFF\U+FFFF\U+FFFF\U+FFFF\U+FFFF\U+FFFF\U+FFFF\U+FFFF

Seems like problem with libedit. The previous asterisk versions allow to use internal libedit - current one do not.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Trivial

Versions

18.14.0, 18.16.0, 20.2.0

Components/Modules

res_speech_aeap

Operating Environment

Amazon Linux 2 on x86_64 and aarch64

Frequency of Occurrence

None

Issue Description

This is a carry forward of https://issues.asterisk.org/jira/browse/ASTERISK-30420 which has been reconfirmed as a continuing issue on v20 as well as v18.

We receive from Asterisk:

{
    "request": "setup",
    "version": "0.1.0",
    "codecs":
    [
        {
            "name": "ulaw"
        }
    ],
    "params":
    {},
    "id": "211233a3-48de-4758-b46c-90b3701a3d06"
}

We reply successfully with:

{
    "response": "setup",
    "id": "211233a3-48de-4758-b46c-90b3701a3d06",
    "codecs":
    [
        {
            "name": "ulaw"
        }
    ]
}

Asterisk shows the following, and then SEGFAULTs:

ERROR[19158] res_aeap/transaction.c: AEAP transaction (0x7f5f0800f8d0): message 'setup' timed out
VERBOSE[8438][C-0000003b] pbx.c: Executing [17195559990@dial-out:7] SpeechStart("IAX2/hwl-pbx-5767", "") in new stack
VERBOSE[8438][C-0000003b] pbx.c: Spawn extension (dial-out, 17195559990, 7) exited non-zero on 'IAX2/hwl-pbx-5767'
VERBOSE[8438][C-0000003b] chan_iax2.c: Hungup 'IAX2/hwl-pbx-5767'

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Major

Versions

18.17.1

Components/Modules

talkdetect / dsp

Operating Environment

all

Frequency of Occurrence

Occasional

Issue Description

talk_detect signals premature detection of the end of speech (and reported negative duration).

In the example log, talk detect was established with an end silence duration of 1500 milliseconds, but events were signalled well before that period was reached.

The talk_detect_audiohook_cb() function in func_talkdetect.c declares the variable total_silence without initialising it.
It then passes the address of that variable to the ast_dsp_silence() function, and expects to use the contents of the variable after the dsp function returns zero (to tell how long the silence has been).

Now, perhaps total_silence should have been initialised to zero, or perhaps the fault lies with the ast_dsp_silence_noise_with_energy() function (called by ast_dsp_silence()) failing to set a value for the total silence found. but either way, for the ChannelTalkingFinished event to be signalled with a negative duration it looks like the ast_dsp_silence() function must be returning zero and total_silence must contain a value greater than the silence threshold (1500 in my case). Since ast_dsp_silence_noise_with_energy() is undocumented, it's hard to tell whether the fault lies with the calling talk_detect code or in the dsp code.

Relevant log output

{
    application = TestApp;
    "asterisk_id" = "4c:d9:8f:45:ca:aa";
    recording = {
        format = sln16;
        name = "110_252027_2";
        state = recording;
        "target_uri" = "channel:1683631086.5164";
    };
    timestamp = "2023-05-09T12:18:28.412+0100";
    type = RecordingStarted;
}
{
    application = TestApp;
    "asterisk_id" = "4c:d9:8f:45:ca:aa";
    channel = {
        accountcode = "";
        caller = {
            name = "";
            number = "+xxxxxxxxxxxx";
        };
        connected = {
            name = "";
            number = "";
        };
        creationtime = "2023-05-09T12:18:06.713+0100";
        dialplan = {
            "app_data" = TestApp;
            "app_name" = Stasis;
            context = Colt;
            exten = "+***********";
            priority = 1;
        };
        id = "1683631086.5164";
        language = en;
        name = "PJSIP/Colt-00000a1e";
        "protocol_id" = "[email protected]";
        state = Up;
    };
    timestamp = "2023-05-09T12:18:28.452+0100";
    type = ChannelTalkingStarted;
}
{
    application = TestApp;
    "asterisk_id" = "4c:d9:8f:45:ca:aa";
    channel = {
        accountcode = "";
        caller = {
            name = "";
            number = "+xxxxxxxxxxxx";
        };
        connected = {
            name = "";
            number = "";
        };
        creationtime = "2023-05-09T12:18:06.713+0100";
        dialplan = {
            "app_data" = TestApp;
            "app_name" = Stasis;
            context = Colt;
            exten = "+***********";
            priority = 1;
        };
        id = "1683631086.5164";
        language = en;
        name = "PJSIP/Colt-00000a1e";
        "protocol_id" = "[email protected]";
        state = Up;
    };
    duration = "-660";
    timestamp = "2023-05-09T12:18:29.292+0100";
    type = ChannelTalkingFinished;
}
{
    application = TestApp;
    "asterisk_id" = "4c:d9:8f:45:ca:aa";
    channel = {
        accountcode = "";
        caller = {
            name = "";
            number = "+xxxxxxxxxxxx";
        };
        connected = {
            name = "";
            number = "";
        };
        creationtime = "2023-05-09T12:18:06.713+0100";
        dialplan = {
            "app_data" = TestApp;
            "app_name" = Stasis;
            context = Colt;
            exten = "+***********";
            priority = 1;
        };
        id = "1683631086.5164";
        language = en;
        name = "PJSIP/Colt-00000a1e";
        "protocol_id" = "[email protected]";
        state = Up;
    };
    timestamp = "2023-05-09T12:18:29.512+0100";
    type = ChannelTalkingStarted;
}
{
    application = TestApp;
    "asterisk_id" = "4c:d9:8f:45:ca:aa";
    channel = {
        accountcode = "";
        caller = {
            name = "";
            number = "+xxxxxxxxxxxx";
        };
        connected = {
            name = "";
            number = "";
        };
        creationtime = "2023-05-09T12:18:06.713+0100";
        dialplan = {
            "app_data" = TestApp;
            "app_name" = Stasis;
            context = Colt;
            exten = "+***********";
            priority = 1;
        };
        id = "1683631086.5164";
        language = en;
        name = "PJSIP/Colt-00000a1e";
        "protocol_id" = "[email protected]";
        state = Up;
    };
    duration = "-961";
    timestamp = "2023-05-09T12:18:30.051+0100";
    type = ChannelTalkingFinished;
}

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Trivial

Versions

18.17.0

Components/Modules

core?

Operating Environment

Gentoo

Frequency of Occurrence

Constant

Issue Description

By compiling asterisk with asan (but it can be noticed as well via valgrind) I see an off-by-one that happens by default.

Relevant log output

~ $ /usr/sbin/asterisk -C /etc/asterisk/asterisk.conf -f -U asterisk
Unable to access the running directory (Permission denied).  Changing to '/' for compatibility.
PBX UUID: 80ab15e7-983a-4e45-87da-dfdf67426b1d
[May  5 11:46:06] NOTICE[2506348]: loader.c:2415 load_modules: 314 modules will be loaded.
[May  5 11:46:06] NOTICE[2506348]: cdr.c:4568 cdr_toggle_runtime_options: CDR simple logging enabled.
[May  5 11:46:06] WARNING[2506348]: config.c:2041 process_text_line: parse error: No category context for line 310 of /etc/asterisk/geolocation.conf
[May  5 11:46:06] ERROR[2506348]: res_sorcery_config.c:334 sorcery_config_internal_load: Contents of config file 'geolocation.conf' are invalid and cannot be parsed
[May  5 11:46:06] WARNING[2506348]: config.c:2041 process_text_line: parse error: No category context for line 310 of /etc/asterisk/geolocation.conf
[May  5 11:46:06] ERROR[2506348]: res_sorcery_config.c:334 sorcery_config_internal_load: Contents of config file 'geolocation.conf' are invalid and cannot be parsed
=================================================================
==2506348==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030002c0458 at pc 0x7f741af1f286 bp 0x7fff5e6db130 sp 0x7fff5e6da8a8
READ of size 1 at 0x6030002c0458 thread T0
    #0 0x7f741af1f285  (/usr/lib/gcc/x86_64-pc-linux-gnu/12/libasan.so.8+0x74285)
    #1 0x7f741af212c5 in __vsnprintf_chk (/usr/lib/gcc/x86_64-pc-linux-gnu/12/libasan.so.8+0x762c5)
    #2 0x6e14fd in vsnprintf /usr/include/bits/stdio2.h:68
    #3 0x6e14fd in __ast_str_helper /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/strings.c:71
    #4 0x7189c4 in ast_str_append_va /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/include/asterisk/strings.h:1041
    #5 0x7189c4 in ast_str_append /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/include/asterisk/strings.h:1123
    #6 0x7191f5 in xmldoc_parse_para /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:1335
    #7 0x71b4f6 in xmldoc_parse_parameter /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:1948
    #8 0x71b87f in _ast_xmldoc_build_arguments /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:2068
    #9 0x71d683 in xmldoc_build_documentation_item /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:2397
    #10 0x71f896 in xmldoc_build_list_responses /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:2472
    #11 0x71f896 in ast_xmldoc_build_list_responses /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:2501
    #12 0x7d834b in ast_manager_register2 /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/manager.c:7851
    #13 0x7f7417069314 in ast_res_pjsip_initialize_configuration res_pjsip/pjsip_configuration.c:2079
    #14 0x7f7417045c0c in load_module /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/res/res_pjsip.c:3173
    #15 0x5c6cb5 in start_resource /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:1728
    #16 0x5c84c9 in start_resource_attempt /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:1915
    #17 0x5cafad in start_resource_list /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:2012
    #18 0x5cafad in load_resource_list /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:2194
    #19 0x5cafad in load_modules /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:2417
    #20 0x43ceaf in asterisk_daemon /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/asterisk.c:4261
    #21 0x43ceaf in main /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/asterisk.c:4028
    #22 0x7f741a560189  (/lib64/libc.so.6+0x23189)
    #23 0x7f741a560244 in __libc_start_main (/lib64/libc.so.6+0x23244)
    #24 0x441110 in _start (/usr/sbin/asterisk+0x441110)

0x6030002c0458 is located 0 bytes to the right of 24-byte region [0x6030002c0440,0x6030002c0458)
allocated by thread T0 here:
    #0 0x7f741af67e47 in calloc (/usr/lib/gcc/x86_64-pc-linux-gnu/12/libasan.so.8+0xbce47)
    #1 0x492868 in __ast_repl_calloc /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/astmm.c:1537
    #2 0x492868 in __ast_calloc /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/astmm.c:1607
    #3 0x718dc2 in _ast_str_create /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/include/asterisk/strings.h:661
    #4 0x718dc2 in xmldoc_string_cleanup /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:372
    #5 0x71925a in xmldoc_string_cleanup /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:365
    #6 0x71925a in xmldoc_parse_para /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:1331
    #7 0x71b4f6 in xmldoc_parse_parameter /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:1948
    #8 0x71b87f in _ast_xmldoc_build_arguments /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:2068
    #9 0x71d683 in xmldoc_build_documentation_item /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:2397
    #10 0x71f896 in xmldoc_build_list_responses /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:2472
    #11 0x71f896 in ast_xmldoc_build_list_responses /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/xmldoc.c:2501
    #12 0x7d834b in ast_manager_register2 /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/manager.c:7851
    #13 0x7f7417069314 in ast_res_pjsip_initialize_configuration res_pjsip/pjsip_configuration.c:2079
    #14 0x7f7417045c0c in load_module /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/res/res_pjsip.c:3173
    #15 0x5c6cb5 in start_resource /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:1728
    #16 0x5c84c9 in start_resource_attempt /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:1915
    #17 0x5cafad in start_resource_list /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:2012
    #18 0x5cafad in load_resource_list /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:2194
    #19 0x5cafad in load_modules /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/loader.c:2417
    #20 0x43ceaf in asterisk_daemon /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/asterisk.c:4261
    #21 0x43ceaf in main /var/tmp/portage/net-misc/asterisk-18.17.0/work/asterisk-18.17.0/main/asterisk.c:4028
    #22 0x7f741a560189  (/lib64/libc.so.6+0x23189)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/gcc/x86_64-pc-linux-gnu/12/libasan.so.8+0x74285) 
Shadow bytes around the buggy address:
  0x0c0680050030: fd fa fa fa fd fd fd fa fa fa fd fd fd fd fa fa
  0x0c0680050040: fd fd fd fa fa fa fd fd fd fd fa fa fd fd fd fd
  0x0c0680050050: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
  0x0c0680050060: fd fa fa fa fd fd fd fa fa fa fd fd fd fd fa fa
  0x0c0680050070: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
=>0x0c0680050080: fa fa fd fd fd fd fa fa 00 00 00[fa]fa fa fa fa
  0x0c0680050090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06800500a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06800500b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06800500c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c06800500d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2506348==ABORTING

### Asterisk Issue Guidelines

- [X] Yes, I have read the Asterisk Issue Guidelines

Improvement Description

https://wiki.asterisk.org/wiki/display/AST/C+API+Deprecation

ast_gethostbyname() is now deprecated in favor of the ast_sockaddr_resolve() and ast_sockaddr_resolve_first_af() functions in include/asterisk/netsock2.h.

Severity

Minor

Versions

18, 20, 21, master

Components/Modules

res_pjsip_rfc3326

Operating Environment

Cent OS

Frequency of Occurrence

None

Issue Description

Since Gerrit commit 19570 the 'Call completed elsewhere' reason is not passed on to endpoints.

The setup is as follows:

Endpoint -> Asterisk 1 (via Call Group) -> Asterisk 2 -> Endpoint

To test make a call from one Endpoint on Asterisk 1 which contains a group with two endpoints on Asterisk 2. Answer the call on one of the endpoints in the group. Asterisk 1 sends headers:

CSeq: 29930 CANCEL
Reason: SIP;cause=200;text="Call completed elsewhere"
Reason: Q.850;cause=26
Max-Forwards: 70
User-Agent: Asterisk
Content-Length: 0

Asterisk 2 does not send on the 'Reason' headers.

Asterisk 1 does not contain the patch and passes on the Headers correctly.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Minor

Versions

18.14.0

Components/Modules

app_voicemail_imap

Operating Environment

Ubuntu 22.04

Frequency of Occurrence

Frequent

Issue Description

Seen by user: When the IMAP server is down, a wrong MWI is delivered. My desk phone shows 2 waiting messages (when there were none previously).

Apparent cause: the function static int messagecount(const char *mailbox_id, const char *folder) just returns the result from calling __messagecount(context, mailbox, folder). But that can be negative in case of error. Then the clients get a NOTIFY with "-1" messages waiting. The function has_voicemail(const char *mailbox, const char *folder) similarly checks for the result of __messagecount being != 0 instead of >0.

This happens when the IMAP connection is lost and can't be reestablished (e.g. IMAP server shut down), but judging from the code it can happen in other error situations too.

Relevant log output

When the IMAP server shuts down, asterisk regularly logs:

[May  4 20:42:51] ERROR[1642]: app_voicemail_imap.c:3287 mm_log: IMAP Error: Can't connect to 10.9.4.2,993: Connection refused
[May  4 20:42:51] ERROR[1642]: app_voicemail_imap.c:2497 __messagecount: Houston we have a problem - IMAP mailstream is NULL

The clients get this bogus NOTIFY:

NOTIFY sip:30@***;transport=tcp;x-reg=*** SIP/2.0
Via: SIP/2.0/TCP ***;rport;branch=***;alias
From: <sip:30@***>;tag=***
To: <sip:30@***;x-reg=***>
Contact: <sip:30@***;transport=TCP>
Call-ID: ***
CSeq: *** NOTIFY
Subscription-State: terminated
Event: message-summary
Allow-Events: message-summary, presence, dialog, refer
Max-Forwards: 70
User-Agent: Asterisk PBX 18.14.0~dfsg+~cs6.12.40431414-1
Content-Type: application/simple-message-summary
Content-Length:   104

Messages-Waiting: yes
Message-Account: sip:*90@***;transport=TCP
Voice-Message: -1/0 (0/0)

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Feature Description

This is the first of a couple new features made possible by #81. This adds support for synchronized call forwarding and do not disturb features to PJSIP, which many IP phones (e.g. Polycom SoundPoint, VVX) support, providing for a significantly better user experience. This is implemented according to the official Broadworks specifications and designed to be drop-in compatible for Broadworks.

This also helps bridge feature parity as this has been achievable for a long time using the Call Manager patches for chan_sip.

Severity

Trivial

Versions

18.15.1

Components/Modules

app_voicemail

Operating Environment

FreePBX Distro SNG7 16.0.39

Frequency of Occurrence

Constant

Issue Description

We have a custom dialplan application that records responses to a few prompts, then combines those recordings in to a single file and emails it while also sticking it in a mailbox to allow users without email access to check it remotely. Since this goes around the normal voicemail system it doesn't abide by the configured limits and after a period of time where the users were handling it entirely through email the mailbox ended up with 392 messages out of an allowed 100.

Eventually someone started calling in to the mailbox again and attempted to work their way through the backlog. They got through what we now know to have been 110 messages and then they reported that the system was just repeating the menu prompts.

I called in to check the mailbox myself while watching the Asterisk console and immediately after entering the password to the mailbox was greeted with the message app_voicemail.c:9007 open_mailbox: Resequencing Mailbox: /var/spool/asterisk/voicemail/default/8550/INBOX, expected 100 but found 282 message(s) in box with max threshold of 100. repeated twice as the system voiced "You have 282 new messages". I pressed 1 for new messages, got the "First message" prompt, then an error on the console app_voicemail.c:8727 play_message: No message attribute file?!! (/var/spool/asterisk/voicemail/default/8550/INBOX/msg0000.txt) and the advanced options prompt exactly as the user had reported.

I looked in the mailbox folder and found that the files present were msg0110 through msg0392, so knowing it was so close to the limit I guessed that might be relevant. I raised maxmsg to 1000, reloaded Asterisk, and tried again. This time I got a different error reflecting the raised limits, app_voicemail.c:9007 open_mailbox: Resequencing Mailbox: /var/spool/asterisk/voicemail/default/8550/INBOX, expected 392 but found 282 message(s) in box with max threshold of 1000. and was able to play messages. Looking in the folder after that point I saw msg0000 through msg0281 as expected and redialing the mailbox another time resulted in no further errors.

Looking in to the Asterisk code I found that this behavior seems to be intentional. The error message about resequencing the mailbox comes from line 9007 of app_voicemail.c and right above that on line 8999 is the comment /* for local storage, checks directory for messages up to maxmsg limit */, though the actual for loop in resequence_mailbox() looks as far as maxmsg + 10. Clearly from the logs and audible prompts Asterisk knows there are really 282 messages in the mailbox, but it intentionally fails to handle that situation properly and as a result makes the mailbox unusable until an admin intervenes, so I think it should count as a bug even though it's "working as designed". Why should it stop resequencing at maxmsg+10 if it knows there are more messages?

Of course our specific situation was caused by our unorthodox use of the mailbox allowing new messages to be inserted after it was "full" but as far as I can tell this same behavior could be triggered by simply reducing maxmsg when a mailbox already has 10 or more messages beyond the new limit.

Replication steps:

1. Have a mailbox with > maxmsg+10 messages in it.
2. Trigger resequencing.
3. Messages beyond maxmsg+10 will not have been resequenced, but will still be counted, attempts to play the resulting gap in the sequence will fail.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Minor

Versions

18, 20, master

Components/Modules

configure

Operating Environment

All

Frequency of Occurrence

Constant

Issue Description

The autoconf logic at:

Assumes that the source code for PJSIP will be present when it is not guaranteed. This can lead to improper behavior.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Minor

Versions

18.17.1, 20.2.0

Components/Modules

app_followme

Operating Environment

Linux x86_64

Frequency of Occurrence

Constant

Issue Description

Setting enable_callee_prompt=no, makes FollowMe application dial only first 'number' entry forever, ignoring the configured timeout.

https://issues.asterisk.org/jira/browse/ASTERISK-30326

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Trivial

Versions

20

Components/Modules

contrib

Operating Environment

Debian 11 on aarch64/arm64 platforms. 'uname -m' = aarch64

Frequency of Occurrence

Constant

Issue Description

When looking to install prerequisites and their dependencies, the current logic attempts to force-install 32-bit armhf binaries on 64-bit aarch/arm64 platforms. This is a result of using aptitude in contrib/scripts/install_prereq.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Trivial

Versions

18, 19, 20, 21

Components/Modules

cli

Operating Environment

Any

Frequency of Occurrence

Constant

Issue Description

root# asterisk -rvvvv -T
'T' option is not compatible with remote console mode and has no effect.

Asterisk 18.14.0, Copyright (C) 1999 - 2022, Sangoma Technologies Corporation and others.
Created by Mark Spencer <[email protected]>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Connected to Asterisk 18.14.0 currently running on IS-COMM-NYC-01 (pid = 26094)
[2023-05-18 14:27:18.293-0400] VERBOSE[21689][C-00001348]: <PJSIP/c30081-101-00001d9f> Playing 'vm-Old.ulaw' (language 'en')
[2023-05-18 14:27:18.878-0400] VERBOSE[21689][C-00001348]: <PJSIP/c30081-101-00001d9f> Spawn extension (checkOwnVoicemail, s, 18) exited non-zero
[2023-05-18 14:27:18.878-0400] VERBOSE[21689][C-00001348]: <PJSIP/c30081-101-00001d9f> Got SoftHangup Request (0x7ffab049f6d0) (cause: 16)

But.. the -T option does have an effect. It turns on timestamps for all console messages, even if asterisk is not configured to do so by default.

@InterLinked1

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Trivial

Versions

18, 20, master

Components/Modules

LICENSE

Operating Environment

All

Frequency of Occurrence

Constant

Issue Description

The link in the LICENSE file to the trademark policy should be https://www.sangoma.com/wp-content/uploads/Sangoma-Trademark-Policy-1.pdf

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

When finding endpoints , return as dial string rather than looping over endpoints and building dial string

Severity

Major

Versions

20, 18

Components/Modules

Resources/res_rtp_asterisk

Operating Environment

centos 8

Frequency of Occurrence

Occasional

Issue Description

As shown in the gdb output, Asterisk crashed when calling free().

Relevant log output

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x0000ffff7e8fca0c in __GI_abort () at abort.c:79
#2  0x0000ffff7e936f08 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0xffff7e9fd380 "%s\n")
    at ../sysdeps/posix/libc_fatal.c:181
#3  0x0000ffff7e93d7f4 in malloc_printerr (str=str@entry=0xffff7e9f8e28 "free(): invalid next size (fast)") at malloc.c:5389
#4  0x0000ffff7e93f198 in _int_free (av=0xfffed0000020, p=0xfffe54de9180, have_lock=0) at malloc.c:4248
#5  0x000000000046a9e4 in __ast_free (ptr=0xfffe54de9190, file=0x6a43e0 "astobj2.c", lineno=634, 
    func=0x6a46b8 <__PRETTY_FUNCTION__.9962> "__ao2_ref") at astmm.c:1556
#6  0x000000000046c350 in __ao2_ref (user_data=0xfffe54de91d8, delta=-1, tag=0x0, file=0xffff366e3ec0 "res_rtp_asterisk.c", 
    line=4956, func=0xffff366e8d60 <__PRETTY_FUNCTION__.43552> "_dtor_rtcp_report") at astobj2.c:634
#7  0x000000000046c5d8 in __ao2_cleanup_debug (obj=0xfffe54de91d8, tag=0x0, file=0xffff366e3ec0 "res_rtp_asterisk.c", line=4956, 
    function=0xffff366e8d60 <__PRETTY_FUNCTION__.43552> "_dtor_rtcp_report") at astobj2.c:673
#8  0x0000ffff366d0ab4 in _dtor_rtcp_report (v=0xffff0ac89608) at res_rtp_asterisk.c:4954
#9  0x0000ffff366d0e98 in ast_rtcp_write (data=0xfffeda5a0668) at res_rtp_asterisk.c:4954
#10 0x00000000005bf7d8 in ast_sched_runq (con=0x32c62ce0) at sched.c:822
#11 0x00000000005bd8b0 in sched_run (data=0x32c62ce0) at sched.c:166
#12 0x0000000000615abc in dummy_start (data=0x32b5bc50) at utils.c:1574
#13 0x0000ffff7ed618cc in start_thread (arg=0xffffe388d80f) at pthread_create.c:486
#14 0x0000ffff7e99e54c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Major

Versions

20.0.0

Components/Modules

chan_dahdi

Operating Environment

Debian

Frequency of Occurrence

Constant

Issue Description

Caller ID presentation is always set to "available" on incoming calls to FXO ports, even though it's not. This fixes this by taking the appropriately set presentation flag and setting the presentation on the channel.

Imported from JIRA: https://issues.asterisk.org/jira/browse/ASTERISK-30333

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Improvement Description

CommUnity UCaaS submission - Logging changes to indication

Improvement Description

When the Asterisk is restared it does not preserve paused reason for members of realtime queues. This was fixed for non-realtime queues in https://gerrit.asterisk.org/c/asterisk/+/2131/

Patch exists - pr coming soon

Severity

Minor

Versions

20.0.1

Components/Modules

sig_analog

Operating Environment

Debian

Frequency of Occurrence

Constant

Issue Description

The hidecallerid option in chan_dahdi does not currently work properly. This fixes it.

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Feature Description

Currently, Asterisk queue handling is performed from the perspective of the caller: for a given call, find an agent that could handle the call.

When an agent is in multiple queues, there may be many callers that want to be connected - any asterisk does not guarantee which one is handled first. For call centers, it makes sense to handle callers "in order", ie. handle first the caller that is waiting for the longest period of time.

This was previously discussed in these issues:

• https://issues.asterisk.org/jira/browse/ASTERISK-17732
• https://issues.asterisk.org/jira/browse/ASTERISK-17570

Improvement Description

CommUnity UCaaS submission - add timing information to lock debug when using the DEBUG_THREADS option.

Add last locked/unlocked timestamps to debug information.

Improvement Description

Per discussion on the asterisk-dev mailing list to reduce churn when configure changes are made, and to reduce our conflicts if we have multiple configure changes going on the following will be done:

1. 'configure' will be removed from the mainline branches (18, 20, master)
2. Documentation will be updated with instructions for running bootstrap.sh in this scenario
3. Makefile will state that configure needs to be run if it has not already been done and is invoked
4. The release process will be updated to run bootstrap.sh and produce the configure script, this configure script will be placed in the tag and release tarball
5. The CI process will be updated to include running bootstrap.sh as part of the build process
6. Add to .gitignore in mainline branches

Improvement Description

Because app_meetme is going to be removed next year, this migrates the SLA applications (SLAStation/SLATrunk) to its own separate module, app_sla, that uses ConfBridge under the hood instead of MeetMe.

The user interface is identical to before so this change should be transparent to users of the SLA applications.

Imported from: https://issues.asterisk.org/jira/browse/ASTERISK-30309

Severity

Trivial

Versions

16, 18, 20

Components/Modules

STIR/SHAKEN

Operating Environment

CentOS 7 x64

Frequency of Occurrence

Constant

Issue Description

When signing outbound calls, Asterisk is using the wrong callerID to look up certificates.

There is a patch available in progress, I just wanted to get it into the Github issue system:

https://gerrit.asterisk.org/c/asterisk/+/16174

Dial plan example:
exten => 507,1,Set(CALLERID(num)=442081254195)

507 is the extension, 442081254195 is the Caller ID number (network number) which should be utilized for cert check

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Improvement Description

CommUnity UCaaS submission - add local optimization begin event

The current AST_CEL_LOCAL_OPTIMIZE event is triggered on a local optimize end indicating the optimization took place. This change would add a AST_CEL_LOCAL_OPTIMIZE_BEGIN event for further detail.

Severity

Trivial

Versions

18.18.0

Components/Modules

cli

Operating Environment

Debian 11.7

Frequency of Occurrence

Constant

Issue Description

In Asterisk 18.18.0 command output "core show channels verbose" now has two lines, I think that is not correct

Asterisk 18.18.0 (output in two lines)
CLI> core show channels verbose
Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgeID

Asterisk 18.17.0 (output in one line)
CLI> core show channels verbose
Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgeID

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Minor

Versions

20.1.0

Components/Modules

say.c

Operating Environment

Debian

Frequency of Occurrence

Constant

Issue Description

say.c does not play "digits/oclock" for the French language in ast_say_time_fr. It appears to be missing ast_waitstream. This code is present for other languages.

It also should use feminine for the minutes announcement, like it does for the hour.

Imported from JIRA: https://issues.asterisk.org/jira/browse/ASTERISK-30488

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Feature Description

Currently, Asterisk can refer endpoints to some resource or URI only during a call using the Transfer application. However, there are use cases which require out-of-dialog refers for click to dial or remote dial scenarios.

For the PJSIP technology for example, out-of-dialog REFERs provide this functionality, and this scenario is described in RFC 5359, section 2.18.

A new ARI resource for endpoints (possibly /endpoints/refer with similar parameters to the sendMessage endpoint) could provide this feature.

Improvement Description

Adding an AMI action that will allow you to specify a channel and get all channels that are connected to it, including local channels and what they are connected to

Feature Description

Imported from JIRA: https://issues.asterisk.org/jira/browse/ASTERISK-30003

Currently, if an FXS port is configured with immediate=yes, then a fake ringback tone is immediately applied on the channel before dialplan execution begins and continues until the dialplan stops it.

This is highly undesirable because even if the channel starts doing something else immediately, the audible ring is noticeable and distracting. Additionally, this behavior is just downright incorrect and should never have existed in the first place.

This adds an immediate_ring config option to chan_dahdi that allows this fake ringback tone to be suppressed if it is not wanted, leaving the default behavior unchanged.

Severity

Minor

Versions

20.3.0

Components/Modules

contrib/scripts

Operating Environment

Linux Debian 12

Frequency of Occurrence

Constant

Issue Description

Running the install_prereq hang, test mode or install, CTRL/C to abort the proscessus. Culpit is handle_debian()
extra_packs=check_installed_debs $PACKAGES_DEBIAN
Replacing this line with
check_installed_debs $PACKAGES_DEBIAN
and adapting check_installed_debs by replacing "$@" with "$1" does the job except that extra_packs stays empty (if any)

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines

Severity

Minor

Versions

20.1.0

Components/Modules

asterisk.logrotate

Operating Environment

Debian 11

Frequency of Occurrence

Constant

Issue Description

Imported from JIRA: https://issues.asterisk.org/jira/browse/ASTERISK-30442

Commit 55c53de changed the first line of contrib/scripts/asterisk.logrotate to read

__LOGDIR__/debug.log __LOGDIR__/console __LOGDIR__/full.log __LOGDIR__/messages.log __LOGDIR__/*log {

Installing asterisk and running the service creates the file /var/log/asterisk/messages.log.
Running make install-logrotate installs /etc/logrorate.d/asterisk from the above template. Then running systemctl restart logrotate results in a failed service for logrotate. Manually calling logrotate from the command line reveals the error is

error: asterisk:1 duplicate log entry for /var/log/asterisk/messages.log
error: found error in file asterisk, skipping

The "*log" in the first line of the logrotate config is expanding to messages.log, which now means that file is listed twice, and the configuration is bad. The obvious fix is to remove all explicit .log files and just allow the file globbing to take care of that.

__LOGDIR__/console __LOGDIR__/*.log {

Relevant log output

No response

Asterisk Issue Guidelines

• Yes, I have read the Asterisk Issue Guidelines