October 2025 - sr-dev - kamailio.org

[kamailio/kamailio] Memory usage increases everytime tls.reload is executed (Issue #3823)
by Sebastian Denz 10 Jul '26

10 Jul '26

### 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>

12 55

[kamailio/kamailio] http_client/http_async_client crash at startup if used with tls and openssl 1.1 (Issue #2912)
by kdanderso 01 Jun '26

01 Jun '26

### Description When attempting to use either http_client or http_async_client with tls support enabled and openssl version 1.1.x, Kamailio crashes at startup. If openssl is reverted to version 1.0.2r as described in #1860, the issue does not occur. #### Reproduction On a system using openssl version 1.1.x (e.g. 1.1.1l) start Kamailio 5.5.2 with this config file for http_client failure: [kamailio.cfg.txt](https://github.com/kamailio/kamailio/files/7442436/kamail… To test http_async_client, load pv.so and http_async_client.so instead of http_client.so. #### Debugging Data [bt.txt](https://github.com/kamailio/kamailio/files/7442493/bt.txt) #### Log Messages [kam.log.txt](https://github.com/kamailio/kamailio/files/7442496/kam.log.txt) ### Additional Information * **Kamailio Version**: [kamversion.txt](https://github.com/kamailio/kamailio/files/7442506/kamversi… * **Operating System**: Linux 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:50:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux [os.txt](https://github.com/kamailio/kamailio/files/7442509/os.txt) -- 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/2912

5 10

[tracker] Assignee added: Assignment operators don't work
by sip-router 29 May '26

29 May '26

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.

10 9

[kamailio/kamailio] ims_diameter_server not freeing shared memory (Issue #4116)
by MGrimby 20 May '26

20 May '26

### 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 10

[kamailio/kamailio] presence: preserve etag uniqueness when marking presentity for removal (PR #4275)
by Alessio Garzi 19 May '26

19 May '26

#### 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 #### Description When the `presence` module attempts to clean up records in the `presentity` table, it replaces the `etag` with a static, hardcoded string: ``` "*#-OFFLINE-#*" ``` However, the `presentity` table enforces a uniqueness constraint on the following combination of fields: ``` MariaDB [kamailio]> show create table presentity; | presentity | CREATE TABLE `presentity` ( ... UNIQUE KEY `presentity_idx` (`username`,`domain`,`event`,`etag`), ``` This approach breaks the uniqueness of etag, which is intended to differentiate records , especially in cases such as parallel calls, or when using kamailio as a forking proxy. Instead of overwriting the etag with the static offline marker, this patch appends the marker to the existing etag value. This ensures the offline flag is retained while preserving the uniqueness of the etag. The deletion query was also updated accordingly: it now identifies offline records using a LIKE '%*#-OFFLINE-#*' clause. Based on testing, the duplicate key errors no longer occur, and the cleanup logic now behaves as expected. This patch improves the reliability of presentity cleanup without requiring schema or index changes. Please consider merging into master. Thanks! You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4275 -- Commit Summary -- * presence: preserve etag uniqueness when marking presentity for removal -- File Changes -- M src/modules/presence/presentity.c (90) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4275.patch https://github.com/kamailio/kamailio/pull/4275.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4275 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4275(a)github.com>

3 11

[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 19 May '26

19 May '26

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>

5 5

[kamailio/kamailio] Issue with usrloc 'handle_lost_tcp' and dmq_usrloc 'usrloc_delete' (Issue #3479)
by alternatenetwork 02 May '26

02 May '26

### Description When a TLS connection is closed and handle_lost_tcp=1 the entry is deleted for usrloc. This deletion is not synced via DMQ even though usrloc_delete=1. There is also an issue on the same server if a re-registration happens right after before the timeout was supposed to expire then $var(sv_res) = 2 even though the usrloc table is empty. So it seems like the way handle_lost_tcp deletes is not deleting fully in registrar. usrloc db_mode is 0 ### Troubleshooting #### Reproduction Setup 2 servers with DMQ and close the TCP connection. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.6.1 (x86_64/linux) d8f98b 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: d8f98b compiled on 19:05:04 Aug 16 2022 with gcc 8.3.0 ``` * **Operating System**:  ``` Debian 10 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3479 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3479(a)github.com>

3 6

[kamailio/kamailio] http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table (Issue #4431)
by fulhade 20 Apr '26

20 Apr '26

fulhade created an issue (kamailio/kamailio#4431) Testing 6.0.3 noticed that log is filled with INFO log messages from title (every 5s). No errors in logs, usual stuff except info on tcpcon ``` Oct 12 00:40:24 kamailio[4350]: INFO: <core> [core/tcp_main.c:3124]: tcpconn_1st_send(): quick connect for 0x7f78f8c79b10 sock 38 Oct 12 22:42:26 kamailio[4355]: INFO: <core> [core/tcp_main.c:3124]: tcpconn_1st_send(): quick connect for 0x7f78f8c79b10 sock 32 ... Oct 13 07:42:12 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:17 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:22 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:27 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:32 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:37 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table ``` Using docker image built on trixie: https://pastebin.com/0wZ0X9wb Not sure how to reproduce, it just appear on testing machine after couple of days. Unfortunately we used 5.6.3 before this, so not sure when did it break for us. http_async_client usage: ``` $http_req(hdr) = "Content-Type: application/json"; $http_req(hdr) = "Expect: "; $http_req(body) = $dlg_var(http_body); http_async_query("${URL}/RoutingService/route", "ROUTING_RESPONSE"); ``` Memory looks fine, but one of four CPU core spike to 96%. <img width="1119" height="955" alt="Image" src="https://github.com/user-attachments/assets/ffff8680-84ad-4866-9892-a6e6eefd…" /> core.tcp_info, mod.stats all shm, mod.stats all pkg https://pastebin.com/QLZ8mZdD -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4431 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4431(a)github.com>

4 8

[kamailio/kamailio] topos: Allow contact a/b host like user part (PR #4246)
by Xenofon Karamanos 16 Apr '26

16 Apr '26

#### 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  In this PR we introduce a new mode and two new parameters for accomplishing the same thing for user part also in domain part. Docs incoming if no significant changes are needed. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4246 -- Commit Summary -- * topos: Add new contact_mode=3 and 2 new modparam for contact host domains * topos: Refactor contact_mode handling * topos: Append port and protocol param -- File Changes -- M src/modules/topos/topos_mod.c (13) M src/modules/topos/tps_storage.c (428) M src/modules/topos/tps_storage.h (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4246.patch https://github.com/kamailio/kamailio/pull/4246.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4246 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4246(a)github.com>

4 8

[kamailio/kamailio] jwt module - build by default and upload to deb.kamailio.org (Issue #4416)
by Michael Kanchuker 07 Apr '26

07 Apr '26

mkl262 created an issue (kamailio/kamailio#4416) Hello, Im asking to add the JWT Module to the default list of modules that are being built and uploaded to [deb.kamailio.org](https://deb.kamailio.org/). Will editing the CMAKE scripts will be enough (in which case I can open a PR for it), or does it require modifying the Jenkins pipelines? Thanks, Michael. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4416 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4416(a)github.com>

3 9