asterisk / asterisk Goto Github PK
View Code? Open in Web Editor NEWThe official Asterisk Project repository.
Home Page: https://www.asterisk.org
License: Other
The official Asterisk Project repository.
Home Page: https://www.asterisk.org
License: Other
Trivial
18.15.1
app_voicemail
FreePBX Distro SNG7 16.0.39
Constant
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:
No response
Minor
18,20,master
codec_ilbc
Fedora 37
ilbc-3.0.4-3.fc37.x86_64
Constant
ilbc 3.0 has api changes that prevent codec_ilbc from building
[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
Major
18.17.1
talkdetect / dsp
all
Occasional
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.
{
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;
}
Trivial
18.17.0
core?
Gentoo
Constant
By compiling asterisk with asan (but it can be noticed as well via valgrind) I see an off-by-one that happens by default.
~ $ /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
CommUnity UCaaS submission - Logging changes to indication
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
Minor
18, 20, 21, master
res_pjsip_rfc3326
Cent OS
None
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.
No response
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.
Minor
18.14.0
app_voicemail_imap
Ubuntu 22.04
Frequent
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.
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)
CommUnity UCaaS submission - add timing information to lock debug when using the DEBUG_THREADS option.
Add last locked/unlocked timestamps to debug information.
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.
Minor
20.1.0
asterisk.logrotate
Debian 11
Constant
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 {
No response
Trivial
GIT
Core
N/A
None
Remove the, now obsolete, .gitreview
file from the root of the project.
No response
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.
Minor
20.2.1
CLI
Stock Ubuntu 22.04.2 LTS (Jammy Jellyfish)
Constant
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.
No response
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
Major
20, 18
Resources/res_rtp_asterisk
centos 8
Occasional
As shown in the gdb output, Asterisk crashed when calling free().
(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
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
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:
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
.
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.
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.
Trivial
18, 19, 20, 21
cli
Any
Constant
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.
No response
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
Trivial
18.18.0
cli
Debian 11.7
Constant
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
No response
Trivial
18.14.0, 18.16.0, 20.2.0
res_speech_aeap
Amazon Linux 2 on x86_64 and aarch64
None
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'
No response
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.
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
Minor
18, 20, master
configure
All
Constant
The autoconf logic at:
Line 2514 in 1b95f6e
Assumes that the source code for PJSIP will be present when it is not guaranteed. This can lead to improper behavior.
No response
Minor
20, 18
Resources/res_sorcery_memory_cache
CentOS 8.5
Constant
The pointer returned by ast_strdup had never been freed.
Imported from: https://issues.asterisk.org/jira/browse/ASTERISK-30429
No response
Trivial
18, 20, master
res_musiconhold
ubuntu
None
CommUnity UCaaS submission - moh_files_generator releases channel lock while still accessing channel moh state.
No response
Blocker
20.3.0
res_srtp
Alma Linux 9
Red Hat Enterprise 9
Oracle Linux 9
Rocky Linux 9
Constant
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.
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!
Minor
20.0.1
sig_analog
Debian
Constant
The hidecallerid option in chan_dahdi does not currently work properly. This fixes it.
No response
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:
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
Minor
16.29.0, 18.15.0, 20.0.0
res_pjsip, res_pjsip_outbound_registration
Debian 11
Constant
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.
No response
Minor
all
func_curl
Ubuntu 22
Constant
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
No response
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
Trivial
20
contrib
Debian 11 on aarch64/arm64 platforms. 'uname -m' = aarch64
Constant
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
.
No response
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
Major
20.0.0
chan_dahdi
Debian
Constant
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
No response
Major
18
chan_pjsip,res_pjsip
Debian Buster
Constant
Issue:
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
[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
See Above
Minor
18.17.1, 20.2.0
app_followme
Linux x86_64
Constant
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
No response
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:
Minor
20.3.0
contrib/scripts
Linux Debian 12
Constant
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)
No response
Minor
20.1.0
say.c
Debian
Constant
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
No response
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.
Major
master,20,19,18,16
chan_spy, channels
Right now, testing with branch 18, but this should be on all versions.
Frequent
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:
CEL hangup events -- are generated because of a publish by the ast_channel destructor:
Lines 2206 to 2213 in 1a7866b
asterisk/main/stasis_channels.c
Lines 948 to 950 in 1a7866b
Lines 910 to 921 in 1a7866b
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:
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):
__ao2_link()
-> rb_ao2_new_node()
-> "Container node creation"
)At t=1, we traverse the iterator. We might decide to skip channelA and start spying on channelB:
/* Bump ref of returned object */ ("Next iterator object.")
, replace last_node (NULL), last_node = channelA, return channelA/* Bump ref of returned object */ ("Next iterator object.")
, replace last_node (channelA, -1 ref), last_node = channelBchannel_spy
)At this point, the references look like this:
Now, at t=2, channelA and channelC hang up:
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:
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
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
asterisk/main/astobj2_container.c
Line 356 in 1a7866b
(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
Lines 994 to 999 in 1a7866b
(channels are popped from the ao2_container list, but not as immediate as we would like)
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.
Trivial
18, 20, master
LICENSE
All
Constant
The link in the LICENSE file to the trademark policy should be https://www.sangoma.com/wp-content/uploads/Sangoma-Trademark-Policy-1.pdf
No response
When finding endpoints , return as dial string rather than looping over endpoints and building dial string
Trivial
16, 18, 20
STIR/SHAKEN
CentOS 7 x64
Constant
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
No response
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.