March 2025 - sr-dev - kamailio.org

[kamailio/kamailio] Segfault when using kamailio 5.8.4 as a presence proxy (Issue #4102)
by Joe Mordica 21 Jul '25

21 Jul '25

### Description We are now using kamailio on the edge as a presence proxy to scale presence. We have 3 internal kamailio instances handling the actual subscriptions and publishing. This works well, however, once per 24-36hours we experience a crash on the border proxy instance. We did not experience this when using the border proxy as a presence server (there was no proxying SUBSCRIBE). ### Troubleshooting #### Reproduction I believe this is happening when a customers network randomly experiences issues where it doesn't receive our replies to subscribes (and continues to send a subscribe). Logs are below. #### Debugging Data  Here's the output while replacing any sensitive info in the payload. ``` GNU gdb (Debian 13.1-3) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/kamailio... Reading symbols from /usr/lib/debug/.build-id/ce/c19d0ed1a928e4e25a84ae20d77e9c904a4892.debug... warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing [New LWP 26] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `kamailio -DD -E -m 8000 -M 512 -f /etc/kamailio/kamailio.cfg -P /var/run/kamail'. Program terminated with signal SIGSEGV, Segmentation fault. #0 via_builder (len=len@entry=0x7ffed7e3ecb8, msg=msg@entry=0x7ff9529548b0, send_info=send_info@entry=0x7ff764d20bb0, branch=branch@entry=0x7ffed7e3ecc0, extra_params=0x0, hp=hp@entry=0x7ffed7e3ebb0) at core/msg_translator.c:2910 2910 core/msg_translator.c: No such file or directory. (gdb) bt full #0 via_builder (len=len@entry=0x7ffed7e3ecb8, msg=msg@entry=0x7ff9529548b0, send_info=send_info@entry=0x7ff764d20bb0, branch=branch@entry=0x7ffed7e3ecc0, extra_params=0x0, hp=hp@entry=0x7ffed7e3ebb0) at core/msg_translator.c:2910 via_len = <optimized out> extra_len = <optimized out> line_buf = <optimized out> max_len = <optimized out> via_prefix_len = <optimized out> address_str = <optimized out> port_str = 0x0 send_sock = 0x0 comp_len = <optimized out> comp_name_len = <optimized out> port = <optimized out> proto = <optimized out> ip = {af = 536870912, len = 0, u = {addrl = {534820896, 1586192}, addr32 = {534820896, 0, 1586192, 0}, addr16 = {47136, 8160, 0, 0, 13328, 24, 0, 0}, addr = " \270\340\037\000\000\000\000\0204\030\000\000\000\000"}} from = 0x0 local_addr = {s = {sa_family = 16, sa_data = "#\000\000\000\000\000\020\000\000\000\000\000\000"}, sin = {sin_family = 16, sin_port = 35, sin_addr = {s_addr = 0}, sin_zero = "\020\000\000\000\000\000\000"}, sin6 = {sin6_family = 16, sin6_port = 35, sin6_flowinfo = 0, sin6_addr = {__in6_u = { __u6_addr8 = "\020\000\000\000\000\000\000\000\003\000\000\000\000\000\000", __u6_addr16 = {16, 0, 0, 0, 3, 0, 0, 0}, __u6_addr32 = {16, 0, 3, 0}}}, sin6_scope_id = 3000082688}, sas = {ss_family = 16, __ss_padding = "#\000\000\000\000\000\020\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\000\241\321\262cg\357`@\000\000\000\000\000\000\000X\f-\177!V\000\000\020\016\217R\371\177\000\000\001\000\000\000!V\000\000*\000\000\000\000\000\000\000\001\000\000\000\376\177\000\000\004\360;\177!V\000\000\250,A\177!V\000\000\000\355\343\327\376\177\000\000\000\241\321\262cg\357`h\256\006R\371\177\000", __ss_align = 94701866020241}} con = 0x0 rxavp = 0x0 xname = {s = 0x0, len = -2141140176} __func__ = "via_builder" #1 0x000056217f155030 in create_via_hf (len=len@entry=0x7ffed7e3ecb8, msg=msg@entry=0x7ff9529548b0, send_info=send_info@entry=0x7ff764d20bb0, branch=branch@entry=0x7ffed7e3ecc0) at core/msg_translator.c:3232 via = <optimized out> extra_params = {s = 0x0, len = 0} hp = {host = 0x56217f4fb380 <default_global_address>, port = 0x56217f4fb370 <default_global_port>} sbuf = "\331\023\000\000\001", '\000' <repeats 18 times> --Type <RET> for more, q to quit, c to continue without paging--info locals slen = <optimized out> xparams = <optimized out> id_buf = <optimized out> id_len = 0 __func__ = "create_via_hf" __llevel = <optimized out> __kld = <optimized out> #2 0x000056217f1592f7 in build_req_buf_from_sip_req (msg=msg@entry=0x7ff9529548b0, returned_len=returned_len@entry=0x7ffed7e3eeac, send_info=send_info@entry=0x7ff764d20bb0, mode=mode@entry=128) at core/msg_translator.c:2096 len = 581 new_len = <optimized out> received_len = 0 rport_len = 0 uri_len = 0 via_len = 0 body_delta = 0 line_buf = 0x0 received_buf = 0x0 rport_buf = 0x0 new_buf = 0x0 buf = 0x56217f5866c0 <buf> "SUBSCRIBE sip:74@sip.domain.co SIP/2.0\r\nVia: SIP/2.0/UDP 12.171.207.82:25744;branch=z9hG4bK1805670803;rport\r\nFrom: \"Heather Myers\" <sip:1086448@sip.domain.co>;tag=1805518213\r\nTo: <sip:74@sip.domain.co>\r\nCa"... path_buf = {s = 0x0, len = 0} offset = 0 s_offset = 0 size = <optimized out> via_anchor = 0x7ff952951300 via_lump = <optimized out> via_rm = <optimized out> via_insert_param = 0x0 path_anchor = <optimized out> path_lump = <optimized out> branch = {s = 0x7ff952954ed8 "z9hG4bKc7ed.5819b4295fe83f981a2fc19b7f739d7e.0", len = 46} flags = 262273 --Type <RET> for more, q to quit, c to continue without paging--list udp_mtu = <optimized out> di = {send_sock = 0x0, to = {s = {sa_family = 18608, sa_data = "\225R\371\177\000\000\002\000\023\331\n4\001\r"}, sin = {sin_family = 18608, sin_port = 21141, sin_addr = { s_addr = 32761}, sin_zero = "\002\000\023\331\n4\001\r"}, sin6 = {sin6_family = 18608, sin6_port = 21141, sin6_flowinfo = 32761, sin6_addr = {__in6_u = { __u6_addr8 = "\002\000\023\331\n4\001\r\000\000\000\000\000\000\000", __u6_addr16 = {2, 55571, 13322, 3329, 0, 0, 0, 0}, __u6_addr32 = {3641901058, 218182666, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 18608, __ss_padding = "\225R\371\177\000\000\002\000\023\331\n4\001\r", '\000' <repeats 103 times>, __ss_align = 0}}, id = 0, send_flags = {f = 0, blst_imask = 0}, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0} ret = <optimized out> __func__ = "build_req_buf_from_sip_req" error00 = <optimized out> #3 0x00007ff951fbe90d in prepare_new_uac (t=t@entry=0x7ff764d20880, i_req=i_req@entry=0x7ff9529548b0, branch=branch@entry=0, uri=<optimized out>, uri@entry=0x7ff9529548e8, path=<optimized out>, path@entry=0x7ff952954f60, next_hop=<optimized out>, fsocket=0x7ff9528f0e10, snd_flags=..., fproto=<optimized out>, flags=<optimized out>, instance=<optimized out>, ruid=<optimized out>, location_ua=<optimized out>) at ./src/modules/tm/t_fwd.c:482 shbuf = 0x0 add_rm_backup = <optimized out> body_lumps_backup = <optimized out> parsed_uri_bak = {user = { s = 0x56217f5866ce <buf+14> "74(a)sip.domain.co SIP/2.0\r\nVia: SIP/2.0/UDP 12.171.207.82:25744;branch=z9hG4bK1805670803;rport\r\nFrom: \"Heather Myers\" <sip:1086448@sip.domain.co>;tag=1805518213\r\nTo: <sip:74@sip.domain.co>\r\nCall-ID: 0_18056"..., len = 2}, passwd = {s = 0x0, len = 0}, host = { s = 0x56217f5866d1 <buf+17> "sip.domain.co SIP/2.0\r\nVia: SIP/2.0/UDP 12.171.207.82:25744;branch=z9hG4bK1805670803;rport\r\nFrom: \"Heather Myers\" <sip:1086448@sip.domain.co>;tag=1805518213\r\nTo: <sip:74@sip.domain.co>\r\nCall-ID: 0_18056078"..., len = 11}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = { s = 0x0, len = 0}, port_no = 0, proto = 0, type = SIP_URI_T, flags = 0, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = { s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = { s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}} ret = -1 len = 32761 parsed_uri_ok_bak = <optimized out> free_new_uri = 1 msg_uri_bak = {s = 0x0, len = 0} dst_uri_bak = {s = 0x7ff9529525f0 "sip:10.52.1.13:5081", len = 19} dst_uri_backed_up = 1 path_bak = {s = 0x0, len = 0} free_path = 1 instance_bak = {s = 0x0, len = 0} ``` #### Log Messages  ``` ERROR 2025-01-10T06:00:31.847348563Z [resource.labels.containerName: kamailio] 8(28) CRITICAL: {1 1 SUBSCRIBE 0_1907143137(a)192.168.100.28} tm [timer.h:188]: _set_fr_retr(): already added: 0x7ff763e62250 , tl=0x7ff763e62270!!! ERROR 2025-01-10T06:00:31.847388483Z [resource.labels.containerName: kamailio] 8(28) CRITICAL: {1 1 SUBSCRIBE 0_1907143137(a)192.168.100.28} tm [t_fwd.c:1613]: t_send_branch(): BUG: retransmission already started for: 0x7ff763e62250 ERROR 2025-01-10T06:00:31.847394809Z [resource.labels.containerName: kamailio] 8(28) ERROR: {1 1 SUBSCRIBE 0_1907143137(a)192.168.100.28} sl [sl_funcs.c:428]: sl_reply_error(): stateless error reply used: No error (0/SL) ERROR 2025-01-10T06:00:31.847400738Z [resource.labels.containerName: kamailio] 8(28) BUG: {1 1 SUBSCRIBE 0_1907143137(a)192.168.100.28} tm [t_lookup.c:2052]: t_unref(): REQ_ERR DELAYED should have been caught much earlier for 0x7ff763e61f70: 24 (hex 18) ERROR 2025-01-10T06:00:47.346744773Z [resource.labels.containerName: kamailio] 45(65) ERROR: <core> [core/tcp_main.c:4818]: tcpconn_main_timeout(): connect 64.63.142.90:12190 failed (timeout) ERROR 2025-01-10T06:00:58.274915089Z [resource.labels.containerName: kamailio] 45(65) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 20 ERROR 2025-01-10T06:01:02.715789076Z [resource.labels.containerName: kamailio] 0(1) ALERT: <core> [main.c:805]: handle_sigs(): child process 26 exited by a signal 11 ERROR 2025-01-10T06:01:02.715827333Z [resource.labels.containerName: kamailio] 0(1) ALERT: <core> [main.c:809]: handle_sigs(): core was generated ERROR 2025-01-10T06:01:02.718815287Z [resource.labels.containerName: kamailio] 45(65) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 25 ERROR 2025-01-10T06:01:02.720985493Z [resource.labels.containerName: kamailio] 45(65) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 23 ERROR 2025-01-10T06:01:02.725450552Z [resource.labels.containerName: kamailio] 45(65) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 30 ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions I can atleast say that when this segfault happens that these logs are always present right before the crash. However, I also see instances of these logs without a crash immediately following. On the proxy we are doing this is withindlg route to send subscribes to the presence route: ``` if KSR.is_SUBSCRIBE() and KSR.is_myself_ruri() then -- in-dialog subscribe requests ksr_route_presence(); KSR.x.exit(); end ``` Any then this is our ksr_route_presence(): ``` function ksr_route_presence() if not KSR.is_SUBSCRIBE() then return 1; end local fuser = KSR.kx.get_fuser(); if fuser=='' then KSR.xlog.xinfo('Subscription attempt without username from IP ' .. KSR.kx.get_srcip() .. ' - Rejecting\n'); KSR.sl.sl_send_reply(404, 'Not Found'); KSR.x.exit(); end KSR.pv.sets('$avp(s:tenant)', string.match(fuser, '-(.*)')); local setId = '6' .. KSR.kx.get_def('DEFAULT_DISPATCH_SET'); local modeId = '7'; if KSR.dispatcher.ds_select_dst(setId, modeId)<0 then KSR.sl.send_reply(404, 'No destination'); KSR.x.exit(); end KSR.corex.set_send_socket(KSR.kx.get_def('PRIVATE_LISTEN_IP') .. ':' .. KSR.kx.get_def('INTERNAL_PORT')); KSR.tm.t_on_failure('ksr_route_rtf_dispatch'); ksr_route_relay(); end ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**:  ``` PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" ``` ``` Linux gke-us-south1-external-sip-800ca69e-qyb3 5.15.0-1048-gke #53-Ubuntu SMP Tue Nov 28 00:39:01 UTC 2023 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4102 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4102(a)github.com>

5 40

[kamailio/kamailio] dmq send dialog message failed (Issue #4189)
by QuincyGao 21 Jul '25

21 Jul '25

QuincyGao created an issue (kamailio/kamailio#4189)  ### Description  I used dmq on two machines, registered two softphones on the 111 machine, and then used one phone to call another. After the call was connected, dmq sent a dialog message with an error message 400 bad request. Here is the 111 config, 113 almost same to 111: ``` loadmodule "dmq.so" modparam("dmq", "server_address", "sip:172.16.4.111:5464") modparam("dmq", "server_socket", "udp:172.16.4.111:5464") modparam("dmq", "notification_address", "sip:172.16.4.113:5464") modparam("dmq", "notification_channel", "peers") modparam("dmq", "num_workers", 4) modparam("dmq", "ping_interval", 30) loadmodule "dmq_usrloc.so" modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "sync", 1) modparam("dmq_usrloc", "batch_msg_contacts", 50) # 50 contacts / message modparam("dmq_usrloc", "batch_size", 10000) # 10000 contacts / batch modparam("dmq_usrloc", "batch_usleep", 500000) loadmodule "dialog.so" modparam("dialog", "enable_stats", 1) modparam("dialog", "enable_dmq", 1) ... if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting dlg_manage(); } ``` Here is the sip: <img width="836" alt="Image" src="https://github.com/user-attachments/assets/df609e21-77bb-43e9-a8aa-112069a3…" /> the 113 log error: ``` dialog [dlg_dmq.c:127]: dlg_dmq_handle_msg(): no content length header found ``` ### Troubleshooting #### Reproduction  The inevitable bug #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` 113 log: 22(4389) DEBUG: <core> [core/udp_server.c:708]: udp_rcv_loop(): received on udp socket: (106/100/767) [[KDMQ sip:dialog@172.16.4.113:5464 SIP/2.0 0D 0A Via: SIP/2.0/UDP 172.16.4.111:5464;branch=z9hG4bK28e.2ec7]] 22(4389) DEBUG: <core> [core/receive.c:190]: ksr_evrt_received(): event route core:msg-received not defined 22(4389) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 22(4389) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request: 22(4389) DEBUG: <core> [core/parser/msg_parser.c:724]: parse_msg(): method: <KDMQ> 22(4389) DEBUG: <core> [core/parser/msg_parser.c:726]: parse_msg(): uri: <sip:dialog@172.16.4.113:5464> 22(4389) DEBUG: <core> [core/parser/msg_parser.c:728]: parse_msg(): version: <SIP/2.0> 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Via] type 1 22(4389) DEBUG: <core> [core/parser/parse_via.c:1312]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK28e.2ec78467000000000000000000000000.0>; state=16 22(4389) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header reached, state=5 22(4389) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found, flags=2 22(4389) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the first via 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [To] type 3 22(4389) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=10 22(4389) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [32]; uri=[sip:dialog@172.16.4.113:5464] 22(4389) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (32)[<sip:dialog@172.16.4.113:5464> ], to tag (0)[] 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [From] type 4 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [CSeq] type 5 22(4389) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <10> <KDMQ> 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Call-ID] type 6 22(4389) DEBUG: <core> [core/receive.c:397]: receive_msg(): --- received sip message - request - call-id: [6ecc0d71033645ea-1972(a)172.16.4.111] - cseq: [10 KDMQ] 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts... 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=584 a=26 n=xlog 22(4389) INFO: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <script>: 172.16.4.111:5464|172.16.4.113:5464|udp|KDMQ 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=592 a=16 n=if 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=589 a=25 n=is_method 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=590 a=24 n=dmq_process_message 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dmq [message.c:154]: ki_dmq_process_message_rc(): dmq_handle_message [KDMQ sip:dialog@172.16.4.113:5464] 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dmq [message.c:168]: ki_dmq_process_message_rc(): dmq_handle_message peer found: dialog 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=6c399121368d030ed41b62758342ea91-0405b528 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=29 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dialog [dlg_dmq.c:124]: dlg_dmq_handle_msg(): dmq message received 22(4389) ERROR: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dialog [dlg_dmq.c:127]: dlg_dmq_handle_msg(): no content length header found ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled on 11:27:01 Mar 21 2025 with gcc 4.8.5 ``` * **Operating System**:  ``` centos7.9 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4189 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4189(a)github.com>

4 7

[kamailio/kamailio] siptrace: sip_trace_mode("d") not working (Issue #4178)
by c.long 18 Jul '25

18 Jul '25

longchun4835 created an issue (kamailio/kamailio#4178)  ### Description Using function sip_trace_mode() with parameter d to enable dialog tracing mode logs: ``` BUG: siptrace [siptrace.c:1671]: add_info_xavp(): URI should be in raw format here ERROR: siptrace [siptrace.c:888]: sip_trace_helper(): failed to serialize siptrace info! Won't trace dialog! ``` ### Troubleshooting #### Reproduction my module parameters: ``` #!ifdef WITH_HOMER loadmodule "siptrace.so" modparam("siptrace", "duplicate_uri", HOMER_URL) modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_flag", 22) modparam("siptrace", "trace_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "hep_capture_id", HOMER_HEP_ID) #!endif ... request_route { ... if (is_method("INVITE")) { sip_trace_mode("d"); } } ``` ### Possible Solutions I checked the source code and found that the issue occurs when sip_trace_helper() is called inside the ki_sip_trace_mode() function, with the third parameter (duri) set to NULL. I don’t quite understand the logic behind passing NULL does this mean that the 'D' parameter will never working when calling sip_trace_mode()? Additionally, I have another question: in the sip_trace_helper() function, why does it call trace_transaction() instead of trace_dialog() when strace_type == SIPTRACE_DIALOG? ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.6.4 (x86_64/linux) a004cf flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: a004cf compiled on 09:14:30 Jan 23 2025 with gcc 8.3.1 ``` * **Operating System**: ``` NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4178 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4178(a)github.com>

3 5

[kamailio/kamailio] tls: Create one shared context and reuse it. (PR #3972)
by Xenofon Karamanos 10 Jul '25

10 Jul '25

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3823 #### Description  This PR aims to implement what was discussed in [mailing list](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-dev@lists.kama… regarding some `tls.reload` and increasing memory usage. It adds a new parameter `enable_shared_ctx` in `tls` module that if set to 0, preserves the old behavior and if set to 1 (other than 0 tbh), it creates a single SSL context that is being shared. This have the effect of using way less memory when initialized as well, but also minimizes (can't say it fixes the problem) the `tls.reload` memory increase. I have also added a small markdown (comparison.md) file, where some comparisons where made between enabled/disabled shared context and with/without CA file (where the initial problem was occurring by the reporter). Feedback would be necessary to verify whether this patch, acts as expected and kamailio works as intented. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3972 -- Commit Summary -- * tls: Add parameter for shared contexts * tls: Comparison for enable_shared_ctx -- File Changes -- A comparison.md (15) M src/modules/tls/tls_domain.c (172) M src/modules/tls/tls_mod.c (11) M src/modules/tls/tls_mod.h (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3972.patch https://github.com/kamailio/kamailio/pull/3972.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3972 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3972(a)github.com>

4 13

Kamailio rpm server
by Patrick Wakano 08 Jul '25

08 Jul '25

Hello list, Hope everyone is fine. I'm trying to install the latest 6.0.1 version from https://rpm.kamailio.org/centos/ but it doesn't seem to be updated...The latest version available there is the 5.8.5. Version 6.0.0 isn't there as well... Is it still maintained? or just some rpmbuild command missed? Thank you, Patrick

3 9

[tracker] Assignee added: Assignment operators don't work
by sip-router 06 Jul '25

06 Jul '25

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#100 - Assignment operators don't work User who did this - Alex Hermann (axlh) http://sip-router.org/tracker/index.php?do=details&task_id=100 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

3 2

[kamailio/kamailio] Kamailio blocks in SSL_accept (Issue #4185)
by Mathias Schneuwly 04 Jul '25

04 Jul '25

schneuwlym created an issue (kamailio/kamailio#4185) ### Description This issue is a follow up of the discussion in the [mailing list](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.ka… We are using Kamailio 5.8.4 in a yocto scarthgap based image. We noticed on multiple nodes, that suddenly phones lost their registrations and the log showed messages like `send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)`. After debugging we guess that the `send_fd` messages are just a symptom, not the cause. Generating a backtrace using `kamctl trap` shows that all TCP receiver are waiting for a `pthread_rwlock_...` lock. Our deployments, where we randomly see the issue, are very small; 10-30 registrations. I've tested kamailio version 5.8.4, 5.8.5, 5.8.6 and 6.0.1 and I was able to reproduce the issue with all versions. I've also tested version 5.5.4, but with an older yocto (dunfell) which used openssl 1.1.1w, **which did not block!** Yocto Scarthgap uses OpenSSL 3.2.3 and we also updated to version 3.4.1, which didn't show any difference. ### Troubleshooting #### Reproduction Meanwhile we found a way to reproduce the issue within seconds. It requires a bit of brute force, but it locks kamailio reliable. We are generating 3 parallel SIP REGISTER streams with sipexer to 3 different accounts. Following an example of one stream: ``` watch -n 0.1 "./sipexer -register -vl 3 -co -com -ex 3600 -fu "2" -au "2" -ap "test" -tk <path to key>.key -tc <path to certificate>.cer -ti -sd -ru sip:<domain> -cu sip:2@<domain> tls:<fqdn>:5061;sleep 0.1;./sipexer -register -vl 3 -co -com -ex 0 -fu "2" -au "2" -ap "test" -tk <path to key>.key -tc <path to cert>.cer -ti -sd -ru sip:<domain> -cu sip:2@<domain> tls:<fqdn>:5061" ``` Our dialplan is quite complex, but I was also able to reproduce the issue with the default [dialplan](https://raw.githubusercontent.com/kamailio/kamailio/refs/heads/5.… with the following changes: ``` 169a170,171 > #!define WITH_TLS > 205a208,219 > alias=udp:<domain>:5060 > alias=udp:127.0.0.1:5060 > alias=udp:10.0.6.1:5060 > alias=tls:<domain> > alias=tls:10.0.6.1:5061 > alias=tls:10.165.42.76:5061 > alias=tls:<domain>:5061 > alias=udp:<domain> > listen=udp:127.0.0.1:5060 > listen=tls:10.0.6.1:5061 > listen=udp:10.0.6.1:5060 > listen=tls:10.165.42.76:5061 498c512 < modparam("tls", "config", "/usr/local/etc/kamailio/tls.cfg") --- > modparam("tls", "config", "/etc/kamailio/kamailio-tls.cfg") ``` ``` # cat /etc/kamailio/kamailio-tls.cfg [server:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = "<path to key>.key" certificate = "<path to cert>.crt" ca_list = "<path to ca>.pem" [client:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = "<path to key>.key" certificate = "<path to cert>.crt" ca_list = "<path to ca>.pem" ``` #### Debugging Data Following the backtrace of one tcp listener process. The full backtrace can be found [here](https://github.com/user-attachments/files/19430313/gdb_kamailio_20250… ``` ---start 4608 ----------------------------------------------------- [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fc855758a0c, expected=expected@entry=3, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>, cancel=cancel@entry=false) at futex-internal.c:103 warning: 103 futex-internal.c: No such file or directory #0 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fc855758a0c, expected=expected@entry=3, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>, cancel=cancel@entry=false) at futex-internal.c:103 err = -512 clockbit = 256 op = <optimized out> #1 0x00007fc85a59429c in __GI___futex_abstimed_wait64 (futex_word=futex_word@entry=0x7fc855758a0c, expected=expected@entry=3, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>) at futex-internal.c:128 No locals. #2 0x00007fc85a59d830 in __pthread_rwlock_wrlock_full64 (abstime=0x0, clockid=0, rwlock=0x7fc855758a00) at /usr/src/debug/glibc/2.39+git/nptl/pthread_rwlock_common.c:730 private = <optimized out> wf = <optimized out> err = <optimized out> prefer_writer = false may_share_futex_used_flag = true wpf = <optimized out> ready = <optimized out> r = <optimized out> may_share_futex_used_flag = <optimized out> r = <optimized out> done = <optimized out> wpf = <optimized out> ready = <optimized out> __value = <optimized out> prefer_writer = <optimized out> private = <optimized out> wf = <optimized out> err = <optimized out> w = <optimized out> w = <optimized out> private = <optimized out> err = <optimized out> w = <optimized out> wf = <optimized out> wf = <optimized out> __value = <optimized out> #3 ___pthread_rwlock_wrlock (rwlock=0x7fc855758a00) at pthread_rwlock_wrlock.c:26 result = <optimized out> #4 0x00007fc859820b49 in CRYPTO_THREAD_write_lock (lock=<optimized out>) at /usr/src/debug/openssl/3.2.3/crypto/threads_pthread.c:108 No locals. #5 0x00007fc8599bd5da in ossl_prov_drbg_generate (drbg=0x7fc855710040, out=0x7fc856471980 "", outlen=48, strength=256, prediction_resistance=0, adin=0x7ffeec8b67e0 "@", adinlen=8) at /usr/src/debug/openssl/3.2.3/providers/implementations/rands/drbg.c:645 fork_id = <optimized out> reseed_required = 0 ret = 0 __func__ = "ossl_prov_drbg_generate" err = <optimized out> now = <optimized out> #6 0x00007fc8599bd9ca in ossl_drbg_get_seed (vdrbg=<optimized out>, pout=0x7ffeec8b6880, entropy=<optimized out>, min_len=<optimized out>, max_len=<optimized out>, prediction_resistance=0, adin=0x7ffeec8b6838 "\220'\037V\310\177", adin_len=8) at /usr/src/debug/openssl/3.2.3/providers/implementations/rands/drbg.c:175 drbg = 0x7fc855710040 bytes_needed = 48 buffer = 0x7fc856471980 "" __func__ = "ossl_drbg_get_seed" #7 0x00007fc8599bc907 in get_entropy (drbg=<optimized out>, drbg@entry=0x7fc8561f2790, pout=pout@entry=0x7ffeec8b6880, entropy=<optimized out>, min_len=48, max_len=48, prediction_resistance=prediction_resistance@entry=0) at /usr/src/debug/openssl/3.2.3/providers/implementations/rands/drbg.c:245 bytes = <optimized out> p_str = 256 __func__ = "get_entropy" #8 0x00007fc8599bd26c in ossl_prov_drbg_reseed_unlocked (drbg=drbg@entry=0x7fc8561f2790, prediction_resistance=prediction_resistance@entry=0, ent=ent@entry=0x0, ent_len=ent_len@entry=0, adin=adin@entry=0x0, adinlen=adinlen@entry=0) at /usr/src/debug/openssl/3.2.3/providers/implementations/rands/drbg.c:573 entropy = 0x0 entropylen = 0 __func__ = "ossl_prov_drbg_reseed_unlocked" #9 0x00007fc8599bd68e in ossl_prov_drbg_generate (adinlen=0, adin=0x0, prediction_resistance=0, strength=<optimized out>, outlen=32, out=0x7fc8564717c8 "", drbg=0x7fc8561f2790) at /usr/src/debug/openssl/3.2.3/providers/implementations/rands/drbg.c:697 fork_id = <optimized out> reseed_required = <optimized out> ret = <optimized out> fork_id = <optimized out> reseed_required = <optimized out> ret = <optimized out> __func__ = "ossl_prov_drbg_generate" err = <optimized out> now = <optimized out> #10 ossl_prov_drbg_generate (drbg=0x7fc8561f2790, out=0x7fc8564717c8 "", outlen=32, strength=<optimized out>, prediction_resistance=0, adin=0x0, adinlen=0) at /usr/src/debug/openssl/3.2.3/providers/implementations/rands/drbg.c:634 fork_id = <optimized out> reseed_required = 0 ret = 0 __func__ = "ossl_prov_drbg_generate" err = <optimized out> now = <optimized out> #11 0x00007fc8597e75c6 in evp_rand_generate_locked (ctx=ctx@entry=0x7fc8561f26f0, out=out@entry=0x7fc8564717c8 "", outlen=outlen@entry=32, strength=strength@entry=0, prediction_resistance=<optimized out>, prediction_resistance@entry=0, addin=0x0, addin_len=0) at /usr/src/debug/openssl/3.2.3/crypto/evp/evp_rand.c:570 chunk = 32 max_request = 65536 params = {{key = 0x7fc8599e9521 "max_request", data_type = 2, data = 0x7ffeec8b6968, data_size = 8, return_size = 8}, {key = 0x0, data_type = 0, data = 0x0, data_size = 0, return_size = 0}} __func__ = "evp_rand_generate_locked" #12 0x00007fc8597e840b in EVP_RAND_generate (ctx=0x7fc8561f26f0, out=out@entry=0x7fc8564717c8 "", outlen=outlen@entry=32, strength=strength@entry=0, prediction_resistance=prediction_resistance@entry=0, addin=addin@entry=0x0, addin_len=0) at /usr/src/debug/openssl/3.2.3/crypto/evp/evp_rand.c:592 res = <optimized out> #13 0x00007fc8598f9282 in RAND_bytes_ex (ctx=warning: could not convert 'ossl_lib_ctx_st' from the host encoding (ANSI_X3.4-1968) to UTF-32. This normally should not happen, please file a bug report. 0x0, buf=0x7fc8564717c8 "", num=32, strength=0) at /usr/src/debug/openssl/3.2.3/crypto/rand/rand_lib.c:380 rand = <optimized out> meth = <optimized out> __func__ = "RAND_bytes_ex" #14 0x00007fc859bdb62c in def_generate_session_id (ssl=ssl@entry=0x7fc856436e50, id=id@entry=0x7fc8564717c8 "", id_len=id_len@entry=0x7ffeec8b6ae4) at /usr/src/debug/openssl/3.2.3/ssl/ssl_sess.c:326 retry = 0 #15 0x00007fc859bdc132 in ssl_generate_session_id (s=s@entry=0x7fc856436e50, ss=ss@entry=0x7fc856471570) at /usr/src/debug/openssl/3.2.3/ssl/ssl_sess.c:409 tmp = 32 cb = 0x7fc859bdb600 <def_generate_session_id> ssl = <optimized out> __func__ = "ssl_generate_session_id" #16 0x00007fc859bdc31e in ssl_get_new_session (s=s@entry=0x7fc856436e50, session=session@entry=1) at /usr/src/debug/openssl/3.2.3/ssl/ssl_sess.c:464 ss = 0x7fc856471570 __func__ = "ssl_get_new_session" #17 0x00007fc859c3f169 in tls_early_post_process_client_hello (s=0x7fc856436e50) at /usr/src/debug/openssl/3.2.3/ssl/statem/statem_srvr.c:1898 i = <optimized out> loop = <optimized out> sctx = 0x7fc855d24280 j = <optimized out> dgrd = DOWNGRADE_NONE protverr = <optimized out> c = <optimized out> clienthello = 0x7fc856470a90 al = 80 id = <optimized out> comp = 0x0 ciphers = 0x7fc856471330 scsvs = 0x7fc8564713c0 ssl = 0x7fc856436e50 j = <optimized out> i = <optimized out> al = <optimized out> protverr = <optimized out> loop = <optimized out> id = <optimized out> comp = <optimized out> c = <optimized out> ciphers = <optimized out> scsvs = <optimized out> clienthello = <optimized out> dgrd = <optimized out> sctx = <optimized out> ssl = <optimized out> __func__ = "tls_early_post_process_client_hello" err = <optimized out> cipher = <optimized out> trc_out = <optimized out> pos = <optimized out> pref_cipher = <optimized out> master_key_length = <optimized out> m = <optimized out> comp_id = <optimized out> k = <optimized out> m = <optimized out> nn = <optimized out> v = <optimized out> done = <optimized out> o = <optimized out> #18 tls_post_process_client_hello (s=0x7fc856436e50, wst=<optimized out>) at /usr/src/debug/openssl/3.2.3/ssl/statem/statem_srvr.c:2295 rv = <optimized out> cipher = <optimized out> ssl = 0x7fc856436e50 err = <optimized out> __func__ = "tls_post_process_client_hello" #19 0x00007fc859c2bc1b in read_state_machine (s=0x7fc856436e50) at /usr/src/debug/openssl/3.2.3/ssl/statem/statem.c:712 mt = 1 pkt = {curr = 0x7fc856466125 "", remaining = 0} max_message_size = 0x7fc859c3e3e0 <ossl_statem_server_max_message_size> ret = <optimized out> process_message = 0x7fc859c42400 <ossl_statem_server_process_message> post_process_message = 0x7fc859c414f0 <ossl_statem_server_post_process_message> st = 0x7fc856436ee0 len = 273 transition = 0x7fc859c3d330 <ossl_statem_server_read_transition> cb = 0x7fc859c91d90 <sr_ssl_ctx_info_callback> ssl = 0x7fc856436e50 st = <optimized out> ret = <optimized out> mt = <optimized out> len = <optimized out> transition = <optimized out> pkt = <optimized out> process_message = <optimized out> post_process_message = <optimized out> max_message_size = <optimized out> cb = <optimized out> ssl = <optimized out> __func__ = "read_state_machine" #20 state_machine (s=0x7fc856436e50, server=1) at /usr/src/debug/openssl/3.2.3/ssl/statem/statem.c:478 buf = 0x0 cb = 0x7fc859c91d90 <sr_ssl_ctx_info_callback> st = 0x7fc856436ee0 ret = -1 ssret = <optimized out> ssl = 0x7fc856436e50 __func__ = "state_machine" #21 0x00007fc859cbf036 in tls_accept (c=c@entry=0x7fc856461be0, error=error@entry=0x7ffeec8b6dd8) at tls_server.c:457 ret = <optimized out> ssl = 0x7fc856436e50 cert = <optimized out> tls_c = 0x7fc8564171b0 tls_log = <optimized out> __func__ = "tls_accept" ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.4 (x86_64/linux) f1d83d flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: f1d83d compiled on 10:25:58 Nov 12 2024 with x86_64-ruag-linux-gcc 13.3.0 ``` * **Operating System**: It is a yocto scarthgap based image (Version 5.0.6 LTS) ``` Linux ttel 6.6.54-yocto-standard #1 SMP PREEMPT_DYNAMIC Tue Oct 8 03:03:40 UTC 2024 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4185 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4185(a)github.com>

6 12

[kamailio/kamailio] [Websocket] websocket:closed sometimes is not fired (Issue #3950)
by Gustavo Almeida 27 Jun '25

27 Jun '25

### Description After carrying out some load tests using the `Websocket` module, I noticed that sometimes the `websocket:closed` event is not triggered. This problem seems to be particularly noticeable when the load is high and simultaneous. Example: 1000 records simultaneously. In the tests carried out, I realized that the number of times the event is not triggered is small, in the order of [1-10]/1000. I check that when I do a `ws.dump` I don't have any active connections, and I confirm that they are all effectively cleaned (`netstat -ano | grep 8061`). However, the event is not triggered for some connections. I can see this in the logs, and also when i display the content of an hash table, i'm dropping key inside `websocket:closed` event. ### Troubleshooting The troubleshooting was simplistic, i.e. I ran the same test n times, and validated that the event was triggered for all connections, the number of `ws` connections listed by `Kamailio`, and the open connections. #### Reproduction To reproduce, we can use any mechanism that emulates the use of the `Websocket` module. For example, I used the `sipexer` tool to create a `wss` connection with `Kamailio`, forcing simultaneous registrations. Example command: `sipexer -cb -mt register -ex 60 -au <user> -ap <pass> -fuser example -fd mydomain -wso https://10.0.0.12:10000 -ruri sip:kamailio -su wss://kamailio:8061` Kamailio TLS listener: `listen=tls:10.0.0.12:8061 advertise PUBLIC_IP` Websocket module: ``` loadmodule "websocket.so" tcp_accept_no_cl=yes ``` ``` event_route[websocket:closed] { xlog("L_NOTICE", "WebSocket connection closed $proto:$si:$sp\n"); <I also delete where a htable key> } ``` #### Debugging Data ``` [root@ ~]$ prcmd ws.dump { connections: { } info: { wscounter: 0 truncated: no } } [root@ ~]$ netstat -ano | grep 8061 tcp 0 0 10.0.0.12:8061 0.0.0.0:* LISTEN off (0.00/0/0) [root ~]$ prcmd htable.dump wsauth | grep "name" | wc -l 3 [root ~]$ cat /var/log/kamailio.log | grep "WebSocket connection closed" | wc -l 997 [root ~]$ cat /var/log/proxy-registrar/proxy-registrar.log | grep "ERR" | grep "WAR" | wc -l 0 ``` #### Log Messages Nothing relevant. #### SIP Traffic Nothing relevant here, the SIP Flow is OK. ### Additional Information ``` version: kamailio 5.6.4 (x86_64/linux) a004cf-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: a004cf -dirty compiled on 23:17:27 Jun 7 2024 with gcc 4.8.5 ``` * **Operating System**: ``` CentOS Linux release 7.9.2009 (Core) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3950 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3950(a)github.com>

6 7

[kamailio/kamailio] If fix_nated_contact is used, then remove_hf("Contact"), the contact header will not be deleted cleanly. (Issue #4190)
by QuincyGao 24 Jun '25

24 Jun '25

QuincyGao created an issue (kamailio/kamailio#4190)  ### Description  I want to use opensips as SBC, When the agent registers to kamailio, the contact content is modified to the ip and port of kamailio, and then Register is forwarded to the agent. remove_hf("Contact") can't remove the whole Contact( field, vlue). here is my config: ``` route[REGISTRAR] { if (!is_method("REGISTER")) return; if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); #!ifdef WITH_NATSIPPING # do SIP NAT pinging setbflag(FLB_NATSIPPING); #!endif } fix_nated_contact(); if (!save("location","0x02")) { #if (!save("location")) { sl_reply_error(); } $fs="udp:172.16.4.111:5461"; $du="sip:172.16.4.114:5060"; remove_hf("Contact"); $var(contact) = "Contact: <sip:" +$fU+"@"+"172.16.4.111:5461>;expires=120\r\n" ; append_hf("$var(contact)"); route(RELAY); exit; } ``` here is the sip message: ``` 2025/03/26 16:36:07.706093 172.16.4.111:5461 -> 172.16.4.114:5060 REGISTER sip:172.16.4.111:5460 SIP/2.0 Via: SIP/2.0/UDP 172.16.4.111:5461;branch=z9hG4bKfc7e.d2df36f3b5681afeb71e442e645de38d.0 Via: SIP/2.0/UDP 172.16.80.3:49309;received=172.16.80.3;rport=49309;branch=z9hG4bKPj8ab8bd1d3c3a4c1bb0cd639540fa3183 Max-Forwards: 69 From: <sip:1008@172.16.4.111>;tag=95f7f5601f8b40458a1efe6923ab0a29 To: <sip:1008@172.16.4.111> Call-ID: f84b643f5d284d18a0d8175e1ef4d747 CSeq: 33264 REGISTER User-Agent: MicroSIP/3.21.6 sip:1008@172.16.80.3:49309;obExpires: 120 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 Contact: <sip:1008@172.16.4.111:5461>;expires=120 ``` you can see the problem is that: `sip:1008@172.16.80.3:49309;obExpires: 120` , `sip:1008@172.16.80.3:49309` is the value of the Contact field after fix_nated_contact(). ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled on 11:27:01 Mar 21 2025 with gcc 4.8.5 ``` * **Operating System**:  ``` Centos7.9 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4190 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4190(a)github.com>

2 4

[kamailio/kamailio] Writing to $fU or $tU appends to header user (Issue #3165)
by Benoît Panizzon 24 Jun '25

24 Jun '25

Dear Gang Possibly @oej could provide more in-depth information as he has witnessed this issue. Usually the user of the from URI is the phone number displayed at the destination. There are situations where this phone number is translated. As example. In Switzerland, the user is used to see numbers in a local format. National number starting with 0 and international numbers with 00 but on interconnection between telcos, e164 is used. So basically when a call is sent to a customer '+41' is replaced by '0' and '+' is replaced by '00'. Let's start with an example From: header: `From: "Maurice Moss" <sip:+41991234567@example.com>;user=phone` So shortly before the call is sent out to the location of the registered CPE, this is done: ``` if ($fU =~ "^\+41") { $fU = "0" + $(fU{s.substr,3,0}); } else if ($fU = ~ "^\+") { $fU = "00" + $(fU{s.substr,1,0}); } ``` What is sent to the CPE now looks like this: `From: "Maurice Moss" <sip:0991234567@example.com>;user=phone` Now we hit an error like 486 BUSY and the destination has call forwarding active to a mobile phone on another TSP. So we have to send the call out back the IC and numbers need to be translated back to e164. We handle this in a failure route, which in turn could trigger a branch route. So we revert the number back to e164: `$fU = "+41" + $(fU{s.substr,1,0});` Expected outcome: `From: "Maurice Moss" <sip:+41991234567@example.com>;user=phone` Observed outcome: `From: "Maurice Moss" <sip:0991234567+41991234567@example.com>;user=phone` So setting $fU more than once is appending to the user element of the From header URI. This behavior has not been found in any documentation. I have been working around most of the issues by making sure I change $fU (and $tU) at the latest possible time and only once. But in the case described above, I have not been able to come up with a work-around yet. I also can't think of any benefit of the way those PV are handled or any harm that could be done, to handle them differently and make the last 'write' overwrite and previous value, instead of appending. Thank you for looking into this. -Benoît- -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3165 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3165(a)github.com>

3 4

[kamailio/kamailio] Crash involving rtpengine (Issue #4179)
by Joe Mordica 24 Jun '25

24 Jun '25

jmordica created an issue (kamailio/kamailio#4179) ### Description Kamailio crash involving rtpengine ### Troubleshooting #### Reproduction  #### Debugging Data  ``` GNU gdb (Debian 13.1-3) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/kamailio... Reading symbols from /usr/lib/debug/.build-id/20/dc8be8c0aa02eba62b84db3c283789f068fb79.debug... warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing [New LWP 37] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `kamailio -DD -E -m 8000 -M 512 -f /etc/kamailio/kamailio.cfg -P /var/run/kamail'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt full #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 tid = <optimized out> ret = 0 pd = <optimized out> old_mask = {__val = {0}} ret = <optimized out> #1 0x00007f0a2dd31f1f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 No locals. #2 0x00007f0a2dce2fb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 ret = <optimized out> #3 0x00007f0a2dccd472 in __GI_abort () at ./stdlib/abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {1880844493789993498, 1880844493789993498, 1880844493789993498, 0, 0, 0, 0, 2314885530818453536, 2314885530818453536, 2314885530818453536, 2314885530818453536, 0, 0, 0, 0, 94814674008008}}, sa_flags = 365707264, sa_restorer = 0x563bc3029320 <log_prefix_buf>} #4 0x0000563bc2e27414 in qm_debug_check_frag (qm=qm@entry=0x7f0815cc4000, f=f@entry=0x7f0834533950, file=file@entry=0x7f0a0a93420f "rtpengine: rtpengine_hash.c", line=line@entry=528, eline=eline@entry=546, efile=0x563bc2f6abcc "core/mem/q_malloc.c") at core/mem/q_malloc.c:132 p = <optimized out> __func__ = "qm_debug_check_frag" #5 0x0000563bc2e282b9 in qm_free (qmp=<optimized out>, p=0x7f0834533990, file=0x7f0a0a93420f "rtpengine: rtpengine_hash.c", func=0x7f0a0a935040 <__func__.2> "rtpengine_hash_table_free_entry", line=528, mname=0x7f0a0a92a000 "rtpengine") at core/mem/q_malloc.c:546 qm = <optimized out> f = 0x7f0834533950 size = <optimized out> next = <optimized out> prev = <optimized out> __func__ = "qm_free" #6 0x0000563bc2e2d51f in qm_shm_free (qmp=<optimized out>, p=0x7f0834533990, file=0x7f0a0a93420f "rtpengine: rtpengine_hash.c", func=0x7f0a0a935040 <__func__.2> "rtpengine_hash_table_free_entry", line=528, mname=0x7f0a0a92a000 "rtpengine") at core/mem/q_malloc.c:1532 No locals. #7 0x00007f0a0a922adb in rtpengine_hash_table_free_entry (entry=0x7f08263a3f80) at ./src/modules/rtpengine/rtpengine_hash.c:528 __func__ = "rtpengine_hash_table_free_entry" --Type <RET> for more, q to quit, c to continue without paging--info locals #8 0x00007f0a0a927dd4 in rtpengine_hash_table_lookup (callid=..., viabranch=..., op=op@entry=OP_OFFER) at ./src/modules/rtpengine/rtpengine_hash.c:428 entry = 0x7f08263a3f80 last_entry = 0x7f08174e0450 hash_index = 87 node = <optimized out> __func__ = "rtpengine_hash_table_lookup" #9 0x00007f0a0a90ec2b in select_rtpp_node_old (do_test=1, op=OP_OFFER, viabranch=..., callid=...) at ./src/modules/rtpengine/rtpengine.c:3810 node = 0x0 node = <optimized out> __func__ = "select_rtpp_node_old" __llevel = <optimized out> __kld = <optimized out> __llevel = <optimized out> __kld = <optimized out> #10 select_rtpp_node (callid=..., viabranch=..., queried_nodes_list=0x7f0a0de84430, queried_nodes=queried_nodes@entry=0, op=OP_OFFER, do_test=1) at ./src/modules/rtpengine/rtpengine.c:3864 node = 0x0 __func__ = "select_rtpp_node" #11 0x00007f0a0a91228a in rtpp_function_call (bencbuf=bencbuf@entry=0x7ffeb1d5bea0, msg=msg@entry=0x7f0a0de94350, op=<optimized out>, flags_str=<optimized out>, body_out=body_out@entry=0x7ffeb1d5be80, cl_field=cl_field@entry=0x7ffeb1d5be90) at ./src/modules/rtpengine/rtpengine.c:3178 ng_flags = {via = -1, to = 1, packetize = 0, transport = 256, directional = 0, dict = 0x7f0a0de98b78, flags = 0x7f0a0de98d08, direction = 0x7f0a0de98e68, replace = 0x7f0a0de98ec8, rtcp_mux = 0x7f0a0de98f28, sdes = 0x7f0a0de98f88, t38 = 0x7f0a0de99098, received_from = 0x7f0a0de98e08, codec = 0x7f0a0de990f8, codec_strip = 0x0, codec_offer = 0x0, codec_transcode = 0x0, codec_mask = 0x0, codec_set = 0x0, codec_except = 0x0, codec_accept = 0x0, codec_consume = 0x0, call_id = { s = 0x563bc30e195f <buf+287> "5783b150-6ad4-4e55-9555-decf4048c8fb\r\nCSeq: 23471 INVITE\r\nAllow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, INFO, REFER\r\nk: replaces, histinfo\r\nX-UNIQUEI"..., len = 36}, from_tag = { s = 0x563bc30e18fb <buf+187> "47d9d572-1f09-46bf-b966-16988c17cf56\r\nt: <sip:02-5333@10.142.0.56>\r\nm: <sip:vxm@10.52.7.2:5081>\r\ni: 5783b150-6ad4-4e55-9555-decf4048c8fb\r\nCSeq: 23471 INVITE\r\nAllow: OPTIONS, REGISTER, SUBSCRIBE, NOTIF"..., len = 36}, to_tag = {s = 0x0, len = 0}} item = <optimized out> resp = <optimized out> viabranch = {s = 0x7f0a0dd15720 "z9hG4bKPje1c3efee-2490-4035-9e2e-b124ec630b820", len = 46} body = { s = 0x563bc30e1b33 <buf+755> "v=0\r\no=- 1936793669 1936793669 IN IP4 10.52.7.2\r\ns=VXM\r\nc=IN IP4 10.52.7.2\r\nt=0 0\r\nm=audio 18690 RTP/AVP 0 101\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=ptime:20\r\na=maxptime:140\r\na=sendre"..., len = 204} --Type <RET> for more, q to quit, c to continue without paging--list error = <optimized out> ret = 1 queried_nodes = 0 cont_type = <optimized out> node = <optimized out> cp = <optimized out> pv_val = {rs = {s = 0x7f083a53d3c0 "p", len = -1025336010}, ri = 47244640256, flags = 1} md5 = "\004\220\361\302;V\000\000\260r\366\302;V", '\000' <repeats 11 times>, "\345\323A\270\253\205\301" branch_buf = "\210\033\016\303;V\000\000\177W\315\302;V\000\000\216\033\016\303;V\000\000\000\345\323A\270\253\205\301\224\033\016\303;V\000\000\000\345\323A\270\253\205\301\220\201\351\r\n\177\000\000\000\345" result = <optimized out> t = <optimized out> branch_idx = <optimized out> __func__ = "rtpp_function_call" select_node = <optimized out> #12 0x00007f0a0a917346 in rtpp_function_call_ok (bencbuf=bencbuf@entry=0x7ffeb1d5bea0, msg=msg@entry=0x7f0a0de94350, op=<optimized out>, flags_str=<optimized out>, body=body@entry=0x7ffeb1d5be80, cl_field=cl_field@entry=0x7ffeb1d5be90) at ./src/modules/rtpengine/rtpengine.c:3371 ret = <optimized out> __func__ = "rtpp_function_call_ok" #13 0x00007f0a0a919708 in rtpengine_offer_answer (msg=0x7f0a0de94350, flags=<optimized out>, op=<optimized out>, more=0) at ./src/modules/rtpengine/rtpengine.c:4495 bencbuf = {pieces = 0x7f0a0de9a270, free_list = 0x0, error = 0} dict = <optimized out> body = {s = 0x7f0a0de94350 "\233@\006", len = 1104405760} newbody = <optimized out> anchor = <optimized out> pv_val = {rs = {s = 0x0, len = 177318755}, ri = 0, flags = 4} cur_body = {s = 0x0, len = 0} cl_field = {s = 0x0, len = 0} cl_repl = {s = 0x0, len = 0} __func__ = "rtpengine_offer_answer" error_free = <optimized out> #14 0x0000563bc2c77195 in sr_kemi_exec_func (ket=ket@entry=0x7f0a0a93d5c8 <sr_kemi_rtpengine_exports+72>, msg=<optimized out>, pno=pno@entry=1, vps=<optimized out>) at core/kemiexec.c:84 ``` #### Log Messages  ``` CRITICAL: {1 23471 INVITE 5783b150-6ad4-4e55-9555-decf4048c8fb} <core> [core/mem/q_malloc.c:148]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0c00a0d, abcdefed)[0x7f0834533950:0x7f0834533990]! Memory allocator was called from rtpengine: rtpengine_hash.c:528. Fragment marked by rtpengine: ../../core/parser/../ut.h:891. Exec from core/mem/q_malloc.c:546. CRITICAL: {1 23471 INVITE 5783b150-6ad4-4e55-9555-decf4048c8fb} <core> [core/mem/q_malloc.c:156]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten [0x7f08345335b0:0x7f08345335f0] - fragment marked by core: core/msg_translator.c:2305 ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**:  ``` Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Linux gke-us-east1-external-sip-4b67daea-x3rj 5.15.0-1020-gke #25-Ubuntu SMP Thu Oct 27 05:38:18 UTC 2022 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4179 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4179(a)github.com>

4 10

[kamailio/kamailio] cmake: switching deb rules (Issue #4053)
by Victor Seva 23 Jun '25

23 Jun '25

Opening this generic issue to track issues when trying to switch deb package generation to cmake: -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4053 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4053(a)github.com>

5 59

[kamailio/kamailio] Handling Duplicate Values in secfilter Module's kamcmd Commands (Issue #4091)
by AsedMorteza 23 Jun '25

23 Jun '25

**Description** The `secfilter` module in `kamcmd` currently allows duplicate entries when adding values to certain lists (e.g., blacklists, whitelists). This can lead to unexpected behavior and potential inconsistencies. Could you clarify the reason behind accepting duplicate values? Recently, I submitted a pull request to add delete commands to the `secfilter` module #4089. When a user, for example, executes: `kamcmd secfilter.del_bl user 1005` I iterate through the entire list to ensure all occurrences of `1005` are removed, as I realized duplicates might exist. This is inefficient and could be avoided by preventing duplicates in the first place. **Proposed Solutions** 1. **Prevent Duplicates in Existing `add` Commands:** * I can modify existing `add` commands to directly prevent the addition of duplicate values. This would simplify future operations and improve performance. 2. **Introduce New `add_unique` Commands:** * I can maintain the current `add` commands for backward compatibility. * I can introduce new `add_unique` commands (e.g., `secfilter.add_bl_unique`) that explicitly reject duplicate entries. **Recommendation** I recommend implementing the first solution (preventing duplicates in existing `add` commands) as it provides the most straightforward and efficient approach. **Further Considerations** * Consider adding a check for duplicates during the `add` operation and returning an appropriate error message if a duplicate is encountered. * Document the behavior of duplicate values in the `secfilter` module's documentation. **I would appreciate your feedback and guidance on the best course of action.** -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4091 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4091(a)github.com>

6 12

[kamailio/kamailio] topoh: fix bug in hiding record routes in reply messages (PR #4170)
by Farzaneh Soltanzadeh 21 Jun '25

21 Jun '25

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4170 -- Commit Summary -- * hide all record routes except last one in reply messages -- File Changes -- M src/modules/topoh/th_msg.c (16) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4170.patch https://github.com/kamailio/kamailio/pull/4170.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4170 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4170(a)github.com>

3 13

[kamailio/kamailio] ims_diameter_server not freeing shared memory (Issue #4116)
by MGrimby 19 Jun '25

19 Jun '25

### Description I have run in to an issue when sending diameter requests using the ims_diameter_server module. Shared memory keeps increasing and are not being freed until restart of kamailio. This leads to all shared memory is being used and no more are able to be allocated. This only happens when the request is sent synchronously. When sent asynchronously shared memory is being freed as far as I can see. Following functions have been used for sending requests. diameter_request([peer], appid, commandcode, message) diameter_request_async([peer], appid, commandcode, message) ### Troubleshooting Sent a bunch of diameter requests and verified that shared memory for the following functions are not freed. do_receive(600): AAATranslateMessage(500): AAACreateAVP(137): #### Reproduction It's possible to reproduce by sending sync diameter request and verify shared memory. Example of diameter request block ``` route[CHECK_LOCATION] { diameter_request("hss.ims.test.local", "16777217", "306", "[ " + "{ \"avpCode\":260, \"vendorId\":0, \"Flags\":64, \"list\":[ { \"avpCode\":266, \"vendorId\":0, \"Flags\":64, \"int32\":10415 }, { \"avpCode\":258, \"vendorId\":0, \"Flags\":64, \"int32\":16777217 } ] }, " + "{ \"avpCode\":277, \"vendorId\":0, \"Flags\":64, \"int32\":1 }, " + "{ \"avpCode\":283, \"vendorId\":0, \"Flags\":64, \"string\":\"ims.test.local\"}, " + "{ \"avpCode\":706, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":700, \"vendorId\":10415, \"Flags\":192, \"list\": [ { \"avpCode\":601, \"vendorId\":10415, \"Flags\":192, \"string\":\"tel:" + $fU + "\" }]}, " + "{ \"avpCode\":707, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":703, \"vendorId\":10415, \"Flags\":192, \"int32\":14 } ]"); xlog("L_INFO", "Sent Diameter request"); } ``` Stats cdp:replies_received = 343310 shmem:fragments = 142 shmem:free_size = 1221489992 shmem:max_used_size = 948242168 shmem:real_used_size = 925993656 shmem:total_size = 2147483648 shmem:used_size = 558205656 kamcmd mod.stats cdp shm do_receive(600): 256245808 AAATranslateMessage(500): 64420712 AAACreateAVP(137): 218100320 Total: 538774000 #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) dc393e flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: dc393e compiled on 13:56:27 Feb 27 2024 with gcc 8.5.0 ``` * **Operating System**:  ``` Linux bmatkamas1 4.18.0-553.16.1.el8_10.x86_64 #1 SMP Thu Aug 1 04:16:12 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 8.10 (Ootpa) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4116 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4116(a)github.com>

4 6

[kamailio/kamailio] Memory usage increases everytime tls.reload is executed (Issue #3823)
by Sebastian Denz 18 Jun '25

18 Jun '25

### Description We are using Kamailio 5.7.4 on Debian 12 (from http://deb.kamailio.org/kamailio57) with rtpengine as an Edgeproxy for our clients. The instance terminates SIP/TLS (with Cliencertificates) and forwards the SIP Traffic to internal systems. After some days we are getting errors like this `tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=7318616 threshold1=8912896` First we thought Kamailio just doesnt have enough memory, so we doubled it.. But after some days the Logmessage (and Userissues) occured again. So we monitored the shmmem statistics and found that used and max_used are constantly growing til it reaches the limit. As i mentioned we are using client-certificates and so we are also using the CRL feature. We do have a systemd-timer which fetches the CRL every hour and runs 'kamcmd tls.reload' when finished. Our tls.cfg looks like this: ``` [server:default] method = TLSv1.2+ private_key = /etc/letsencrypt/live/hostname.de/privkey.pem certificate = /etc/letsencrypt/live/hostname.de/fullchain.pem ca_list = /etc/kamailio/ca_list.pem ca_path = /etc/kamailio/ca_list.pem crl = /etc/kamailio/combined.crl.pem verify_certificate = yes require_certificate = yes [client:default] verify_certificate = yes require_certificate = yes ``` After testing a bit we found that every time tls.reload is executed Kamailio consumes a bit more memory which eventually leads to all the memory being consumed which leads to issues for our users. See following example: ``` [0][root@edgar-dev:~]# while true ; do /usr/sbin/kamcmd tls.reload ; /usr/sbin/kamcmd core.shmmem ; sleep 1 ; done Ok. TLS configuration reloaded. { total: 268435456 free: 223001520 used: 41352552 real_used: 45433936 max_used: 45445968 fragments: 73 } Ok. TLS configuration reloaded. { total: 268435456 free: 222377960 used: 41975592 real_used: 46057496 max_used: 46069232 fragments: 78 } Ok. TLS configuration reloaded. { total: 268435456 free: 221748664 used: 42604992 real_used: 46686792 max_used: 46698080 fragments: 77 } Ok. TLS configuration reloaded. { total: 268435456 free: 221110832 used: 43242408 real_used: 47324624 max_used: 47335608 fragments: 81 } ^C [130][root@edgar-dev:~]# ``` ### Troubleshooting #### Reproduction Everytime tls.reload is called the memory consumptions grows.. #### Debugging Data  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### Log Messages  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### SIP Traffic SIP doesnt seem to be relevant here ### Possible Solutions Calling tls.reload less often or restart kamailio before memory is consumed ;) ### Additional Information ``` version: kamailio 5.7.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**: ``` * Debian GNU/Linux 12 (bookworm) * Linux edgar-dev 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3823 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3823(a)github.com>

9 33

[kamailio/kamailio] cmake format options and naming styles (Issue #4075)
by Daniel-Constantin Mierla 18 Jun '25

18 Jun '25

Discussion to define cmake format options and coding/naming styles. It is better to define most of them now to have coherency in the future. Started from the discussion on #4066. Comment with what you would like to have, describing when useful why your proposal is a good/better option. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4075 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4075(a)github.com>

5 12

[kamailio/kamailio] TOPOS removes via header when calling drop in event_route[topos:msg-outgoing] (Issue #4157)
by Brandon Armstead 16 Jun '25

16 Jun '25

CrazyTux created an issue (kamailio/kamailio#4157) ### TOPOS removes via header ``` event_route[topos:msg-outgoing] { # Feature Flag is enabled ** problem occurs here ** if($sht(feature_flags=>kamailio-disable-internal-topos) == "true") { if(ds_is_from_list(KAM_SET_ID, 3, "sip:$sndto(ip):5060")) { drop; } } } ``` ### Troubleshooting - verified via exists in original 200 OK REPLY from Freeswitch - checked wire and verified via header is missing when forwarding 200 OK onward to next kamailio (B) node from Kamailio (A) #### Reproduction Call drop in event route `topos:msg-outgoing` - call flow: Freeswitch -> Kamailio A -> Kamailio B -> UAC - place incoming call into kamailio - put call on hold / reinvite #### Debugging Data ``` Disabling topos entirely via header is correctly sent from A -> B. ``` #### Log Messages (Kamailio B) ``` 2025-02-25T00:19:08.545447+00:00 /usr/sbin/kamailio[3959021]: ERROR: {2 1 INVITE 995df181-4eae-40ae-8225-427ce8252250} <core> [core/receive.c:542]: receive_msg(): no via found in reply 2025-02-25T00:19:09.045917+00:00 /usr/sbin/kamailio[3959037]: ERROR: {2 1 INVITE 995df181-4eae-40ae-8225-427ce8252250} <core> [core/receive.c:542]: receive_msg(): no via found in reply 2025-02-25T00:19:10.046936+00:00 /usr/sbin/kamailio[3958995]: ERROR: {2 1 INVITE 995df181-4eae-40ae-8225-427ce8252250} <core> [core/receive.c:542]: receive_msg(): no via found in reply 2025-02-25T00:19:12.048099+00:00 /usr/sbin/kamailio[3959003]: ERROR: {2 1 INVITE 995df181-4eae-40ae-8225-427ce8252250} <core> [core/receive.c:542]: receive_msg(): no via found in reply ``` #### SIP Traffic `reinvite B -> A:` ``` INVITE sip:mod_sofia@54.245.XX.XX:5060 SIP/2.0 Record-Route: <sip:35.161.XX.XX:5060;r2=on;lr;ftag=9vX27Um099jZS;did=a2b.7e62> Record-Route: <sip:35.161.XX.XX:7443;transport=ws;r2=on;lr;ftag=9vX27Um099jZS;did=a2b.7e62> Via: SIP/2.0/UDP 35.161.XX.XX:5060;branch=z9hG4bK16be.085d2f3d83e8d939f7f1d3fbc4a5ff09.0 Via: SIP/2.0/WSS 74jssm3ooc66.invalid;received=209.160.251.114;branch=z9hG4bK3968143 To: <sip:9496294444@54.245.XX.XX>;tag=9vX27Um099jZS From: <sip:Dff742e5340fDd93847e@9e3f4e45-01cf-1f66-8d70-8d14ec555153>;tag=q1vfbk6o6q CSeq: 1 INVITE Call-ID: 995df181-4eae-40ae-8225-427ce8252250 Max-Forwards: 69 Allow: ACK,BYE,CANCEL,INFO,INVITE,MESSAGE,NOTIFY,OPTIONS,PRACK,REFER,REGISTER,SUBSCRIBE Contact: <sip:tu0r7r7u@74jssm3ooc66.invalid;transport=ws> Supported: outbound User-Agent: WebPhone/3.1740423483.87 Content-Type: application/sdp Content-Length: 1538 Route: <sip:34.213.XX.XX:5060;r2=on;lr;ftag=9vX27Um099jZS;did=a2b.1142>,<sip:34.213.XX.XX;r2=on;lr;ftag=9vX27Um099jZS;did=a2b.1142> P-SR-XUID: atpsh-7cde-67bcbccd-3c68ef-1 v=0 o=- 4757376688759011024 3 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 a=extmap-allow-mixed a=msid-semantic: WMS 35a33e17-dd80-46fa-afe9-72fdd03d4e41 m=audio 32999 UDP/TLS/RTP/SAVPF 0 102 101 103 63 9 8 13 c=IN IP4 209.160.251.114 a=rtcp:9 IN IP4 0.0.0.0 a=candidate:2845667355 1 udp 2122260223 10.82.226.218 54425 typ host generation 0 network-id 1 network-cost 10 a=candidate:1750280017 1 udp 1686052607 209.160.251.114 32999 typ srflx raddr 10.82.226.218 rport 54425 generation 0 network-id 1 network-cost 10 a=ice-ufrag:Eb9h a=ice-pwd:nQdfpsILiUI+YKSQT3eZy52x a=ice-options:trickle a=fingerprint:sha-256 BA:68:25:D5:66:70:A9:17:38:18:74:0A:B3:C2:3E:F9:3A:A0:7C:5F:18:0F:EB:B7:93:28:86:56:62:23:DF:E5 a=setup:actpass a=mid:0 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=sendonly a=msid:35a33e17-dd80-46fa-afe9-72fdd03d4e41 57910219-943b-4687-9511-b9a9d0a1ea6f a=rtcp-mux a=rtcp-rsize a=rtpmap:0 PCMU/8000 a=rtpmap:102 opus/48000/2 a=fmtp:102 minptime=10;useinbandfec=1 a=rtpmap:101 telephone-event/8000 a=rtpmap:103 telephone-event/48000 a=rtpmap:63 red/48000/2 a=fmtp:63 102/102 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:13 CN/8000 a=ssrc:2604971680 cname:YEcJO5XrSKZor1jY a=ssrc:2604971680 msid:35a33e17-dd80-46fa-afe9-72fdd03d4e41 57910219-943b-4687-9511-b9a9d0a1ea6f ``` `200 OK Freeswitch -> A` ``` SIP/2.0 200 OK v:SIP/2.0/UDP 34.213.XX.XX:5060;branch=z9hG4bK16be.86ee5e1d4190783bd6a79bd21110d190.0 f:<sip:Dff742e5340fDd93847e@9e3f4e45-01cf-1f66-8d70-8d14ec555153>;tag=q1vfbk6o6q t:<sip:9496294444@54.245.XX.XX>;tag=9vX27Um099jZS i:995df181-4eae-40ae-8225-427ce8252250 CSeq:1 INVITE m:<sip:mod_sofia@54.245.XX.XX:5060> Accept:application/sdp Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REGISTER,REFER,NOTIFY,PUBLISH,SUBSCRIBE k:timer,path,replaces x:90;refresher=uas c:application/sdp Content-Disposition:session l:284 v=0 o=FreeSWITCH 1740424963 1740424965 IN IP4 54.245.XX.XX s=FreeSWITCH c=IN IP4 54.245.XX.XX t=0 0 m=audio 17776 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=recvonly a=ptime:20 a=rtcp-mux a=rtcp:17776 IN IP4 54.245.XX.XX ``` `200 OK A -> B` ``` SIP/2.0 200 OK f:<sip:Dff742e5340fDd93847e@9e3f4e45-01cf-1f66-8d70-8d14ec555153>;tag=q1vfbk6o6q t:<sip:9496294444@54.245.XX.XX>;tag=9vX27Um099jZS i:995df181-4eae-40ae-8225-427ce8252250 CSeq:1 INVITE m:<sip:mod_sofia@54.245.XX.XX:5060> Accept:application/sdp Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REGISTER,REFER,NOTIFY,PUBLISH,SUBSCRIBE k:timer,path,replaces x:90;refresher=uas c:application/sdp Content-Disposition:session l:315 v=0 o=FreeSWITCH 1740424963 1740424965 IN IP4 34.211.XX.XX s=FreeSWITCH c=IN IP4 34.211.XX.XX t=0 0 m=audio 20374 RTP/AVP 0 101 a=mid:0 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=recvonly a=rtcp:20374 a=rtcp-mux a=ptime:20 a=ice-options:trickle a=end-of-candidates ``` ### Possible Solutions TBD ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.2 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 ``` <img width="629" alt="Image" src="https://github.com/user-attachments/assets/fc46f76e-7a6f-431f-a00e-84fbbece…" /> * **Operating System**: ``` No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye ``` I can provide PCAP as well if required. Let me know if additional information is required. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4157 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4157(a)github.com>

4 10

[kamailio/kamailio] tcp_timer_check_connections() logs on CRITICAL and is not caught by event_route[tcp:timeout] (Issue #3995)
by Fritjof Höst 13 Jun '25

13 Jun '25

### Description Hi! We are in the progress of upgrading from Kamailio 5.5 to 5.8. During our testing we have noticed a new error being reported from Kamailio. We don’t see any other errors following it. ```jsx /usr/sbin/kamailio[201]: CRITICAL: <core> [core/tcp_main.c:5544]: tcp_timer_check_connections(): message processing timeout on connection id: 67896 (state: 3) - closing ``` It does seem to be [new code](https://github.com/kamailio/kamailio/blob/master/src/core/tcp_main.c#… in Kamailio reporting this issue. Given that this is a fairly expected thing, cleaning up a connection which receives no traffic within the given time, is there a need for it to be reported on CRITICAL? I’d also expect it to be caught by ``` event_route[tcp:timeout] { xlog("L_INFO","connection $conid timeouts (unanswered keepalives)"); } ``` given that [the description](https://www.kamailio.org/docs/modules/stable/modules/tcpops.ht… of this one is `Called for connection timeouts (unanswered keepalives).`. ### Troubleshooting We don't have any way to reproduce it, we are still investigating it to figure out the cause. It happens around every 2 hours, so we think there might some some scheduled test or job running in our test system causing this. ### Additional Information * **Kamailio Version** - 5.8.3 * **Operating System**: Debian 12 AMI from the AWS Marketplace. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3995 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3995(a)github.com>

6 12

[kamailio/kamailio] tls_wolfssl: crash qm_free / qm_debug_check_frag (Issue #4074)
by Fred Posner 12 Jun '25

12 Jun '25

### Introduction First, I apologize for the lack of detail here. I am unable to get a core dump and as a production box, I was unable to run in debug mode. ### Description Using Kamailio 5.8.4 on Debian 12, every 60-80 minutes, the software would crash, blaming tls_wolfssl, such as: ``` 2024-12-16T14:58:27.554497+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[9084]: CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: bad pointer 0x1 (out of memory block!) called from tls_wolfssl: tls_init.c: ser_free(240) - ignoring 2024-12-16T14:58:27.554555+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[9084]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f3440ba7560 (address 0x7f3440ba75a0) beginning overwritten (23)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by :29. Exec from core/mem/q_malloc.c:546. 2024-12-16T14:58:27.616558+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[9089]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 103 2024-12-16T14:58:27.617684+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[8992]: ALERT: <core> [main.c:805]: handle_sigs(): child process 9084 exited by a signal 6 2024-12-16T14:58:27.618339+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[8992]: ALERT: <core> [main.c:809]: handle_sigs(): core was not generated 2024-12-16T14:58:27.618477+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[8992]: INFO: <core> [main.c:832]: handle_sigs(): terminating due to SIGCHLD 2024-12-16T14:58:27.618589+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[9088]: INFO: <core> [main.c:888]: sig_usr(): signal 15 received ``` ``` 2024-12-16T14:57:52.029277+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21605]: CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: bad pointer 0x1 (out of memory block!) called from tls_wolfssl: tls_init.c: ser_free(240) - ignoring 2024-12-16T14:57:52.029347+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21605]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f085996b500 (address 0x7f085996b540) beginning overwritten (0)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:546. 2024-12-16T14:57:52.048597+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21611]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 101 2024-12-16T14:57:52.048921+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21512]: ALERT: <core> [main.c:805]: handle_sigs(): child process 21605 exited by a signal 6 2024-12-16T14:57:52.048953+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21512]: ALERT: <core> [main.c:809]: handle_sigs(): core was not generated 2024-12-16T14:57:52.048975+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21512]: INFO: <core> [main.c:832]: handle_sigs(): terminating due to SIGCHLD 2024-12-16T14:57:52.048997+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21609]: INFO: <core> [main.c:888]: sig_usr(): signal 15 received ``` ``` 2024-12-16T16:21:35.967576+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[10591]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f442778d110 (address 0x7f442778d150) beginning overwritten (0)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:546. ``` ``` 2024-12-16T13:31:55.995222+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7602]: CRITICAL: <core> [core/mem/q_malloc.c:555]: qm_free(): BUG: freeing already freed pointer (0x7f8e55830a70), called from tls_wolfssl: tls_init.c: ser_free(240), first free tls_wolfssl: tls_init.c: ser_malloc(228) - ignoring 2024-12-16T13:32:40.093954+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7603]: CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: bad pointer 0x7a100000000 (out of memory block!) called from tls_wolfssl: tls_init.c: ser_free(240) - ignoring 2024-12-16T13:32:40.094047+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7603]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f8e55762720 (address 0x7f8e55762760) beginning overwritten (0)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:546. 2024-12-16T13:32:40.260913+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7504]: CRITICAL: <core> [core/mem/q_malloc.c:555]: qm_free(): BUG: freeing already freed pointer (0x7f8e55761a70), called from core: core/tcp_main.c: _tcpconn_free(1666), first free tls_wolfssl: tls_init.c: ser_free(240) - ignoring 2024-12-16T13:32:40.263520+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7504]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f8e55762720 (address 0x7f8e55762760) beginning overwritten (0)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:546. ``` The system was handling ~900 TLS registrations with ~2700 presence SUBSCRIBE events. **Running the same config with `tls.so` does not result in crash.** ### Additional Information * **Kamailio Version** - 5.8.4 ``` version: kamailio 5.8.4 (x86_64/linux) 598105-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 598105 -dirty compiled on 04:31:34 Dec 16 2024 with gcc 12.2.0 ``` * **Operating System**: ``` Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Linux ip-172-16-0-52 6.1.0-28-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux ``` * TCP Settings ``` children=16 disable_tcp=no tcp_connection_lifetime=3605 tcp_accept_no_cl=yes tcp_max_connections=8192 tcp_defer_accept=yes tcp_accept_unique=0 tcp_connection_lifetime=3605 tcp_connection_match=1 tcp_connect_timeout=10 tcp_crlf_ping=yes tcp_linger2=1 tcp_keepalive=yes tcp_reuse_port=yes tcp_keepidle=20 tcp_keepintvl=15 tcp_rd_buf_size=65536 tcp_msg_data_timeout=40 tcp_msg_read_timeout=40 tcp_check_timer=20 tls_threads_mode=2 tls_max_connections=8192 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4074 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4074(a)github.com>

3 6

[kamailio/kamailio] tcp_send_timeout does not apply for outbound connections (Issue #4187)
by Oleg Vedeneev 11 Jun '25

11 Jun '25

ovedeneev created an issue (kamailio/kamailio#4187) ### Description [tcp_send_timeout](https://www.kamailio.org/wikidocs/cookbooks/5.8.x/core/#t… option does not apply for outbound connections. #### Reproduction 1. Establish TCP OPTIONS between Kamailio and target node. 2. On target node block incoming traffic from Kamailio node using iptables. 3. Notice on Kamailio node that TCP retransmission packets don't follow tcp_send_timeout settings, instead they fall back to kernel's net.ipv4.tcp_retries2 settings. ### Additional Information * **Kamailio Version** ``` # kamailio -V version: kamailio 5.8.2 (aarch64/linux) 446039 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT-NOSMP, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 446039 compiled on 14:32:09 Nov 14 2024 with gcc 8.5.0 ``` * **Operating System**: ``` Linux xxx 4.18.0-553.6.1.el8.aarch64 #1 SMP Thu May 30 04:10:32 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4187 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4187(a)github.com>

4 5

[kamailio/kamailio] rtpengine: fix race condn (same ip:port) in parallel forks due to gencookie (PR #4139)
by Souradeep Bera 01 Jun '25

01 Jun '25

- avoid parallel calls to gencookie from generating the same cookie for rtpengine #### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4139 -- Commit Summary -- * rtpengine: fix race condn assigning same ip:port due to gencookie in parallel forks -- File Changes -- M src/modules/rtpengine/rtpengine.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4139.patch https://github.com/kamailio/kamailio/pull/4139.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4139 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4139(a)github.com>

4 6

[kamailio/kamailio] Possibly adjusting the SDP parser to be more lenient towards scenarios where a stream is being removed/rejected and connection-information "c=" is only available per media (no session-wide "c=") and the removed/rejected stream omits all fields (Issue #3982)
by thomas414 31 May '25

31 May '25

### Description I encountered an issue with a specific device that is receiving a T.38 fax. The call gets established towards the device normally with inband media, then the device requests T.38 media and tries to remove the audio media via sending port 0 in the ReInvite SDP. Also it sends connection-information only on the media level and there is no "c=" on the session level. Reading through the related RFCs and the kamailio code and discussing this on the mailing list, we came to the conclusion that kamailio is doing everything correct as per RFC. Though we were wondering if it would be possible to adjust the parser to be not as strict as it is right now, and allow a missing "c=" line on the media-level if the stream is removed/rejected via port 0, since i see no sense in requiring connection information. Of course we are also in contact with the vendor to hopefully adjust on their side. Here are the related RFCs: 1. RFC8866 5.7 `A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. It MAY contain a single session-level "c=" line and additional media-level "c=" line(s) per-media-description, in which case the media-level values override the session-level settings for the respective media.` 2. RFC3264 8.2 `Existing media streams are removed by creating a new SDP with the port number for that stream set to zero. The stream description MAY omit all attributes present previously, and MAY list just a single media format.` At first i was especially confused by the RFC3264 8.2 part, since it seemed correct what the device is sending, but if you read carefully and keep the wording for SDP in mind only attributes ("a=") MAY be omitted. So a "c=" line should still be in the SDP for the removed media if it's not included on the session-level. Or do you see this differently? ### Expected behavior Kamailio allows and parses the SDP when there is no session-wide "c=", a media stream is being removed via port zero and there is no "c=" for this media stream and only the remaining media streams include a "c=" line. #### Actual observed behavior Kamailio throws an error when trying to parse the SDP. #### Log Messages ``` <core> [core/parser/sdp/sdp.c:523]: parse_sdp_session(): can't find media IP in the message ``` #### SIP Traffic ``` v=0 o=xmserver 1726638425 1726638427 IN IP4 169.254.1.1 s=xmserver t=0 0 m=audio 0 RTP/AVP 8 m=image 56002 udptl t38 c=IN IP4 169.254.1.1 a=sendrecv a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:72 a=T38FaxUdpEC:t38UDPRedundancy ``` ### Possible Solutions ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.3 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**: ``` Debian 12 Linux hostname 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3982 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3982(a)github.com>

3 5

[kamailio/kamailio] Inactive video stream: can't find media IP in the message (Issue #3406)
by schoberw 31 May '25

31 May '25

### Description In some situations the other side UA must reply with an inactive media stream. E.g. if video was added but not supported by the other side. The UAS then must answer with an m=video 0 RTP/.. line. It seams that the video section must contain a c= line with an IP address for rtpengine to function. If there is no c line (no IP address) the SDP body cannot be parsed and thus no RTP proxy is invoked. ### Troubleshooting Not easy to reproduce since the answer must bei "wrong". Is it correct to reply an SDP body (media = video) like this? ``` m=video 0 RTP/AVPF 96 a=label:1 a=inactive a=mid:1 ``` Maybe not (but Audiocodes SBC lates LTS version does it) - so we are dependent on other side now that this service works. #### Reproduction reInvite with Video to a UA that has no video Support (e.g. Bria -> Snom). Drop the c line in the video part with some textops in 200 OK (just to reproduce of course). A -> B, connect the call A -> + video, B has no video support A presses hold #### Log Messages Incoming 200 OK after doing hold with an inactive video: ``` v=0 o=root 436040161 309284577 IN IP4 1.2.3.5 s=call t=0 0 m=audio 14200 RTP/AVPF 9 8 126 c=IN IP4 1.2.3.5 a=ptime:20 a=recvonly a=mid:0 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000 a=fmtp:126 0-15 m=video 0 RTP/AVPF 96 a=label:1 a=inactive a=mid:1 Mar 27 17:52:22 c5p05es2-1 /usr/sbin/kamailio[2938205]: ERROR: <core> [core/parser/sdp/sdp.c:490]: parse_sdp_session(): can't find media IP in the message Mar 27 17:52:22 c5p05es2-1 /usr/sbin/kamailio[2938205]: INFO: <script>: >>> Sending Reply: 200 OK (1.2.3.4:443 -> 100.108.48.38:65251) ``` Compare to working SDP parsing: ``` a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000 a=fmtp:126 0-15 m=video 0 RTP/AVP 96 c=IN IP4 1.2.3.5 a=inactive a=mid:1 Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: ONREPLY_ROUTE[FORWARD] Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: ROUTE[RTPP_REPLY] Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > 200 with video Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > 200 with inactive video Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > Remove inactive video Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > Answer to WebRTC client: 200 - qijpuibkv6ufhnd282ks Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: >>> Sending Reply: 200 OK (91.237.65.14:443 -> 80.108.48.38:65388) ``` ### Possible Solutions Tried to fix in script: ``` if(sdp_with_media("video")) xlog("L_INFO", "> $rs with video"); if(sdp_with_active_media("video")) xlog("L_INFO", "> $rs with active video"); if(!sdp_with_active_media("video")) xlog("L_INFO", "> $rs with inactive video"); if(sdp_with_media("video") && !sdp_with_active_media("video")) { # try fix for RMT#60189 xlog("L_INFO", "> Remove inactive video"); sdp_remove_media("video"); msg_apply_changes(); # needed? } ``` But since sdpops cannot parse it cannot remove the buggy media, too. See the log: non of the xlog is logging. If there is inactive media the c line is not mandatory. The parser should accept this by adding a default IP of 0.0.0.0, if needed Doing tricks with textops is not a easy nor performant solution to accept this wrong SDP from other parties. ### Additional Information ``` version: kamailio 5.6.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 ``` * **Operating System**: Debian Bullseye -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3406 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3406(a)github.com>

3 5

[kamailio/kamailio] dispatcher: weight documentation and workaround for limitations (PR #4158)
by Christian Berger 31 May '25

31 May '25

- describe limitation of weight parameter - describe a potential workaround against those limitations  #### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [X] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  We had problems understanding the weight parameter of the dispatcher module and wrote a little workaround against the problems we have found. This workaround in the configuration file improves behavior for setups with many dispatcher targets at the cost of more CPU load. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4158 -- Commit Summary -- * dispatcher: weight documentation and workaround for limitations -- File Changes -- M src/modules/dispatcher/doc/dispatcher_admin.xml (28) A src/modules/dispatcher/doc/weights.cfg (49) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4158.patch https://github.com/kamailio/kamailio/pull/4158.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4158 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4158(a)github.com>

4 4

[kamailio/kamailio] core: local TCP socket is bound on listening address (PR #3925)
by sergey-safarov 28 May '25

28 May '25

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description As a local IP address for TCP sending operation the Kamailio service is taking the same network_interface/IP_address, which is used by the service for TCP listening. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3925 -- Commit Summary -- * core: local TCP socket is bound on listening address -- File Changes -- M src/core/tcp_main.c (24) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3925.patch https://github.com/kamailio/kamailio/pull/3925.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3925 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3925(a)github.com>

5 16

[kamailio/kamailio] ims_dialog: missing srdb1 schema definition (Issue #4100)
by Victor Seva 20 May '25

20 May '25

there's no ``kamailio-ims_dialog.xml`` at ``src/lib/srdb1/schema`` but there's a manual file created at ``utils/kamctl/mysql/ims_dialog-create.sql`` Same thing for: - ``utils/kamctl/mysql/ims_charging-create.sql`` - ``utils/kamctl/mysql/ims_usrloc_pcscf-create.sql`` - ``utils/kamctl/mysql/ims_usrloc_scscf-create.sql`` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4100 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4100(a)github.com>

3 10

[kamailio/kamailio] generate rpm packages using github actions (PR #4194)
by sergey-safarov 17 May '25

17 May '25

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description I have refactored the rpm packaging and am now using the GitHub actions. Now `tar.gz` archive with rpm packages, source rpm and deps rpm files attached to the release message like. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4194 -- Commit Summary -- * generate rpm packages using github actions -- File Changes -- A .github/workflows/rpm.yml (57) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4194.patch https://github.com/kamailio/kamailio/pull/4194.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4194 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4194(a)github.com>

2 5

[kamailio/kamailio] rtpengine: select node with weight=0 if no other nodes online (Issue #4180)
by sergey-safarov 13 May '25

13 May '25

sergey-safarov created an issue (kamailio/kamailio#4180) ### Description I have installed two `rtpengine` instances and want to use them as an `active backup`. I want to use `backup` only when `active` is unavailable. Closest settings for this rtpengine node `weight` and want to use settings like ``` MariaDB [kamailio]> select * from rtpengine; +----+-------+---------------------------------+--------+----------+---------------------+ | id | setid | url | weight | disabled | stamp | +----+-------+---------------------------------+--------+----------+---------------------+ | 1 | 0 | udp6:[2005:84c0:bf:11::20]:2223 | 1 | 0 | 1900-01-01 00:00:01 | | 2 | 0 | udp6:[2005:84c0:bf:11::21]:2223 | 0 | 0 | 1900-01-01 00:00:01 | +----+-------+---------------------------------+--------+----------+---------------------+ ``` But in case `weight=0` node is not selected and handled as disabled. It will be fine do not use rtpengine nodes with `weight=0` when other rtpengine with `weight!=0` are available. But if no other nodes are available, use `weight=0` nodes as last resort. ### Expected behavior Do not use rtpengine nodes with `weight=0` when other rtpengine with `weight!=0` are available. But if no other nodes are available, use `weight=0` nodes as last resort. #### Actual observed behavior The node is not selected and handled as disabled when `weight=0`. #### Log Messages ``` rtpengine [rtpengine.c:3430]: rtpp_test(): rtpengine instance <udp6:[2005:84c0:bf:11::21]:2223> found, support for it enabled rtpengine [rtpengine.c:3883]: select_rtpp_node(): rtpengine failed to select new for calllen=27 callid=1-10824@2005:84c0:bf:11::22 rtpengine [rtpengine.c:3183]: rtpp_function_call(): no available proxies ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4180 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4180(a)github.com>

3 3

[kamailio/kamailio] WSS-connections show up as <null> in $tls_version and $tls_cypher_info (Issue #4167)
by Christian Berger 12 May '25

12 May '25

ChristianBergerSipgate created an issue (kamailio/kamailio#4167) Hi, we have found a potential bug. The pseudo variables return null for WSS connections. Example config: `xlog("L_INFO", "<mainLogic> REGISTER: TLS or WSS detected: fU=$fU tls_version=$tls_version tls_cipher_info=$tls_cipher_info ua=$ua\n");` Log output: `Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "ERROR", "module": "tls", "file": "tls_select.c", "line": 131, "function": "get_cur_connection", "message": "Transport protocol is not TLS (bug in config)\n" } Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "tls", "file": "tls_select.c", "line": 310, "function": "get_version", "message": "TLS connection not found in select_version\n" } Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "ERROR", "module": "tls", "file": "tls_select.c", "line": 131, "function": "get_cur_connection", "message": "Transport protocol is not TLS (bug in config)\n" } Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "tls", "file": "tls_select.c", "line": 201, "function": "get_cipher", "message": "TLS connection not found in select_cipher\n" } Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "message": "<mainLogic> REGISTER: TLS or WSS detected: fU=1125411e0 tls_version=<null> tls_cipher_info=<null> ua=webphone\n" }` As you can see both tls_version and tls_cipher_info return <null> even though the underlying connection is via WSS. We have looked into it, and it seems like `get_cur_connection` in `modules/tls/tls_select.c` only checks for TLS, but not WSS. ``` struct tcp_connection *get_cur_connection(struct sip_msg *msg) { struct tcp_connection *c; if(_tls_pv_con != 0) return _tls_pv_con; if(msg->rcv.proto != PROTO_TLS) { ERR("Transport protocol is not TLS (bug in config)\n"); return 0; } c = tcpconn_get(msg->rcv.proto_reserved1, 0, 0, 0, cfg_get(tls, tls_cfg, con_lifetime)); if(c && c->type != PROTO_TLS) { ERR("Connection found but is not TLS\n"); tcpconn_put(c); return 0; } return c; } ``` We think that checking for `PROTO_WSS` might solve the issue. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4167 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4167(a)github.com>

4 5

[kamailio/kamailio] cdp: restructure locking order to prevent rare deadlock (PR #4191)
by Morten Tryfoss 06 May '25

06 May '25

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description We've been running the ims_charging module in production for quite some time, without any issues. A couple of days ago the whole instance freezed, but I was able to get a dump before the stuck processes before restarting. The traffic volume has gradually increased over time, so it's likely related to that. I then did a summary of the different types of stuck processes. Which locks they're holding, and what they're waiting for: ``` holding lock: AAASessionsLock waiting for lock: lock_get(peer_list_lock); #1 0x00007fe70eba8cde in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:108 #2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7fe6e4a5ba30) at peermanager.c:259 #3 0x00007fe70ebb64b7 in get_first_connected_route (cdp_session=0x7fe6e5cc5350, r=0x7fe6e4a5ba30, app_id=4, vendor_id=10415) at routing.c:115 #4 0x00007fe70ebb9a37 in get_routing_peer (cdp_session=0x7fe6e5cc5350, m=0x7fe6e5447ab0) at routing.c:293 #5 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5447ab0, callback_f=0x7fe707a9e323 <resume_on_initial_ccr>, callback_param=0x7fe6e5297110) at diameter_comm.c:139 #6 0x00007fe707a9d3e0 in Ro_Send_CCR (msg=0x7fe70f011100, dlg=0x7fe6e5c571f0, dir=0, reservation_units=30, incoming_trunk_id=0x7ffe50efb060, outgoing_trunk_id=0x7ffe50efb050, pani=0x7ffe50efaee0, action=0x7fe70efa4730, tindex=10484, tlabel=677172593) at ims_ro.c:1511 #7 0x00007fe707a8285d in ki_ro_ccr (msg=0x7fe70f011100, s_route_name=0x7ffe50efb080, s_direction=0x7ffe50efb070, reservation_units=30, s_incoming_trunk_id=0x7ffe50efb060, s_outgoing_trunk_id=0x7ffe50efb050) at ims_charging_mod.c:742 #8 0x00007fe707a7bf01 in w_ro_ccr (msg=0x7fe70f011100, c_route_name=0x7fe70ef8b8d0 "\220\311\371\016\347\177", c_direction=0x7fe70ef8b980 "p\240\371\016\347\177", reservation_units=30, c_incoming_trunk_id=0x7fe70ef8ba30 "p\241\371\016\347\177", c_outgoing_trunk_id=0x7fe70ef8bae0 "\360\241\371\016\347\177") at ims_charging_mod.c:507 #9 0x00000000004858d8 in do_action (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1144 #10 0x00000000004928d6 in run_actions (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1618 #11 0x0000000000492f52 in run_actions_safe (h=0x7ffe50eff1e0, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1681 #12 0x0000000000450156 in rval_get_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, i=0x7ffe50efbec8, rv=0x7fe70ef9c1d8, cache=0x0) at core/rvalue.c:973 #13 0x0000000000454d24 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efbec8, rve=0x7fe70ef9c1d0) at core/rvalue.c:1854 #14 0x0000000000454d52 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efc448, rve=0x7fe70ef9b920) at core/rvalue.c:1864 #15 0x00000000004850ce in do_action (h=0x7ffe50eff1e0, a=0x7fe70ef9b070, msg=0x7fe70f011100) at core/action.c:1097 -- holding lock: AAASessionsLock waiting for lock: lock_get(peer_list_lock); #1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:121 #2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7ffe50efab90) at peermanager.c:259 #3 0x00007fe70ebb8e89 in get_routing_peer (cdp_session=0x7fe6e5ab6910, m=0x7fe6e5435be0) at routing.c:252 #4 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5435be0, callback_f=0x7fe707a95edc <resume_on_termination_ccr>, callback_param=0x0) at diameter_comm.c:139 #5 0x00007fe707a95b02 in send_ccr_stop_with_param (ro_session=0x7fe6e5ab65e0, code=0, reason=0x7ffe50efb060) at ims_ro.c:1181 #6 0x00007fe707a72ff7 in dlg_terminated (dlg=0x7fe6e623d7a0, type=64, termcode=0, reason=0x7fe707ab72b3 "normal call clearing", _params=0x7fe707f67280 <params>) at dialog.c:249 #7 0x00007fe707a6a729 in dlg_callback_received (dlg=0x7fe6e623d7a0, type=64, _params=0x7fe707f67280 <params>) at dialog.c:25 #8 0x00007fe707d341b9 in run_dlg_callbacks (type=64, dlg=0x7fe6e623d7a0, req=0x7fe70f011100, rpl=0x0, dir=1, dlg_data=0x0) at dlg_cb.c:271 #9 0x00007fe707cf4db4 in dlg_terminated (req=0x7fe70f011100, dlg=0x7fe6e623d7a0, dir=1) at dlg_handlers.c:413 #10 0x00007fe707cfddeb in dlg_onroute (req=0x7fe70f011100, route_params=0x7ffe50efb6d0, param=0x0) at dlg_handlers.c:1097 #11 0x00007fe70ad285f6 in run_rr_callbacks (req=0x7fe70f011100, rr_param=0x7ffe50efb7c0) at rr_cb.c:96 #12 0x00007fe70ad3ae92 in after_loose (_m=0x7fe70f011100, preloaded=0) at loose.c:1021 #13 0x00007fe70ad3b5ce in loose_route_mode (_m=0x7fe70f011100, _mode=0) at loose.c:1056 #14 0x00007fe70ad3f74f in w_loose_route (msg=0x7fe70f011100, p1=0x0, p2=0x0) at rr_mod.c:273 #15 0x00000000004855ff in do_action (h=0x7ffe50efc390, a=0x7fe70efe0d40, msg=0x7fe70f011100) at core/action.c:1121 -- holding lock: lock_get(peer_list_lock); waiting for lock: lock_get(p->lock); #1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5cbd0) at ../../core/futexlock.h:121 #2 0x00007fe70ebab0ae in peer_timer (now=1742807320, ptr=0x0) at peermanager.c:286 #3 0x00007fe70ebd0f39 in timer_loop () at timer.c:116 #4 0x00007fe70ebd21b2 in timer_process (returns=0) at timer.c:216 #5 0x00007fe70eb8ccf8 in diameter_peer_start (blocking=0) at diameter_peer.c:350 #6 0x00007fe70eb7cbb2 in cdp_child_init (rank=0) at cdp_mod.c:272 -- holding lock: lock_get(p->lock) waiting for lock: AAASessionsLock #1 0x00007fe70ebf2597 in futex_get (lock=0x7fe6e4a5d490) at ../../core/futexlock.h:108 #2 0x00007fe70ebf26f1 in AAASessionsLock (hash=0) at session.c:79 #3 0x00007fe70ebf5e6e in cdp_get_session (id=...) at session.c:316 #4 0x00007fe70eba6892 in Snd_Message (p=0x7fe6e4a5c880, msg=0x7fe6e63998d0) at peerstatemachine.c:1237 #5 0x00007fe70eba003e in sm_process (p=0x7fe6e4a5c880, event=Send_Message, msg=0x7fe6e63998d0, peer_locked=0, sock=0) at peerstatemachine.c:429 #6 0x00007fe70ebcbdc6 in AAASendMessage (message=0x7fe6e63998d0, callback_f=0x7fe707a8f208 <resume_on_interim_ccr>, callback_param=0x7fe6e6190a90) at diameter_comm.c:166 #7 0x00007fe707a8edb3 in send_ccr_interim (ro_session=0x7fe6e5399160, used=60, reserve=30) at ims_ro.c:847 #8 0x00007fe707a68bd6 in ro_session_ontimeout (tl=0x7fe6e5399200) at ro_timer.c:513 #9 0x00007fe707a63078 in ro_timer_routine (ticks=114862426, attr=0x0) at ro_timer.c:279 #10 0x00000000004fd33e in compat_old_handler (ti=1837798827, tl=0x7fe6e4cf6260, data=0x7fe6e4cf6260) at core/timer.c:980 #11 0x00000000004fde7a in slow_timer_main () at core/timer.c:1103 #12 0x000000000042e4e7 in main_loop () at main.c:1911 #13 0x000000000043876c in main (argc=10, argv=0x7ffe50f001c8) at main.c:3236 ``` In `get_first_connected_route()` in `routing.c` of the cdp module there are two places `get_peer_by_fqdn()` are called. One of them has an unlock/relock of the session list before and after (and a comment about holding two locks at a time), while the other doesn't. I'm currently testing two version of this. The first by just doing the some relock for the other `get_peer_by_fqdn()`, but this PR got an approach for maybe fixing more latent issues. `sm_process()` also got some strange handling by `Rcv_Process()` after the peer lock is released, which seems to be about the same thing. My deadlock is for the `Snd_Message()` equivalent. I've now removed this queueing behaviour, and instead doing a re-lock of the peer to (hopefully) have the same locking order as the other operations. The problem with this thing is how rare it occurs. Just wanted to share my findings for others with more knowledge to the cdp module for comments, suggestions and hopefully some extra testing. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4191 -- Commit Summary -- * cdp: restructure locking order to prevent rare deadlock -- File Changes -- M src/modules/cdp/peerstatemachine.c (25) M src/modules/cdp/routing.c (6) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4191.patch https://github.com/kamailio/kamailio/pull/4191.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4191 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4191(a)github.com>

4 13

[kamailio/kamailio] Topoh module does not hide 180 Ringing and 200 Ok to the caller UE in IMS config (Issue #4164)
by Farzaneh Soltanzadeh 05 May '25

05 May '25

Fr-Soltanzadeh created an issue (kamailio/kamailio#4164) ### Description In a IMS lab using Kamailio PCSCF, ICSCF and SCSCF default configs, I have used TOPOH module in PCSCF for topology hiding. Topoh config is as follows: ``` modparam("topoh", "mask_key", "my-key") modparam("topoh", "mask_ip", "127.0.0.2") modparam("topoh", "sanity_checks", 1) ``` As shown in attached traffic, SCSCF IP is not hided in 180 ringing and 200ok messages to the caller. In invite, ack and bye messages hiding is performed well. [topoh.zip](https://github.com/user-attachments/files/19086420/topoh.zip) [topoh.zip](https://github.com/user-attachments/files/19086428/topoh.zip) [topoh.zip](https://github.com/user-attachments/files/19086431/topoh.zip)  ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` (paste your output here) ``` * **Operating System**:  ``` (paste your output here) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4164 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4164(a)github.com>

3 4

[kamailio/kamailio] secfilter‌: support remove rule in Whitelist and Blacklist (PR #4089)
by AsedMorteza 30 Apr '25

30 Apr '25

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description ##### **Summary** This update introduces new functionality to the `secfilter` module, enabling the removal of entries from both the Blacklist and Whitelist. It also includes automatic detection and removal of duplicate values from these lists. ##### **Details** * Users can now remove specific entries from the Blacklist or Whitelist based on type (e.g., IP, domain, user) and a given value. * Supports removal of single or multiple matching entries in one operation. ##### **Benefits** - Improves the usability and flexibility of the `secfilter` module by allowing fine-grained control over list management. - Ensures that the Blacklist and Whitelist are kept clean and free from redundant entries. - Enhances performance by reducing unnecessary duplication in the lists. ##### Testing This feature was tested using `kmcmd` commands in various scenarios: - Removing the **first element** in the list. - Removing an element from the **middle** of the list. - Removing the **last element** in the list. - Removing **all matching elements** in the list. In all cases, the commands worked correctly, and the lists were updated and cleaned as expected. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4089 -- Commit Summary -- * secfilter‌: support remove rule in Whitelist and Blacklist -- File Changes -- M src/modules/secfilter/secfilter.c (8) M src/modules/secfilter/secfilter.h (3) M src/modules/secfilter/secfilter_db.c (106) M src/modules/secfilter/secfilter_rpc.c (95) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4089.patch https://github.com/kamailio/kamailio/pull/4089.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4089 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4089(a)github.com>

6 11

[kamailio/kamailio] Allow single quotes in From name (Issue #3984)
by ThomasSevestre 28 Apr '25

28 Apr '25

### Description `secf_check_sqli_all();` block requests when a single quote is present in From name : ``` From: "O'Reilly" <sip:100@example.net>;tag=abcd ``` Since single quotes are frequent in names. It makes it difficult to use this function. ### Possible Solutions A solution would be to skip single quote check in From name. I'll write the PR if you are OK with this solution -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3984 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3984(a)github.com>

5 10

[kamailio/kamailio] Update PCSCF IMS example config (PR #4177)
by Tobias Funke 25 Apr '25

25 Apr '25

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  The name of the `location` database for the `pcscf` was changed to `pcscf_location` here: https://github.com/kamailio/kamailio/commit/360bccbca1fe7515384065651034374…. So the example IMS pcscf config is not working right now. This simple PR provides the fix. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4177 -- Commit Summary -- * Update example pcscf ims config -- File Changes -- M misc/examples/ims/pcscf/kamailio.cfg (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4177.patch https://github.com/kamailio/kamailio/pull/4177.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4177 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4177(a)github.com>

3 3

[kamailio/kamailio] Why can't set_body_multipart and append_body_part* functions be used from ONREPLY_ROUTE? (Issue #4149)
by rodrigodc 22 Apr '25

22 Apr '25

rodrigodc created an issue (kamailio/kamailio#4149) Hello, Is there a strong reason why the following functions from [textops](https://www.kamailio.org/docs/modules/5.4.x/modules/textops.html) can't be used from `ONREPLY_ROUTE`? - [set_body_multipart](https://www.kamailio.org/docs/modules/5.4.x/modules/tex… - [append_body_part_hex](https://www.kamailio.org/docs/modules/5.4.x/modules/t… I need to add ISUP to outgoing `SIP/18x` replies which already have an SDP body and would like to use those functions for that. However, they cannot be used from `ONREPLY_ROUTE`, just as they can from `REQUEST_ROUTE` (which I use to add ISUP to `SIP/INVITE`). So I am considering sending a pull request allowing them to be used from `ONREPLY_ROUTE`, but first I would like to know if it makes sense. Thank you. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4149 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4149(a)github.com>

4 4

[kamailio/kamailio] xmpp module causes crash in component mode with prosody (Issue #4154)
by Jan Rozhon 22 Apr '25

22 Apr '25

jrozhon created an issue (kamailio/kamailio#4154)  ### Description I have Kamailio configured to act as a gateway between SIP and XMPP in my lab setup. I only have module configured, no routing is implemented yet. When handshake with XMPP server (Prosody) occurs, Kamailio crashes. ### Troubleshooting I cannot use newer version of kamailio as it crashes because of presence module. Older versions up to 5.5.7 behave the same. If i get backtrace right crash is caused by a problem with parsing the incoming xml, but it seems fine to me. #### Reproduction Have prosody xmpp server configured to accept component connection from kamailio. In kamailio have xmpp.so module loaded with following parameters set: modparam("xmpp", "backend", "component") modparam("xmpp", "gateway_domain", "kamailio-dns") modparam("xmpp", "xmpp_domain", "xmpp-dns") modparam("xmpp", "xmpp_host", "xmpp-dns") modparam("xmpp", "xmpp_port", 5347) modparam("xmpp", "xmpp_password", "shared-password") #### Debugging Data ``` (gdb) bt full #0 _xode_put_expatattribs (owner=0x13c5480, atts=0x13be6d0) at xstream.c:35 i = 10 #1 0x00007f77df410211 in _xode_stream_startElement (xs=0x13c07f0, name=0x13c0170 "stream:stream", atts=0x13be6d0) at xstream.c:56 p = 0x13be110 #2 0x00007f77df3c2934 in doContent () from /lib64/libexpat.so.1 No symbol table info available. #3 0x00007f77df3c0fde in doProlog () from /lib64/libexpat.so.1 No symbol table info available. #4 0x00007f77df3c1eac in prologProcessor () from /lib64/libexpat.so.1 No symbol table info available. #5 0x00007f77df3b958f in callProcessor () from /lib64/libexpat.so.1 No symbol table info available. #6 0x00007f77df3c60a7 in XML_ParseBuffer () from /lib64/libexpat.so.1 No symbol table info available. #7 0x00007f77df410594 in xode_stream_eat (xs=0x13c07f0, buff=0x7f77df4185e0 <buf> "<?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:component:accept' id='09b989ba-0ba4-4b58-ad8e-53b07fe2f13a' from='sip.xmpp.osk3.lab' xml:lang='en'>", len=197) at xstream.c:176 err = 0x4000000 <error: Cannot access memory at address 0x4000000> xerr = 0x7f77e4d06ed0 <syslog> maxerr = "maximum node size reached" deeperr = "maximum node depth reached" #8 0x00007f77df404955 in xmpp_component_child_process (data_pipe=9) at xmpp_component.c:237 buf = 0x7f77df4185e0 <buf> "<?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:component:accept' id='09b989ba-0ba4-4b58-ad8e-53b07fe2f13a' from='sip.xmpp.osk3.lab' xml:lang='en'>" fd = 5 maxfd = 9 rv = 1 fdset = {__fds_bits = {32, 0 <repeats 15 times>}} pool = 0x13bae50 stream = 0x13c07f0 priv = {fd = 5, running = 1} cmd = 0xa09250 <main_state+16> __func__ = "xmpp_component_child_process" #9 0x00007f77df3fafef in xmpp_process (rank=1) at xmpp.c:280 __func__ = "xmpp_process" #10 0x00007f77df3fac4b in child_init (rank=0) at xmpp.c:263 pid = 0 #11 0x0000000000650a0c in init_mod_child (m=0x7f77e44b8f90, rank=0) at core/sr_module.c:911 ret = 0 __func__ = "init_mod_child" #12 0x0000000000650656 in init_mod_child (m=0x7f77e44b93e0, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #13 0x0000000000650656 in init_mod_child (m=0x7f77e44b9b78, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #14 0x0000000000650656 in init_mod_child (m=0x7f77e44ba000, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #15 0x0000000000650656 in init_mod_child (m=0x7f77e44bafa0, rank=0) at core/sr_module.c:903 ret = 32 __func__ = "init_mod_child" #16 0x0000000000650656 in init_mod_child (m=0x7f77e44bb498, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #17 0x0000000000650656 in init_mod_child (m=0x7f77e44bbe58, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #18 0x0000000000650656 in init_mod_child (m=0x7f77e44bc370, rank=0) at core/sr_module.c:903 ret = 1 __func__ = "init_mod_child" #19 0x0000000000651207 in init_child (rank=0) at core/sr_module.c:990 ret = -464031792 type = 0x884ffb "PROC_MAIN" __func__ = "init_child" #20 0x000000000042fb48 in main_loop () at main.c:1929 i = 8 pid = 450007 si = 0x0 si_desc = "udp receiver child=7 sock=kamailio.osk3.lab:5060\000K\207\362\377\177\000\000\000\000\000\000\000\000\000\000PQ\207\362\377\177\000\000\263\266\204\000\000\000\000\0000\277K\344w\177\000\000\320n\320\344w\177\000\000\000\000\000\004\000\000\000\000jo\320\344w\177\000\0000\000\000\0000\000\000\000\bM\207\362\377\177\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #21 0x0000000000439d03 in main (argc=11, argv=0x7ffff2875268) at main.c:3213 cfg_stream = 0x130b380 c = -1 r = 0 tmp = 0x7ffff2876ea2 "" tmp_len = 0 port = 0 proto = 0 ahost = 0x0 aport = 0 options = 0x8373a8 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 863415900 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x40 p = 0x1000000 <error: Cannot access memory at address 0x1000000> st = {st_dev = 23, st_ino = 1015, st_nlink = 2, st_mode = 16832, st_uid = 977, st_gid = 976, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1739449861, tv_nsec = 919999685}, st_mtim = {tv_sec = 1740224132, tv_nsec = 607723775}, st_ctim = {tv_sec = 1740224132, tv_nsec = 607723775}, __glibc_reserved = {0, 0, 0}} tbuf = "9M\t\345w\177\000\000\210\n\006\345w\177\000\000\340N\207\362\377\177\000\000\006\000\000\000\000\000\000\000\b\367\005\345w\177\000\000\006\000\000\000\020\000\000\0000Z\t\345w\177\000\000\325\331\006\345w\177\000\000\000\000\000\000\000\000\000\000\240\354\006\345w\177\000\000\370\377\300\344w\177\000\000\000:\005\345w\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\260N\207\362\377\177\000\000\240\n\006\345w\177\000\000\240\n\006\345w\177\000\000\000\000\000\000\000\000\000\000`H\005\345w\177\000\000\260N\207\362\377\177\000\000\200e\t\345w\177\000\000\000\360\005\345w\177\000\000\342\373\005\345w\177\000\000v\244\006\345w\177\000\000\334#\300\344w\177\000\000"... option_index = 12 long_options = {{name = 0x839a46 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x8344f4 "version", has_arg = 0, flag = 0x0, val = 118}, { name = 0x839a4b "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x839a51 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x839a57 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x839a60 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x839a6a "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x839a74 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x839a7f "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x839a88 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x839a93 "debug", has_arg = 1, flag = 0x0, val = 1032}, { name = 0x839a99 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x839aa3 "atexit", has_arg = 1, flag = 0x0, val = 1034}, { name = 0x839aaa "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" ``` ``` (gdb) info locals i = 10 ``` ``` (gdb) list 30 static void _xode_put_expatattribs(xode owner, const char **atts) 31 { 32 int i = 0; 33 if(atts == NULL) 34 return; 35 while(*(atts[i]) != '\0') { 36 xode_put_attrib(owner, atts[i], atts[i + 1]); 37 i += 2; 38 } 39 } ``` #### Log Messages  ``` Feb 22 11:39:10 kamailio /usr/sbin/kamailio[445061]: INFO: tls [tls_domain.c:418]: ksr_tls_fill_missing(): TLSc<default>: verify_client=0 Feb 22 11:39:10 kamailio /usr/sbin/kamailio[445061]: INFO: tls [tls_domain.c:781]: set_verification(): TLSc<default>: Server MAY present invalid certificate Feb 22 11:39:10 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 28 Feb 22 11:39:10 kamailio /usr/sbin/kamailio[445066]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 3 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445107]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 15 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445065]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 2 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445088]: INFO: ctl [io_listener.c:214]: io_listen_loop(): using epoll_lt io watch method (config) Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445070]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 4 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445064]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 1 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445074]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 7 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445076]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 8 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445096]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 9 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445085]: INFO: jsonrpcs [jsonrpcs_sock.c:471]: jsonrpc_dgram_process(): a new child 0/445085 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445072]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 6 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445108]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 16 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445061]: ALERT: <core> [main.c:792]: handle_sigs(): child process 445090 exited by a signal 11 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445061]: ALERT: <core> [main.c:796]: handle_sigs(): core was generated Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445061]: INFO: <core> [main.c:819]: handle_sigs(): terminating due to SIGCHLD Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445071]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 5 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445066]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445065]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445076]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445064]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445083]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445089]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445081]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 25 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 17 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 15 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 8 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445088]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 26 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445077]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received ``` #### SIP Traffic  ``` no sip traffic, just simple xml exchanged ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.5 (x86_64/linux) 58499a flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 58499a compiled on 00:00:00 Sep 13 2022 with gcc 11.4.1 ``` * **Operating System**:  ``` RHEL 9 Linux kamailio 5.14.0-503.15.1.el9_5.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Nov 14 15:45:31 EST 2024 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4154 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4154(a)github.com>

3 4

[kamailio/kamailio] Error when sending NOTIFYs in the presence of disconnected websocket watchers (Issue #4118)
by Flavio Grossi 20 Apr '25

20 Apr '25

### Description if multiple sip websocket clients are subscribed to some UA and one of the watchers suddenly disappears (e.g. the web page is reloaded), then no NOTIFY is ever sent after issuing a `pres_refresh_watchers()`. The following error is logged: ``` WARNING: <core> [core/msg_translator.c:3007]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found ERROR: tm [t_msgbuilder.c:1423]: assemble_via(): via building failed ERROR: tm [t_msgbuilder.c:1614]: build_uac_req(): error while assembling Via ERROR: tm [uac.c:552]: t_uac_prepare(): Error while building message ERROR: presence [notify.c:1734]: send_notify_request(): in function tm t_request_within() ERROR: presence [notify.c:1829]: notify(): sending Notify not successful ERROR: presence [notify.c:1585]: query_db_notify(): Could not send notify for [event]=dialog ERROR: presence [presence.c:739]: pres_refresh_watchers(): sending Notify requests ``` ### Troubleshooting when the client disconnects, the old watcher is not removed from the active_watchers table, instead it coexists with the new one, but the stale connection causes the error above when sending the notify, and then all of the following watchers (even the valid ones) are skipped too. Looking at the logs, the valid watchers are not notified because the while loop [here](https://github.com/kamailio/kamailio/blob/b96bc11a54f11ec688429c057bf… is skipped because of the `goto done` line in case of errors, which happens because it fails to build the via header for the message relevant to the stale websocket connection. By breaking out of the while loop, the remaining subs in the `subs_array` are skipped. #### Reproduction Just subscribe to a sip client using a websocket-based phone, then abruptly disconnect it (e.g. by reloading the web page) and then issue a `pres_refresh_watchers()` to make it generate a notify. #### Debugging Data #### Log Messages #### SIP Traffic ### Possible Solutions I tried to use the "websocket:closed" route to purge stale connections, but to my knowledge there are no APIs to clean invalid watchers. A possible solution could be to automatically remove the watchers on disconnection and maybe skip the invalid ones without exiting from the refresh loop ### Additional Information kamailio 5.8.2 * **Operating System**: Rocky Linux 9 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4118 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4118(a)github.com>

4 5

[kamailio/kamailio] fr_timer documentation mistake (Issue #3939)
by Dmitry Sinina 20 Apr '25

20 Apr '25

Documentation https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.p.fr_timer says: >Timer which hits if no **final reply** for a request or ACK for a negative INVITE reply arrives (in milliseconds). Looks like it is not correct description - fr_timer value works until 1xx(not **final**) response received and then timer restarted with fr_inv_timer value there: https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_reply.c#L… Looks like old doc from sip router https://sip-router.org/wiki/ref_manual/timers explains it correctly: > fr_timer This timer is used for all SIP requests. It hits if no reply for an INVITE request or other request has been received (F in milliseconds). If a provisional reply is received for an INVITE (any 1xx), then the fr_inv_timer will be used instead. And if no replies (at all) for an INVITE are received before `fr_timer` hits, the transaction is terminated with a 408 in failure route. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3939 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3939(a)github.com>

3 10

[kamailio/kamailio] path: add_path_received() appends transport=ws instead of transport=wss (Issue #4168)
by Christian Berger 19 Apr '25

19 Apr '25

ChristianBergerSipgate created an issue (kamailio/kamailio#4168) We think we have found a potential bug in the path module. When we call `add_path_received()` we get the following for WSS connections: `Path: <sip:217.10.77.242;lr;received=sip:217.10.69.93:42612%3Btransport%3Dws>` We think there should be a `transport%3Dwss` appended instead of ws. We have looked a bit into the code and think that this is caused by the following definition: ``` in modules/path/path.c const static char *proto_strings[] = { [PROTO_TCP] = "%3Btransport%3Dtcp", [PROTO_TLS] = "%3Btransport%3Dtls", [PROTO_SCTP] = "%3Btransport%3Dsctp", [PROTO_WS] = "%3Btransport%3Dws", [PROTO_WSS] = "%3Btransport%3Dws", }; ``` We think that on the last line, it should read ` [PROTO_WSS] = "%3Btransport%3Dwss",` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4168 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4168(a)github.com>

5 5

[kamailio/kamailio] clean_sa(): Error sending delete SAs command via netlink socket: Invalid argument (#2707)
by openspring 16 Apr '25

16 Apr '25

### Description  #### Log Messages  ``` 0(117561) DEBUG: <core> [core/route_struct.c:128]: mk_action(): ACTION type5, i/count 0/1: type 1(1)/ data 0x7f8583620ef0 0(117561) DEBUG: <core> [core/route_struct.c:128]: mk_action(): ACTION type16, i/count 0/3: type 22(16)/ data 0x7f8583621ad8 0(117561) DEBUG: <core> [core/route_struct.c:128]: mk_action(): ACTION type16, i/count 1/3: type 8(8)/ data 0x7f8583620fd8 0(117561) DEBUG: <core> [core/route_struct.c:128]: mk_action(): ACTION type16, i/count 2/3: type 0(0)/ data 0x7f8500000000 0(117561) DEBUG: <core> [core/route.c:129]: route_add(): mapping routing block (0xb914c0)[MT_indialog_reply] to 6 ERROR: bad config file (1 errors) 0(117561) DEBUG: <core> [core/sr_module.c:765]: destroy_modules(): starting modules destroy phase 0(117561) DEBUG: debugger [debugger_api.c:1267]: dbg_destroy_mod_levels(): Destroyed _dbg_mod_table, size 32 0(117561) ERROR: ims_ipsec_pcscf [ipsec.c:567]: clean_sa(): Error sending delete SAs command via netlink socket: Invalid argument 0(117561) WARNING: ims_ipsec_pcscf [cmd.c:998]: ipsec_cleanall(): Error cleaning IPSec Security associations during startup. 0(117561) ERROR: ims_ipsec_pcscf [ipsec.c:609]: clean_policy(): Error sending delete policies command via netlink socket: Invalid argument 0(117561) WARNING: ims_ipsec_pcscf [cmd.c:1002]: ipsec_cleanall(): Error cleaning IPSec Policies during startup. 0(117561) ERROR: ims_ipsec_pcscf [ims_ipsec_pcscf_mod.c:309]: mod_destroy(): Error destroying spi generator 0(117561) ERROR: ims_ipsec_pcscf [ims_ipsec_pcscf_mod.c:313]: mod_destroy(): Error destroying port generator 0(117561) DEBUG: tm [t_funcs.c:84]: tm_shutdown(): start 0(117561) DEBUG: tm [t_funcs.c:87]: tm_shutdown(): emptying hash table 0(117561) DEBUG: tm [t_funcs.c:89]: tm_shutdown(): removing semaphores 0(117561) DEBUG: tm [t_funcs.c:91]: tm_shutdown(): destroying tmcb lists 0(117561) DEBUG: tm [t_funcs.c:94]: tm_shutdown(): done 0(117561) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized 0(117561) DEBUG: <core> [core/mem/shm.c:289]: shm_destroy_manager(): destroying memory manager: q_malloc 0(117561) DEBUG: <core> [core/mem/q_malloc.c:1185]: qm_shm_lock_destroy(): destroying the shared memory lock 0(117561) DEBUG: <core> [core/mem/pkg.c:98]: pkg_destroy_manager(): destroying memory manager: q_malloc ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.4.4 (x86_64/linux) 8d6c2b flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 8d6c2b compiled on 22:26:30 Apr 11 2021 with gcc 4.8.5 ``` * **Operating System**:  ``` NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2707

5 5

[kamailio/kamailio] DMQ improvements related to node status (PR #4182)
by Stefan Mititelu 11 Apr '25

11 Apr '25

#### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Some improvements related to DMQ node status: 1. Allow other modules that use DMQ to detect NOT_ACTIVE nodes via default response callback. Note that only internal dmq ping mechanism can set them back to DMQ_NODE_ACTIVE status. 2. Simplify node status and merge DMQ_NODE_PENDING + DMQ_NODE_TIMEOUT into DMQ_NODE_NOT_ACTIVE since those specific states were never used to be compared against. 3. Add new mod parameters which will control after how many fails the node should be moved to DMQ_NODE_NOT_ACTIVE state. Under testing currently. Will update if any bugs found. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4182 -- Commit Summary -- * dmq: add default response callback * dmq: simplify node status * dmq: add two new modparams -- File Changes -- M src/modules/dialog/dlg_dmq.c (16) M src/modules/dialog/dlg_dmq.h (3) M src/modules/dmq/dmq.c (4) M src/modules/dmq/dmq.h (2) M src/modules/dmq/dmq_funcs.c (6) M src/modules/dmq/dmqnode.c (70) M src/modules/dmq/dmqnode.h (9) M src/modules/dmq/doc/dmq_admin.xml (64) M src/modules/dmq/notification_peer.c (80) M src/modules/dmq/notification_peer.h (3) M src/modules/dmq_usrloc/usrloc_sync.c (12) M src/modules/dmq_usrloc/usrloc_sync.h (2) M src/modules/htable/ht_dmq.c (15) M src/modules/htable/ht_dmq.h (3) M src/modules/presence/presence_dmq.c (16) M src/modules/presence/presence_dmq.h (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4182.patch https://github.com/kamailio/kamailio/pull/4182.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4182 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4182(a)github.com>

4 8

[kamailio/kamailio] dispatcher: added ping socket configuration (PR #4186)
by Michael Furmur 11 Apr '25

11 Apr '25

- add dispatcher modparam `ds_ping_socket` - add gateway param `ping_socket`   #### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description could be useful for HA use cases where multiple kamailio nodes share a common Virtual IP (e.g.: managed by the VRRP). we need to route requests using Virtual IP socket configured with `ds_default_sockname`/`socket` and to perform destinations probing using self-IP socket configured with `ds_ping_socket`/`ping_socket`. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4186 -- Commit Summary -- * dispatcher: added ping socket configuration -- File Changes -- M src/modules/dispatcher/dispatch.c (32) M src/modules/dispatcher/dispatch.h (2) M src/modules/dispatcher/dispatcher.c (25) M src/modules/dispatcher/doc/dispatcher_admin.xml (20) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4186.patch https://github.com/kamailio/kamailio/pull/4186.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4186 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4186(a)github.com>

3 5

[kamailio/kamailio] Ims registrar scscf regpv fix (PR #4166)
by Lyubomir Yatanski 11 Apr '25

11 Apr '25

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4166 -- Commit Summary -- * ims_registrar_scscf: fix reg_fetch_contacts call * ims_registrar_scscf: fix documentation -- File Changes -- M src/modules/ims_registrar_scscf/doc/ims_registrar_scscf_admin.xml (6) M src/modules/ims_registrar_scscf/regpv.c (25) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4166.patch https://github.com/kamailio/kamailio/pull/4166.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4166 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4166(a)github.com>

3 18

[kamailio/kamailio] cmake_format all files (PR #4192)
by Xenofon Karamanos 08 Apr '25

08 Apr '25

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4192 -- Commit Summary -- * cmake: Alter some of cmake-format options * cmake: Fix formatting according to cmake-format config file. -- File Changes -- M CMakeLists.txt (18) M cmake/BuildType.cmake (8) M cmake/cmake-format.py (4) M cmake/compiler-specific.cmake (24) M cmake/defs.cmake (29) M cmake/groups.cmake (45) M cmake/modules-docs.cmake (94) M cmake/modules/FindBerkeleyDB.cmake (60) M cmake/modules/FindErlang.cmake (52) M cmake/modules/FindLdap.cmake (32) M cmake/modules/FindLibev.cmake (4) M cmake/modules/FindLibfreeradiusClient.cmake (21) M cmake/modules/FindMariaDBClient.cmake (3) M cmake/modules/FindMySQL.cmake (114) M cmake/modules/FindNETSNMP.cmake (15) M cmake/modules/FindOracle.cmake (11) M cmake/modules/FindRadius.cmake (6) M cmake/os-specific/darwin.cmake (38) M cmake/os-specific/dragonfly.cmake (9) M cmake/os-specific/freebsd.cmake (3) M cmake/os-specific/linux.cmake (9) M src/CMakeLists.txt (44) M src/core/CMakeLists.txt (16) M src/modules/CMakeLists.txt (55) M src/modules/app_perl/CMakeLists.txt (17) M src/modules/auth_radius/CMakeLists.txt (7) M src/modules/db2_ldap/CMakeLists.txt (3) M src/modules/db_berkeley/CMakeLists.txt (3) M src/modules/dnssec/CMakeLists.txt (5) M src/modules/kazoo/CMakeLists.txt (3) M src/modules/nghttp2/CMakeLists.txt (5) M src/modules/nsq/CMakeLists.txt (5) M src/modules/phonenum/CMakeLists.txt (16) M src/modules/ruxc/CMakeLists.txt (3) M src/modules/sctp/CMakeLists.txt (6) M src/modules/secsipid_proc/CMakeLists.txt (3) M src/modules/snmpstats/CMakeLists.txt (3) M src/modules/tls/CMakeLists.txt (29) M src/modules/tlsa/CMakeLists.txt (11) M src/modules/xhttp_pi/CMakeLists.txt (7) M utils/CMakeLists.txt (6) M utils/db_berkeley/CMakeLists.txt (3) M utils/kamcmd/CMakeLists.txt (26) M utils/kamctl/CMakeLists.txt (161) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4192.patch https://github.com/kamailio/kamailio/pull/4192.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4192 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4192(a)github.com>

3 18

[kamailio/kamailio] Problems with ims_ipsec_pcscf and closed tcp connections (Issue #4138)
by Atanas Bakalov 05 Apr '25

05 Apr '25

### Description Let's assume we have a MO call from UE to P-CSCF that's over ipsec. Let's assume the picked ports are like UE(6101) -> P-CSCF(6100) We have also set tcp_connection_lifetime to be 20 sec. 20 sec after INVITE connection is RST from Kamailio as expected. Then ( > 20sec later) an INVITE response comes from B side, and must be delivered to the UE. Kamailio opens a new connection and tries to establish a connection from 5060 (standard port)->6101 instead of 6100(P-CSCF) -> 6101(UE). IPSEC associations are not engaged and UE does not handle the request properly. ### Troubleshooting #### Reproduction #### Debugging Data #### Log Messages #### SIP Traffic ### Possible Solutions The IPSEC module should re-open the tcp connection if it sees it's been dropped as core module has no awareness of IPSEC. * **Operating System**: All -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4138 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4138(a)github.com>

3 3

[kamailio/kamailio] pua_json : add support for as-feature-event (PR #4195)
by ThomasSevestre 04 Apr '25

04 Apr '25

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description This PR allow usage of the new presence_dfks module with pua_json You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4195 -- Commit Summary -- * pua_json: add support for as-feature-event -- File Changes -- M src/modules/pua_json/defs.h (16) M src/modules/pua_json/pua_json_publish.c (55) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4195.patch https://github.com/kamailio/kamailio/pull/4195.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4195 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4195(a)github.com>

2 9

[kamailio/kamailio] github: [skip ci]: bump awalsh128/cache-apt-pkgs-action from 1.4.3 to 1.5.0 (PR #4196)
by dependabot[bot] 31 Mar '25

31 Mar '25

Bumps [awalsh128/cache-apt-pkgs-action](https://github.com/awalsh128/cache-apt-pkg… from 1.4.3 to 1.5.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/awalsh128/cache-apt-pkgs-action/releases&quot… releases</a>.</em></p> <blockquote> <h2>v1.5.0</h2> <h2>What's Changed</h2> <ul> <li>fix: remove timestamps from loglines by <a href="https://github.com/F2210"><code>@F2210</code&g… in <a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/pull… <li>Update actions/checkout versions in README by <a href="https://github.com/ulgens"><code>@ulgens</code… in <a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/pull… <li>Avoid using xargs when creating package tarballs by <a href="https://github.com/bscott-zebra"><code>@bscott-ze… in <a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/pull… <li>Add support for virtual packages and break out APT logic into common by <a href="https://github.com/awalsh128"><code>@awalsh128&lt… in <a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/pull… </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/F2210"><code>@F2210</code&g… made their first contribution in <a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/pull… <li><a href="https://github.com/ulgens"><code>@ulgens</code… made their first contribution in <a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/pull… <li><a href="https://github.com/bscott-zebra"><code>@bscott-ze… made their first contribution in <a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/pull… </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/awalsh128/cache-apt-pkgs-action/compare/v1.4.… </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/awalsh128/cache-apt-pkgs-action/commit/7ca5f4… Fix exec error.</li> <li><a href="https://github.com/awalsh128/cache-apt-pkgs-action/commit/2330cb… Add support for virtual packages and break out APT logic into common library....</li> <li><a href="https://github.com/awalsh128/cache-apt-pkgs-action/commit/128de2… Add support for virtual packages and break out APT logic into common library....</li> <li><a href="https://github.com/awalsh128/cache-apt-pkgs-action/commit/13d222… Avoid using xargs when creating package tarballs (<a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/issu… <li><a href="https://github.com/awalsh128/cache-apt-pkgs-action/commit/d1a184… Update actions/checkout versions in README (<a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/issu… <li><a href="https://github.com/awalsh128/cache-apt-pkgs-action/commit/dfe9c8… fix: remove timestamps from loglines (<a href="https://redirect.github.com/awalsh128/cache-apt-pkgs-action/issu… <li>See full diff in <a href="https://github.com/awalsh128/cache-apt-pkgs-action/compare/v1.4.… view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?d… Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4196 -- Commit Summary -- * github: [skip ci]: bump awalsh128/cache-apt-pkgs-action -- File Changes -- M .github/workflows/pull_request.yml (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4196.patch https://github.com/kamailio/kamailio/pull/4196.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4196 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4196(a)github.com>

2 1

git:master:f05e6e11: github: [skip ci]: bump awalsh128/cache-apt-pkgs-action
by Victor Seva 31 Mar '25

31 Mar '25

Module: kamailio Branch: master Commit: f05e6e11dcb13f971465db691b1b947bbdc13c34 URL: https://github.com/kamailio/kamailio/commit/f05e6e11dcb13f971465db691b1b947… Author: dependabot[bot] <49699333+dependabot[bot](a)users.noreply.github.com> Committer: Victor Seva <linuxmaniac(a)torreviejawireless.org> Date: 2025-04-01T00:45:47+02:00 github: [skip ci]: bump awalsh128/cache-apt-pkgs-action Bumps [awalsh128/cache-apt-pkgs-action](https://github.com/awalsh128/cache-apt-pkg… from 1.4.3 to 1.5.0. - [Release notes](https://github.com/awalsh128/cache-apt-pkgs-action/releases) - [Commits](https://github.com/awalsh128/cache-apt-pkgs-action/compare/v1.4.3.… --- updated-dependencies: - dependency-name: awalsh128/cache-apt-pkgs-action dependency-version: 1.5.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support(a)github.com> --- Modified: .github/workflows/pull_request.yml --- Diff: https://github.com/kamailio/kamailio/commit/f05e6e11dcb13f971465db691b1b947… Patch: https://github.com/kamailio/kamailio/commit/f05e6e11dcb13f971465db691b1b947… --- diff --git a/.github/workflows/pull_request.yml b/.github/workflows/pull_request.yml index 5be003dcea8..96f3ac6b864 100644 --- a/.github/workflows/pull_request.yml +++ b/.github/workflows/pull_request.yml @@ -27,7 +27,7 @@ jobs: uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} - - uses: awalsh128/cache-apt-pkgs-action(a)v1.4.3 + - uses: awalsh128/cache-apt-pkgs-action(a)v1.5.0 with: packages: cmake-format - name: Run scripts/check-cmake-format.sh

1 0

master force push
by Sergey Safarov 29 Mar '25

29 Mar '25

Hello. I just pushed by mistake own branch to the master. @Daniel-Constantin Mierla <miconda(a)gmail.com> @Victor Seva <linuxmaniac(a)torreviejawireless.org> could you force push correct commit 95d0c1fc38da00dc6bbda19dba1ac4b20535abf5 Sergey

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2025