sr-dev March 2024

sr-dev@lists.kamailio.org

14 participants
238 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, 50 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, 25 minutes

[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] WIP pkg: RPM packaging add kamailio-tls_wolfssl subpackage (PR #3592)

by space88man

#### 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 - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description Not for merging yet. Package tls_wolfssl as an alternative to OpenSSL 3.x. Depends on PR https://github.com/kamailio/kamailio/pull/3590 You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3592 -- Commit Summary -- * pkg: RPM packaging add kamailio-tls_wolfssl subpackage -- File Changes -- M pkg/kamailio/obs/kamailio.spec (18) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3592.patch https://github.com/kamailio/kamailio/pull/3592.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3592 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3592(a)github.com>

6 days, 17 hours

[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

[kamailio/kamailio] tcpops module event_route[tcp:closed] route block $conid is null (Issue #3767)

by liangbaolin

### Description During the process of using version 5.7.4 of Kamailio, I found that the $conid cannot be correctly obtained in the TCP: closed routing block of the TCP module event_route. I am certain that it is normal in version 5.4.8. ### Troubleshooting ``` pv [pv_core.c:2725]: pv_get_tcpconn_id() ``` #### Reproduction The test scenario initiated a register registration process for me, and after completing the disconnection of the TCP connection, triggered this event. #### Log Messages  ``` 2024-02-26T01:35:55.902002512Z 52(98) DEBUG: <core> [core/receive.c:635]: receive_msg(): cleaning up 2024-02-26T01:35:55.902034482Z 52(98) DEBUG: <core> [core/tcp_read.c:280]: tcp_read_data(): EOF on connection 0x7f99a1546a80 (state: 0, flags: c018) - FD 24, bytes 0, rd-flags 10000 ([12.0.1.6]:15821 -> [12.0.1.6]:5060)52(98) DEBUG: <core> [core/tcp_read.c:343]: tcp_read(): read 0 bytes: 2024-02-26T01:35:55.902051542Z 2024-02-26T01:35:55.902058282Z 52(98) DEBUG: <core> [core/tcp_read.c:1532]: tcp_read_req(): read= 0 bytes, parsed=0, state=0, error=1 2024-02-26T01:35:55.902063282Z 52(98) DEBUG: <core> [core/tcp_read.c:1534]: tcp_read_req(): last char=0x00, parsed msg= 2024-02-26T01:35:55.902069402Z 2024-02-26T01:35:55.902074032Z 52(98) DEBUG: <core> [core/tcp_read.c:1544]: tcp_read_req(): EOF 2024-02-26T01:35:55.902101372Z 52(98) DEBUG: <core> [core/io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0x559e8a029740, 24, -1, 0x10) fd_no=2 called 2024-02-26T01:35:55.902153162Z 52(98) DEBUG: <core> [core/tcp_read.c:1927]: handle_io(): removing from list 0x7f99a1546a80 id 2 fd 24, state 2, flags c018, main fd 134, refcnt 2 ([12.0.1.6]:15821 -> [12.0.1.6]:5060) 2024-02-26T01:35:55.902168112Z 52(98) DEBUG: <core> [core/tcp_read.c:1702]: release_tcpconn(): releasing con 0x7f99a1546a80, state -1, fd=24, id=2 ([12.0.1.6]:15821 -> [12.0.1.6]:5060) 2024-02-26T01:35:55.902173372Z 52(98) DEBUG: <core> [core/tcp_read.c:1705]: release_tcpconn(): extra_data (nil) 2024-02-26T01:35:55.902208402Z 83(129) DEBUG: <core> [core/tcp_main.c:3747]: handle_tcp_child(): reader response= 7f99a1546a80, -1 from 1 2024-02-26T01:35:55.902224742Z 83(129) DEBUG: <core> [core/tcp_main.c:3904]: handle_tcp_child(): case CONN_EOF tcp_emit_closed_event before 5 2024-02-26T01:35:55.902229802Z 83(129) DEBUG: <core> [core/tcp_main.c:3671]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) 2024-02-26T01:35:55.902318572Z 83(129) DEBUG: tcpops [tcpops.c:311]: tcpops_handle_tcp_closed(): received TCP closed event 2024-02-26T01:35:55.902331352Z 83(129) DEBUG: tcpops [tcpops.c:261]: tcpops_tcp_closed_run_route(): event reason id: 0 rt: 1 2024-02-26T01:35:55.902335132Z 83(129) ERROR: tcpops [tcpops.c:278]: tcpops_tcp_closed_run_route(): run_top_route() before tev->id: 2 2024-02-26T01:35:55.902480972Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902493872Z 83(129) DEBUG: pv [pv_core.c:2725]: pv_get_tcpconn_id(): no conid 2024-02-26T01:35:55.902498762Z 83(129) DEBUG: pv [pv_core.c:2726]: pv_get_tcpconn_id(): msg->rcv.proto_reserved1: 2 2024-02-26T01:35:55.902503592Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902508262Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 111 2024-02-26T01:35:55.902513422Z 83(129) ERROR: <script>: tcp connection closed conid: (<null>), tcp(conid): <null>, Ri: 12.0.1.185, Rp: 5060 , si: 12.0.1.6 , sp: 15821 2024-02-26T01:35:55.902607692Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902625622Z 83(129) DEBUG: pv [pv_core.c:2725]: pv_get_tcpconn_id(): no conid 2024-02-26T01:35:55.902630672Z 83(129) DEBUG: pv [pv_core.c:2726]: pv_get_tcpconn_id(): msg->rcv.proto_reserved1: 2 2024-02-26T01:35:55.902635822Z 83(129) ERROR: tcpops [tcpops.c:280]: tcpops_tcp_closed_run_route(): run_top_route() after tev->id: 2 2024-02-26T01:35:58.777642759Z 41(87) DEBUG: ims_dialog [dlg_handlers.c:2026]: print_all_dlgs(): ********************41(87) DEBUG: ims_dialog [dlg_handlers.c:2027]: print_all_dlgs(): printing 65536 dialogs ``` #### SIP Traffic  ``` my test script block event_route[tcp:closed] { xlog("L_ERR", "$proto connection closed conid: ($conid), tcp(conid): $tcp(conid), Ri: $Ri, Rp: $Rp , si: $si , sp: $sp\n"); } file: src/modules/pv/pv_core.c int pv_get_tcpconn_id(struct sip_msg *msg, pv_param_t *param, pv_value_t *res) { ... if((con = tcpconn_get(msg->rcv.proto_reserved1, 0, 0, 0, 0)) == NULL) // return false { LM_DBG("no conid\n"); //additional custom log LM_DBG("msg->rcv.proto_reserved1: %d\n",msg->rcv.proto_reserved1); return pv_get_null(msg, param, res); } .... } file: src/core/tcp_main.c struct tcp_connection *tcpconn_lookup(int id, struct ip_addr *ip, int port, union sockaddr_union *local_addr, int try_local_port, ticks_t timeout) { ... if(unlikely(c == NULL)) { c = _tcpconn_find(id, ip, port, &local_ip, local_port); // retrun c == null } ... } struct tcp_connection *_tcpconn_find( int id, struct ip_addr *ip, int port, struct ip_addr *l_ip, int l_port) { ... if(likely(id)) { hash = tcp_id_hash(id); for(c = tcpconn_id_hash[hash]; c; c = c->id_next) { //tcpconn_id_hash find c is null #ifdef EXTRA_DEBUG LM_DBG("c=%p, c->id=%d, port=%d\n", c, c->id, c->rcv.src_port); print_ip("ip=", &c->rcv.src_ip, "\n"); #endif .... } inline static int tcpconn_try_unhash(struct tcp_connection *tcpconn) { ... _tcpconn_detach(tcpconn); //executed ... lock_release(&tcpconn->write_lock); ... } static inline void _tcpconn_detach(struct tcp_connection *c) { ... tcpconn_listrm(tcpconn_id_hash[c->id_hash], c, id_next, id_prev); //remove c ... } ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) 9920d9-dirty flags: , EXTRA_DEBUGUSE_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: 9920d9 -dirty compiled on 09:59:52 Feb 26 2024 with gcc 7.5.0 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3767 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3767(a)github.com>

1 week, 3 days

[kamailio/kamailio] secsipid method to only validate signature without checking the rest of the header (Issue #3784)

by Ben Kaufman

### Description Currently secsipid has a method to sign arbitrary (json) data (`secsipid_sign`), however it has no converse method to check the signature. Currently, an attempt to check a `div` signature for example will yield a `-303` error (`SIPHdrInfo`). Rather than trying to have full parsing for every possible type of Identity header (which are likely to increase in variety), it would be good to simply check "is this signature valid by trusted key", possibly validating the `iat` timestamp as well, but without any other opinions on the header values. ### Expected behavior A feature to check only the signature of an identity header. #### Actual observed behavior Currently the `secsipid_check_` family of functions fails for non- `shaken` passport types. #### Debugging Data The following DIV identity header was generated by secsipid's `secsipid_sign()` function, so it should be possible to reverse this to validate the signature: ``` Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9kLm10c2VjLm1lL2QzYTkvQmZUeGJVTlozS1FMLnBlbSJ9.eyJkZXN0Ijp7InRuIjpbIjE2MTI1NTU0MzIxIl19LCJpYXQiOiIxNzEwMTY5MzQ1Iiwib3JpZyI6eyJ0biI6IjE1NTU3MzU5MzA5In0sImRpdiI6eyJ0biI6IjE5NTI1NTU5ODc2In19.-0QF6-u6zgAQNoAhdiETuhAu7FuRDzxmFch_cTdhcbeWvUZ60NQXxdPM-JucpOtFaEdn9wnFreAZ_6vZoc_Phg;info=<https://d.mtsec.me/d3a9/BfTxbUNZ3KQL.pem>;alg=ES256;ppt=div ``` ### Possible Solutions Because it's fairly straight forward to investigate the JWT, it's not necessary to try to account for every possible passport type, etc. The act of validating the signature is the complicated part, so a function that does only that would be convenient. ### 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**: Currently alpine linux 3.19 in a docker container, but it should be pretty reproducible everywhere. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3784 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3784(a)github.com>

1 week, 3 days

[kamailio/kamailio] Dialog DMQ sync: Timer needs fixing, firing on wrong node! (Issue #3656)

by Benoît Panizzon

Situation: Two Kamailio nodes syncing dialog profiles via DMQ Observation: When a dialog timeout is encountered, about half of the time, the timeout is triggered on the peer node not handling the dialog preventing the call to be correctly terminated and also leaving entries in the dialog database which never get deleted. https://kamailio.org/docs/modules/5.7.x/modules/dialog.html#dialog.p.enable… Makes clear, that only the node which is handling the dialog in question, can make changes not related to the dialog profiles. So when a dialog times out, it is this node which has to trigger the timeout, not any other one. When looking at the source code, it is clear, that the 'lifetime' is transmitted via DMQ dialog message to the peer nodes, which in turn arm a timer. So it is obvious, this time will trigger, sometimes before the instance handling the dialog itself triggers that timer. With some assistance of @oej I found a way to alter the JSON payload to extend the lifetime on the peer nodes: ``` route[DMQ_CAPTURE] { if(is_method("KDMQ")) { if(has_body("application/json") && $fU == 'dialog') { if (jansson_get("lifetime", $rb, "$var(lifetime)")) { $var(new_lifetime) = $var(lifetime) + 60; # Add 60 seconds on DMQ peer to make sure it expires AFTER main node. $var(newrb) = $rb; jansson_set("integer", "lifetime", $var(new_lifetime), "$var(newrb)"); set_body("$var(newrb)","application/json"); msg_apply_changes(); } } dmq_handle_message(); exit; } } ``` Testing with this config fixed the issue of the timeout firing on a peer node instead of the node handling the dialog. Issue is present in 5.5, 5.6 and after looking at the code, I assume also on 5.7 -Benoît -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3656 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3656(a)github.com>

1 week, 5 days

[kamailio/kamailio] Wrong Route header order in called party re-INVITE when using topos (Issue #3778)

by Javi Montoro

Hi There, We found a situation where topos seems to break, let me explain... Assuming the following scenario: ``` Caller ---- Callee A: ------INVITE-----> Record-Route:A.A.A.A, Record-Route:B.B.B.B B: <-----200 OK------ C: <-----INVITE------ Route: A.A.A.A, B.B.B.B D: ------200 OK-----> Record-Route:B.B.B.B, Record-Route:A.A.A.A (reversed order) E: <======INVITE===== Route: B.B.B.B, A.A.A.A (wrong) ``` A and B establish the connection from caller to callee, and topos works fine. C (re-INVITE from callee) sends the Route header according to the Record-Routes from the original INVITE (A) D is the 200 OK sent from the caller to the first re-INVITE (C) coming from the callee, with the Record-Route headers reversed, because is the order in which the callee received them; and according to the RFC it's working as intended: ``` When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. [...] [When a UAC receives a response...] The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. ``` E takes the Route order from the last 200 OK ignoring they are in reversed order and assuming the top one is the first one, when it should be the other way around, sending to an IP address not reachable from the callee. And I think here is the issue, topos should not update the path on the Record-Routes from a 200 OK but if it does, it should take the reverse order When disabling topos, everything works fine, or with topos enabled, by setting rr_update=0 works for us, but what if there is a real path update, rr_update=0 wouldn't work for us anymore. The Kamailio version is 5.8.0-rc0 Let me know if you need more information. Thanks a lot, Javi -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3778 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3778(a)github.com>

2 weeks, 3 days

[kamailio/kamailio] Kamailio became unresponsive during runtime (#2380)

by ObakeFilter

### Description Hi, I ran into an issue where the Kamailio service seemingly froze (didn't crash, but failed to receive and deliver calls) while running, I went through the logs a little bit, and saw the same log pattern (pasted below) recouring every few months or so, on an older installation (5.2.0). Usually, it ended up automatically restarting the service. But not this time, I had to reload it manually to make the service work again. Is this a known issue? How can I make sure that the service will be able to restart the next time it happens? Edward ### Troubleshooting #### Debugging Data  ``` GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/sbin/kamailio...done. warning: exec file is newer than core file. [New LWP 11413] Core was generated by `kamailio'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f4e4a52e428 in ?? () (gdb) Quit (gdb) bt full #0 0x00007f4e4a52e428 in ?? () No symbol table info available. #1 0x00007f4e4a53002a in ?? () No symbol table info available. #2 0x0000000000000020 in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. (gdb) info locals No symbol table info available. (gdb) list 1871 & now if we don't need it */ 1872 #ifdef USE_SLOW_TIMER 1873 + 1 /* slow timer process */ 1874 #endif 1875 #ifdef USE_TCP 1876 +((!tcp_disable)?( 1/* tcp main */ + tcp_listeners ):0) 1877 #endif 1878 #ifdef USE_SCTP 1879 +((!sctp_disable)?sctp_listeners:0) 1880 #endif (gdb) ``` #### Log Messages  ``` Jun 28 16:35:22 kamprodegres kamailio: INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Jun 28 16:35:22 kamprodegres kamailio: WARNING: <core> [core/socket_info.c:1394]: fix_hostname(): could not rev. resolve 70.36.25.87 Jun 28 16:35:22 kamprodegres kamailio: WARNING: <core> [core/socket_info.c:1394]: fix_hostname(): could not rev. resolve 70.36.25.87 Jun 28 16:35:22 kamprodegres kamailio: INFO: <core> [core/tcp_main.c:5042]: init_tcp(): using epoll_lt as the io watch method (auto detected) Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: jsonrpcs [jsonrpcs_sock.c:197]: jsonrpc_dgram_mod_init(): the socket /var/run/kamailio/kamailio_rpc.sock already exists, trying to delete it... Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: rr [rr_mod.c:177]: mod_init(): outbound module not available Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [main.c:2779]: main(): processes (at least): 40 - shm size: 67108864 - pkg size: 8388608 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Jun 28 16:35:22 kamprodegres kamailio[8518]: INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/8518 Jun 28 16:35:22 kamprodegres kamailio[8519]: INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Jun 29 18:13:37 kamprodegres kamailio[8513]: INFO: {1 581461 CANCEL 402954192_49936786(a)67.231.13.146} tm [t_reply.c:478]: _reply_light(): can't generate 487 reply when a final 404 was sent out Jun 29 18:27:00 kamprodegres kamailio[8508]: INFO: {1 211236 CANCEL 405019408_127896329(a)67.231.13.146} tm [t_reply.c:478]: _reply_light(): can't generate 487 reply when a final 404 was sent out Jun 29 18:51:10 kamprodegres /usr/local/sbin/kamailio[2269]: NOTICE: <core> [main.c:725]: handle_sigs(): Thank you for flying kamailio!!! Jun 29 18:51:10 kamprodegres /usr/local/sbin/kamailio[2326]: INFO: <core> [main.c:847]: sig_usr(): signal 15 received ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.2 (x86_64/linux) 7ba545 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_BLACKLIST, HAVE_RESOLV_RES 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: 7ba545 compiled on 16:37:32 Jun 14 2020 with gcc 5.4.0 ``` * **Operating System**:  ``` Ubuntu 16.04 ``` -- 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/2380

2 weeks, 4 days

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2024