sr-dev March 2026

sr-dev@lists.kamailio.org

35 participants
467 discussions

[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

[kamailio/kamailio] Kamailio 5.4.x dialog profiles functionality dead-lock on certain high-load scenarios (Issue #2923)
by Henning Westerholt 03 Apr '26

03 Apr '26

### Description The Kamailio 5.4.x dialog profiles functionality can lead to dead-lock on certain high-load scenarios. The Kamailio dialog profiles are used to track parallel channels for about 200 outgoing PSTN carrier interconnections. During high traffic times (like several thousands parallel calls) the Kamailio server will frequently (e.g. hourly) goes into an end-less loop while executing get_profile_size in the configuration script. This causes the locking for the dialog profiles never be released and Kamailio will stop serving traffic. Internal monitoring tools and RPC commands stay working, as long as they do not touch the dialog functionality. A similar (dedicated) Kamailio setup is used for tracking parallel channels for customers. Here the dead-lock is not observed that frequently, but aparentely also some crashes happens in a much longer time interval. ### Troubleshooting After analysis of the back-traces with GDB the get_profile_size() function was removed from the configuration script. After this change the crash did not happened anymore for several days. #### Reproduction Issue could not be reproduced so far. #### Debugging Data ##### bt 1 (some data removed) (gdb) bt \# 0 0x00007f57cf3b00da in get_profile_size (profile=0x7f50ccbc7e80, value=0x7ffd9928f300) at dlg_profile.c:859 n = 364 i = 12 ph = 0x7f50d3e4b7d0 \# 1 0x00007f57cf419c67 in w_get_profile_size_helper (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7ffd9928f300, spd=0x7f57d6916960) at dialog.c:941 \# 2 0x00007f57cf41a459 in w_get_profile_size3 (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7f57d6935118, result=0x7f57d6916960) at dialog.c:982 \# 3 0x0000000000463fea in do_action (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1094 \# 4 0x00000000004711ee in run_actions (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1581 \# 5 0x000000000046058b in do_action (h=0x7ffd99293610, a=0x7f57d690fda8, msg=0x7f57d699d418) at core/action.c:700 The first back-trace was taking from a running process with gdb. The counter in f0 does not increased that much during this time, probably due the overflow of the loop counter. ##### bt2 (analysis with data structure with gdb scripts) Here the loop counter in f0 showed a really high value. Expected size of dialog profiles hash table: (gdb) p profile->entries[3] $4 = {first = 0x7f9bfd4aad98, content = 2068} (gdb) p profile->entries[7] $3 = {first = 0x7f9c12079f70, content = 784} (gdb) p profile->entries[12] $6 = {first = 0x7f9c02be5d50, content = 7600} (gdb) p profile->entries[14] $2 = {first = 0x7f9bff636de8, content = 6764} hash table bucket 14 shows a lot of corruption and the loop never ends (carrier names and IPs replaced). The list for hash bucket 7 got linked to the list for hash bucket 14: counter 6755: prev 0x7f9c0b9dcde0 - current 0x7f9c02e5b378 - next 0x7f9c0a5f9ba0 - value carrier1-XX.XX - hash 14 counter 6756: prev 0x7f9c02e5b378 - current 0x7f9c0a5f9ba0 - next 0x7f9c0860b968 - value carrier1-XX.XX▒▒▒▒ - hash 14 counter 6757: prev 0x7f9c0a5f9ba0 - current 0x7f9c0860b968 - next 0x7f9bfe3f3a78 - value carrier1-XX.XX▒▒▒▒ - hash 14 counter 6758: prev 0x7f9c0860b968 - current 0x7f9bfe3f3a78 - next 0x7f9c10d977f0 - value carrier1-XX.XX - hash 14 counter 6759: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 6760: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7 counter 6761: prev 0x7f9c0ae198b0 - current 0x7f9c12079f70 - next 0x7f9c011f2540 - value-carrier2-XX.XX▒▒▒▒ - hash 7 counter 6762: prev 0x7f9c12079f70 - current 0x7f9c011f2540 - next 0x7f9bfff886f0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 6763: prev 0x7f9c011f2540 - current 0x7f9bfff886f0 - next 0x7f9c05db00a8 - value carrier3-XX.XX= - hash 7 [...] counter 28270: prev 0x7f9c019d06e8 - current 0x7f9bfaf18290 - next 0x7f9c12c90680 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 28271: prev 0x7f9bfaf18290 - current 0x7f9c12c90680 - next 0x7f9c086a2b58 - value-carrier2-XX.XX▒▒▒▒ - hash 7 counter 28272: prev 0x7f9c12c90680 - current 0x7f9c086a2b58 - next 0x7f9c0b4f09e8 - value carrier2-XX.XX▒▒▒▒ - hash 7 [...] hash table bucket 7 is still consistent regarding the loop, but already shows initial sign of corruption. There is one item of the list for hash bucket 14 visible: counter 780: prev 0x7f9c0db57ac8 - current 0x7f9c02225700 - next 0x7f9bfbf7db08 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 781: prev 0x7f9c02225700 - current 0x7f9bfbf7db08 - next 0x7f9c10d977f0 - value carrier1-XX.XX- hash 14 counter 782: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 783: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7 total size of hash table is 784 #### Log Messages No special log messages observed. #### SIP Traffic SIP traffic looked ok during analysis of the core dumps. ### Possible Solutions * adding additional safe-guards for the get_profile_size function to not access data from other hash buckets * stopping the loop counter after some threshold * finding and fixing the source of the internal data corruption (obviously) * refactoring the dialog modules to use another approach for storing the dialog profile information ### Additional Information * **Kamailio version**: Kamailio 5.4.7, compiled from git repository * **Operating System**: CentOS 7.9 -- 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/2923

3 8

[kamailio/kamailio] event_route[network:msg] cannot read network variables like $si and $Ri (Issue #4673)
by rodrigodc 03 Apr '26

03 Apr '26

rodrigodc created an issue (kamailio/kamailio#4673) ### Description I have tried using [event_route[network:msg]](https://www.kamailio.org/docs/modules/5.2.x/modul… to intercept raw incoming and outgoing messages. I need to handle those messages conditionally, based on the source IP address where they came from (incoming messages), or the destination IP address they are going to (outgoing messages). So, I tried using `$si` from event_route[network:msg], but that didn't work because that variable **seems to be empty** when `event_route[network:msg]` runs. The same happens with other network-related variables like $Ri, etc. Is that expected behavior? ### Troubleshooting #### Reproduction Run the following code: ``` # enable network io interception loadmodule "corex"; modparam("corex", "nio_intercept", 1); # try to access $si (or any network related variable) from event_route[network:msg] event_route[network:msg] { xlog("si=$si Ri=$Ri\n"); } ``` It turns out the output shows that `$si` and `$Ri` are both empty. ### Possible Solutions I have also tried using [src_ip](https://www.kamailio.org/wikidocs/cookbooks/6.1.x/core/#src_ip) and related, but that also does not seem to work (presumably because the information might not yet availble at the time `event_route[network:msg]` runs). ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 6.1.0 (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, DBG_QM_MALLOC, DBG_F_MALLOC, DBG_TLSF_MALLOC, USE_FUTEX, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED 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. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**: ``` Linux localhost 6.1.0-44-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.164-1 (2026-03-09) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4673 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4673(a)github.com>

4 6

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

01 Apr '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 26

[kamailio/kamailio] Allow customizing the contact user in uac reg requests (Issue #4653)
by Flavio Grossi 01 Apr '26

01 Apr '26

flaviogrossi created an issue (kamailio/kamailio#4653) ### Description Currently the uac module uses the value of the `l_uuid` variable as the user part in the contact header for the REGISTER request. Some providers, especially when registering trunks, requires the user part to be the registration username though, and, while it is possible to do it using the config, it may get cumbersome and error prone to remap the contact back in the reply. ### Expected behavior To be able to customize the contact in the register #### Actual observed behavior The register hardcodes the `l_uuid` value in the register, see [here](https://github.com/kamailio/kamailio/blob/d9a05f9781d2d9cddf485e938ea… This causes the registration to never be in the registered status when it is queried via the reg_dump rpc, unless the contact is rewritten via config both in the request (to make the SIP provider happy) and in the reply (to replace it back to use the uuid so that the check [here](https://github.com/kamailio/kamailio/blob/d9a05f9781d2d9cddf485e938ea… matches). ### Possible Solutions I'm currently testing a patch which: - adds an optional new field `contact_user` which, if present, is used in the contact user part instead of the uuid; - adds to the outgoing REGISTER the contact parameter `line=<l_uuid>` (only when `contact_user` is configured, returns an error if `contact_addr` already contains a line parameter to avoid it to be silently overwritten) - the REGISTER reply match is extended to check the uuid in the line parameter instead of the user part (only if `contact_user` is configured) to select the correct binding. This means that if the new parameter is configured, the contact will be in the form `sip:<contact_user>@<contact_addr>;line=<l_uuid>`. If not, the usual `sip:<l_uuid>@<contact_addr>` is sent. This should allow the new feature while also being retro compatible. Do you think this is correct? Any feedback? If it is, i can send a PR for review. ### Additional Information This applies to the latest develop version of kamailio and is OS independent -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4653 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4653(a)github.com>

2 3

git:master:ae6727a7: tls_wolfssl: fix typos and formatting in doc
by S-P Chan 31 Mar '26

31 Mar '26

Module: kamailio Branch: master Commit: ae6727a706156572117e66da497d7739ff170f95 URL: https://github.com/kamailio/kamailio/commit/ae6727a706156572117e66da497d773… Author: S-P Chan <shihping.chan(a)gmail.com> Committer: S-P Chan <shihping.chan(a)gmail.com> Date: 2026-04-01T07:45:56+08:00 tls_wolfssl: fix typos and formatting in doc --- Modified: src/modules/tls_wolfssl/doc/tls_wolfssl.xml --- Diff: https://github.com/kamailio/kamailio/commit/ae6727a706156572117e66da497d773… Patch: https://github.com/kamailio/kamailio/commit/ae6727a706156572117e66da497d773… --- diff --git a/src/modules/tls_wolfssl/doc/tls_wolfssl.xml b/src/modules/tls_wolfssl/doc/tls_wolfssl.xml index 6f013c37043..e8a2c4deff8 100644 --- a/src/modules/tls_wolfssl/doc/tls_wolfssl.xml +++ b/src/modules/tls_wolfssl/doc/tls_wolfssl.xml @@ -42,7 +42,7 @@ with the <emphasis>tls</emphasis> module. </para> <para> - Is is highly recommended to run this module with MT-mode (<code>tcp_main_threads = 1</code>). + It is highly recommended to run this module with MT-mode (<code>tcp_main_threads = 1</code>). </para> <para> This module is derived from the &tls-url; @@ -68,11 +68,13 @@ <example> <title>Quick Start Basic Config</title> <programlisting> - #... - loadmodule "sl.so" - loadmodule "tls_wolfssl.so" - #... refer to Quick Start of tls module - #... for further configuration +... +#... +loadmodule "sl.so" +loadmodule "tls_wolfssl.so" +#... refer to Quick Start of tls module +#... for further configuration +... </programlisting> </example> </section> @@ -86,11 +88,14 @@ <para>Kamailio shared memory allocators, used in MP-mode(<code>tcp_main_threads = 0</code>), support 16-byte alignment - it is possible to use this module with either the internal submodule or distro provided packages. For reference the ideal build flags are: + <programlisting> +... # - this assumes the allocators are 16-byte aligned # - Debian currently does not use -DWOLF_CRYPTO_CB_RSA_PAD: this affects use of RSA # padding mechanisms on HSMs EXTRA_CFLAGS="-g -O2 -DWOLF_CRYPTO_CB_RSA_PAD" ./configure --enable-distro --enable-pkcs11 +... </programlisting> </para> </section> @@ -104,15 +109,19 @@ EXTRA_CFLAGS="-g -O2 -DWOLF_CRYPTO_CB_RSA_PAD" ./configure --enable-distro --ena </para> <para> In most case compiling the wolfSSL TLS module is as simple as: + <programlisting> - make -C modules/tls_wolfssl - # to use the internal git submodule - make -C src WOLFSSL_INTERNAL=yes module_group_more="tls_wolfssl" group_include=more every-module - # cmake - cd build; make tls_wolfssl - cd build; make WOLFSSL_INTERNAL=ON tls_wolfssl +... +make -C modules/tls_wolfssl +# to use the internal git submodule +make -C src WOLFSSL_INTERNAL=yes module_group_more="tls_wolfssl" group_include=more every-module +# cmake +cd build; make tls_wolfssl +cd build; make WOLFSSL_INTERNAL=ON tls_wolfssl +... </programlisting> - </para> + + </para> </section> <section id="tls.pkcs11"> <sectioninfo></sectioninfo> @@ -124,9 +133,10 @@ EXTRA_CFLAGS="-g -O2 -DWOLF_CRYPTO_CB_RSA_PAD" ./configure --enable-distro --ena The key naming convention for keys follows a PKCS#11-URI-like style: <programlisting> ... -# in tls.cfg these pseudo-file names to refer to PKCS#11 keys; this format -# is not conformant to RFC 7512 +# - in tls.cfg these pseudo-file names to refer to PKCS#11 keys +# - this format is not entirely conformant with RFC 7512 private_key = /uri:pkcs11:module=/usr/lib64/libsoftokn3.so;token=MyToken;object=MyPrivateKey;pin=12345678 +... </programlisting> The string value itself cannot contain spaces so, e.g <code>token=NSS%20Certificate%20DB</code>,

1 0

git:6.1:bc491917: ims_ocs: Fix typos in comments
by Xenofon Karamanos 31 Mar '26

31 Mar '26

Module: kamailio Branch: 6.1 Commit: bc4919177557a48f697d85aa9d7f6def826dc7e4 URL: https://github.com/kamailio/kamailio/commit/bc4919177557a48f697d85aa9d7f6de… Author: Xenofon Karamanos <xk(a)gilawa.com> Committer: Xenofon Karamanos <xk(a)gilawa.com> Date: 2026-03-31T16:53:32Z ims_ocs: Fix typos in comments (cherry picked from commit 0eb01e0515c84314b0b7e334b348b331afeaf233) --- Modified: src/modules/ims_ocs/ocs_avp_helper.c --- Diff: https://github.com/kamailio/kamailio/commit/bc4919177557a48f697d85aa9d7f6de… Patch: https://github.com/kamailio/kamailio/commit/bc4919177557a48f697d85aa9d7f6de… --- diff --git a/src/modules/ims_ocs/ocs_avp_helper.c b/src/modules/ims_ocs/ocs_avp_helper.c index 378b2a209bc..18b143a60ad 100644 --- a/src/modules/ims_ocs/ocs_avp_helper.c +++ b/src/modules/ims_ocs/ocs_avp_helper.c @@ -29,9 +29,9 @@ /** * Returns the value of a certain AVP from a Diameter message. - * @param m - Diameter message to look into + * @param msg - Diameter message to look into * @param avp_code - the code to search for - * @param vendorid - the value of the vendor id to look for or 0 if none + * @param vendor_id - the value of the vendor id to look for or 0 if none * @param func - the name of the calling function, for debugging purposes * @returns the str with the payload on success or an empty string on failure */

1 0

git:6.1:612dc997: ims_ocs: Add memory check
by Xenofon Karamanos 31 Mar '26

31 Mar '26

Module: kamailio Branch: 6.1 Commit: 612dc997579fa5e2f37deb7345705e2003a3a0ff URL: https://github.com/kamailio/kamailio/commit/612dc997579fa5e2f37deb7345705e2… Author: Xenofon Karamanos <xk(a)gilawa.com> Committer: Xenofon Karamanos <xk(a)gilawa.com> Date: 2026-03-31T16:53:32Z ims_ocs: Add memory check (cherry picked from commit 53b47f5be5961dfca0142c74d549f7de5ce768b8) --- Modified: src/modules/ims_ocs/ims_ocs_mod.c --- Diff: https://github.com/kamailio/kamailio/commit/612dc997579fa5e2f37deb7345705e2… Patch: https://github.com/kamailio/kamailio/commit/612dc997579fa5e2f37deb7345705e2… --- diff --git a/src/modules/ims_ocs/ims_ocs_mod.c b/src/modules/ims_ocs/ims_ocs_mod.c index d8aed134762..44aa77ea56c 100644 --- a/src/modules/ims_ocs/ims_ocs_mod.c +++ b/src/modules/ims_ocs/ims_ocs_mod.c @@ -96,6 +96,10 @@ static int mod_init(void) callback_singleton = shm_malloc(sizeof(int)); + if(callback_singleton == 0) { + LM_ERR("No shared memory left\n"); + goto error; + } *callback_singleton = 0; cdp_avp = 0; @@ -113,6 +117,10 @@ static int mod_init(void) return 0; error: + /* clean up */ + if(callback_singleton) { + shm_free(callback_singleton); + } LM_ERR("Failed to initialise ims_ocs module\n"); return -1; }

1 0

git:6.1:b886b662: ims_ocs: Free after copying the values
by Xenofon Karamanos 31 Mar '26

31 Mar '26

Module: kamailio Branch: 6.1 Commit: b886b6623dec905b817bfc4c09e095ce1f582312 URL: https://github.com/kamailio/kamailio/commit/b886b6623dec905b817bfc4c09e095c… Author: Xenofon Karamanos <xk(a)gilawa.com> Committer: Xenofon Karamanos <xk(a)gilawa.com> Date: 2026-03-31T16:53:32Z ims_ocs: Free after copying the values - Remove extra freeavplist call - Add len check (cherry picked from commit a56942affd35d41890c23f1d3b5bb519f87ef5ad) --- Modified: src/modules/ims_ocs/ocs_avp_helper.c --- Diff: https://github.com/kamailio/kamailio/commit/b886b6623dec905b817bfc4c09e095c… Patch: https://github.com/kamailio/kamailio/commit/b886b6623dec905b817bfc4c09e095c… --- diff --git a/src/modules/ims_ocs/ocs_avp_helper.c b/src/modules/ims_ocs/ocs_avp_helper.c index f350a79a12b..378b2a209bc 100644 --- a/src/modules/ims_ocs/ocs_avp_helper.c +++ b/src/modules/ims_ocs/ocs_avp_helper.c @@ -208,8 +208,7 @@ int getUnits(AAAMessage *msg, int *used, int *service, int *group) list2 = cdp_avp->cdp->AAAUngroupAVPS(req_units->data); value = cdpb.AAAFindMatchingAVPList( list2, list2.head, AVP_CC_Time, 0, 0); - cdpb.AAAFreeAVPList(&list2); - if(value) + if(value && value->data.len >= 4) units = get_4bytes(value->data.s); cdpb.AAAFreeAVPList(&list2); }

1 0

git:6.0:038f72a5: ims_ocs: Fix typos in comments
by Xenofon Karamanos 31 Mar '26

31 Mar '26

Module: kamailio Branch: 6.0 Commit: 038f72a54ac887a1ec3f060ed7c50a740119b7e8 URL: https://github.com/kamailio/kamailio/commit/038f72a54ac887a1ec3f060ed7c50a7… Author: Xenofon Karamanos <xk(a)gilawa.com> Committer: Xenofon Karamanos <xk(a)gilawa.com> Date: 2026-03-31T16:53:30Z ims_ocs: Fix typos in comments (cherry picked from commit 0eb01e0515c84314b0b7e334b348b331afeaf233) --- Modified: src/modules/ims_ocs/ocs_avp_helper.c --- Diff: https://github.com/kamailio/kamailio/commit/038f72a54ac887a1ec3f060ed7c50a7… Patch: https://github.com/kamailio/kamailio/commit/038f72a54ac887a1ec3f060ed7c50a7… --- diff --git a/src/modules/ims_ocs/ocs_avp_helper.c b/src/modules/ims_ocs/ocs_avp_helper.c index 378b2a209bc..18b143a60ad 100644 --- a/src/modules/ims_ocs/ocs_avp_helper.c +++ b/src/modules/ims_ocs/ocs_avp_helper.c @@ -29,9 +29,9 @@ /** * Returns the value of a certain AVP from a Diameter message. - * @param m - Diameter message to look into + * @param msg - Diameter message to look into * @param avp_code - the code to search for - * @param vendorid - the value of the vendor id to look for or 0 if none + * @param vendor_id - the value of the vendor id to look for or 0 if none * @param func - the name of the calling function, for debugging purposes * @returns the str with the payload on success or an empty string on failure */

1 0

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