May 2023 - sr-dev - kamailio.org

[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] Library libjson-c-dev 0.15.2 not compatible with pua_json module (Issue #3376)
by Henning Westerholt 28 Feb '24

28 Feb '24

There seems to be an incompatibility in the pua_json module related to the libjson-c-dev" version. The module crashes on startup on version 0.15.2 (e.g. from Debian bullseye). It works with version 0.12 (e.g. Debian buster). Backtrace below: ``` #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f6d265e5537 in __GI_abort () at abort.c:79 #2 0x00007f6d265e540f in __assert_fail_base (fmt=0x7f6d2675d6a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f6d2322c091 "jso->_ref_count > 0", file=0x7f6d2322c064 "./json_object.c", line=308, function=<optimized out>) at assert.c:92 #3 0x00007f6d265f4662 in __GI___assert_fail (assertion=0x7f6d2322c091 "jso->_ref_count > 0", file=0x7f6d2322c064 "./json_object.c", line=308, function=0x7f6d2322c480 "json_object_put") at assert.c:101 #4 0x00007f6d23224732 in json_object_put () from /lib/x86_64-linux-gnu/libjson-c.so.5 #5 0x00007f6d25842362 in pua_json_publish (msg=0x7fffb3fffb20, json=0x7f6d25ff5778 "{\"Call-ID\":\"111\",\"Event-Category\":\"presence\",\"Event-Name\":\"update\",\"Event-Package\":\"message-summary\",\"Expires\":\"3600\",\"To\":\"sip:103@XXX.YYY.55.208\",\"To-User\":\"103\",\"To-Realm\":\"XXX.YYY.55.208\",\"From\":\""...) at pua_json_publish.c:383 #6 0x00007f6d2583e74a in w_pua_json_publish (msg=0x7fffb3fffb20, p1pjson=0x7f6d25ff5988 "xW\377%m\177", p2=0x0) at pua_json_mod.c:100 #7 0x0000563199d1c47e in do_action () #8 0x0000563199d29ae6 in run_actions () #9 0x00007f6d2324444e in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/xhttp.so #10 0x00007f6d23246005 in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/xhttp.so #11 0x0000563199e6cb10 in nonsip_msg_run_hooks () #12 0x0000563199ede538 in receive_msg () #13 0x0000563199cac4f2 in receive_tcp_msg () #14 0x0000563199caeb51 in tcp_read_req () #15 0x0000563199cb2028 in ?? () #16 0x0000563199c9da4f in ?? () #17 0x0000563199cb4f8c in tcp_receive_loop () #18 0x0000563199e2330b in tcp_init_children () #19 0x0000563199c8967f in main_loop () #20 0x0000563199c9446e in main () ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3376 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3376(a)github.com>

3 11

[kamailio/kamailio] [pua] reginfo_increase_version does nothing (Issue #3234)
by Matteo 09 Feb '24

09 Feb '24

### Description The reginfo notifications sent via pua_reginfo + presence_reginfo contains the version fixed to `0`. The pua docs report the param `reginfo_increase_version` which should increase the version if enabled, but currently does nothing. Looking into the code seems to confirm that, param is read from `pua` module but is not used anywhere. While the param `dlginfo_increase_version` seems to be used for the intended scope. #### Reproduction Setup pua + pua_reginfo to publish registration informations and observe that version param of reginfo is always 0, not respecting pua `reginfo_increase_version` setting. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.6.1 (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 9.4.0 ``` * **Operating System**: ``` Linux Debian bullseye/sid ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3234 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3234(a)github.com>

4 10

[kamailio/kamailio] callout from event_route [tm:local-response] only occurs once (Issue #3064)
by dpaape 03 Feb '24

03 Feb '24

version: kamailio 5.5.2 (arm6/linux) 55e232 raspberry pi 3b I initially stated that I was running on 5.5.3 but I was mistaken. However I checked the 5.5.3 source and it appears to be the same. I think that there is a bug in the tm module with respect to the "tm:local-response" event route. In the "t_reply.c" file, there is a static variable called '_tm_local_response_set_lookup'. This variable is initialized at load time to zero. It is checked in the '_reply_light()' routine and will initiate a local callback from the config script if "armed". The problem as I see it is that if the callback is readied, the variable is set to one. But it is never reset. So the observed behavior is as follows. A REGISTER is received and the request_route arms the callback. The REGISTER requires an authorization (local database sqlite). After the 401 is sent back, the callback via the event route is called as expected. All good except that the event route script fragment is never executed again after the first call... ever, even if it's a new REGISTER request. I would think that somewhere in the tm module, the variable should be reset to zero so that subsequent transactions can initiate the event route again. Or maybe the variable ought to live somewhere in the transaction cell??? . . . t_on_reply ("MY_FRAG"); t_on_failure ("MY_FRAG"); . . . event_route [tm:local-response] { xlog ("L_NOTICE", IN tm:local-response\n"); my_function(); } . . . So 'my_function()' is only called once. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3064 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3064(a)github.com>

6 9

[kamailio/kamailio] cfgt: doesn't support tm_suspend() tm_continue() (#684)
by Victor Seva 23 Jan '24

23 Jan '24

Actual implementation doesn't work with async. Need to investigate how to support it --- 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/684

3 8

[kamailio/kamailio] dialog: failover database loading behaviour in shared DB scenario, expiration of dialogs (#2080)
by Henning Westerholt 20 Jan '24

20 Jan '24

The dialog module will expire dialogs that don't actually belong to the particular proxy. Scenario: 2 proxies on 5.2.4 with a loadbalancer in front. Call was routed over proxy1, dialog timeout on proxy2 was shorter (to make it easier to reproduce it). The results: * Dialog synchronized with DMQ: proxy 2 would timeout the dialog * Dialog entry synchronized to proxy2 DB and proxy2 restarted: Proxy2 would timeout the dialog * Dialog entry synchronized to proxy2 DB and proxy2 not restarted: Proxy2 would _not_ timeout the dialog (I’ve tried both db_mode 1 and 2) So the proxy2 would load the dialog into memory and then later expire it. So timeout routes, send_bye on timeout would not work correctly. One idea to solve this would be to check e.g. over the existing socket data if the dialog belongs to this proxy and skip loading it in this case. This could be also made configurable e.g. with a module parameter. Any comments? Better ideas how to solve it? -- 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/2080

5 9

[kamailio/kamailio] Kamailio 5.6 do not execute "event_route[websocket:closed]" when tcp reset (Issue #3389)
by ReznikovAlexei 17 Jan '24

17 Jan '24

### Description I have faced with an issue in Kamailio 5.6 when tcp closed reset by peer on remote side but Kamailio dont executing route block "event_route[websocket:closed]". ### Kamailio minimal config file ####### Global Parameters ######### listen=udp:192.168.31.81:5060 listen=tcp:192.168.31.81:5060 listen=tcp:192.168.31.81:7000 tcp_accept_no_cl=yes ######## Kamailio control connector module ######## loadmodule "tm.so" loadmodule "ctl.so" modparam("ctl", "binrpc_buffer_size", 4096) loadmodule "pv.so" loadmodule "sl.so" loadmodule "xlog.so" loadmodule "nathelper.so" loadmodule "xhttp.so" loadmodule "websocket.so" loadmodule "ipops.so" loadmodule "siputils.so" loadmodule "rr.so" loadmodule "usrloc.so" loadmodule "registrar.so" request_route { if(method=="REGISTER"){ save("location"); exit; } } event_route[xhttp:request] { set_reply_close(); set_reply_no_connect(); xlog("L_WARN", "websocket|log|connection from $si received!\n"); if ($hdr(Upgrade)=~"websocket" && $hdr(Connection)=~"Upgrade" && $rm=~"GET") { if (ws_handle_handshake()) { exit; } } xhttp_reply("404", "Not found", "", ""); } event_route[websocket:closed] { xlog("L_WARN", "websocket|log|connection from $si closed!\n"); } #### Reproduction ###Kamailio started and client sipml5 connected [root@centos8 kamailio]# sh /root/run_kamailio.sh Listening on udp: 192.168.31.81:5060 tcp: 192.168.31.81:5060 tcp: 192.168.31.81:7000 Aliases: tcp: centos8.local.tst:7000 tcp: centos8.local.tst:5060 udp: centos8.local.tst:5060 15(29286) WARNING: <script>: websocket|log|connection from 192.168.31.100 received! ### closing tcp connection by remote side C:\Users\Alex>netstat -ano | findstr :7000 TCP 192.168.31.100:51688 192.168.31.81:7000 ESTABLISHED 9624 C:\Users\Alex>taskkill /pid 9624 /F SUCCESS: The process with PID 9624 has been terminated. ### issue reproduced 17(29288) ERROR: <core> [core/tcp_read.c:272]: tcp_read_data(): error reading: Connection reset by peer (104) ([192.168.31.100]:51688 ->17(29288) ERROR: <core> [core/tcp_read.c:274]: tcp_read_data(): -> [192.168.31.81]:7000) 17(29288) ERROR: <core> [core/tcp_read.c:1478]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f47d5134ad0 r: 0x7f47d5134bf8 (-1) And nothing else but I am expecting something like that: this is output from Kamailio 5.5 where the issue not reproduced. 13(39207) WARNING: websocket [ws_frame.c:227]: encode_and_send_ws_frame(): TCP/TLS connection get failed 13(39207) ERROR: websocket [ws_frame.c:761]: ping_pong(): sending keepalive 14(39208) WARNING: <script>: websocket|log|connection from 192.168.31.100 closed! Also additional output ws.dump [root@centos8 kamailio]# kamcmd ws.dump { connections: { } info: { wscounter: 0 truncated: no } } ### Possible Solutions I found a commit which called this behavior https://github.com/kamailio/kamailio/commit/3033b7681b4240fd64c9f1ff446b529… If I was built Kamailo without this commit, the issue not reproduced, also the issue not reproduced in Kamailio 5.5 or older. ### Additional Information ``` [root@centos8 kamailio-5.6]# kamailio -v version: kamailio 5.6.4 (x86_64/linux) a004cf 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: a004cf compiled on 11:09:28 Mar 6 2023 with gcc 8.5.0 ``` * **Operating System**: ``` [root@centos8 kamailio-5.6]# cat /etc/centos-release CentOS Stream release 8 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3389 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3389(a)github.com>

3 4

[kamailio/kamailio] core/cfg has memory leak if string value is set (#2094)
by Bastian Triller 17 Jan '24

17 Jan '24

### Description Setting string values via `cfg_rpc` leaves old strings in SHM. #### Reproduction  Set some string value to e.g. `tm.ac_extra_hdrs`: ```shell x=10 while [ $x -gt 0 ] ; do sudo kamctl rpc cfg.sets tm ac_extra_hdrs das$x >/dev/null sleep 0.001 x=$((x - 1)) done ``` #### Debugging Data After running above snippet four times: ``` sudo kamcmd cfg.set_now_int core mem_dump_shm 1 grep "^Oct 4 15:11:4.* qm_status:.*alloc'd" /var/log/syslog | cut -d: -f6- | sort | uniq -c | sort -n | grep core/cfg/cfg 1 alloc'd from core: core/cfg/cfg_struct.c: cfg_shmize(217) 1 alloc'd from core: core/cfg/cfg_struct.c: sr_cfg_init(322) 1 alloc'd from core: core/cfg/cfg_struct.c: sr_cfg_init(334) 1 alloc'd from core: core/cfg/cfg_struct.c: sr_cfg_init(346) 1 alloc'd from core: core/cfg/cfg_struct.c: sr_cfg_init(353) 1 alloc'd from core: core/cfg/cfg_struct.c: sr_cfg_init(360) 2 alloc'd from core: core/cfg/cfg_ctx.c: cfg_register_ctx(47) 3 alloc'd from core: core/cfg/cfg_struct.c: cfg_clone_global(625) 39 alloc'd from core: core/cfg/cfg_ctx.c: cfg_set_now(559) 40 alloc'd from core: core/cfg/cfg_struct.c: cfg_child_cb_new(828) 42 alloc'd from core: core/cfg/cfg_struct.c: cfg_clone_str(130) sudo kamcmd mod.stats core shm|grep \\bcfg_ cfg_clone_global(625): 1392 cfg_set_now(559): 624 cfg_clone_str(130): 384 cfg_shmize(217): 696 cfg_register_ctx(47): 64 cfg_child_cb_new(828): 2560 ``` memory values from cfg_clone_str addresses: ``` grep -B1 'Oct 4 15:11:4.*cfg_clone_str' /var/log/syslog|sed '/address=/!d' | cut -d: -f6- 55. N address=0x7f1310eab7f8 frag=0x7f1310eab7c0 size=40 used=1 56. N address=0x7f1310eab888 frag=0x7f1310eab850 size=24 used=1 62. N address=0x7f1310ec7b10 frag=0x7f1310ec7ad8 size=8 used=1 65. N address=0x7f1310ec7ca0 frag=0x7f1310ec7c68 size=8 used=1 68. N address=0x7f1310ec7e30 frag=0x7f1310ec7df8 size=8 used=1 69. N address=0x7f1310ec7ea0 frag=0x7f1310ec7e68 size=8 used=1 72. N address=0x7f1310ec8030 frag=0x7f1310ec7ff8 size=8 used=1 75. N address=0x7f1310ec81c0 frag=0x7f1310ec8188 size=8 used=1 78. N address=0x7f1310ec8350 frag=0x7f1310ec8318 size=8 used=1 81. N address=0x7f1310ec84e0 frag=0x7f1310ec84a8 size=8 used=1 84. N address=0x7f1310ec8670 frag=0x7f1310ec8638 size=8 used=1 87. N address=0x7f1310ec8800 frag=0x7f1310ec87c8 size=8 used=1 90. N address=0x7f1310ec8990 frag=0x7f1310ec8958 size=8 used=1 93. N address=0x7f1310ec8b20 frag=0x7f1310ec8ae8 size=8 used=1 96. N address=0x7f1310ec8cb0 frag=0x7f1310ec8c78 size=8 used=1 99. N address=0x7f1310ec8e40 frag=0x7f1310ec8e08 size=8 used=1 103. N address=0x7f1310ec92f0 frag=0x7f1310ec92b8 size=8 used=1 106. N address=0x7f1310ec9480 frag=0x7f1310ec9448 size=8 used=1 109. N address=0x7f1310ec9610 frag=0x7f1310ec95d8 size=8 used=1 112. N address=0x7f1310ec97a0 frag=0x7f1310ec9768 size=8 used=1 115. N address=0x7f1310ec9930 frag=0x7f1310ec98f8 size=8 used=1 118. N address=0x7f1310ec9ac0 frag=0x7f1310ec9a88 size=8 used=1 121. N address=0x7f1310ec9c50 frag=0x7f1310ec9c18 size=8 used=1 124. N address=0x7f1310ec9de0 frag=0x7f1310ec9da8 size=8 used=1 127. N address=0x7f1310ec9f70 frag=0x7f1310ec9f38 size=8 used=1 131. N address=0x7f1310eca420 frag=0x7f1310eca3e8 size=8 used=1 134. N address=0x7f1310eca5b0 frag=0x7f1310eca578 size=8 used=1 137. N address=0x7f1310eca740 frag=0x7f1310eca708 size=8 used=1 140. N address=0x7f1310eca8d0 frag=0x7f1310eca898 size=8 used=1 144. N address=0x7f1310ecad80 frag=0x7f1310ecad48 size=8 used=1 147. N address=0x7f1310ecaf10 frag=0x7f1310ecaed8 size=8 used=1 150. N address=0x7f1310ecb0a0 frag=0x7f1310ecb068 size=8 used=1 153. N address=0x7f1310ecb230 frag=0x7f1310ecb1f8 size=8 used=1 156. N address=0x7f1310ecb3c0 frag=0x7f1310ecb388 size=8 used=1 159. N address=0x7f1310ecb550 frag=0x7f1310ecb518 size=8 used=1 162. N address=0x7f1310ecb6e0 frag=0x7f1310ecb6a8 size=8 used=1 165. N address=0x7f1310ecb870 frag=0x7f1310ecb838 size=8 used=1 168. N address=0x7f1310ecba00 frag=0x7f1310ecb9c8 size=8 used=1 172. N address=0x7f1310ecbeb0 frag=0x7f1310ecbe78 size=8 used=1 175. N address=0x7f1310ecc040 frag=0x7f1310ecc008 size=8 used=1 178. N address=0x7f1310ecc1d0 frag=0x7f1310ecc198 size=8 used=1 181. N address=0x7f1310ecc360 frag=0x7f1310ecc328 size=8 used=1 0x7f1310eab7f8: "trying -- your call is important to us" 0x7f1310eab888: "Server Internal Error" 0x7f1310ec7b10: "das10" 0x7f1310ec7ca0: "das9" 0x7f1310ec7e30: "das10" 0x7f1310ec7ea0: "das10" 0x7f1310ec8030: "das9" 0x7f1310ec81c0: "das9" 0x7f1310ec8350: "das8" 0x7f1310ec84e0: "das7" 0x7f1310ec8670: "das6" 0x7f1310ec8800: "das5" 0x7f1310ec8990: "das4" 0x7f1310ec8b20: "das3" 0x7f1310ec8cb0: "das2" 0x7f1310ec8e40: "das1" 0x7f1310ec92f0: "das10" 0x7f1310ec9480: "das9" 0x7f1310ec9610: "das8" 0x7f1310ec97a0: "das7" 0x7f1310ec9930: "das6" 0x7f1310ec9ac0: "das5" 0x7f1310ec9c50: "das4" 0x7f1310ec9de0: "das3" 0x7f1310ec9f70: "das2" 0x7f1310eca420: "das1" 0x7f1310eca5b0: "das8" 0x7f1310eca740: "das7" 0x7f1310eca8d0: "das6" 0x7f1310ecad80: "das5" 0x7f1310ecaf10: "das4" 0x7f1310ecb0a0: "das3" 0x7f1310ecb230: "das2" 0x7f1310ecb3c0: "das1" 0x7f1310ecb550: "das8" 0x7f1310ecb6e0: "das7" 0x7f1310ecb870: "das6" 0x7f1310ecba00: "das5" 0x7f1310ecbeb0: "das4" 0x7f1310ecc040: "das3" 0x7f1310ecc1d0: "das2" 0x7f1310ecc360: "das1" ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` /usr/sbin/kamailio -v version: kamailio 5.2.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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: unknown compiled with gcc 6.3.0 ``` * **Operating System**: ``` Debian 9.11 ``` -- 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/2094

5 13

[kamailio/kamailio] dmq_usrloc not replicating contact attributes (#1968)
by pwakano 16 Jan '24

16 Jan '24

### Description  The dmq_usrloc module is not replicating the extra attributes saved in the xavp for the contact. So remote nodes don't receive these values, being unable to access it properly. It is expected that the attributes are replicated as well. #### Reproduction  Setup two nodes using the dmq_usrloc and usrloc in db_mode=0. When receiving a REGISTER, before saving the contact add some attribute in the xavp_contact. In a subsequent message to this contact (e.g.: INVITE) use a lookup() or registered() and try to access the desired xavp_contact attribute. If the request is received in the local node (which received the original REGISTER), the attribute will be valid, but if the request is received in the remote node, the attribute is empty. #### Log Messages  ``` May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: registrar [save.c:410]: pack_ci(): generated ruid is: uloc-5cee2114-5abe-2 May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ucontact.c:73]: ucontact_xavp_store(): trying to clone per contact xavps May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: <core> [core/xavp.c:697]: xavp_clone_level_nodata(): cloned root xavp [ulattrs] May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: <core> [core/xavp.c:721]: xavp_clone_level_nodata(): cloned inner xavp [cluster_node] May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ucontact.c:1701]: update_ucontact(): exists callback for type= UL_CONTACT_UPDATE May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ul_callback.h:84]: run_ul_callbacks(): contact=0x7f51b624d418, callback type 2/15, id 1 entered May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:776]: dmq_ul_cb_contact(): Callback from usrloc with type=2 May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:427]: init_usrloc_dmq_recv(): Initializing usrloc_dmq_recv for pid (23230) May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:785]: dmq_ul_cb_contact(): Replicating local update to other nodes... May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:746]: usrloc_dmq_send_contact(): sending serialized data {"action":1,"aor":"345671002","ruid":"uloc-5cee20df-5953-1","c":"sip:345671002@172.28.128.200:5060;rinstance=38e53fed7e84e081;transport=UDP","received":"","path":"<sip:172.28.128.102:5060;received=sip:172.28.128.200:5060;lr>","callid":"NOeeFh1Bh5JR0eJG8DENkg..","user_agent":"Z 3.15.40006 rv2.8.20","instance":"","expires":1559110577,"cseq":12,"flags":0,"cflags":3072,"q":-1,"last_modified":1559109977,"methods":4294967295,"reg_id":0,"server_id":0} May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:315]: usrloc_dmq_send(): sending dmq broadcast... ``` ### Possible Solutions  Only workaround seems to use usrloc with db_mode=3 and then not use the dmq_usrloc, having the usrloc with attributes info shared via the DB.... ### Additional Information Kamailio 5.2.2 installed from the repo. ``` # kamailio -v version: kamailio 5.2.2 (x86_64/linux) 67f967 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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: 67f967 compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5 ``` * **Operating System**:  ``` # cat /etc/centos-release CentOS Linux release 7.3.1611 (Core) # uname -a Linux kamailio-2 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20 12:24:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ``` -- 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/1968

3 7

[kamailio/kamailio] Ticket to monitor the progress of tls_wolfssl (Issue #3160)
by space88man 15 Jan '24

15 Jan '24

### Description This is an umbrella ticket to address issues with the WIP `tls_wolfssl` module ### Expected behavior The module behaves robustly under load testing and various configurations and thus can be accepted long-term in kamailio -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3160 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3160(a)github.com>

4 7