sr-dev June 2024

sr-dev@lists.kamailio.org

14 participants
217 discussions

[kamailio/kamailio] Debian package build fails for Kamailio 5.7.4 (Issue #3722)

by Alexander Bakker

### Description The Debian package build fails for Kamailio 5.7.4 because it can't find static libssl. This happens because ``LIBSSL_STATIC_SRCPATH`` is set to the wrong location in the rules file. ### Troubleshooting #### Reproduction 1. Run ``ln -s pkg/kamailio/deb/bookworm debian`` 2. Run ``make deb`` #### Output ``` gcc -shared -g -m64 -Wl,-O2 -Wl,-E -Wl,-z,relro -pthread -rdynamic "-ldl" -Wl,-Bsymbolic-functions tls_bio.o tls_cfg.o tls_config.o tls_ct_wrq.o tls_domain.o tls_dump_vf.o tls_init.o tls_locking.o tls_map.o tls_rand.o tls_rpc.o tls_select.o tls_server.o tls_util.o tls_verify.o tlsa_mod.o -lm /usr/lib64/libssl.a /usr/lib64/libcrypto.a -o tlsa.so /usr/bin/ld: cannot find /usr/lib64/libssl.a: No such file or directory /usr/bin/ld: cannot find /usr/lib64/libcrypto.a: No such file or directory collect2: error: ld returned 1 exit status make[5]: *** [../../Makefile.rules:191: tlsa.so] Error 1 ``` ### Possible Solutions An extremely hacky workaround is to patch the rules file to point ``LIBSSL_STATIC_SRCPATH`` to the right location: ``` sed -i -e "/LIBSSL_STATIC_SRCPATH/a export\\ LIBSSL_STATIC_SRCPATH=\\/usr\\/lib\\/$(uname -m)-linux-gnu" pkg/kamailio/deb/bookworm/rules ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` 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**: ``` Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm ``` ``` Linux 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3722 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3722(a)github.com>

13 hours, 55 minutes

[kamailio/kamailio] No CDR is written on failover (Issue #3254)

by Earn330

Hi, I think there is an issue with writing CDRs on failover scenarios. I have two servers with Kamailio. Both server running Debian 11 (bulleye) and latest Kamailio 5.6.1 from git. I'm using DMQ to sync dialogs and htable between these servers, so both servers have the same knowledge of dialog state. Both Kamailio uses nobind option, so I can switch a VIP from one server to the other one. This is managed with keepalived. Switching the VIP from one server the other one works fine an while a call is running I can switch the VIP. I can see that the BYE Message is handled OK after I made a switch. I can see that acc is triggered but what is missing is acc_cdr in this case. I'm using htable to fill all necessary variables to complete the CDR an I can see that all values are synced correctly. The acc_cdr is created fine if there is no failover so i think it can't be an configuration issue. Both server holds the same Kamailio configuration except the IP. `version: kamailio 5.6.1 (x86_64/linux) bfc5c2-dirty 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: bfc5c2 -dirty compiled with gcc 10.2.1` `root@voip-lab-proxy01:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye` `root@voip-lab-proxy01:~# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 38 bits physical, 48 bits virtual CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 23 Model name: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz Stepping: 10 CPU MHz: 2500.088 BogoMIPS: 5000.17 Virtualization: VT-x Hypervisor vendor: KVM Virtualization type: full L1d cache: 128 KiB L1i cache: 128 KiB L2 cache: 16 MiB L3 cache: 16 MiB NUMA node0 CPU(s): 0-3 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Mitigation; PTE Inversion; VMX EPT disabled Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown Vulnerability Meltdown: Mitigation; PTI Vulnerability Mmio stale data: Unknown: No mitigations Vulnerability Retbleed: Not affected Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni vmx ssse3 cx16 pdcm sse4_1 x2apic tsc_deadline_timer xsave hypervisor lahf_lm cpuid_fault pti tpr_shadow vnmi flexpriority vpid tsc_adjust arat arch_capabilit ies` If you need more information, please let me know. As I'm running this on a test system I can reproduce the issue at any time. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3254 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3254(a)github.com>

17 hours, 30 minutes

[kamailio/kamailio] ims_registrar_scscf: cannot build on Fedora 40 (Issue #3855)

by sergey-safarov

### Description "ims_registrar_scscf" cannot be compiled on Fedora 40 dist. ``` CC (gcc) [M ims_registrar_scscf.so] reply.o CC (gcc) [M ims_registrar_scscf.so] rerrno.o CC (gcc) [M ims_registrar_scscf.so] save.o CC (gcc) [M ims_registrar_scscf.so] server_assignment.o CC (gcc) [M ims_registrar_scscf.so] sip_msg.o CC (gcc) [M ims_registrar_scscf.so] stats.o CC (gcc) [M ims_registrar_scscf.so] userdata_parser.o userdata_parser.c: In function ‘ifc_tDefaultHandling2char’: userdata_parser.c:126:13: error: implicit declaration of function ‘strtol’; did you mean ‘strtok’? [-Wimplicit-function-declaration] 126 | r = strtol((char *)x, (char **)NULL, 10); | ^~~~~~ | strtok userdata_parser.c: In function ‘parse_spt_extension’: userdata_parser.c:411:32: error: implicit declaration of function ‘atoi’ [-Wimplicit-function-declaration] 411 | switch(atoi((char *)x)) { | ^~~~ make[2]: *** [../../Makefile.rules:100: userdata_parser.o] Error 1 make[1]: *** [Makefile:508: modules] Error 1 make[1]: Leaving directory '/root/rpmbuild/BUILD/kamailio-5.8.1/src' make: *** [Makefile:34: every-module] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.tyeQgK (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.tyeQgK (%build) ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` used modified 5.8.1 version ``` * **Operating System**: ``` [root@sbc-stage-a0 SPECS]# cat /etc/os-release NAME="Fedora Linux" VERSION="40 (Container Image)" ID=fedora VERSION_ID=40 VERSION_CODENAME="" PLATFORM_ID="platform:f40" PRETTY_NAME="Fedora Linux 40 (Container Image)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:40" DEFAULT_HOSTNAME="fedora" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=40 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=40 SUPPORT_END=2025-05-13 VARIANT="Container Image" VARIANT_ID=container ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3855 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3855(a)github.com>

3 days, 23 hours

[kamailio/kamailio] extented haproxy protocol support (PR #3731)

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 - [ ] 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 #3667 #### Description Allow creating Record-Route and Via header using destination address and port in the haproxy protocol header. PR created behalf @ivanuschak You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3731 -- Commit Summary -- * core: extented haproxy protocol parser * rr: extented haproxy protocol suppport * path: extented haproxy protocol suppport * websocket: extented haproxy protocol suppport * siptrace: extented haproxy protocol suppport -- File Changes -- M src/core/forward.h (4) M src/core/msg_translator.c (137) M src/core/parser/msg_parser.h (1) M src/core/receive.c (6) M src/core/receive.h (3) M src/core/tcp_conn.h (1) M src/core/tcp_main.c (22) M src/core/tcp_read.c (20) M src/modules/path/path.c (2) M src/modules/rr/loose.c (4) M src/modules/rr/record.c (6) M src/modules/siptrace/siptrace.c (89) M src/modules/websocket/ws_frame.c (9) M src/modules/websocket/ws_handshake.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3731.patch https://github.com/kamailio/kamailio/pull/3731.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3731 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3731(a)github.com>

3 days, 23 hours

[kamailio/kamailio] ndb_redis: Error when receiving 'MOVED' response from redis-cluster with TLS (Issue #3894)

by uv-2722

### Description Hello, I am using ndb_redis module with TLS and redis-cluster. kamailio connects to the cluster endpoint when getting data, gets a 'MOVED' response and prints below error, it does not get data from the new host. ### Troubleshooting I have verified that I can connect to the cluster endpoint and the host in 'MOVED' using redis-cli on the system that kamailio is running on. I tried to connect to a self hosted cluster without TLS, it works as expected. It also works as expected with TLS and a single redis host. #### Reproduction Connect to a redis-cluster over TLS #### Log Messages  ``` 2024-06-25T20:48:53.626708963Z 2024-06-25 20:48:53.626584 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:437]: redisc_get_server(): Hash 31807 (ra) 2024-06-25T20:48:53.626710053Z 2024-06-25 20:48:53.626600 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:440]: redisc_get_server(): Entry 31807 (ra) 2024-06-25T20:48:53.626711073Z 2024-06-25 20:48:53.626636 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:444]: redisc_get_server(): Using entry 31807 (ra) 2024-06-25T20:48:53.626712073Z 2024-06-25 20:48:53.626651 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:1030]: redisc_exec(): rsrv->ctxRedis = 0x556b4456dc20 2024-06-25T20:48:53.626713073Z 2024-06-25 20:48:53.626667 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:1036]: redisc_exec(): rsrv->ctxRedis = 0x556b4456dc20 2024-06-25T20:48:53.626810463Z 2024-06-25 20:48:53.626762 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:896]: check_cluster_reply(): Redis replied: "MOVED 3667 testdbredis-masked-hostname.00000000001110000000.130-characters-long.00000000000011111111100000000.availability-zone.amazonaws.com:6379" 2024-06-25T20:48:53.626811523Z 2024-06-25 20:48:53.626777 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:904]: check_cluster_reply(): Port "6379" [4] => 6379 2024-06-25T20:48:53.626816413Z 2024-06-25 20:48:53.626793 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:914]: check_cluster_reply(): Host "testdbredis-masked-hostname.00000000001110000000.130-characters-long.000000…" [130] 2024-06-25T20:48:53.626846113Z 2024-06-25 20:48:53.626810 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:925]: check_cluster_reply(): Name of new connection: testdbredis-masked-hostname.00000000001110000000.130-characters-long.00000000000011111111100000000. 2024-06-25T20:48:53.626851443Z 2024-06-25 20:48:53.626827 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:437]: redisc_get_server(): Hash 968070864 (testdbredis-masked-hostname.00000000001110000000.130-characters-long.00000000000011111111100000000.) 2024-06-25T20:48:53.626896173Z 2024-06-25 20:48:53.626844 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:440]: redisc_get_server(): Entry 31807 (ra) 2024-06-25T20:48:53.626897503Z 2024-06-25 20:48:53.626861 3(17) NOTICE: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:450]: redisc_get_server(): No entry found. 2024-06-25T20:48:53.626955363Z 2024-06-25 20:48:53.626877 3(17) ERROR: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:947]: check_cluster_reply(): failed to print server spec string 2024-06-25T20:48:53.626957263Z 2024-06-25 20:48:53.626893 3(17) DEBUG: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:1115]: redisc_exec(): rpl->rplRedis->type:6 2024-06-25T20:48:53.626958443Z 2024-06-25 20:48:53.626908 3(17) ERROR: {Kam 192.168.20.4 503874790_98536808 1 753067 INVITE}ndb_redis [redis_client.c:1117]: redisc_exec(): Redis error:MOVED 3667 testdbredis-masked-hostname.00000000001110000000.130-characters-long.00000000000011111111100000000.availability-zone.amazonaws.com:6379 ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.1 (x86_64/linux) 384843 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: 384843 compiled on 19:05:30 Jun 25 2024 with gcc 12.2.0 ``` * Hiredis(v1.2.0) and hiredis-cluster(v0.13.0) are installed from source, both with ssl support. * **Operating System**:  ``` Debian 12 ``` ### Kamailio config snippet ``` loadmodule "ndb_redis.so" . . # ----- ndb_redis params ----- modparam("ndb_redis", "server", "name=ra;addr=cluster.testdbredis-masked-hostname.0000000011111111100000.availability-zone.amazonaws.com;port=6379;tls=1") modparam("ndb_redis", "init_without_redis", 1) modparam("ndb_redis", "cluster", 1) modparam("ndb_redis", "allow_dynamic_nodes", 1) modparam("ndb_redis", "ca_path", "/etc/ssl/certs") modparam("ndb_redis", "debug", 1) . . redis_cmd("ra", "HMGET usr_preferences:entry::%s:%s blocked", "$rU", "$fU", "r"); if($redis(r=>value[0]) == 1) { . } ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3894 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3894(a)github.com>

4 days, 20 hours

[kamailio/kamailio] db_redis: compile issues with TLS + redis-cluster (Issue #3893)

by uv-2722

5 days, 7 hours

[kamailio/kamailio] Usrloc keepalive: Not sending OPTIONS to UDP endpoints- 5.8.0 and 5.8.1 (Issue #3844)

by Luke Escudé

Running compiled Kamailio 5.8.1 (previously 5.8.0) on Debian 12 64-bit We're seeing an issue with UDP endpoints (this issue does not happen with TCP and TLS) where usrloc will not send OPTIONS packet keepalives. Here are all of our usrloc parameters: modparam("usrloc", "db_mode", 0) modparam("usrloc", "ka_domain", "SIPDOMAIN") #-- SIPDOMAIN is a fqdn modparam("usrloc", "ka_from", "sip:proxy-ping@SIPDOMAIN") modparam("usrloc", "ka_mode", 1) modparam("usrloc", "timer_interval", 20) #-- How often to qualify endpoints and clean mem tables? modparam("usrloc", "timer_procs", 4) modparam("usrloc", "ka_randomize", 10) modparam("usrloc", "use_domain", 0) modparam("usrloc", "server_id_filter", 1) modparam("usrloc", "ka_filter", 0) modparam("usrloc", "ka_timeout", 60) #-- How quickly to expire a contact if it does not reply to keepalive? modparam("usrloc", "matching_mode", 0) modparam("usrloc", "handle_lost_tcp", 1) modparam("usrloc", "close_expired_tcp", 1) modparam("usrloc", "desc_time_order", 1) modparam("usrloc", "hash_size", 14) It seems usrloc is not actually using timer_interval at all for UDP devices. However, it does seem to be sending OPTIONS every 20 seconds on TCP/TLS. (this is confirmed via packet capture on a SIP phone). -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3844 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3844(a)github.com>

6 days, 8 hours

[kamailio/kamailio] WIP pkg: RPM packaging add kamailio-tls_wolfssl subpackage (PR #3592)

by space88man

6 days, 17 hours

[kamailio/kamailio] ims_registrar_pcscf,ims_qos: added a parameter for trusting the bottom Via header on requests (PR #3891)

by Dragos Vingarzan

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - Not yet - first let's see if the work is valid, then I'll recompose the whole work to satisfy this. Otherwise... if I need to fix something, it's too hard to work like this... - [ ] Each component has a single commit (if not, squash them into one commit) - ditto - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Normally, the IMS P-CSCF should identify the clients (UEs) by the received IP address and ports on Rx. The current code is using a mix of that, plus using Contact and Via headers, with arguable potential security issues. This patch adds a new parameter to `ims_registrar_pcscf` and `ims_qos` modules, allowing for an optional outsource of the IPsec functionality to another element, which is also in charge of checking/enforcing correct UE Via header. The existing code is allowed to work as before, with the default value of the flag being towards that. List of functional changes: - `ims_qos` - added `trust_bottom_via` parameter - List of indirect changes: - default I-CSCF config example contained a questionable line which adds a `+` as a prefix in Request-URI. After way too much time wasted to figure out why the Diameter LIR has bogus SIP or TEL URI values in UserName AVP, I have discovered this. Seems like someone had just tel-URIs in their network, but otherwise the blind addition of this prefix makes no sense to me. - added a `str2ushort()` macro, since code was using some dangerous casting and macros with a larger type - List of non-functional fixes: - spelling in comments - comments at the end of line moved above the line they refer to; with just 80 columns code-formatting, commenting on the same line provides for some super weird and hard to read code, so IMHO should not be allowed (or ... much harder now... increase to 120 columns) - You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3891 -- Commit Summary -- * squashed work -- File Changes -- M misc/examples/ims/icscf/kamailio.cfg (4) M src/core/ut.h (36) M src/lib/ims/ims_getters.c (2) M src/modules/ims_icscf/location.c (10) M src/modules/ims_qos/ims_qos_mod.c (27) M src/modules/ims_qos/ims_qos_mod.h (1) M src/modules/ims_qos/rx_aar.h (4) M src/modules/ims_qos/rx_authdata.h (2) M src/modules/ims_qos/rx_avp.c (2) M src/modules/ims_qos/rx_avp.h (1) M src/modules/ims_registrar_pcscf/doc/ims_registrar_pcscf_admin.xml (39) M src/modules/ims_registrar_pcscf/ims_registrar_pcscf_mod.c (18) M src/modules/ims_registrar_pcscf/notify.c (2) M src/modules/ims_registrar_pcscf/save.c (78) M src/modules/ims_registrar_pcscf/service_routes.c (125) M src/modules/ims_registrar_pcscf/subscribe.c (75) M src/modules/ims_registrar_pcscf/subscribe.h (4) M src/modules/ims_usrloc_pcscf/udomain.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3891.patch https://github.com/kamailio/kamailio/pull/3891.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3891 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3891(a)github.com>

1 week

[kamailio/kamailio] performance regression related to new TCP connection tracking feature with a high number of connections (Issue #3759)

by Henning Westerholt

### Description On systems with a high number of TCP sessions there can be a significant performance regression observed, probably related to the newly added TCP connection tracking feature. ### Troubleshooting #### Reproduction No special configuration is necessary, just install the latest 5.7.x release, e.g. 5.7.3 on a production system with a lot of clients connected over TCP or TLS. You need to have a large number of clients connected to be able to observe the regression. For a high number of connections (e.g. more then 20.000 up to 30.000 connections) the Kamailio servers uses about 30% to 50% more CPU as with the old version. #### Debugging Data Two graphs were attached to this issue. The first shows the CPU load before (less load) and after the upgrade (increased load). The second is a flamegraph that shows that over 80% of the CPU time is spent in the newly added function tcp_connection_limit_srcip(). <img width="372" alt="cpu-load-before-after" src="https://github.com/kamailio/kamailio/assets/6481937/ec92c41b-25e2-4847-a4bc…"> ![flamegraph](https://github.com/kamailio/kamailio/assets/6481937/5c2e3982-2d5b-4acd-a774-bad8fa64bd0a) Most of the CPU time is spend in the TCP main process, as expected. #### Log Messages No special log messages could be observed. #### SIP Traffic ### Possible Solutions The TCP limit feature should probably be optimized to not cause such a large performance regression. It should be also possible to deactivate it completly and therefore getting a comparable performance as before the feature addition. ### Additional Information Kamailio 5.7.3 and probably also git master version. * **Operating System**: Debian 11, Debian 12 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3759 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3759(a)github.com>

1 week, 3 days

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2024