sr-dev December 2024

sr-dev@lists.kamailio.org

17 participants
343 discussions

[kamailio/kamailio] app_python3: evaluate LIBS variable imediately in Makefile (PR #4085)

by sergey-safarov

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description latest `make` version does not evaluate variables immediately. PR explicitly evaluates the LIBS makefile variable. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4085 -- Commit Summary -- * app_python3: evaluate LIBS variable imediately in Makefile -- File Changes -- M src/modules/app_python3/Makefile (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4085.patch https://github.com/kamailio/kamailio/pull/4085.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4085 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4085(a)github.com>

1 week, 1 day

[kamailio/kamailio] cmake: switching deb rules (Issue #4053)

by Victor Seva

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>

1 week, 1 day

[kamailio/kamailio] The future of internal libraries (Issue #4041)

by Daniel-Constantin Mierla

Considering that it hasn't been much activity around the internal libraries for long time, I was wondering if it still makes sense to keep them like they are or merge them in the core. Recently, during the devel meeting, I relocated a couple of them to the archive. The `lib/binrpc` (and `print`) can have the same fate, being not actually used. The srdb1 is very common and I guess it is very rare the case when a deployment is used without a module not depending on it (e.g., even if dispatcher is used with a list file, the code is still linked to this library). The `trie` library is small and `ims` is actually a set of getter functions for message attribtues/headers. The `srdb2` is not used much, but I think the right approach for it is to change the modules using it to `libsrdb1` and get rid of it completely sometime in the future. Till then the code is not big and can reside as part of the core. The benefits I see are in simplifying the build system (current makefiles and hopefully soon-to-be-merged the one based on cmake), reducing also the time to compute compile and link dependencies; getting rid of packaging complexity (same library may be needed by different modules, which, when packaged separately, the library has to be in a 3rd package, or have dependency of the other module's package -- probably now the libs are shipped with the core package). The code for libs can stay at the same location, so source code for modules doesn't need to be updated, just that they are compiled with the core, removing internal libs from makefiles. Thinking that we go for 6.0.x, clarifying the plans for this component and cleaning it, if decided so, should fit well in such version number jump. Opinions? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4041 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4041(a)github.com>

1 week, 2 days

[kamailio/kamailio] Unexpected return code from route with switch-case block (Issue #4088)

by Marat

### Description I see unexpected return code from route if there is no explicit `return` and switch-case block.  #### Reproduction Here is simple configuration part: ``` route(TEST_ROUTE_WITH_SWITCH); xlog("L_WARN", "TEST_ROUTE_WITH_SWITCH result $rc\n"); ... route[TEST_ROUTE_WITH_SWITCH] { $var(a) = "a"; switch ($var(a)) { case "a": case "b": $var(b) = $var(a); break; default: $var(c) = $var(a); } # must be optional according to documentation: # https://www.kamailio.org/wiki/cookbooks/5.3.x/core#return # > If no value is specified, or a route reaches its end without executing a return statement, it returns 1. # # return 1; } ``` Log: ``` WARNING: <script>: TEST_ROUTE_WITH_SWITCH result 0 ``` At the same time if there is no switch-block, return code is 1 as expected: ``` route[TEST_ROUTE_WITH_SWITCH] { $var(a) = "a"; } ``` Log: ``` WARNING: <script>: TEST_ROUTE_WITH_SWITCH w/o switch-case result 1 ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` $ ./build/sbin/kamailio -v version: kamailio 5.7.5 (x86_64/linux) b47500-dirty 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: b47500 -dirty compiled on 22:02:13 Nov 9 2024 with /usr/bin/gcc 11.3.1 ``` * **Operating System**:  ``` Oracle Linux 9 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4088 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4088(a)github.com>

1 week, 4 days

[kamailio/kamailio] Module dispatcher: ds_is_active() return incorrect. (Issue #4001)

by Minh Vũ

#### Kamailo 5.8 ### Description I use ```ds_is_active function()``` in ```dispatcher``` module. ``` $var(sip_url) = $sht(conf_fs=>$var(conf_id)); # sip:192.168.1.44:5060 if(ds_is_active("1", "$var(sip_url)")){ #### is allways run } ``` or ```ds_is_active("1", $var(sip_url))``` #### Debugging Data When I check dispatcher: ``` "DEST": { "URI": "sip:192.168.1.44:5060", "FLAGS": "IP", "PRIORITY": 0, "ATTRS": { "BODY": "rweight=50;weight=50;cc=1", "DUID": null, "MAXLOAD": 0, "WEIGHT": 50, "RWEIGHT": 50, "SOCKET": null, "SOCKNAME": null, "OBPROXY": null } } ``` Why is the flag set to ```IP```, but ```ds_is_active()``` returns true? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4001 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4001(a)github.com>

1 week, 5 days

[kamailio/kamailio] Memory usage increases everytime tls.reload is executed (Issue #3823)

by Sebastian Denz

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

1 week, 5 days

[kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)

by space88man

### Description From the cmake timeline 3.0(2014) is called "modern cmake" and ~3.12/3.13(2018) is "more modern cmake" : https://www.youtube.com/watch?v=y7ndUhdQuU8 Since we are doing a major renovation on the kamailio build system should we target the "more modern" generation (that is already > 5 years old). This will encourage the project to follow cmake best practices. Ping @xkaraman @miconda Versions in debian: buster(3.13) bullseye(3.25) bookworm/trixie(3.30) -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4078(a)github.com>

2 weeks, 1 day

[kamailio/kamailio] kamcmd tls.reload problem (Issue #4033)

by ynasida

Hello, I am using letsencrypt cert and key and do not want to restart kamailio every 3 months to load new ones. I know that there is: kamcmd tls.reload method but it has an error for me. error: 500 - Error while fixing TLS configuration (consult server log) I am checking the logs and see: kamailio[3865480]: INFO: tls [tls_domain.c:345]: ksr_tls_fill_missing(): TLSs<default>: tls_method=3 kamailio[3865480]: INFO: tls [tls_domain.c:357]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/certs/my_cert.crt' kamailio[3865480]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' kamailio[3865480]: INFO: tls [tls_domain.c:371]: ksr_tls_fill_missing(): TLSs<default>: ca_path='(null)' kamailio[3865480]: INFO: tls [tls_domain.c:378]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' kamailio[3865480]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing(): TLSs<default>: require_certificate=0 kamailio[3865480]: INFO: tls [tls_domain.c:390]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' kamailio[3865480]: INFO: tls [tls_domain.c:397]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/certs/private.key' kamailio[3865480]: INFO: tls [tls_domain.c:401]: ksr_tls_fill_missing(): TLSs<default>: verify_certificate=0 kamailio[3865480]: INFO: tls [tls_domain.c:406]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 kamailio[3865480]: INFO: tls [tls_domain.c:410]: ksr_tls_fill_missing(): TLSs<default>: verify_client=0 kamailio[3865480]: NOTICE: tls [tls_domain.c:1168]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... kamailio[3865480]: ERROR: tls [tls_domain.c:590]: load_cert(): TLSs<default>: Unable to load certificate file '/etc/kamailio/certs/my_cert.crt' kamailio[3865480]: ERROR: tls [tls_util.h:49]: tls_err_ret(): load_cert:error:03000072:digital envelope routines::decode error (sni: unknown) kamailio[3865480]: ERROR: tls [tls_util.h:49]: tls_err_ret(): load_cert:error:0A00018F:SSL routines::ee key too small (sni: unknown) Any advice ? It's interesting that there are not any TLS errors in case I restart kamailio. I can make TLS calls without problems. deb 12.5 version: kamailio 5.7.4 (x86_64/linux) -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4033 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4033(a)github.com>

2 weeks, 1 day

[kamailio/kamailio] Close parenthesis on error description (#2589)

by Javier Valencia

Close parentheses on error description when *Not enough parameters* on *htable_rpc_delete*. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2589 -- Commit Summary -- * Close parenthesis on error description -- File Changes -- M src/modules/htable/htable.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2589.patch https://github.com/kamailio/kamailio/pull/2589.diff -- 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/pull/2589

2 weeks, 1 day

[kamailio/kamailio] cmake - make clean deletes readme files from modules source folders (Issue #4084)

by Daniel-Constantin Mierla

Executing `make clean` in the `build` folder deletes the `README` files from the modules folders. This is probably because the README is an output of a `cmake-make` command. What would be the best option to skip this removing? I found: - https://stackoverflow.com/questions/6259372/cmake-preventing-make-clean-fro… Which indicates adding: ``` SET_DIRECTORY_PROPERTIES(PROPERTIES CLEAN_NO_CUSTOM 1) ``` In the CMakeLists.txt inside the module folders. But maybe it is another place where it can be done once for all modules, or another option... -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4084 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4084(a)github.com>

2 weeks, 2 days

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev December 2024