sr-dev November 2025

sr-dev@lists.kamailio.org

13 participants
229 discussions

[kamailio/kamailio] tls_wolfssl: assertion (Issue #4391)
by Dennis 09 Dec '25

09 Dec '25

Den4t created an issue (kamailio/kamailio#4391) Hi ! Kamailio v.5.8.6, used as webrtc registrar/GW, wolfssl v.5.7.4, high call load, OS: Ubuntu 22 Periodically kamailio dumps core with assertion: ``` Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) backtrace #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140585212159808, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007fdc8ba5f476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007fdc8ba457f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007fdc8ba4571b in __assert_fail_base (fmt=0x7fdc8bbfa130 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fdc7a6b299f "nw == bytes_read", file=0x7fdc7a6b089a "tls_server.c", line=1056, function=<optimized out>) at ./assert/assert.c:94 #6 0x00007fdc8ba56e96 in __GI___assert_fail (assertion=0x7fdc7a6b299f "nw == bytes_read", file=0x7fdc7a6b089a "tls_server.c", line=1056, function=0x7fdc7a6b5068 "tls_h_read_f") at ./assert/assert.c:103 #7 0x00007fdc7a48cd89 in tls_h_read_f () from /usr/lib64/kamailio/modules/tls_wolfssl.so #8 0x00005622baa30e8e in ?? () #9 0x00005622baa3273b in tcp_read_req () #10 0x00005622baa3c7c2 in ?? () #11 0x00005622babf61d6 in ?? () #12 0x00005622baa42b87 in tcp_receive_loop () #13 0x00005622baa24188 in tcp_init_children () #14 0x00005622ba7b1b33 in main_loop () #15 0x00005622ba7a5888 in main () ``` I couldn't reproduce this issue in a lab, but I think that possibly the issue depends on TLS traffic burst behavior. We have some buggy webrtc clients, which floods using MESSAGE requests with high CPS periodically. I assume that might be this traffic somehow fills the BIO buffers in wolfssl. As result wolfSSL_BIO_write function returns with error. I have no time to debug deeply, so I made a quick fix here: https://github.com/Den4t/kamailio/commit/20579f02354356dedb5f5ac1f9bff65314… I see following logs after the fix has been applied: ``` 2025-09-02T09:24:04.393019+03:00 iptel /usr/sbin/kamailio[892554]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=7115, npos=-1) 2025-09-02T10:44:21.556481+03:00 iptel /usr/sbin/kamailio[892559]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=6201, npos=-1) 2025-09-02T10:58:31.563456+03:00 iptel /usr/sbin/kamailio[892558]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=7587, npos=-1) ``` But service is alive. It is better to lose one session than the whole service. In any case this is just a crutch for quick problem fix, so it would be nice if tls_wolfssl module's author took a deeper look at the problem. P.S. I assume that module's logic should check BIO flags after the call to wolfSSL_BIO_write, f.e. this function can return error with bio flag WOLFSSL_BIO_FLAG_RETRY set. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4391 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4391(a)github.com>

3 3

[kamailio/kamailio] dispatcher: selected hash more accessible in failover (PR #4500)
by Tyler Moore 08 Dec '25

08 Dec '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 moves the selected hash up the call stack so it is more accessible in failover, and by the higher order functions. It is a little hard to see the benefit until I get the next few patchsets submitted, but I will link them below this description. The biggest benefit for other dispatcher algorithm developers is that the hash selected is now available on failover and can be used to lookup attrs (or any other info) needed for implementing more complex failure scenarios. These are the examples I am working on that depend on this change (as an example of how it can be used): 1. [rpc commands][1] - an example where a user can test selection algorithms with a dataset, without stepping into gdb 2. [failover selection][2] - an example algorithm that makes use of this change for re-balancing the distribution on failover (in mode 1) [1]: https://github.com/devopsec/kamailio/tree/dispatcher_rpc_updates [2]: https://github.com/devopsec/kamailio/tree/dispatcher_alg_updates You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4500 -- Commit Summary -- * dispatcher: make hash result more accessible -- File Changes -- M src/modules/dispatcher/dispatch.c (201) M src/modules/dispatcher/dispatch.h (16) M src/modules/dispatcher/dispatcher.c (148) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4500.patch https://github.com/kamailio/kamailio/pull/4500.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4500 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4500(a)github.com>

2 8

[kamailio/kamailio] Outbound (PR #4449)
by sergey-safarov 08 Dec '25

08 Dec '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 #4315 #### Description Added a function to check the flow token. Useful to make sure the client TCP connection is alive. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4449 -- Commit Summary -- * outbound: added check_flow_token function * outbound: docbook - fixed 'Attribute "xmlns:xi" must be declared for element type' * outbound: fixed xml validation errors * outbound: added check_flow_token documentation -- File Changes -- M src/modules/outbound/doc/outbound.xml (3) M src/modules/outbound/doc/outbound_admin.xml (78) M src/modules/outbound/outbound_mod.c (149) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4449.patch https://github.com/kamailio/kamailio/pull/4449.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4449 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4449(a)github.com>

4 24

[kamailio/kamailio] outbound + loose_route: new exit code when flow token does not exist (Issue #4315)
by sergey-safarov 08 Dec '25

08 Dec '25

sergey-safarov created an issue (kamailio/kamailio#4315) ### Description Use case WebRTC client connected to Kaamilio Edge proxy. For network connectivity reasons, the flow token may no longer be valid. In this case, behavior should be described in the [RFC5626, 5.3.1 Processing Incoming Requests](https://datatracker.ietf.org/doc/html/rfc5626#section-5.3.1) > If the flow no longer exists, the proxy SHOULD send a 430 (Flow Failed) response to the request. Also [9.3 Incoming Call and Proxy Crash](https://datatracker.ietf.org/doc/html/rfc5626#section-9.3) > Bob's authoritative proxy first tries the flow to EP1, but EP1 no longer has a flow to Bob, so it responds with a 430 (Flow Failed) response. To get it working, it will be fine to use construction like ``` if (!loose_route()) { switch($rc) { case -4: sl_send_reply("403", "Flow Failed"); exit; case -2: sl_send_reply("403", "Forbidden"); exit; default: xlog("L_ERR", "in request_route\n"); sl_reply_error(); exit; } } ``` Where `loose_route` returns a new error code (`-4` for example). This error code is generated when the flow token points to not existing TCP/TLS/WSS connection. ### Expected behavior Kamailio `loose_route` allows the check of flow token validity before messages related via non-existent TCP/TLS/WSS connections. #### Actual observed behavior For now, Kamailio tries to relay messages to non-existent client connections and generate an error message like ``` 477 Unfortunately error on sending to next hop occurred (477/TM) 500 Message processing error (2/TM) ``` #### How to reproduce Required to start Kamailio with a config like ``` listen=udp:127.0.0.1:5060 listen=tcp:127.0.0.1:5060 loadmodule "pv.so" loadmodule "xlog.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "siputils.so" loadmodule "rr.so" loadmodule "stun.so" loadmodule "outbound.so" modparam("outbound", "force_outbound_flag", 1) modparam("outbound", "flow_token_secret", "kamailio") loadmodule "debugger.so" modparam("debugger", "cfgtrace", 1) modparam("debugger", "log_level_name", "exec") request_route { loose_route(); switch($rc) { case -3: xlog("L_ERR", "loose_route code -3\n"); break; case -2: xlog("L_ERR", "loose_route code -2\n"); break; case -1: xlog("L_ERR", "loose_route code -1\n"); break; case 1: xlog("L_ERR", "loose_route code 1\n"); break; case 2: xlog("L_ERR", "loose_route code 2\n"); break; } record_route(); if (has_totag()) { t_relay(); } else { t_relay_to_udp("127.0.0.1", "5080"); } } ``` Then need to start SIPp server script using the command ``` sipp -sf uas.xml -p 5080 -d 4000 -bind_local 127.0.0.1 ``` And then start SIPp client script using the command ``` sipp -sf uac.xml -m 1 -t t1 127.0.0.1 ``` Where `uac.xml` and `uas.xml` are attached [sipp-scripts.tar.gz](https://github.com/user-attachments/files/21187724/sip… -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4315 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4315(a)github.com>

3 7

[kamailio/kamailio] siptrace: core uac send request and $sel() used (Issue #4356)
by sergey-safarov 08 Dec '25

08 Dec '25

sergey-safarov created an issue (kamailio/kamailio#4356) ### Description Kamailio core generated when `siptrace` module tries to relay a message generated by `uac` module. ### Troubleshooting #### Reproduction To reproduce the issue need to start Kamailio with the config file. ``` #!KAMAILIO #!define L_INFO 2 #!trydef TROUBLESHOOT_NET "" local.trace_troubleshooting_net = TROUBLESHOOT_NET descr "trace all SIP messages from given network" # IPv4 listeners listen=udp:lan debug=L_INFO log_stderror=yes loadmodule "pv.so" loadmodule "tm.so" ####### DATABASE module ########## #!substdef "!KAMAILIO_DB_URL!mysql://kamailio:change_me@127.0.0.1:3306/kamailio!g" loadmodule "db_mysql.so" loadmodule "uac.so" modparam("uac", "reg_db_url", "KAMAILIO_DB_URL") modparam("uac", "reg_contact_addr", "192.168.1.2:5080") modparam("uac","restore_mode","none") ####### siptrace module ########## loadmodule "siptrace.so" modparam("siptrace", "duplicate_uri", "sip:127.0.0.1:9060") modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_mode", 1) ####### Routing Logic ######## request_route { drop; } event_route[siptrace:msg] { if ($sel(cfg_get.local.trace_troubleshooting_net) != "") { return; } } ``` In the database, need to inserta record ```sql INSERT INTO `uacreg` VALUES (1,'120','120','example.com','120','10.191.1.21','','120','','8e789f9318c98b9ffd4f0fd9e0b8a747','sip:10.191.1.21;transport=udp',120,0,0,'',''); ``` #### Debugging Data Backtrace for the generated core in the attached file [kamailio-bt-full.txt](https://github.com/user-attachments/files/21671121/ka… #### Log Messages ``` / # kamailio -DD --atexit=no -m 64 -M 8 -E 0(43) INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Listening on udp: 10.191.1.20:5060 Aliases: udp: ip-10-191-1-20.ec2.internal:5060 0(43) INFO: <core> [core/tcp_main.c:5232]: init_tcp(): using epoll_lt as the io watch method (auto detected) 0(43) INFO: siptrace [siptrace.c:438]: mod_init(): can't load dlg api. Will not install dialog callbacks. 0(43) ERROR: siptrace [../../modules/sl/sl.h:107]: sl_load_api(): cannot find bind_sl 0(43) WARNING: siptrace [siptrace.c:450]: mod_init(): cannot bind to SL API. Will not install sl callbacks. 0(43) INFO: <core> [main.c:3233]: main(): processes (at least): 14 - shm size: 67108864 - pkg size: 8388608 0(43) INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 4 0(43) INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 4 0(43) INFO: <core> [core/udp_server.c:264]: probe_max_send_buffer(): SO_SNDBUF is initially 212992 for fd 4 0(43) INFO: <core> [core/udp_server.c:334]: probe_max_send_buffer(): SO_SNDBUF is finally 425984 on fd 4 0(43) ALERT: <core> [main.c:805]: handle_sigs(): child process 55 exited by a signal 11 0(43) ALERT: <core> [main.c:809]: handle_sigs(): core was generated 0(43) INFO: <core> [main.c:832]: handle_sigs(): terminating due to SIGCHLD 1(44) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 2(45) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 3(46) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 4(47) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 5(48) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 6(49) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 7(50) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 8(51) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 9(52) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 13(56) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 10(53) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 11(54) INFO: <core> [main.c:888]: sig_usr(): signal 15 received 0(43) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized ``` ### Possible Solutions As temporary workaround we use ```diff diff --git a/src/core/cfg/cfg_select.c b/src/core/cfg/cfg_select.c index f948dd4ab4..1a36ef378a 100644 --- a/src/core/cfg/cfg_select.c +++ b/src/core/cfg/cfg_select.c @@ -207,8 +207,10 @@ int select_cfg_var(str *res, select_t *s, struct sip_msg *msg) group = (cfg_group_t *)s->params[1].v.p; var = (cfg_mapping_t *)s->params[2].v.p; - if(!group || !var) + if(!group || !var || NULL == *(group->handle)) { + LM_ERR("incorrect input args\n"); return -1; + } /* use the module's handle to access the variable, so the variables * are read from the local config */ ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` / # 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 on 14:31:12 Nov 18 2024 with gcc 14.2.0 ``` * **Operating System**:  ``` NAME="Alpine Linux" ID=alpine VERSION_ID=3.21.4 PRETTY_NAME="Alpine Linux v3.21" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues" ``` uname ``` Linux sbc0-site0-stage.ph.nga911.com 6.15.5-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jul 6 09:16:17 UTC 2025 x86_64 Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4356 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4356(a)github.com>

3 6

[kamailio/kamailio] ims_qos_npn: Wmaybe-uninitialized build warning (Issue #4484)
by sergey-safarov 08 Dec '25

08 Dec '25

sergey-safarov created an issue (kamailio/kamailio#4484) ``` /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ims_qos_npn/rx_aar.c:671:69: warning: ‘rpl_sdp_session’ may be used uninitialized [-Wmaybe-uninitialized] 671 | ipB = rpl_sdp_session->ip_addr; | ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ims_qos_npn/rx_aar.c:560:47: note: ‘rpl_sdp_session’ was declared here 560 | sdp_session_cell_t *req_sdp_session, *rpl_sdp_session; | ^~~~~~~~~~~~~~~ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ims_qos_npn/rx_aar.c:620:35: warning: ‘rpl_sdp_stream’ may be used uninitialized [-Wmaybe-uninitialized] 620 | if(rpl_sdp_stream) { | ^ /root/rpmbuild/BUILD/kamailio-6.1.0-dev1/src/modules/ims_qos_npn/rx_aar.c:561:45: note: ‘rpl_sdp_stream’ was declared here 561 | sdp_stream_cell_t *req_sdp_stream, *rpl_sdp_stream; | ^~~~~~~~~~~~~~ ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4484 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4484(a)github.com>

3 4

[kamailio/kamailio] htable: load data via API (Issue #4457)
by sergey-safarov 08 Dec '25

08 Dec '25

sergey-safarov created an issue (kamailio/kamailio#4457) ### Description For now, `htable` exporting `table_spec` and `init_tables`. [Link](https://github.com/kamailio/kamailio/blob/18beef305002e6b2a4a6504273a… When spec contains `dbmode=1`, then data is not loaded from the database, and `htable` cache data is not available after Kamailio restart. It would be fine to expose `ht_db_load_tables` via `htable` API and other Kamailio modules can get cache after Kamailio restart. ### Expected behavior htables defined via API with param dbmode=1 loaded after Kamailio restart. #### Actual observed behavior htables cache is not loaded after Kamailio restart if the table is created via API. ### Possible Solutions Probably it can be done using this change ```diff From 72e1aea56efa16ecd50806baa94a5cc0f62d37d6 Mon Sep 17 00:00:00 2001 From: Nikolay Ivanuschak <ivanuschak.nikolay(a)gmail.com> Date: Wed, 29 Oct 2025 22:57:49 +0300 Subject: [PATCH] htable: added db API functions --- src/modules/htable/api.c | 25 +++++++++++++++++++++++++ src/modules/htable/api.h | 9 +++++++++ 2 files changed, 34 insertions(+) diff --git a/src/modules/htable/api.c b/src/modules/htable/api.c index 94095d3d5d..02b299d8c4 100644 --- a/src/modules/htable/api.c +++ b/src/modules/htable/api.c @@ -26,6 +26,7 @@ #include "../../core/dprint.h" #include "ht_api.h" +#include "ht_db.h" #include "api.h" #include "ht_dmq.h" @@ -157,6 +158,26 @@ int ht_api_init_tables(void) return ht_init_tables(); } +int ht_api_db_open_con(void) +{ + return ht_db_open_con(); +} + +int ht_api_db_close_con(void) +{ + return ht_db_close_con(); +} + +int ht_api_db_load_tables(void) +{ + return ht_db_load_tables(); +} + +int ht_api_db_sync_tables(void) +{ + return ht_db_sync_tables(); +} + /** * */ @@ -175,5 +196,9 @@ int bind_htable(htable_api_t *api) api->get_expire = ht_api_get_cell_expire; api->rm_re = ht_api_rm_cell_re; api->count_re = ht_api_count_cells_re; + api->db_open_con = ht_api_db_open_con; + api->db_close_con = ht_api_db_close_con; + api->db_load_tables = ht_api_db_load_tables; + api->db_sync_tables = ht_api_db_sync_tables; return 0; } diff --git a/src/modules/htable/api.h b/src/modules/htable/api.h index 2e84f2e0da..1f0a547434 100644 --- a/src/modules/htable/api.h +++ b/src/modules/htable/api.h @@ -38,6 +38,11 @@ typedef int (*ht_api_set_cell_expire_f)( typedef int (*ht_api_get_cell_expire_f)( str *hname, str *name, unsigned int *val); +typedef int (*ht_api_db_open_con_f)(void); +typedef int (*ht_api_db_close_con_f)(void); +typedef int (*ht_api_db_load_tables_f)(void); +typedef int (*ht_api_db_sync_tables_f)(void); + typedef int (*ht_api_rm_cell_re_f)(str *hname, str *sre, int mode); typedef int (*ht_api_count_cells_re_f)(str *hname, str *sre, int mode); @@ -52,6 +57,10 @@ typedef struct htable_api ht_api_get_cell_expire_f get_expire; ht_api_rm_cell_re_f rm_re; ht_api_count_cells_re_f count_re; + ht_api_db_open_con_f db_open_con; + ht_api_db_close_con_f db_close_con; + ht_api_db_load_tables_f db_load_tables; + ht_api_db_sync_tables_f db_sync_tables; } htable_api_t; typedef int (*bind_htable_f)(htable_api_t *api); -- 2.51.0 ``` Here exposed `db_open_con`, `db_close_con`, also because required to make sure database connections are present before reading the database. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4457 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4457(a)github.com>

2 2

[kamailio/kamailio] DB_cluster issue (Issue #4467)
by itpanda2024 08 Dec '25

08 Dec '25

itpanda2024 created an issue (kamailio/kamailio#4467)  ### Description  ### 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/4467 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4467(a)github.com>

3 7

[kamailio/kamailio] KEMI: Add htable count/match API equivalent to $shtcn() (to avoid pv_cache growth with dynamic PV strings) (Issue #4426)
by Hendrik Wedhorn 08 Dec '25

08 Dec '25

wedhornsipgate created an issue (kamailio/kamailio#4426) **Description:** We're missing a KEMI function in the htable module that provides the same functionality as the PV function `$shtcn(table=>pattern)` to count the number of keys in an htable that match a given pattern (prefix/suffix/regex). The goal is to let KEMI scripts perform pattern counts without constructing dynamic PV expressions, which currently causes unbounded pv_cache growth in PKG memory. **Use case / motivation:** We implemented rolling-window rate limiting by writing short-lived, per-call entries into an htable and then counting keys that match a number-derived pattern. Using $shtcn() works well for the logic, but in KEMI (JS/TypeScript) we must call it via pv.gete("$shtcn(...)"). Because the PV string varies per INVITE (different pattern/key each time), these dynamic PV expressions accumulate in the PV cache, growing PKG/private memory over time. We’d like a native KEMI function to perform the same count/match so we can avoid the PV layer entirely. **Environment** Kamailio: 5.8.6 on Debian 12 Scripting: KEMI (JavaScript/TypeScript) Symptom: steady PKG/private memory increase over ~24h under load when using pv.gete("$shtcn(...)"). Disabling the $shtcn() call stops the growth. Related log line: the one discussed in [#3440](https://github.com/kamailio/kamailio/issues/3440) (“pv cache … pkg memory may get filled with pv declarations”). Current line in our script: ```if (ksr.pv.gete(`$shtcn(${htable_count}=>%~${number})`) > threshold) { ... }``` **Current workaround** Restarting the Kamailio every day or disabling rate limit on instances with KEMI. **Idea for API** Minimal, PV-parity: ``` // KEMI export int shtcn_match(str table, str pattern, int mode /* 0=exact, 1=prefix, 2=suffix, 3=regex */); ``` JS example: `const n = KSR.htable.shtcn_match("from_number_count", number, 3); // regex` More explicit helpers (avoids integer modes): ``` KSR.htable.shtcn_exact(table, key) -> int KSR.htable.shtcn_prefix(table, prefix) -> int KSR.htable.shtcn_suffix(table, suffix) -> int KSR.htable.shtcn_regex(table, pattern) -> int ``` **Behavioral notes / expectations** Should mirror $shtcn() semantics where reasonable (esp. regex behavior), but returning an integer directly to KEMI. Must not allocate PV expressions or interact with pv_cache. **Why this belongs in htable KEMI** $shtcn() is already offered at the PV level; parity in KEMI keeps feature consistency across scripting engines. It enables memory-safe implementations of rolling-window rate limits and similar patterns (without touching PV). **Alternatives considered** Replace pattern counting with per-bucket counters (sht_inc), which leads to other problems like increment/decrement handling and locking. Use ratelimit/pike modules—useful for IP/method limits, but our use case is PAI/From/To based and currently hinges on pattern counts. **Acceptance criteria** A KEMI function exists to count matching keys in an htable without PV parsing. Verified that repeated calls with dynamic patterns do not grow PV cache / PKG memory. Basic tests for exact/prefix/suffix/regex modes (and skip_expired if implemented). Thank you! This would let KEMI users keep $shtcn()-style logic with the same performance characteristics, but without the PV-cache side effects. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4426 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4426(a)github.com>

4 4

[kamailio/kamailio] htable: feature parity with kemi funcs (PR #4499)
by Tyler Moore 08 Dec '25

08 Dec '25

- add sht_is_null route function - add sht_inc route function - add sht_dec route function #### 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 Implementing the identical functions from KEMI in the route functions. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4499 -- Commit Summary -- * htable: feature parity with kemi funcs -- File Changes -- M src/modules/htable/doc/htable.xml (2) M src/modules/htable/doc/htable_admin.xml (105) M src/modules/htable/htable.c (95) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4499.patch https://github.com/kamailio/kamailio/pull/4499.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4499 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4499(a)github.com>

2 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2025