sr-dev January 2026

sr-dev@lists.kamailio.org

24 participants
391 discussions

[kamailio/kamailio] IMS_PCSCF: handle_tcpconn_ev failed (Issue #4436)
by Nic the nothing 17 Feb '26

17 Feb '26

nicthenothing created an issue (kamailio/kamailio#4436) Description When using Kamailio IMS (from docker_open5gs setup) as the P-CSCF, SIP calls fail to initiate when the UE’s signaling (“ear” channel) and media (“mouth” channel) are bound to different ports or sockets. In the captured logs, the Request-URI and the Destination-URI differ in both port and alias parameters, resulting in the INVITE not being routed properly through the IPSec tunnel. It seems that Kamailio does not correctly resolve the IPSec tunnel when the UE’s contact and destination information differ (possibly due to alias handling or flag configuration). This issue may relate to improper handling of the alias parameter or flag mismatch between use_dst_uri and use_contact. --- Troubleshooting Reproduction 1. Deploy the default IMS setup from herlesupreeth/docker_open5gs (Kamailio + Open5GS). 2. Attach a UE over IPSec where its signaling and media sockets differ (e.g., TCP vs UDP port mismatch). 3. Initiate a SIP INVITE from UE-A to UE-B. 4. Observe that INVITE fails to reach the destination. Debugging Data N/A (default Docker config used) Log Messages 2025-10-15T13:21:33.638305291Z Destination URI: sip:10.20.7.216:42602;transport=tcp 2025-10-15T13:21:33.638307845Z Request URI: sip:3c7a3414-8cf7-458e-a674-9181ea0ccd15@10.20.7.216:42078 --- SIP Traffic Request-Line: INVITE sip:578da559-1f6e-430f-a953-8e4dfc99918e@10.20.7.228:40404;alias=10.20.7.228~43426~2 SIP/2.0 Request-URI: sip:578da559-1f6e-430f-a953-8e4dfc99918e@10.20.7.228:40404;alias=10.20.7.228~43426~2 Request-URI User Part: 578da559-1f6e-430f-a953-8e4dfc99918e Request-URI Host Part: 10.20.7.228 Request-URI Host Port: 40404 --- Possible Solutions Validate handling of alias parameter in IPSec tunnel search logic. Verify if flag 4 (Use destination URI for IPSec tunnel search) or flag 8 (Use new R-URI for IPSec tunnel search) needs adjustment in modparam("ipsec", "flag", X) for correct behavior. Potential fix may involve extending alias resolution to new R-URI before tunnel lookup. --- Additional Information Kamailio Version: version: kamailio 5.7.x (from docker_open5gs) Operating System: Ubuntu 22.04 (containerized) Linux 5.15.0-122-generic -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4436 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4436(a)github.com>

6 16

[kamailio/kamailio] tls_wolfssl: assertion (Issue #4391)
by Dennis 16 Feb '26

16 Feb '26

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>

5 9

OBD Based Missed Call issue
by Chandra Bhan 14 Feb '26

14 Feb '26

Hi Daniel I hope you are doing well. Looking for your support on kamailio. I am a new for kamailio. I want to build setup OBD Based Missed Call Solution 1. I able to send http request on kamailio but call not getting dial due to some reason Here is my code. Could you help me to resolve the issue. #!KAMAILIO ####### Global Parameters ######### debug=3 log_stderror=yes memdbg=5 memlog=5 children=8 tcp_accept_no_cl=yes auto_aliases=no listen=udp:172.26.12.138:5060 listen=tcp:0.0.0.0:8080 alias=your.public.ip # optional ####### Modules Section ######## loadmodule "sl.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "xlog.so" loadmodule "textops.so" loadmodule "maxfwd.so" loadmodule "sanity.so" loadmodule "siputils.so" loadmodule "xhttp.so" loadmodule "uac.so" ####### Module Parameters ######## # --- TM modparam("tm", "fr_timer", 5000) modparam("tm", "fr_inv_timer", 30000) # --- RR modparam("rr", "enable_double_rr", 1) modparam("rr", "append_fromtag", 1) # --- UAC (authentication profile) # format: # name => sip:proxy, username, password modparam("uac", "uac_reg", "obd => sip:GSM-Gateway-IP:5060,2555,123456" ) ####### Routing Logic ######## request_route { # Sanity checks if (!sanity_check("1511", "7")) { xlog("L_ERR", "Sanity failed\n"); drop; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); exit; } # Handle HTTP requests if ($Rp == 8080 && $rm == "GET") { route(HTTP); exit; } # SIP requests (only outbound calls expected) if (is_method("INVITE")) { record_route(); t_relay(); exit; } if (is_method("ACK|BYE|CANCEL")) { t_relay(); exit; } sl_send_reply("404", "Not Here"); exit; } ####### HTTP ROUTE ######## route[HTTP] { if ($hu =~ "^/call") { # Example: # http://IP:8080/call?msisdn=9999909109 $var(msisdn) = $param(msisdn); if ($var(msisdn) == "") { xhttp_reply("400", "text/plain", "Missing msisdn\n"); exit; } xlog("L_INFO", "HTTP Call request for $var(msisdn)\n"); route(OBD_CALL); xhttp_reply("200", "text/plain", "Call initiated\n"); exit; } xhttp_reply("404", "text/plain", "Invalid URL\n"); exit; } ####### OUTBOUND CALL ROUTE ######## route[OBD_CALL] { $var(dst_uri) = "sip:" + $var(msisdn) + "@GSM-Gateway-IP:5060"; xlog("L_INFO", "Calling $var(dst_uri)\n"); uac_req_send( "INVITE", $var(dst_uri), "sip:kamailio@your.domain", "sip:" + $var(msisdn) + "@your.domain", "", "obd" ); exit; }

5 15

[kamailio/kamailio] topoh Segfault on invalid request URI (Issue #4507)
by Flo 14 Feb '26

14 Feb '26

floo94 created an issue (kamailio/kamailio#4507) ### Description When an invite contains URL-encoded angle brackets (see example request URI), Topoh crashes with a segfault. Unfortunately, I don't have the means to produce logs or a core dump at the moment... Sorry for the poor information. If necessary, I can provide more data later. ### Troubleshooting #### Reproduction #### SIP Traffic Request URI of the INVITE: ``` INVITE sip:%3csip%3aq*testqueue@dev1.test.com>;user=phone|*8 SIP/2.0 ``` ### Possible Solutions disabling topoh ### Additional Information ``` version: kamailio 6.0.2 (x86_64/linux) 567a0e ``` * **Operating System**: ``` Distributor ID: Ubuntu Description: Ubuntu 22.04.5 LTS Release: 22.04 Codename: jammy 5.15.0-153-generic #163-Ubuntu SMP Thu Aug 7 16:37:18 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4507 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4507(a)github.com>

4 6

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

12 Feb '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>

3 7

[kamailio/kamailio] http_client leaks TLS shared memory (Issue #4231)
by Alexander Bakker 10 Feb '26

10 Feb '26

alexbakker created an issue (kamailio/kamailio#4231) ### Description Performing an HTTPS request using the ``http_client`` module results in a shared memory leak, seemingly related to TLS. ### Troubleshooting #### Reproduction Our use case for ``http_client`` is to update an htable with the latest banned IP's from APIBAN as described here: https://github.com/apiban/apiban?tab=readme-ov-file#integration-into-kamail…. Normally, we refresh the list of banned IP's once every 15 minutes, so the shared memory usage grows fairly slowly. The issue can be reproduced using the Kamailio configuration file below. To demonstrate the issue and make the shared memory usage grow faster, we set up a timer that calls ``http_client_query`` in a tight loop. To prevent unnecessary load on the APIBAN infrastructure, we request an example file from my personal server instead. ``` #!KAMAILIO debug=2 log_stderror=yes fork=yes enable_tls=1 loadmodule "tls.so" loadmodule "cfg_rpc.so" loadmodule "pv.so" loadmodule "xlog.so" loadmodule "ctl.so" loadmodule "rtimer.so" loadmodule "http_client.so" modparam("tls", "certificate", "") modparam("tls", "private_key", "") modparam("rtimer", "timer", "name=apiban;interval=100u;mode=1;") modparam("rtimer", "exec", "timer=apiban;route=APIBAN;") route[APIBAN] { xinfo("running apiban refresh\n"); http_client_query("https://alexbakker.me/u/7bvjn9jfas.txt", "$var(banned)"); } ``` Start Kamailio: ``` kamailio -f kamailio.cfg -DD ``` And then watch the shared memory usage grow rapidly: ``` watch -n1 -- kamcmd core.shmmem ``` #### Log Messages Eventually, Kamailio will run out of shared memory and print the following messages to the log: ``` 21(184184) INFO: <script>: running apiban refresh 21(184184) ERROR: http_client [functions.c:471]: curL_request_url(): failed to perform curl (56) (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) ERROR: http_client [functions.c:471]: curL_request_url(): failed to perform curl (56) (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) ERROR: <core> [core/mem/q_malloc.c:758]: qm_realloc(): qm_realloc(0x7585c73c4000, 1024) called from tls: tls_init.c: ser_realloc(372), module: tls; qm_malloc() failed! 21(184184) INFO: <script>: running apiban refresh 21(184184) INFO: <script>: running apiban refresh 21(184184) ERROR: <core> [core/mem/q_malloc.c:758]: qm_realloc(): qm_realloc(0x7585c73c4000, 1024) called from tls: tls_init.c: ser_realloc(372), module: tls; qm_malloc() failed! 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:463]: curL_request_url(): TLS CA certificate read error (url: https://alexbakker.me/u/7bvjn9jfas.txt) ``` ``mem_dump_shm`` reports a large list of TLS-related allocations. Just sharing the last few lines here, as they're seemingly all from the same location. ``` 20(204914) ALERT: qm_status: qm_status(): 28500. N address=0x705ab3178710 frag=0x705ab31786d0 size=112 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28501. N address=0x705ab31787f0 frag=0x705ab31787b0 size=48 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28502. N address=0x705ab3178890 frag=0x705ab3178850 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28503. N address=0x705ab3178920 frag=0x705ab31788e0 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28504. N address=0x705ab31789b0 frag=0x705ab3178970 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28505. N address=0x705ab3178a40 frag=0x705ab3178a00 size=48 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28506. N address=0x705ab3178ae0 frag=0x705ab3178aa0 size=48 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28507. N address=0x705ab3178b80 frag=0x705ab3178b40 size=144 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28509. N address=0x705ab3178d00 frag=0x705ab3178cc0 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28510. N address=0x705ab3178d90 frag=0x705ab3178d50 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_realloc(372) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28512. N address=0x705ab3178ea0 frag=0x705ab3178e60 size=16 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28513. N address=0x705ab3178f20 frag=0x705ab3178ee0 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28515. N address=0x705ab317a3c0 frag=0x705ab317a380 size=112 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28516. N address=0x705ab317a4a0 frag=0x705ab317a460 size=512 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28517. N address=0x705ab317a710 frag=0x705ab317a6d0 size=1504 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28518. N address=0x705ab317ad60 frag=0x705ab317ad20 size=1040 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed ``` ### Possible Solutions I'm not aware of a workaround for this issue. For our specific use case, I'll move the APIBAN polling out of Kamailio to a separate process for now. ### Additional Information I've verified that this issue is reproducible on ``5.5.7``, ``5.6.6``, ``5.7.6``, ``5.8.6`` and ``6.0.1``. * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 6.0.1 (x86_64/linux) fce50d 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: fce50d compiled on 06:42:29 May 6 2025 with gcc 12.2.0 ``` * **Operating System**: ``` $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm $ uname -a Linux ip-10-146-128-121 6.1.0-32-cloud-arm64 #1 SMP Debian 6.1.129-1 (2025-03-06) aarch64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4231 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4231(a)github.com>

6 25

[kamailio/kamailio] cmake: specify additional include and library paths for a module (Issue #4576)
by Daniel-Constantin Mierla 09 Feb '26

09 Feb '26

miconda created an issue (kamailio/kamailio#4576) I am trying to figure out what is the best way to specify additional include and library paths for a module. The particular case right now is `websocket` on `macos` (`darwin`), where `libunistring` is installed via `macports`, but it does not ship a `pkg-config` file, so the option I was looking briefing at would be to add the macports install paths to compiler/linking options `-I` and `-L`: ``` /opt/local/include /opt/local/lib ``` Considering that most of the libraries come with pkg-config, probably the right place is to add to module's `CMakeLists.txt`. I tried to add some condition on `if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")`, but somehow it doesn't see to work (yet). On the other hand, I noticed kind of find-specific-library files inside `cmake/modules/`. Should this be the preferred approach? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4576 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4576(a)github.com>

2 7

[kamailio/kamailio] Handling JSONPath when key name has a `.` - specifically in `json.parse` transformation (Issue #4510)
by Ben Kaufman 07 Feb '26

07 Feb '26

whosgonna created an issue (kamailio/kamailio#4510) ### Description I came across the following behavior when working with data returned from `rtpengine_query_v()`. Some of the returned data has the `to_tag` and `from_tag` as the key name, and in some cases there is a `.` in the tag, which makes this section of the data unavailable using the `json.parse` transfomration. Sample data, pretty printed, and most fields removed to make the problem more visible. Note that the key names are the SIP To: tag and From: tag, so they're not something that can be controlled in Kamailio. ``` { "tags": { "iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3": { "label": "customer" }, "rtmeQtNp5vyBF": { "label": "vendor" } } } ``` The second tag there would be accessible via the `json.parse` transformation like this: ``` $vn(json) = '{"tags":{"iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3":{"label":"customer"},"rtmeQtNp5vyBF":{"label":"vendor"}}}'; $vn(ft) = "rtmeQtNp5vyBF"; $vn(ft_path) = "tags." + $vn(ft) + ".label"; $vn(ft_label) = $(vn(json){json.parse, $vn(ft_path) }); xnotice("FT Label ($vn(ft_path)): $vn(ft_label)\n"); ## output: ## NOTICE: <script>: FT Label (tags.rtmeQtNp5vyBF.label): vendor ``` However, trying to do the same thing with the first tag that contains a dot then has a problem: ``` $vn(json) = '{"tags":{"iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3":{"label":"customer"},"rtmeQtNp5vyBF":{"label":"vendor"}}}'; $vn(tt) = "iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3"; $vn(tt_path) = "tags." + $vn(tt) + ".label"; $vn(tt_label) = $(vn(json){json.parse, $vn(tt_path) }); xnotice("FT Label ($vn(tt_path)): $vn(tt_label)\n"); ## output (contains no value): ## NOTICE: <script>: FT Label (tags.iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3.label): ``` The reason for the failure is rather clear: The `.` is being interpolated as the path separator. I believe that it should be possible to quote this portion of the JSONPath, either as `tags."iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3".label` or `tags["iS.PJbHNJtW8jLJjU5Jw5bANj1rQ5Sh3"].label`, but I'm not able to find a variation that works. I will concede that the documentation for the transformation does not explicitly state JSONPath, so perhaps this is a feature add, and not a bug, however JSONPath seems to otherwise be usable here. ### Troubleshooting #### Reproduction Reproducible by example above ### Possible Solutions Allow JSONPath quoting of the string? ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -v version: kamailio 6.0.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 19:19:24 Nov 24 2025 with cc 14.2.0 ``` * **Operating System**:  ``` # cat /etc/os-release NAME="Alpine Linux" ID=alpine VERSION_ID=3.22.2 PRETTY_NAME="Alpine Linux v3.22" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues" # uname -a Linux 456b7c5e5e64 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4510 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4510(a)github.com>

3 6

[kamailio/kamailio] xhttp_prom: include global tags in user-defined metrics (PR #4575)
by Joel Serrano 06 Feb '26

06 Feb '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 - [X] Related to issue #4574 #### Description  This pull request updates the Prometheus metric label printing logic in `prom_metric.c` to ensure that global tags are always included in the metric output, even when no metric-specific labels are present. The changes also improve how global tags are appended when both user-defined labels and global tags exist. Label and tag printing improvements: * Updated `prom_label_print` to print global tags when metric-specific labels are absent, ensuring consistent inclusion of global tags in all metrics. * Modified both `prom_label_print` and `prom_label_print_le` to append global tags before closing the label braces, so that global tags are always present and correctly formatted. [[1]](diffhunk://#diff-3234c6053b9b93dc271b84392d97cc1c0900a4b4a5b1d62edf71bd48918449c3L1776-R1776) [[2]](diffhunk://#diff-3234c6053b9b93dc271b84392d97cc1c0900a4b4a5b1d62edf71bd48918449c3L1835-R1835) * Refactored `prom_metric_lvalue_print` to handle the presence of user-defined labels and global tags more robustly: when both are present, labels and tags are combined properly; when only tags are present, only tags are printed in braces. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4575 -- Commit Summary -- * xhttp_prom: include global tags in user-defined metrics -- File Changes -- M src/modules/xhttp_prom/prom_metric.c (55) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4575.patch https://github.com/kamailio/kamailio/pull/4575.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4575 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4575(a)github.com>

2 3

[kamailio/kamailio] xhttp_prom: add timestamp_format parameter (PR #4557)
by Daniel Donoghue 06 Feb '26

06 Feb '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: - [x ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description ##### Problem The default timestamp format (integer milliseconds) in xhttp_prom metrics violates the OpenMetrics specification, which requires timestamps in seconds. Monitoring systems like Grafana Alloy and Mimir reject millisecond timestamps, causing metrics ingestion failures. ##### Solution Added new module parameter `timestamp_format` with three configuration options: - **"ms"** (default): Integer milliseconds - maintains backward compatibility - **"s"**: Integer seconds - OpenMetrics compliant - **"sf"**: Seconds with fractional milliseconds - OpenMetrics compliant with sub-second precision ##### Testing - Default behavior tested (parameter omitted defaults to "ms") - All three timestamp formats validated with regex pattern matching - Backward compatibility confirmed - Module compiles cleanly with no warnings ##### Related Files - Module documentation updated in `doc/xhttp_prom_admin.xml` You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4557 -- Commit Summary -- * xhttp_prom: add timestamp_format parameter -- File Changes -- M src/modules/xhttp_prom/doc/xhttp_prom_admin.xml (70) M src/modules/xhttp_prom/prom.c (118) M src/modules/xhttp_prom/prom.h (9) M src/modules/xhttp_prom/prom_metric.c (42) M src/modules/xhttp_prom/xhttp_prom.c (61) M src/modules/xhttp_prom/xhttp_prom.h (5) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4557.patch https://github.com/kamailio/kamailio/pull/4557.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4557 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4557(a)github.com>

4 9

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev January 2026