sr-dev June 2025

sr-dev@lists.kamailio.org

23 participants
272 discussions

[kamailio/kamailio] failed alpine docker image build (Issue #4241)
by sergey-safarov 18 Nov '25

18 Nov '25

sergey-safarov created an issue (kamailio/kamailio#4241) ### Description In the GitHub Actions present Alpine Docker image build error ``` tar (child): kamailio_min-without_os_files.tar.gz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ``` https://github.com/kamailio/kamailio/actions/runs/14722992691/job/413201110… With high probability, this does not work I will work to fix this, but if possible, it will be fine to switch to use `cmake` for Alpine Docker image. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4241 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4241(a)github.com>

3 30

[kamailio/kamailio] cmake: switching deb rules (Issue #4053)
by Victor Seva 13 Nov '25

13 Nov '25

Opening this generic issue to track issues when trying to switch deb package generation to cmake: -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4053 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4053(a)github.com>

5 63

[kamailio/kamailio] alpine: failed build after libjwt-dev upgrade (Issue #4264)
by sergey-safarov 11 Nov '25

11 Nov '25

sergey-safarov created an issue (kamailio/kamailio#4264) On `alpine:edge` upgraded `libjwt-dev` from `1.17.2-r0` to `3.2.1-r0` and on now present this error in the build log. ``` make[2]: --libs: No such file or directory make[2]: --libs: No such file or directory CC (cc) [M jwt.so] jwt_mod.o jwt_mod.c: In function 'ki_jwt_generate_hdrs': jwt_mod.c:215:17: error: implicit declaration of function 'jwt_free_str'; did you mean 'jwt_alg_str'? [-Wimplicit-function-declaration] 215 | jwt_free_str(_jwt_result.s); | ^~~~~~~~~~~~ | jwt_alg_str jwt_mod.c:275:15: error: implicit declaration of function 'jwt_new' [-Wimplicit-function-declaration] 275 | ret = jwt_new(&jwt); | ^~~~~~~ jwt_mod.c:283:15: error: implicit declaration of function 'jwt_add_grant_int' [-Wimplicit-function-declaration] 283 | ret = jwt_add_grant_int(jwt, "iat", iat); | ^~~~~~~~~~~~~~~~~ jwt_mod.c:293:39: error: implicit declaration of function 'jwt_add_grant' [-Wimplicit-function-declaration] 293 | ret = jwt_add_grant(jwt, pit->name.s, pit->body.s); | ^~~~~~~~~~~~~ jwt_mod.c:311:39: error: implicit declaration of function 'jwt_add_header' [-Wimplicit-function-declaration] 311 | ret = jwt_add_header(jwt, header->name.s, header->body.s); | ^~~~~~~~~~~~~~ jwt_mod.c:313:39: error: implicit declaration of function 'jwt_add_header_int'; did you mean 'jwt_header_get'? [-Wimplicit-function-declaration] 313 | ret = jwt_add_header_int(jwt, header->name.s, lval); | ^~~~~~~~~~~~~~~~~~ | jwt_header_get jwt_mod.c:324:15: error: implicit declaration of function 'jwt_set_alg'; did you mean 'jwt_get_alg'? [-Wimplicit-function-declaration] 324 | ret = jwt_set_alg(jwt, valg, (unsigned char *)kdata.s, (size_t)kdata.len); | ^~~~~~~~~~~ | jwt_get_alg jwt_mod.c:330:25: error: implicit declaration of function 'jwt_encode_str' [-Wimplicit-function-declaration] 330 | _jwt_result.s = jwt_encode_str(jwt); | ^~~~~~~~~~~~~~ jwt_mod.c:330:23: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 330 | _jwt_result.s = jwt_encode_str(jwt); | ^ jwt_mod.c:337:9: error: implicit declaration of function 'jwt_free'; did you mean 'jwks_free'? [-Wimplicit-function-declaration] 337 | jwt_free(jwt); | ^~~~~~~~ | jwks_free jwt_mod.c: In function 'ki_jwt_verify_key': jwt_mod.c:443:9: error: unknown type name 'jwt_valid_t'; did you mean 'jwt_value_t'? 443 | jwt_valid_t *jwt_valid = NULL; | ^~~~~~~~~~~ | jwt_value_t jwt_mod.c:477:15: error: implicit declaration of function 'jwt_valid_new' [-Wimplicit-function-declaration] 477 | ret = jwt_valid_new(&jwt_valid, valg); | ^~~~~~~~~~~~~ jwt_mod.c:484:9: error: implicit declaration of function 'jwt_valid_set_headers' [-Wimplicit-function-declaration] 484 | jwt_valid_set_headers(jwt_valid, 1); | ^~~~~~~~~~~~~~~~~~~~~ jwt_mod.c:485:9: error: implicit declaration of function 'jwt_valid_set_now' [-Wimplicit-function-declaration] 485 | jwt_valid_set_now(jwt_valid, iat); | ^~~~~~~~~~~~~~~~~ jwt_mod.c:492:39: error: implicit declaration of function 'jwt_valid_add_grant' [-Wimplicit-function-declaration] 492 | ret = jwt_valid_add_grant(jwt_valid, pit->name.s, pit->body.s); | ^~~~~~~~~~~~~~~~~~~ jwt_mod.c:494:39: error: implicit declaration of function 'jwt_valid_add_grant_int' [-Wimplicit-function-declaration] 494 | ret = jwt_valid_add_grant_int(jwt_valid, pit->name.s, lval); | ^~~~~~~~~~~~~~~~~~~~~~~ jwt_mod.c:505:15: error: implicit declaration of function 'jwt_decode' [-Wimplicit-function-declaration] 505 | ret = jwt_decode( | ^~~~~~~~~~ jwt_mod.c:511:22: error: implicit declaration of function 'jwt_validate' [-Wimplicit-function-declaration] 511 | if((jwtret = jwt_validate(jwt, jwt_valid)) != JWT_VALIDATION_SUCCESS) { | ^~~~~~~~~~~~ jwt_mod.c:511:55: error: 'JWT_VALIDATION_SUCCESS' undeclared (first use in this function) 511 | if((jwtret = jwt_validate(jwt, jwt_valid)) != JWT_VALIDATION_SUCCESS) { | ^~~~~~~~~~~~~~~~~~~~~~ jwt_mod.c:511:55: note: each undeclared identifier is reported only once for each function it appears in jwt_mod.c:512:38: error: implicit declaration of function 'jwt_valid_get_status' [-Wimplicit-function-declaration] 512 | _jwt_verify_status = jwt_valid_get_status(jwt_valid); | ^~~~~~~~~~~~~~~~~~~~ jwt_mod.c:521:9: error: implicit declaration of function 'jwt_valid_free'; did you mean 'jwt_builder_free'? [-Wimplicit-function-declaration] 521 | jwt_valid_free(jwt_valid); | ^~~~~~~~~~~~~~ | jwt_builder_free make[2]: *** [../../Makefile.rules:100: jwt_mod.o] Error 1 make[1]: *** [Makefile:509: modules] Error 1 make[1]: Leaving directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-78541805e73f1ca2a220e84734090ebd606bc5e4/src' make: *** [Makefile:34: all] Error 2 >>> ERROR: kamailio: build failed >>> kamailio: Uninstalling dependencies... (1/1) Purging .makedepends-kamailio (20250527.180[501](https://github.com/sergey-safarov/kamailio/actions/runs/1…) OK: 1028 MiB in 240 packages ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4264 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4264(a)github.com>

4 7

[kamailio/kamailio] Problems with ims_ipsec_pcscf and closed tcp connections (Issue #4138)
by Atanas Bakalov 10 Nov '25

10 Nov '25

### Description Let's assume we have a MO call from UE to P-CSCF that's over ipsec. Let's assume the picked ports are like UE(6101) -> P-CSCF(6100) We have also set tcp_connection_lifetime to be 20 sec. 20 sec after INVITE connection is RST from Kamailio as expected. Then ( > 20sec later) an INVITE response comes from B side, and must be delivered to the UE. Kamailio opens a new connection and tries to establish a connection from 5060 (standard port)->6101 instead of 6100(P-CSCF) -> 6101(UE). IPSEC associations are not engaged and UE does not handle the request properly. ### Troubleshooting #### Reproduction #### Debugging Data #### Log Messages #### SIP Traffic ### Possible Solutions The IPSEC module should re-open the tcp connection if it sees it's been dropped as core module has no awareness of IPSEC. * **Operating System**: All -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4138 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4138(a)github.com>

4 4

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

10 Nov '25

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>

4 17

[kamailio/kamailio] Memory usage increases everytime tls.reload is executed (Issue #3823)
by Sebastian Denz 07 Nov '25

07 Nov '25

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

10 46

[kamailio/kamailio] branch_failure_route does not handle reply while wt_timer period (Issue #4266)
by IgorG 07 Nov '25

07 Nov '25

IgorrG created an issue (kamailio/kamailio#4266) ### Description While implementing mid-register inspired by pull request (https://github.com/kamailio/kamailio/pull/3360) we found the case when it goes impossible to handle responses for registrar servers. In case some of registrars busy and respond with 401 after 200ok received - it is not possible using any routes and configuration options to handle responses received in branch transactions. According to documentation I think that setting wt_timer should allow to absorb and handle responses on failure-route while transaction kept in memory. In fact wt_timer does not affect handling responses in any way. ![Image](https://github.com/user-attachments/assets/14feb472-91ea-4028-8780-1fee1d4ee0e8) ### Troubleshooting To reproduce this case we have configured sipp to response instant with 200ok on registration request. #### Reproduction To reproduce issue SIPP could be setup as one of the dispatcher nodes with instant 200ok reply to register. Kamailio should use following configuration snippet: https://github.com/ovoshlook/kamailio-mid-registrar-config-snippets/blob/ma… #### Log Messages REGISTER|401tm [t_lookup.c:912]: t_reply_matching(): t_reply_matching: hash 12337 label 0 branch 1 REGISTER|401tm [t_lookup.c:986]: t_reply_matching(): reply (0x7f1fc67f83a8) matched an active transaction (T=0x7f1fc0f0f740)! REGISTER|401tm [t_lookup.c:1122]: t_check_msg(): msg (0x7f1fc67f83a8) id=13/1915035 global id=13/1915035 T end=0x7f1fc0f0f740 REGISTER|401tm [t_reply.c:2363]: reply_received(): transaction found - T:0x7f1fc0f0f740 branch:1 REGISTER|401tm [t_reply.c:2376]: reply_received(): original status uas=200, uac[1]=0 local=0 is_invite=0) REGISTER|401tm [t_reply.c:1363]: t_should_relay_response(): ->>>>>>>>> T_code=200, new_code=401 REGISTER|401tm [t_reply.c:1374]: t_should_relay_response(): final reply already sent REGISTER|401tm [t_reply.c:1625]: t_should_relay_response(): finished with rps discarded - uas status: 200 ### Possible Solutions  ### Additional Information * **Kamailio Version** ``` version: kamailio 5.6.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, 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 on 16:35:08 Jun 5 2023 with gcc 10.2.1 ``` * **Operating System**: ``` No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye Linux pbxKamaTest 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4266 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4266(a)github.com>

4 7

[kamailio/kamailio] arm64 support issues (Issue #4235)
by Victor Seva 30 Oct '25

30 Oct '25

linuxmaniac created an issue (kamailio/kamailio#4235) Finally I had the time and patience to address the last issues in our deb environment. Now build flow is by _distribution/architecture_ so errors doesn't interfere in a healthy _distribution/architecture_ combination. > Follow up: same situation > > - **bookworm**: https://kamailio.sipwise.com/view/kamailiodev/job/kamailiodev-nightly-binar… > ``` > /usr/bin/make every-module group_include="kerlang" quiet=verbose > make[1]: Entering directory '/build/kamailio-6.1.0~dev1+bpo12.20250509084438.1' > /usr/bin/make -C src/ every-module > make[2]: Entering directory '/build/kamailio-6.1.0~dev1+bpo12.20250509084438.1/src' > config.mak loaded > Makefile.defs defs skipped > Makefile.defs defs skipped > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault > Makefile:16: *** Not found Erlang. Stop. > make[2]: *** [Makefile:509: modules] Error 1 > make[2]: Leaving directory '/build/kamailio-6.1.0~dev1+bpo12.20250509084438.1/src' > make[1]: *** [Makefile:34: every-module] Error 2 > make[1]: Leaving directory '/build/kamailio-6.1.0~dev1+bpo12.20250509084438.1' > make: *** [debian/rules:134: build_erlang] Error 2 > make: *** Waiting for unfinished jobs.... > ``` > > - **bionic**: https://kamailio.sipwise.com/view/kamailiodev/job/kamailiodev-nightly-binar… > ``` > gcc -shared -g -pthread -Wl,-O2 -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -rdynamic "-ldl" -Wl,-Bsymbolic-functions tls_domain.o tls_init.o tls_verify.o tls_locking.o tls_select.o tls_dump_vf.o tls_bio.o tlsa_mod.o tls_server.o tls_rpc.o tls_ct_wrq.o tls_rand.o tls_util.o tls_cfg.o tls_config.o -lm /usr/lib/aarch64-linux-gnu/libssl.a /usr/lib/aarch64-linux-gnu/libcrypto.a -o tlsa.so > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): In function `sha1_block_armv8': > (.text+0x1240): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o):(.text+0x20): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): In function `poly1305_emit_neon': > (.text+0x9a0): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): In function `sha256_block_data_order': > (.text+0xf88): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): In function `sha512_block_data_order': > (.text+0x10c8): dangerous relocation: unsupported relocation > collect2: error: ld returned 1 exit status > ../../Makefile.rules:191: recipe for target 'tlsa.so' failed > make[3]: *** [tlsa.so] Error 1 > ``` > > - **focal**: https://kamailio.sipwise.com/view/kamailiodev/job/kamailiodev-nightly-binar… > ``` > gcc -shared -g -pthread -Wl,-O2 -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -rdynamic "-ldl" -Wl,-Bsymbolic-functions tls_domain.o tls_init.o tls_verify.o tls_locking.o tls_select.o tls_dump_vf.o tls_bio.o tlsa_mod.o tls_server.o tls_rpc.o tls_ct_wrq.o tls_rand.o tls_util.o tls_cfg.o tls_config.o -lm /usr/lib/aarch64-linux-gnu/libssl.a /usr/lib/aarch64-linux-gnu/libcrypto.a -o tlsa.so > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): in function `sha1_block_armv8': > (.text+0x1240): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o):(.text+0x20): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): in function `poly1305_emit_neon': > (.text+0x9a0): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): in function `sha256_block_data_order': > (.text+0xf88): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): in function `sha512_block_data_order': > (.text+0x1108): dangerous relocation: unsupported relocation > collect2: error: ld returned 1 exit status > ``` > _Originally posted by @linuxmaniac in [#13](https://github.com/sipwise/kamailio-deb-jenkins/issues/13#issuecomment-2866741862)_ -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4235 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4235(a)github.com>

3 4

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

29 Oct '25

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.

4 3

[kamailio/kamailio] tls: Create one shared context and reuse it. (PR #3972)
by Xenofon Karamanos 24 Oct '25

24 Oct '25

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3823 #### Description  This PR aims to implement what was discussed in [mailing list](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-dev@lists.kama… regarding some `tls.reload` and increasing memory usage. It adds a new parameter `enable_shared_ctx` in `tls` module that if set to 0, preserves the old behavior and if set to 1 (other than 0 tbh), it creates a single SSL context that is being shared. This have the effect of using way less memory when initialized as well, but also minimizes (can't say it fixes the problem) the `tls.reload` memory increase. I have also added a small markdown (comparison.md) file, where some comparisons where made between enabled/disabled shared context and with/without CA file (where the initial problem was occurring by the reporter). Feedback would be necessary to verify whether this patch, acts as expected and kamailio works as intented. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3972 -- Commit Summary -- * tls: Add parameter for shared contexts * tls: Comparison for enable_shared_ctx -- File Changes -- A comparison.md (15) M src/modules/tls/tls_domain.c (172) M src/modules/tls/tls_mod.c (11) M src/modules/tls/tls_mod.h (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3972.patch https://github.com/kamailio/kamailio/pull/3972.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3972 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3972(a)github.com>

4 17

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2025