sr-dev December 2023

sr-dev@lists.kamailio.org

14 participants
228 discussions

[kamailio/kamailio] dialog: failover database loading behaviour in shared DB scenario, expiration of dialogs (#2080)

by Henning Westerholt

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

3 months, 2 weeks

[kamailio/kamailio] ndb_redis doesn't use AUTH on a slave server in redis cluster. (Issue #3654)

by Dries De Gendt

### Description & troubleshooting I have defined a redis cluster as followed. The cluster consists of 3 masters (port 6379) and 3 slaves (port 6380). The password is identical on all nodes through redis option 'requirepass'. ``` modparam("ndb_redis", "server", "name=sbcredis;addr=SBCMASTERREDISIP;port=6379;db=0;pass=REDACTED") modparam("ndb_redis", "server", "name=sbcredis;addr=PRIVATEIP;port=6380;db=0;pass=REDACTED") modparam("ndb_redis", "server", "name=sbcredis;addr=ASTP5IP;port=6380;db=0;pass=REDACTED") modparam("ndb_redis", "server", "name=sbcredis;addr=ASTP6IP;port=6379;db=0;pass=REDACTED") modparam("ndb_redis", "server", "name=sbcredis;addr=ASTP3IP;port=6380;db=0;pass=REDACTED") modparam("ndb_redis", "server", "name=sbcredis;addr=ASTP4IP;port=6379;db=0;pass=REDACTED") modparam("ndb_redis", "cluster", 1) modparam("ndb_redis", "allow_dynamic_nodes", 1) modparam("ndb_redis", "debug", 3) ``` When executing the redis_cmd command, most of the times an expected warning is shown due to another server providing the requested slot: `"(error) MOVED ... 192.168.136.241:6380"` Notice that I've enabled "allow_dynamic_nodes" to make sure there is an automated connection attempt to the indicated server. However, it appears that sometimes a "NOAUTH Authentication required." error is thrown when there is a redirection to a slave server serving that slot. I can authenticate succesfull on the redis-cli when using the identical password though. Also note that when a redis master is queried, the redis_cmd is successful. #### Reproduction Each simple redis command that needs authentication (GET, SET, ...) `redis_cmd("sbcredis", "SET TESTKEY TESTVALUE", "r");` #### Log Messages ``` ndb_redis [redis_client.c:1089]: redisc_exec(): Redis error:NOAUTH Authentication required. ``` ### Possible Solutions None for now except disabling the password on all nodes. ### Additional Information ``` kamailio 5.7.2 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3654 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3654(a)github.com>

3 months, 3 weeks

[kamailio/kamailio] kazoo: SIGSEGV on module unload (Issue #3648)

by sergey-safarov

On core load ``` Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/kamailio --atexit=no -DD -P /run/kamailio/kamailio.pid -f /etc/kamail'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000ffff94f36350 in strlen () from /lib64/libc.so.6 Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-236.el8.aarch64 jansson-2.14-1.el8.aarch64 json-c-0.13.1-3.el8.aarch64 keyutils-libs-1.5.10-9.el8.aarch64 krb5-libs-1.18.2-25.el8.aarch64 libblkid-2.32.1-43.el8.aarch64 libcom_err-1.45.6-5.el8.aarch64 libcurl-minimal-7.61.1-33.el8.aarch64 libevent-2.1.8-5.el8.aarch64 libgcc-8.5.0-20.el8.aarch64 libmount-2.32.1-43.el8.aarch64 libnghttp2-1.33.0-3.el8_2.1.aarch64 librabbitmq-0.9.0-4.el8.aarch64 libselinux-2.9-8.el8.aarch64 libunistring-0.9.9-3.el8.aarch64 libuuid-2.32.1-43.el8.aarch64 libxml2-2.9.7-16.el8.aarch64 mariadb-connector-c-3.1.11-2.el8_3.aarch64 openssl-libs-1.1.1k-9.el8.aarch64 pcre-8.42-6.el8.aarch64 pcre2-10.32-3.el8.aarch64 systemd-libs-239-78.el8.aarch64 xz-libs-5.2.4-4.el8.aarch64 zlib-1.2.11-25.el8.aarch64 ``` **bt full** ``` #0 0x0000ffff94f36350 in strlen () from /lib64/libc.so.6 No symbol table info available. #1 0x0000ffff94f60c7c in vfprintf () from /lib64/libc.so.6 No symbol table info available. #2 0x0000ffff94fe500c in __vsyslog_chk () from /lib64/libc.so.6 No symbol table info available. #3 0x0000ffff94fe5110 in syslog () from /lib64/libc.so.6 No symbol table info available. #4 0x000000000077ebb8 in qm_status (qmp=0xffff8acee000) at core/mem/q_malloc.c:877 __llevel = -4 qm = 0xffff8acee000 f = 0xffff8c0e0c08 i = 5961 j = 9650680 h = 0 unused = 0 memlog = -4 mem_summary = 0 __func__ = "qm_status" __llevel = <optimized out> __kld = <optimized out> #5 0x0000000000772e30 in qm_debug_check_frag (qm=0xffff8acee000, f=0xffff8c0e0c08, file=0xffff8a2a47f0 "kazoo: kz_amqp.c", line=633, efile=0x934218 "core/mem/q_malloc.c", eline=511) at core/mem/q_malloc.c:139 p = 0xffffd0ed96e0 __func__ = "qm_debug_check_frag" #6 0x00000000007775c8 in qm_free (qmp=0xffff8acee000, p=0xffff8c0e0c40, file=0xffff8a2a47f0 "kazoo: kz_amqp.c", func=0xffff8a2abcb0 <__func__.18644> "kz_amqp_destroy_channels", line=633, mname=0xffff8a2a4350 "kazoo") at core/mem/q_malloc.c:511 qm = 0xffff8acee000 f = 0xffff8c0e0c08 size = 281472999768912 next = 0xd0ed9740 prev = 0x1 __func__ = "qm_free" #7 0x0000000000784058 in qm_shm_free (qmp=0xffff8acee000, p=0xffff8c0e0c40, file=0xffff8a2a47f0 "kazoo: kz_amqp.c", func=0xffff8a2abcb0 <__func__.18644> "kz_amqp_destroy_channels", line=633, mname=0xffff8a2a4350 "kazoo") at core/mem/q_malloc.c:1350 No locals. #8 0x0000ffff8a248270 in kz_amqp_destroy_channels (server_ptr=0xffff8ad28880) at kz_amqp.c:633 i = 25 __func__ = "kz_amqp_destroy_channels" #9 0x0000ffff8a2482b4 in kz_amqp_destroy_server (server_ptr=0xffff8ad28880) at kz_amqp.c:641 next = 0x0 __func__ = "kz_amqp_destroy_server" #10 0x0000ffff8a248388 in kz_amqp_destroy_zone (zone_ptr=0xffff8ad28410) at kz_amqp.c:652 next = 0xffff8ad28918 server_ptr = 0xffff8ad28880 __func__ = "kz_amqp_destroy_zone" #11 0x0000ffff8a248488 in kz_amqp_destroy_zones () at kz_amqp.c:664 g = 0xffff8ad28410 __func__ = "kz_amqp_destroy_zones" #12 0x0000ffff8a248510 in kz_amqp_destroy () at kz_amqp.c:672 __func__ = "kz_amqp_destroy" #13 0x0000ffff8a2402a0 in mod_destroy () at kazoo.c:541 __func__ = "mod_destroy" #14 0x00000000005e1670 in destroy_modules () at core/sr_module.c:842 t = 0xffff9379c750 foo = 0xffff9379b798 __func__ = "destroy_modules" #15 0x000000000041e81c in cleanup (show_status=1) at main.c:561 memlog = -767102331 __func__ = "cleanup" #16 0x00000000004208b4 in shutdown_children (sig=15, show_status=1) at main.c:704 __func__ = "shutdown_children" #17 0x00000000004217d0 in handle_sigs () at main.c:735 chld = 65535 chld_status = 0 any_chld_stopped = 0 memlog = 4407388 __func__ = "handle_sigs" #18 0x0000000000434058 in main_loop () at main.c:1900 i = 8 pid = 1350059 si = 0x0 si_desc = "udp receiver child=7 sock=[2605:84c0:51:1f04::6]:5080\000\000\000\360\234\355\320\377\377\000\000صx\223\377\377\000\000\300\234\355\320\377\377\000\000\250\303Փ\377\377\000\000\340\234\355\320\377\377\000\000\360\234\355\320\377\377\000\000\360\234\355\320\377\377\000\000\300\234\355\320\377\377\000\000\320\377\377\377\200\377\377\377" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #19 0x000000000043f094 in main (argc=11, argv=0xffffd0eda278) at main.c:3078 cfg_stream = 0xec522a0 c = -1 r = 0 tmp = 0xffffd0edae66 "" tmp_len = 0 port = 0 proto = 65535 ahost = 0x0 aport = 0 options = 0x8c99d0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 1225301378 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0xffffffff p = 0xffff94f39348 <__libc_start_main+160> "" st = {st_dev = 22, st_ino = 18918, st_mode = 16832, st_nlink = 2, st_uid = 992, st_gid = 987, st_rdev = 0, __pad1 = 0, st_size = 60, st_blksize = 4096, __pad2 = 0, st_blocks = 0, st_atim = {tv_sec = 1695127265, tv_nsec = 210164976}, st_mtim = {tv_sec = 1695742685, tv_nsec = 688032700}, st_ctim = {tv_sec = 1695742685, tv_nsec = 688032700}, __glibc_reserved = {0, 0}} tbuf = '\000' <repeats 56 times>, "xN!\225\377\377\000\000hN!\225\377\377\000\000\bN!\225\377\377\000\000(N!\225\377\377\000\000\070N!\225\377\377\000\000\250N!\225\377\377\000\000\270N!\225\377\377\000\000\310N!\225\377\377\000\000HN!\225\377\377\000\000XN!\225\377\377", '\000' <repeats 18 times>, "\330M!\225\377\377", '\000' <repeats 42 times>... option_index = 12 long_options = {{name = 0x8cbda8 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x8c6c10 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x8cbdb0 "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x8cbdb8 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x8cbdc0 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x8cbdd0 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x8cbde0 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x8cbdf0 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x8cbe00 "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x8cbe10 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x8cbe20 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x8cbe28 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x8cbe38 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" ``` Some more info ``` (gdb) f 8 #8 0x0000ffff8a248270 in kz_amqp_destroy_channels (server_ptr=0xffff8ad28880) at kz_amqp.c:633 633 shm_free(server_ptr->channels); (gdb) list 628 for(i=0; i < dbk_channels; i++) { 629 if(server_ptr->channels[i].targeted != NULL) { 630 kz_amqp_free_bind(server_ptr->channels[i].targeted); 631 } 632 } 633 shm_free(server_ptr->channels); 634 server_ptr->channels = NULL; 635 } 636 637 kz_amqp_server_ptr kz_amqp_destroy_server(kz_amqp_server_ptr server_ptr) (gdb) p server_ptr $1 = (kz_amqp_server_ptr) 0xffff8ad28880 (gdb) p *server_ptr $2 = {id = 1, channel_index = 20, zone = 0xffff8ad28410, connection = 0xffff8ad28578, producer = 0xffff8c754700, channels = 0xffff8c0e0c40, next = 0x0} (gdb) p server_ptr->channels $3 = (kz_amqp_channel_ptr) 0xffff8c0e0c40 (gdb) p *server_ptr->channels $4 = {cmd = 0x0, targeted = 0xffff8c0e1220, consumer = 0x0, channel = 1, state = KZ_AMQP_CHANNEL_FREE, timer = {tv_sec = 1700266610, tv_usec = 250929}, lock = 0} (gdb) f 7 #7 0x0000000000784058 in qm_shm_free (qmp=0xffff8acee000, p=0xffff8c0e0c40, file=0xffff8a2a47f0 "kazoo: kz_amqp.c", func=0xffff8a2abcb0 <__func__.18644> "kz_amqp_destroy_channels", line=633, mname=0xffff8a2a4350 "kazoo") at core/mem/q_malloc.c:1350 1350 qm_free(qmp, p, file, func, line, mname); (gdb) list 1345 } 1346 void qm_shm_free(void* qmp, void* p, const char* file, const char* func, 1347 unsigned int line, const char* mname) 1348 { 1349 qm_shm_lock(); 1350 qm_free(qmp, p, file, func, line, mname); 1351 qm_shm_unlock(); 1352 } 1353 #else 1354 void* qm_shm_malloc(void* qmp, size_t size) ``` This happened on customized Kamailio 5.6.4 where reverted some commits. If it does not make sense for you please close. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3648 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3648(a)github.com>

3 months, 3 weeks

[kamailio/kamailio] Kamailio 5.6 do not execute "event_route[websocket:closed]" when tcp reset (Issue #3389)

by ReznikovAlexei

### 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 months, 3 weeks

[kamailio/kamailio] core/cfg has memory leak if string value is set (#2094)

by Bastian Triller

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

3 months, 3 weeks

[kamailio/kamailio] dmq_usrloc not replicating contact attributes (#1968)

by pwakano

### 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 months, 3 weeks

[kamailio/kamailio] ims_usrloc_pcscf: udomain.c get_pcontact_from_cache() name check blocks SIP SUBSCRIBE for some UE's (Issue #3646)

by jbipre2

### Description We have various commercial UE's connecting over an Amarisoft Callbox Classic eNB with Open5GS core network. This issue concerns different UE behaviour. Name checking code introduced between Kamailio v5.6.4 and v5.7.1 (udomain.c lines 580 to 599) leads to rejection of the SUBSCRIBE request from a Huawei UE (user-agent: IM-client/OMA1.0 HW-Rto/V1.0). SUBSCRIBE requests from a OnePlus UE (user-agent: OnePlus_KB2003_RPIA.201005.001) are accepted. We assume that the behaviour of the commercial-off-the-shelf UE's complies with the 3GPP standards; but we do not know to what extent. The following code, however, caused our Huawei UE's to lose VoLTE capability, after updating the Kamailio IMS from v5.6.4 to v5.7.1. ``` 580 if ((contact_info->aor.len>0) && (needle_uri.user.len != 0)){ 581 if ((needle_uri.user.len != c->contact_user.len) || 582 (memcmp(needle_uri.user.s, c->contact_user.s, needle_uri.user.len) != 0)) { 583 LM_ERR("user name does not match - no match here...\n"); 584 LM_DBG("found pcontact username [%d]: [%.*s]\n", i, c->contact_user.len, c->contact_user.s); 585 LM_DBG("incoming contact username: [%.*s]\n", needle_uri.user.len, needle_uri.user.s); 586 c = c->next; 587 continue; 588 } 589 if ((contact_info->aor.len >= 4) && (memcmp(contact_info->aor.s, c->aor.s, 4) != 0)) { // do not mix up sip- and tel-URIs. 590 LM_ERR("scheme does not match - no match here...\n"); 591 LM_DBG("found pcontact scheme [%d]: [%.*s]\n", i, 4, c->aor.s); 592 LM_DBG("incoming contact scheme: [%.*s]\n", 4, contact_info->aor.s); 593 c = c->next; 594 continue; 595 } 596 } 597 else{ 598 LM_DBG("No user name present - abort user name check\n"); 599 } ``` The above code also does not consider the reverse_search flag (uses c=c->next instead of c = reverse_search? c->prev : c->next), so if reverse_search is set, the code's behaviour may be incorrect. In the following pcap file, the Huawei's SIP REGISTER process starts at packet 2, 200 OK arriving in packet 41, with the P-Associated-URI <sip:51194@ims.mnc001.mcc001.3gppnetwork.org>. This UE sends SUBSCRIBE (packet 47) incorporating a new Contact: <sip:51194@10.46.0.6:31896>, presumably derived from the P-Associated-URI; but receives "403 Forbidden - You must register first with a S-CSCF". The Oneplus sends SIP REGISTER at packet 56, receiving 200 OK at packet 83 with P-Associated-URI <sip:51196@ims.mnc001.mcc001.3gppnetwork.org>. But this UE's SUBSCRIBE (packet 84) incorporates the same Contact used in the REGISTER request: <sip:c57d4262-e59d-4530-a0f4-b4faaa2fb1c6@10.46.0.8:5060>, and 200 OK arrives at packet 92. [v571-pcscf-name-check-fail.zip](https://github.com/kamailio/kamailio/files/… #### Debugging Data None acquired #### Log Messages  NB: log messages acquired prior to above pcap. The following extract shows failed name check (udomain.c lines 580 - 599) for username 51194, while 001010000051194 was registered: ``` Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_registrar_pcscf [service_routes.c:210]: getContactP(): This is a request - using first via to find contact Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_registrar_pcscf [service_routes.c:218]: getContactP(): searching for contact with host:port:proto contact [1://10.46.0.6:31894] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:459]: get_pcontact_from_cache(): Searching for contact with AOR [sip:51194@10.46.0.6:31894] in P-CSCF usrloc based on VIA [1://10.46.0.6:31894] Received [1://10.46.0.6:31409], Search flag is 0, reverse_search 0 Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:469]: get_pcontact_from_cache(): Have an AOR to search for Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:474]: get_pcontact_from_cache(): checking for rinstance Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [usrloc.c:157]: get_aor_hash(): Returning hash: [1746035570] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:509]: get_pcontact_from_cache(): get_pcontact slot is [370] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:5060] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:5060] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:5060] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570 Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:31894] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:31894] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:31409] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570 Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:541]: get_pcontact_from_cache(): matched contact ip address and port Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:569]: get_pcontact_from_cache(): found contact with URI [sip:001010000051194@10.46.0.6:31894] Jul 18 12:15:31 corsa03 p-cscf[58090]: ERROR: ims_usrloc_pcscf [udomain.c:583]: get_pcontact_from_cache(): user name does not match - no match here... Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:584]: get_pcontact_from_cache(): found pcontact username [1]: [001010000051194] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:585]: get_pcontact_from_cache(): incoming contact username: [51194] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:643]: get_pcontact_from_cache(): contact not found in memory Jul 18 12:15:31 corsa03 p-cscf[58090]: INFO: ims_registrar_pcscf [service_routes.c:277]: getContactP(): Contact not found based on Contact-header, trying IP/Port/Proto Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:459]: get_pcontact_from_cache(): Searching for contact with AOR [sip:51194@10.46.0.6:31894] in P-CSCF usrloc based on VIA [1://10.46.0.6:31894] Received [1://10.46.0.6:31409], Search flag is 1, reverse_search 0 Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:469]: get_pcontact_from_cache(): Have an AOR to search for Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:474]: get_pcontact_from_cache(): checking for rinstance Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [usrloc.c:157]: get_aor_hash(): Returning hash: [1746035570] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:509]: get_pcontact_from_cache(): get_pcontact slot is [370] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:5060] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:5060] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:5060] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570 Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:546]: get_pcontact_from_cache(): continuing to match on received details Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:31894] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:31894] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:31409] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570 Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:546]: get_pcontact_from_cache(): continuing to match on received details Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:569]: get_pcontact_from_cache(): found contact with URI [sip:001010000051194@10.46.0.6:31894] Jul 18 12:15:31 corsa03 p-cscf[58090]: ERROR: ims_usrloc_pcscf [udomain.c:583]: get_pcontact_from_cache(): user name does not match - no match here... Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:584]: get_pcontact_from_cache(): found pcontact username [1]: [001010000051194] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:585]: get_pcontact_from_cache(): incoming contact username: [51194] Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:643]: get_pcontact_from_cache(): contact not found in memory Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_registrar_pcscf [service_routes.c:282]: getContactP(): No entry in usrloc for 10.46.0.6:31409 (Proto 1) found! Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_registrar_pcscf [service_routes.c:319]: getContactP(): Asserted identity not set Jul 18 12:15:31 corsa03 p-cscf[58090]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[MO] c=[/etc/kamailio/pcscf/route/mo.cfg] l=16 a=26 n=send_reply Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: sl [sl.c:310]: send_reply(): reply in stateless mode (sl) Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: <core> [core/receive.c:126]: sip_check_fline(): first line indicates a SIP reply Jul 18 12:15:31 corsa03 p-cscf[58090]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[MO] c=[/etc/kamailio/pcscf/route/mo.cfg] l=17 a=2 n=exit Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: <core> [core/receive.c:528]: receive_msg(): request-route executed in: 4219 usec Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list 0x7f043587bfc0 ``` ### Possible Solutions Commenting out udomain.c lines 580-599 allowed both UE's to complete their SUBSCRIBE's, and make VoLTE calls. In the following pcap, the Oneplus REGISTER's and SUBSCRIBE's over packets 1 to 37; the Huawei process occurs from packets 45 to 98. [v571-pcscf-name-check-skipped.zip](https://github.com/kamailio/kamailio/fil… ### Additional Information ``` version: kamailio 5.7.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, 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 ``` * **Operating System**:  ``` Linux corsa03 6.5.?-gentoo-x86_64 #2 SMP PREEMPT_DYNAMIC <not recorded> CEST 2023 x86_64 AMD EPYC 7513 32-Core Processor AuthenticAMD GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3646 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3646(a)github.com>

3 months, 3 weeks

[kamailio/kamailio] dmq_usrloc: DMQ also copies and sends attributes related to contacts (PR #3679)

by Xenofon Karamanos

#### 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 - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  This PR fixes the issue in https://github.com/kamailio/kamailio/issues/1968. Any feedback is welcome. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3679 -- Commit Summary -- * dmq_usrloc: Transfer attributes * usrloc: Modify destroy order and contact xavp -- File Changes -- M src/modules/dmq_usrloc/usrloc_sync.c (132) M src/modules/usrloc/ucontact.c (9) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3679.patch https://github.com/kamailio/kamailio/pull/3679.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3679 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3679(a)github.com>

3 months, 3 weeks

[kamailio/kamailio] Ticket to monitor the progress of tls_wolfssl (Issue #3160)

by space88man

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

3 months, 3 weeks

[kamailio/kamailio] kamailio 5.7.2 & master - compile tls_wolfssl error (Issue #3610)

by badien

Compile tls_wolfssl error: checking dependency style of gcc... gcc3 checking whether make supports nested variables... (cached) yes ./configure: line 6164: syntax error near unexpected token `2.4.2' ./configure: line 6164: `LT_PREREQ(2.4.2)' make[2]: *** [Makefile:21: ../../../misc/external/wolfssl/build/include/wolfssl/options.h] Error 2 make[1]: *** [Makefile:508: modules] Error 1 make[1]: Leaving directory '/usr/local/src/kamailio-5.7/src' make: *** [Makefile:34: all] Error 2 Please check, thanks -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3610 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3610(a)github.com>

3 months, 3 weeks

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev December 2023