sr-dev February 2024

sr-dev@lists.kamailio.org

19 participants
250 discussions

[kamailio/kamailio] ndb_reids module in event_route[tcp:closed] route block error: "no redis context for server" (Issue #3768)
by liangbaolin 25 Apr '24

25 Apr '24

### Description The process of using kamailio prompts the following error： ERROR: ndb_redis [redis_client.c:963]: redisc_exec(): no redis context for server: srvN I did not encounter similar errors in version 5.4.8, and there were no similar errors in other routing blocks. Suspect that the new core version has unknown logical issues with the routing block of the module in event_route.  #### Log Messages  ``` 2024-02-26T03:39:11.161557654Z 51(97) DEBUG: <core> [core/tcp_read.c:280]: tcp_read_data(): EOF on connection 0x7f24539006a0 (state: 0, flags: c018) - FD 24, bytes 0, rd-flags 10000 ([12.0.1.6]:22827 -> [12.0.1.6]:5060)51(97) DEBUG: <core> [core/tcp_read.c:343]: tcp_read(): read 0 bytes: 2024-02-26T03:39:11.161563494Z 2024-02-26T03:39:11.161567864Z 51(97) DEBUG: <core> [core/tcp_read.c:1532]: tcp_read_req(): read= 0 bytes, parsed=0, state=0, error=1 2024-02-26T03:39:11.161574144Z 51(97) DEBUG: <core> [core/tcp_read.c:1534]: tcp_read_req(): last char=0x00, parsed msg= 2024-02-26T03:39:11.161579134Z 2024-02-26T03:39:11.161584594Z 51(97) DEBUG: <core> [core/tcp_read.c:1544]: tcp_read_req(): EOF 2024-02-26T03:39:11.161598914Z 51(97) DEBUG: <core> [core/io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0x563e1ce29740, 24, -1, 0x10) fd_no=2 called 2024-02-26T03:39:11.161604494Z 51(97) DEBUG: <core> [core/tcp_read.c:1927]: handle_io(): removing from list 0x7f24539006a0 id 1 fd 24, state 2, flags c018, main fd 132, refcnt 2 ([12.0.1.6]:22827 -> [12.0.1.6]:5060) 2024-02-26T03:39:11.161610294Z 51(97) DEBUG: <core> [core/tcp_read.c:1702]: release_tcpconn(): releasing con 0x7f24539006a0, state -1, fd=24, id=1 ([12.0.1.6]:22827 -> [12.0.1.6]:5060) 2024-02-26T03:39:11.161615934Z 51(97) DEBUG: <core> [core/tcp_read.c:1705]: release_tcpconn(): extra_data (nil) 2024-02-26T03:39:11.162263374Z 83(129) DEBUG: <core> [core/tcp_main.c:3747]: handle_tcp_child(): reader response= 7f24539006a0, -1 from 0 2024-02-26T03:39:11.162286594Z 83(129) DEBUG: <core> [core/tcp_main.c:3671]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) 2024-02-26T03:39:11.162293034Z 83(129) DEBUG: tcpops [tcpops.c:311]: tcpops_handle_tcp_closed(): received TCP closed event 2024-02-26T03:39:11.162299134Z 83(129) DEBUG: tcpops [tcpops.c:261]: tcpops_tcp_closed_run_route(): event reason id: 0 rt: 1 2024-02-26T03:39:11.162304234Z 83(129) ERROR: tcpops [tcpops.c:278]: tcpops_tcp_closed_run_route(): run_top_route() before tev->id: 1 2024-02-26T03:39:11.162311444Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162316784Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162322944Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162328584Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162333764Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162338674Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162343764Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162349254Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162355494Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 101 2024-02-26T03:39:11.162360924Z 83(129) ERROR: <script>: tcp connection closed conid: (1), tcp(conid): 1, Ri: 12.0.1.185, Rp: 5060 , si: 12.0.1.6 , sp: 22827 2024-02-26T03:39:11.162375744Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162381944Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162388024Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162395164Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162400884Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162406634Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162412284Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162417034Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162422294Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 27 2024-02-26T03:39:11.162427844Z 83(129) ERROR: <script>: tcp connection closed (1) 2024-02-26T03:39:11.162433574Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162439254Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162444184Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162449324Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162454724Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 1 2024-02-26T03:39:11.162460094Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 52 2024-02-26T03:39:11.162466084Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162471724Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162477324Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162482144Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162487154Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 52 2024-02-26T03:39:11.162501164Z 83(129) DEBUG: ndb_redis [redis_client.c:399]: redisc_get_server(): Hash 2100282857 (srvN) 2024-02-26T03:39:11.162508124Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694209461 (12.0.1.9:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162514104Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694209462 (12.0.1.8:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162520554Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694209448 (12.0.1.7:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162526404Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694210133 (12.0.1.9:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162532034Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694210134 (12.0.1.8:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162537324Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694210120 (12.0.1.7:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162542824Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2100282854 (srvM), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162548064Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2100282857 (srvN), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162554074Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2100306023 (srvTPS), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162559184Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694209461 (12.0.1.9:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162564524Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694209462 (12.0.1.8:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162569904Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694209448 (12.0.1.7:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162575334Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694210133 (12.0.1.9:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162580154Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694210134 (12.0.1.8:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162585964Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694210120 (12.0.1.7:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162592294Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2100282854 (srvM), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162597644Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2100282857 (srvN), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162611324Z 83(129) DEBUG: ndb_redis [redis_client.c:413]: redisc_get_server(): Using entry 2100282857 (srvN) 2024-02-26T03:39:11.162617084Z 83(129) DEBUG: ndb_redis [redis_client.c:960]: redisc_exec(): rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162622004Z 83(129) ERROR: ndb_redis [redis_client.c:963]: redisc_exec(): no redis context for server: srvN 2024-02-26T03:39:11.162627834Z 83(129) ERROR: tcpops [tcpops.c:280]: tcpops_tcp_closed_run_route(): run_top_route() after tev->id: 1 2024-02-26T03:39:11.162633294Z 83(129) DEBUG: <core> [core/tcp_main.c:3904]: handle_tcp_child(): case CONN_EOF tcp_emit_closed_event before 5 ``` #### SIP Traffic  ``` 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"); if($conid ne $null) { xlog("L_ERR", "$proto connection closed ($conid)\n"); route(TCPEVENT); } } route[TCPEVENT] { if(redis_cmd("srvN", "get %s", "$conid", "r")) { ..... } } #redis module config loadmodule "ndb_redis" modparam("ndb_redis", "cluster", 1) modparam("ndb_redis", "allow_dynamic_nodes", 1) modparam("ndb_redis", "server", "name=srvN;addr=NDB_N_REDIS_CLUSTER_MAINADDR;port=NDB_N_REDIS_CLUSTER_MAINPORT;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=srvM;addr=NDB_M_REDIS_CLUSTER_MAINADDR;port=NDB_M_REDIS_CLUSTER_MAINPORT;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.7:7369;addr=12.0.1.7;port=7369;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.8:7369;addr=12.0.1.8;port=7369;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.9:7369;addr=12.0.1.9;port=7369;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.7:7469;addr=12.0.1.7;port=7469;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.8:7469;addr=12.0.1.8;port=7469;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.9:7469;addr=12.0.1.9;port=7469;pass=NDB_REDIS_PASSWORD") ``` * **Operating System**:  ``` 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/3768 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3768(a)github.com>

3 10

[kamailio/kamailio] Option to not add received via param (Issue #3515)
by zusrut 15 Apr '24

15 Apr '24

### Description Hello. Probably I'm doing something wrong but I can't get rid of **received** parameter in the **Via** header in responses from kamailio by websocket transport. According [RFC 7118](https://datatracker.ietf.org/doc/rfc7118/): `` When a SIP WebSocket Server receives a request, it MAY decide not to add a "received" parameter to the top Via header. Therefore, SIP WebSocket Clients MUST accept responses without such a parameter in the top Via header regardless of whether the **Via** "sent-by" field contains a domain name. `` ### Expected behavior For responses to websocket transport have a way to not add **received** parameter in **Via** header #### Actual observed behavior Responses to OPTION or REGISTER methods trough websocket got **received** containing IP we want to not show to the end users. ### Possible Solutions maybe add a param in **tm** module or something ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.2.1 (x86_64/linux) ``` and ``` kamailio 5.6.1 (x86_64/linux) b36a13 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3515 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3515(a)github.com>

4 7

[kamailio/kamailio] User id conflict between kamctl et. al. and Linux OS installations (Issue #3752)
by Mark Warren 10 Apr '24

10 Apr '24

### Description After installing kamailio on Ubuntu (20.04 and 22.04) using normal kamailio.org instructions, things work fine. However, a developer is working on a large project as root, and occasionally restarts kamailio with the command "kamctl <start|stop|restart>", rather than the OS command "systemctl <stop|start|restart> kamailio". After that, any attempt to restart or check status using systmectl fails, and rebooting the server occasionally fails to restart kamailio. ### Troubleshooting #### Reproduction Install ubuntu 22.04 or 20.04. When up and running, try this: `systemctl status kamailio` (everything looks good) `ps -C kamailio -o comm,uid,euid,pid,ppid` (all happy, Kamailio running as user kamailio) `kamctl restart` `ps -C kamailio -o comm,uid,euid,pid,ppid` (Yes it's running, but as root, not kamailio) `systemctl status kamailio` (FAILS, 20.04 reports "Failed to start", 22.04 reports "kamailio.service: Deactivated successfully") `systemctl restart kamailio` (FAILS - same reports as preceding "status" command) #### Debugging Data  #### Log Messages  After command systemctl restart kamailio: ``` Feb 9 18:30:02 usdc2-lab-drproxy02 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 Feb 9 18:30:02 usdc2-lab-drproxy02 kamailio: INFO: <core> [core/tcp_main.c:5042]: init_tcp(): using epoll_lt as the io watch method (auto detected) Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: rr [rr_mod.c:177]: mod_init(): outbound module not available Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: auth [auth_mod.c:345]: mod_init(): qop set, but nonce-count (nc_enabled) support disabled Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [main.c:2779]: main(): processes (at least): 32 - shm size: 67108864 - pkg size: 8388608 Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: ERROR: <core> [core/tcp_main.c:3162]: tcp_init(): bind(c, 0x7f49b0475c74, 16) on 127.0.0.1:5060 : Address already in use Feb 9 18:30:02 usdc2-lab-drproxy02 /usr/sbin/kamailio[2388]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions Modify kamctl et. al. to call systemctl for start, stop, restart commands. Alternatively have kamctl call setuid() before start, restart, stop commands. ### Additional Information * **Kamailio Version** - output of `kamailio -v` On ubuntu 20.04: ``` version: kamailio 5.3.2 (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_BLACKLIST, 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 9.2.1 ``` For ubuntu 22.04: ``` version: kamailio 5.6.5 (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 with gcc 11.4.0 ``` * **Operating System**: For ubuntu 22.04: ``` root@my_22.04_ubuntu:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy root@my_22.04_ubuntu:~# uname -a Linux my_22.04_ubuntu 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux root@my_22.04_ubuntu:~# ``` For ubuntu 20.04 ``` root@my_20.04_ubuntu:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal root@my_20.04_ubuntu:~# uname -a Linux my_20.04_ubuntu 5.4.0-171-generic #189-Ubuntu SMP Fri Jan 5 14:23:02 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux root@my_20.04_ubuntu:~# ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3752 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3752(a)github.com>

3 3

[kamailio/kamailio] Kamailio segfaults when KEMI functions are invoked from app_python script (Issue #3746)
by David Minh Phan 07 Apr '24

07 Apr '24

### Description Kamailio segfaults when KEMI functions are invoked from app_python script ### Troubleshooting The same code was running ok with the 5.6 branch. It seems that the function sr_apy_kemi_exec_func_ex has been re-written in 5.7 with the following main changes : - The long IF/ELSE statement was replace by a FOR loop - The call to PyArg_ParseTuple function was replaced by the call to PyList_GetItem ==> **This seems to be the cause. The value returned by this function is alway NULL** #### Reproduction Any call to KSR.pv.seti function from a PYTHON 2 script would cause this error. #### Log Messages ``` sbin/kamailio[18449]: ERROR: app_python [apy_kemi.c:280]: sr_apy_kemi_exec_func_ex(): null parameter - func: seti idx: 0 argc: 2 Feb 6 11:34:16 .../sbin/kamailio[18509]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 37 Feb 6 11:34:16 .../sbin/kamailio[18380]: ALERT: <core> [main.c:793]: handle_sigs(): child process 18449 exited by a signal 11 Feb 6 11:34:16 .../sbin/kamailio[18380]: ALERT: <core> [main.c:796]: handle_sigs(): core was not generated Feb 6 11:34:16 .../sbin/kamailio[18380]: INFO: <core> [main.c:818]: handle_sigs(): terminating due to SIGCHLD Feb 6 11:34:16 .../sbin/kamailio[18509]: INFO: <core> [main.c:874]: sig_usr(): signal 15 received Feb 6 11:34:16 .../sbin/kamailio[18502]: INFO: <core> [main.c:874]: sig_usr(): signal 15 received Feb 6 11:34:16 .../sbin/kamailio[18495]: INFO: <core> [main.c:874]: sig_usr(): signal 15 received Feb 6 11:34:16 .../sbin/kamailio[18482]: INFO: <core> [main.c:874]: sig_usr(): signal 15 received ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3746 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3746(a)github.com>

3 3

[kamailio/kamailio] Topos breaks early dialog transactions on multi-homed kamailio instances using enable_double_rr and versions >= 5.6.5 (Issue #3757)
by George Diamantopoulos 05 Apr '24

05 Apr '24

### Description All kamailio versions on the 5.7.x train and additionally point release 5.6.5 break early dialog transactions, at least when the following conditions are (cumulatively) met: * topos-redis is enabled (haven't tested other storage backends yet, let me know if needed) * kamailio is multihomed * enable_double_rr is enabled (the default) ### Troubleshooting #### SIP Traffic Here's an exchange demonstrating the problem: ``` kamailio instance ──────────┬──────────────────┬───────── internal external peer 172.30.154.1:5060 185.73.43.241:5060 195.167.21.66:5060 ──────────┬──────────────────┬───────── ──────────┬───────── │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ INVITE (SDP) │ │ │ ──────────────────────────> │ │ │ 100 Trying │ │ │ <────────────────────────── │ │ │ 183 Session Progress (SDP) │ │ │ <────────────────────────── │ │ │ PRACK │ │ │ ──────────────────────────> │ │ │ 200 OK │ │ │ <────────────────────────── │ │ │ UPDATE (SDP) │ UPDATE (SDP) │ │ <─────────────────────────── │ │ ``` Whereas the expected behaviour should be: ``` │ │ UPDATE (SDP) │ | <────────────────────────── │ UPDATE (SDP)│ │ │ <───────── │ │ │ ``` This is also exemplified by examining the Via headers as rewritten by kamailio. Not working (>= 5.6.5, 5.7.x): * Inbound Via: `Via: SIP/2.0/UDP 195.167.21.66:5060;branch=z9hG4bKtjlwcpvfh03epe0thhtjhq3qg;Role=3;Hpt=8e58_16` * Oubound Via: `Via: SIP/2.0/UDP 185.73.43.241;branch=z9hG4bK66c4.3453dd9a219858819d528b9da671e39e.0` Working (5.6.4): * Inbound Via: `Via: SIP/2.0/UDP 195.167.21.66:5060;branch=z9hG4bK8lj1ahz6npz65khd8jkzl1ohh;Role=3;Hpt=8e68_16` * Oubound Via: `Via: SIP/2.0/UDP 172.30.154.1;branch=z9hG4bK4dce.4f5448efd64465fa5dbaf5eef0dc35b7.0` ### Possible Solutions Only solution I have found so far is to downgrade to kamailio 5.6.4  ### 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 10.2.1 ``` But I have also tested all 5.7.x versions, which are all affected, as well 5.6.5. * **Operating System**:  ``` Linux host 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3757 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3757(a)github.com>

3 8

[kamailio/kamailio] branch_failure route in case 503 and dns failover (PR #3138)
by vlitvinov 02 Apr '24

02 Apr '24

#### Pre-Submission Checklist    - [ ] 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:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  When we use DNS failover in case of timeout kamailio executes the branch_failure route. In the case of the 503 - on_reply route. This commit is to equate behavior in both cases. So if there are more candidates we will always execute branch_failure route and on_reply route only if this is the last candidate. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3138 -- Commit Summary -- * branch_failure route in case 503 and dns failover -- File Changes -- M src/modules/tm/t_reply.c (52) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3138.patch https://github.com/kamailio/kamailio/pull/3138.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3138 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3138(a)github.com>

4 16

[kamailio/kamailio] Consider adding socket options SO_BINDTODEVICE when the interface name is given for listen in the config file (Issue #3716)
by Harish S 01 Apr '24

01 Apr '24

3 3

[kamailio/kamailio] topos module breaks UPDATE (Issue #3437)
by Guybrush T. 27 Mar '24

27 Mar '24

### Description Kamailio v5.5.6 with topos module and postgres DB. UAC (A) -> Kamailio Registrar (B) -> Kamailio PSTN GW (C) -> PSTN (D) Call goes from A to D, PSTN sends UPDATE, UPDATE is routed from C to A instead to B and then to A. #### Reproduction Caller calls callee and receives an UPDATE from callee. In my case it was when the call was routed to voicemail. #### Log Messages ``` Kamailio takes the wrong route in UPDATE (upstream) case. May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: topos [tps_msg.c:882]: tps_request_received(): r-uri updated to: [sip:1234@<UAC-IP>;uniq=B0EB9A84A278626DA07219E2AE01C] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: topos [tps_msg.c:187]: tps_add_headers(): adding to headers(0) - [Route: sip:<<KamailioPSTNgwIP>>;lr=on;ftag=9945501E2B94B883;did=1fc.42f;nat=yes#015#012] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: topos [tps_msg.c:187]: tps_add_headers(): adding to headers(0) - [P-SR-XUID: atpsh-64527b0a-40362-1#015#012] The right one would be the x_rr (a_rr), but it takes only the s_rr: May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:234]: db_postgres_convert_rows(): PQgetvalue(0x7fcb4893db50,0,7)=[sip:<KamailioRegistrarIP>;lr=on;ftag=9945501E2B94B883;did=1fc.7b92] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:242]: db_postgres_convert_rows(): [0][7] Column[x_rr]=[sip:<KamailioRegistrarIP>;lr=on;ftag=9945501E2B94B883;did=1fc.7b92] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:234]: db_postgres_convert_rows(): PQgetvalue(0x7fcb4893db50,0,8)=[sip:<PSTNgw>:5060;transport=udp;lr;Hpt=8ef8_116;CxtId=3;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=18614] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:242]: db_postgres_convert_rows(): [0][8] Column[y_rr]=[sip:<PSTNgw>:5060;transport=udp;lr;Hpt=8ef8_116;CxtId=3;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=18614] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:234]: db_postgres_convert_rows(): PQgetvalue(0x7fcb4893db50,0,9)=[sip:<<KamailioPSTNgwIP>>;lr=on;ftag=9945501E2B94B883;did=1fc.42f;nat=yes] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:242]: db_postgres_convert_rows(): [0][9] Column[s_rr]=[sip:<<KamailioPSTNgwIP>>;lr=on;ftag=9945501E2B94B883;did=1fc.42f;nat=yes] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263019]: DEBUG: db_postgres [km_res.c:242]: db_postgres_convert_rows(): [0][10] Column[a_rr]=[sip:<KamailioRegistrarIP>;lr=on;ftag=9945501E2B94B883;did=1fc.7b92] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263019]: DEBUG: db_postgres [km_res.c:234]: db_postgres_convert_rows(): PQgetvalue(0x7fcb4893dbd8,0,11)=[] ``` ### Possible Solutions Respect Route headers for UPDATE messages. ### Additional Information Current running kamailio 5.5.6 but tried also latest 5.6.4 with same behavior. ``` version: kamailio 5.5.6 (x86_64/linux) 72dbb0 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: 72dbb0 compiled on 05:48:21 Apr 27 2023 with gcc 11.3.0 ``` * **Operating System**: ``` Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy Linux sipproxy 5.15.0-70-generic #77-Ubuntu SMP Tue Mar 21 14:02:37 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux ``` Possibly related bug: https://github.com/kamailio/kamailio/issues/3090 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3437 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3437(a)github.com>

4 10

[kamailio/kamailio] xhttp: fix execution of async functions (PR #3723)
by Vadim Saranov 21 Mar '24

21 Mar '24

#### 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:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3720 #### Description Fixing R-RURI and adding necessary headers when creating fake_msg in xhttp_mod.c for successful message validation and the ability to perform various kamailio functions from event_route[xhttp:request]. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3723 -- Commit Summary -- * xhttp: fix execution of async functions -- File Changes -- M src/modules/xhttp/xhttp_mod.c (39) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3723.patch https://github.com/kamailio/kamailio/pull/3723.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3723 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3723(a)github.com>

3 5

[kamailio/kamailio] Docs: TLS module known limitation needs clarifications (Issue #3717)
by Thierno IB. BARRY 15 Mar '24

15 Mar '24

### Description We recently deployed successfully Kamailio with TLS certificates. Now we would like to use let's encrypt certificate which expire after 3 months. Means we need to renew certificate approximatively every 2 months. But while reading docs, in [known limitations](https://kamailio.org/docs/modules/devel/modules/tls.html#tls.k… it says : > TLS specific config reloading is not safe, so for now better don't use it, especially under heavy traffic. We struggle to understand if this behaviour is risky and not recommended under heavy traffic for certificate renewal. The doc has been added initially by @poandrei 18 years ago in Feb 21 2007 (see [commit](https://github.com/kamailio/kamailio/commit/32e4977cdb9c1c9ca24c140…) While digging we came across few discussions Kamailio user groups which are saying "the opposite" (kind of): - [Comments by a co-founder of Kamailio ](https://www.mail-archive.com/sr-users@lists.kamailio.org/msg16014.html)stating that the old connections shouldn’t be affected by reload. - Comments by a Kamailio core developer stating that certificate reload is fine with the “reload” cmd ([link1](https://lists.kamailio.org/pipermail/sr-users/2022-February/114296.h…, [link2](https://github.com/kamailio/kamailio/issues/3305)) Plus in another section in docs: - [By definition :](https://kamailio.org/docs/modules/devel/modules/tls.html#tls.r.tls.reload) (the) existing active TLS connections are not terminated and they continue to use the old certificates. The new configuration will be used for new connections. So 18 years after, Is it safe to use `tls.reload` command in production and in heavy traffic for **TLS certificate renewal** ? Because it sounds scary and confusing. So the documentation as it is, really needs clarifications to let users know which risk they're taking when running the `tls.reload` command.  ### Expected behavior The document should clearly documents risks, at least for certificate renewal. #### Actual observed behavior Docs and Kamailio user/dev groups are confusing. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3717 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3717(a)github.com>

3 6

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev February 2024