sr-dev March 2026

sr-dev@lists.kamailio.org

35 participants
465 discussions

[kamailio/kamailio] dmqueue: add peer-up and peer-down event_routes (PR #4661)
by Gustavo Almeida 21 Apr '26

21 Apr '26

#### Description This PR introduces `event_routes` that will trigger when `dmq peers` go up and down during the time. Really useful to detect problems between `peers` and allows addition of prometheus metrics for example, to add automatic visibility. #### 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:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Tests Tested locally simulating crashes and startups to evaluate the trigger of routes. Couldn't found any problems or strange cases, on ping intervals the status validation, gives the correct output. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4661 -- Commit Summary -- * dmqueue: add peer up and down event routes -- File Changes -- M src/modules/dmq/dmq.c (68) M src/modules/dmq/dmq.h (3) M src/modules/dmq/dmqnode.c (30) M src/modules/dmq/dmqnode.h (2) M src/modules/dmq/doc/dmq_admin.xml (79) M src/modules/dmq/notification_peer.c (22) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4661.patchhttps://github.com/kama… -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4661 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4661(a)github.com>

4 31

[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] tm: use bitwise check for REQ_ERR_DELAYED in t_unref() (PR #4644)
by Norm Brandinger 20 Apr '26

20 Apr '26

Fixes #4503. ### Problem Transactions leak when `drop;` executes in a `branch_route` and modules like `pua_dialoginfo` are loaded. The leaked transactions persist indefinitely in shared memory — no final reply is sent, no timer fires, and `wait_handler()` never frees the cell. ### Cause `set_kr()` accumulates flags with `|=`, but the first cleanup check in `t_unref()` uses exact equality: ```c if(unlikely(kr == REQ_ERR_DELAYED)) { // fails when other flags are set ``` When `pua_dialoginfo` processes an INVITE, it calls `dialog_publish_multi()` inline during `DLGCB_CREATED`, which goes through `pua_send_publish()` → `tmb.t_request()` → `t_uac_prepare()` → `set_kr(REQ_FWDED)`. If the INVITE's `branch_route` then calls `drop;`, `t_relay_to()` ORs in `REQ_ERR_DELAYED`, making `_tm_kr = REQ_FWDED | REQ_ERR_DELAYED` (17). In `t_unref()`: - Check 1: `17 == 16` → false - Check 2: `17 == 0` → false - Check 3: `(17 & 16)` true, but `(17 & ~(4|2|16|1))` = 0 → false All three checks fail. The transaction is orphaned. This affects any module that calls `t_request()` or `t_uac_prepare()` inline during INVITE processing — `pua_dialoginfo` is one common example. ### Fix Change the check from exact equality to a bitwise test: ```c - if(unlikely(kr == REQ_ERR_DELAYED)) { + if(unlikely(kr & REQ_ERR_DELAYED)) { ``` The delayed-reply handler now fires whenever `REQ_ERR_DELAYED` is present, regardless of other flags accumulated by `set_kr()`. This is safe because: - `REQ_ERR_DELAYED` is only set in `t_relay_to()` when `t_forward_nonack()` fails and the delayed-reply path is chosen — it is never set spuriously. - `kill_transaction()` already handles the case where a final reply was previously sent (`FL_FINAL_REPLY` check → `t_release_transaction()`). The existing check-3 fallback (lines 2077-2084) becomes unreachable after this change but is harmless to leave in place. ### Workaround On 6.1+ where `delayed_reply` is a runtime modparam, setting `modparam("tm", "delayed_reply", 0)` avoids the vulnerable code path. On ≤ 6.0.x, `TM_DELAYED_REPLY` is a compile-time `#define` (always on) and there is no workaround — only this patch fixes the leak. ### Test results Ten-scenario matrix across 6.0.3, 6.1.0, and 6.2.0-dev0 master. 1000 INVITEs per run, `fr_timer=5000`, `branch_route` with unconditional `drop;`. Contamination triggered naturally by loading `dialog` + `pua` + `pua_dialoginfo` — no source modification beyond this patch. | # | Version | Patch | `delayed_reply` | current | 5xx | SHM delta | Verdict | |---|---------|-------|:---------------:|--------:|----:|----------:|---------| | 1 | 6.0.3 | no | x | 431 | 0 | +7,150,272 | **LEAK** | | 2 | 6.0.3 | yes | x | 0 | 353 | 0 | OK | | 3 | 6.1.0 | no | 1 | 431 | 0 | +7,287,200 | **LEAK** | | 4 | 6.1.0 | no | 0 | 0 | 375 | 0 | OK | | 5 | 6.1.0 | yes | 1 | 0 | 407 | 0 | OK | | 6 | 6.1.0 | yes | 0 | 0 | 336 | 0 | OK | | 7 | 6.2.0-dev0 | no | 1 | 446 | 0 | +7,770,288 | **LEAK** | | 8 | 6.2.0-dev0 | no | 0 | 0 | 461 | 0 | OK | | 9 | 6.2.0-dev0 | yes | 1 | 0 | 448 | 0 | OK | | 10 | 6.2.0-dev0 | yes | 0 | 0 | 448 | 0 | OK | `delayed_reply` = x: not available as a modparam (compile-time, always on). `current`: transactions remaining in hash table after test. `5xx`: 500 replies sent by the delayed-reply handler (nonzero = cleanup ran). --- *Note: AI tooling was used to assist with the code analysis, reproduction, and test automation for this issue. All diagnosis, testing, and review was supervised by @NormB — the AI did not operate autonomously. The root cause identification, fix selection, and validation were guided and verified at each step.* You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4644 -- Commit Summary -- * tm: use bitwise check for REQ_ERR_DELAYED in t_unref() -- File Changes -- M src/modules/tm/t_lookup.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4644.patch https://github.com/kamailio/kamailio/pull/4644.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4644 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4644(a)github.com>

5 17

[kamailio/kamailio] Potential SHM memory leak in pua_dialoginfo / pua modules ? (Issue #4503)
by Alessio Garzi 20 Apr '26

20 Apr '26

Ozzyboshi created an issue (kamailio/kamailio#4503) Hello, on my Kamailio installation I am experiencing a significant memory leak in SHM. Here are the details of my system: ``` version: kamailio 6.0.3 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, NO_SIG_DEBUG, 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 compiled with gcc 14.2.0 ``` The memory leak appears only when the presence feature is enabled. When presence is active, Kamailio starts running dialog_publish(), whose code is here: https://github.com/kamailio/kamailio/blob/9dc160d1d2bdf0542d3d9d8ae090bb135… This function does not send the PUBLISH directly: it calls pua_send_publish(), which is a function pointer referring to the send_publish() implementation in the pua module. Then send_publish() eventually calls set_uac_req() and tmb.t_request(): https://github.com/kamailio/kamailio/blob/9dc160d1d2bdf0542d3d9d8ae090bb135… Digging further, tmb.t_request() maps to request() in the TM module, which calls t_uac_with_ids() and then t_uac_prepare(). Now comes the suspicious part: If I comment out the call to t_uac_prepare(), the memory leak disappears. This doesn’t necessarily mean the bug is inside t_uac_prepare(), but it’s a strong hint. t_uac_prepare() allocates a new struct cell and returns it: https://github.com/kamailio/kamailio/blob/9dc160d1d2bdf0542d3d9d8ae090bb135… My concern is: is this cell always freed? The matching cleanup function is free_cell(), used only here: https://github.com/kamailio/kamailio/blob/9dc160d1d2bdf0542d3d9d8ae090bb135… From what I can tell, free_cell() is called only if all these conditions are true: - dst_cell == 0 - is_ack == 1 - dst_req == 0 - In my situation no ACK is involved (Kamailio is a proxy that sends PUBLISH and immediately gets a 200 OK). Therefore, is_ack is always false meaning the free_cell() cleanup logic is skipped entirely. I tried forcing free_cell() unconditionally, but it leads to crashes, so clearly other parts of the code still rely on this structure. Does the current free_cell() logic look correct to you? Is it expected that struct cell allocated by t_uac_prepare() remains unfreed in cases where PUBLISH → 200 OK occurs without ACK? Any guidance on how to proceed or where else to look would be greatly appreciated. Thanks -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4503 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4503(a)github.com>

5 30

[kamailio/kamailio] fix tls_connection_match_domain (PR #4676)
by Michael Furmur 20 Apr '26

20 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 - [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 fix wrong connections reuse in tls_connection_match_domain=yes mode and add test for it * change related places for tls and tls_wolfssl modules * fix protocol checking in _tcpconn_find * add test/unit/62.sh test/unit/62.sh execution time: ``` test/unit$ time make run UNIT=62.sh Run test 62: checks tls_connection_match_domain=yes creates new connection to the same dst ip:port for another tls domain Test unit file 62.sh: ok real 0m1.191s user 0m0.048s sys 0m0.019s ``` was wrongly reusing the same TLS connection even between different TLS domains because: * invalid proto check in _tcpconn_find was skipping tls hook match_domain when it called with proto:0 * passing connection ptr to the get_tls_domain_str in tls_h_match_domain_f was causing tls_get_connect_server_name,tls_get_connect_server_id to check connection against itself instead of XAVPs lookup for the new connection context You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4676?email_source=notifications&a… -- Commit Summary -- * tls: fix tls_h_match_domain_f connection matching * tls_wolfssl: fix tls_h_match_domain_f connection matching * core: _tcpconn_find: fix protocol checking for tls_connection_match_domain * test: add unit/62.sh for tls_connection_match_domain=yes -- File Changes -- M src/core/tcp_main.c (2) M src/modules/tls/tls_server.c (4) M src/modules/tls_wolfssl/tls_server.c (4) A test/unit/62.cfg (37) A test/unit/62.sh (131) A test/unit/62_tls.cfg (11) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4676.patch?email_source=notificat… -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4676 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4676(a)github.com>

2 5

[kamailio/kamailio] DB_cluster issue (Issue #4467)
by itpanda2024 17 Apr '26

17 Apr '26

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>

4 11

[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

[kamailio/kamailio] alpine: failed build 5.8 branch (Issue #4585)
by sergey-safarov 05 Apr '26

05 Apr '26

sergey-safarov created an issue (kamailio/kamailio#4585) ### Description ``` CC (cc) [M ims_dialog.so] dlg_var.o CC (cc) [M ims_dialog.so] ims_dialog.o ims_dialog.c: In function 'mod_init': ims_dialog.c:535:27: error: passing argument 1 of 'register_timer' from incompatible pointer type [-Wincompatible-pointer-types] 535 | if(register_timer(print_all_dlgs, 0, 10) < 0) { | ^~~~~~~~~~~~~~ | | | void (*)(void) In file included from ../../core/pt.h:31, from ../../core/counters.h:37, from ../../core/sr_module.h:42, from ims_dialog.c:7: ../../core/timer.h:189:35: note: expected 'void (*)(unsigned int, void *)' but argument is of type 'void (*)(void)' 189 | int register_timer(timer_function f, void *param, unsigned int interval); | ~~~~~~~~~~~~~~~^ In file included from ims_dialog.c:27: dlg_handlers.h:197:6: note: 'print_all_dlgs' declared here 197 | void print_all_dlgs(); | ^~~~~~~~~~~~~~ make[3]: Entering directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-28bd46f1f22ffacf859504768e7284591ccba126/src/lib/srdb1' make[3]: 'libsrdb1.so.1.0' is up to date. make[3]: Leaving directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-28bd46f1f22ffacf859504768e7284591ccba126/src/lib/srdb1' make[2]: *** [../../Makefile.rules:100: ims_dialog.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [Makefile:509: modules] Error 1 make[1]: Leaving directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-28bd46f1f22ffacf859504768e7284591ccba126/src' make: *** [Makefile:34: all] Error 2 >>> ERROR: kamailio: build failed >>> kamailio: Uninstalling dependencies... ``` ### Additional Information * **Operating System**: ``` / $ cat /etc/os-release NAME="Alpine Linux" ID=alpine VERSION_ID=3.23.3 PRETTY_NAME="Alpine Linux v3.23" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues" ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4585 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4585(a)github.com>

2 2

[kamailio/kamailio] Segmentation Fault on Ctrl-C with No Fork Mode (Issue #4669)
by sznoname 03 Apr '26

03 Apr '26

sznoname created an issue (kamailio/kamailio#4669) Segmentation Fault on Ctrl-C with No Fork Mode Environment - OS: Debian 13.3 - Kamailio Version: 6.1.1 (x86_64/Linux) Relevant Configuration (/etc/kamailio/kamailio.cfg) log_stderror=yes fork=no auto_aliases=no tcp_accept_no_cl=yes loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "nats.so" modparam("nats", "nats_url", "nats://127.0.0.1:4222") modparam("nats", "subject_queue_group", "Kamailio-World:2026") request_route { sl_send_reply("403", "Not relaying"); exit; } Steps to Reproduce 1. Start Kamailio in foreground mode with the given configuration: kamailio 2. Stop the running process using Ctrl-C Observed Output and Crash WARNING: no fork mode and more than one listen address found (will use only the first one) 0(9286) WARNING: <core> [main.c:1460]: main_loop(): using only the first listen address (no fork) ^CSegmentation fault (core dumped) -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4669 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4669(a)github.com>

3 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2026