- sr-users - kamailio.org

Problem with ipsec setting of Via for outgoing message
by Minello, Loredana 24 Mar '25

24 Mar '25

Hello, I'm using Kamailio ver. 5.8.4. I configured the ims_ipsec_pcscf with modparam("ims_ipsec_pcscf", "ipsec_max_connections", 1) and call ipsec_forward with flag = IPSEC_FORWARD_FLAGS where : # - IPSEC_SEND_FORCE_SOCKET 1 # - IPSEC_FORWARD_USEVIA 256 #!define IPSEC_FORWARD_FLAGS 257 For the UE REGISTRATION I have the following flow UE PCSCF_GM_IMS REGISTER (32133) ------------------> (5060) 100 Trying (32133) <------------------ (5060) 401 Unauthorized (32133) <------------------ (5060) REGISTER (TCP) (PORT_UC) ------------------> (PORT_PS) 100 Trying (TCP) (PORT_UC) <------------------ (PORT_PS) 200 OK (TCP) (PORT_UC) <------------------ (PORT_PS) ------------------------------------------------------------------ SUBSCRIBE (UDP) (PORT_UC) ------------------> (PORT_PS) 200 Subscription (UDP) (PORT_US) <------------------ (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) The SUBSCRIBE behavior is correct : PCSCF receives message on PORT_PS and sends on PORT_PC The NOTIFY behavior is wrong: PCSCF send from PORT_PC (correct), but UE respond towards PORT_PC, defined in the Via of the NOTIFY. I know I can use the set_advertised_port() function, and in this case can work, but the function is taking a constant as a parameter, not a variable. This is causing a problem when ipsec_max_connections > 1. In that case it won't be easy to pass the correct port. I was wondering if the ipsec module should properly set the VIA port to the correct PORT_PS, rather than leaving the setting of the correct port by the kamailio.cfg. Do you have any hints on that? Thanks

1 0

Re: send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)
by Mathias Schneuwly 24 Mar '25

24 Mar '25

Thank you, I've already changed the value, but that didn't solve my issue with the blocking Kamailio. I did some tests with an older Yocto image which contains Kamailio 5.5.4 and OpenSSL 1.1.1w. With this combination I was not able to reproduce the deadlock. Am Fr., 21. März 2025 um 16:49 Uhr schrieb Harald Kapper <hk(a)kapper.net>: > Hi > > fyi – in case you need this: > > systemctl edit kamailio.service > > > > add: > > ### Editing /etc/systemd/system/kamailio.service.d/override.conf > > ### Anything between here and the comment below will become the contents > of the drop-in file > > > > [Service] > > LimitNOFILE=40960 > > > > ### Edits below this comment will be discarded > > > > (or whatever number you’d like) > > saving saves the override for systemd into (like) > /etc/systemd/system/kamailio.service.d/override.conf > > > > Afterwards you have to restart the service (systemctl restart > kamailio.service) > > > > And you should be fine. > > > > Regards, hk > > > > *Von:* Henning Westerholt via sr-users <sr-users(a)lists.kamailio.org> > *Gesendet:* Donnerstag, 20. März 2025 14:25 > *An:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch>; Henning Westerholt < > hw(a)gilawa.com> > *Betreff:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hello Mathias, > > > > yes, you can set the open files e.g. in the systemd unit file for Kamailio. > > > > Cheers, > > > > Henning > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Donnerstag, 20. März 2025 13:43 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > > I'll also give a try with 6.0.1 later. > > Meanwhile, I've tested 5.8.6 and 6.0.1 and both show the same issue. > > > > Am Do., 20. März 2025 um 10:21 Uhr schrieb Mathias Schneuwly < > mathias(a)schneuwlys.ch>: > > Hi Henning > > > > > Maybe also check the actual limits by “cat /proc/$kamailio-pid/limits” > Not 100% if its related, but if you are looking to scale this would be for > sure required. > > The limit was > > Max open files 1024 524288 files > > and I changed it now to > > Max open files 65536 65536 files > > > > Are there some recommendations for the limit? Would it make sense to > change that in the provided systemd file if you say that 1024 is not that > much? > > > > But anyway, it fails with 1024 and with 65536. > > > > I've also updated to 5.8.5 and it shows the same issue. I'll also give a > try with 6.0.1 later. > > > > > About the tls_thread_mode – you should use mode 2 if you are running > with openssl 3.x, otherwise you probably will observe random crashes. > > We are running OpenSSL 3.2.3 and tls_thread_mode is set to 2. But it still > blocks. > > > > Best regards > > Mathias > > > > Am Do., 20. März 2025 um 08:42 Uhr schrieb Henning Westerholt < > hw(a)gilawa.com>: > > Hello Mathias, > > > > 1024 open files are not that much, you should increase it for the kamailio > user. Maybe also check the actual limits by “cat > /proc/$kamailio-pid/limits” > > Not 100% if its related, but if you are looking to scale this would be for > sure required. > > > > About the tls_thread_mode – you should use mode 2 if you are running with > openssl 3.x, otherwise you probably will observe random crashes. > > > > If you are seeing the mentioned problem with 15 phones, this is clearly a > problem and should be further investigated. > > > > Cheers, > > > > Henning > > > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Donnerstag, 20. März 2025 08:07 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hi > > > > Thanks for the reply. We are using the following limits and I guess they > are the default values > > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) unlimited > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 15666 > max locked memory (kbytes, -l) 8192 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 15666 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > > But to me, it looks more like a deadlock somewhere around SSL_accept. > According to the stack trace generated with "kamctl trap", all 8 TCP > receiver processes are waiting in "#1 0x00007fa14ca04830 in > pthread_rwlock_wrlock () from /usr/lib/libc.so.6". I guess the message "Too > many references: cannot splice (109)" is just the consequence as the main > process is no longer able to dispatch jobs to the child workers. > > > > Meanwhile, I'm able to reproduce the issue. It requires a bit of brute > force, but it deadlocks reliably after a few seconds. > > > > I'm flooding Kamailio with register messages using sipexer. I'm running > the following command 3 times in parallel and always after a few seconds, > Kamailio is completely blocked. > > watch -n 0.1 "./sipexer -register -vl 3 -co -com -ex 3600 -fu "2" -au "2" > -ap "test" -tk <path to key>.key -tc <path to cert>.cer -ti -sd -ru > sip:<domain> -cu sip:2@<domain> tls:<fqdn>:5061;sleep 0.1;./sipexer > -register -vl 3 -co -com -ex 0 -fu "2" -au "2" -ap "test" -tk <path to > key>.key -tc <path to cert>.cer -ti -sd -ru sip:<domain> -cu sip:2@<domain> > tls:<fqdn>:5061" > > > > I played a bit with the parameters "modparam("tls", "init_mode", 1)" and > "tls_threads_mode = 2", but it didn't seem to change anything. > > > > Please have in mind that we usually do not stress Kamailio that much. We > have seen the issue a couple of times with around 5 to 15 SIP phones > registered. But in this usual setup, the problem does not occur reliably. > > > > Best regards > > Mathias > > > > Am Di., 18. März 2025 um 21:53 Uhr schrieb Henning Westerholt < > hw(a)gilawa.com>: > > Hello, > > > > check the ulimit settings for the kamailio user and general resource usage > on that system. In development branch there is also a feature present to > print the actual ulimits on startup. > > > > Cheers, > > > > Henning > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Montag, 17. März 2025 13:41 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hi > > > > We are using kamailio 5.8.4. > > > > Recently, we noticed, that after a few days, we see the following messages > from Kamailio `2025 Mar 17 10:22:11 ttel CRITICAL: <core> > [core/pass_fd.c:193]: send_fd(): sendmsg failed sending 55 on 52: Too many > references: cannot splice (109)`. > > > > When this happens, devices are no longer able to register. At the moment > we have no idea what might be wrong. > > > > Unfortunately, the internet does not reveal much information regarding > this issue. In one issue related to Kamailio ( > https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…), > I found the command `kamctl trap` and when I execute that, I see one issue, > which might be related, but I'm just guessing... > > > > ``` > > ---start 1782236 ----------------------------------------------------- > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 > $1 = 26 > $2 = {pid = 1782236, unix_sock = 36, idx = 0, status = 1, rank = 17, desc > = "tcp receiver (generic) child=0", '\000' <repeats 97 times>} > #0 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 > No symbol table info available. > #1 0x00007fa14ca04830 in pthread_rwlock_wrlock () from /usr/lib/libc.so.6 > No symbol table info available. > #2 0x00007fa14ac20b49 in CRYPTO_THREAD_write_lock () from > /usr/lib/libcrypto.so.3 > No symbol table info available. > #3 0x00007fa14adbd5da in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #4 0x00007fa14adbd9ca in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #5 0x00007fa14adbc907 in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #6 0x00007fa14adbd26c in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #7 0x00007fa14adbd68e in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #8 0x00007fa14abe75c6 in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #9 0x00007fa14abe840b in EVP_RAND_generate () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #10 0x00007fa14acf9282 in RAND_bytes_ex () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #11 0x00007fa14b06cce8 in ?? () from /usr/lib/libssl.so.3 > No symbol table info available. > #12 0x00007fa14b05bdf7 in ?? () from /usr/lib/libssl.so.3 > No symbol table info available. > #13 0x00007fa14b0ef036 in tls_accept (c=c@entry=0x7fa1475c0dc0, > error=error@entry=0x7ffebd9443b8) at tls_server.c:457 > ret = <optimized out> > ssl = warning: could not convert 'ssl_st' from the host encoding > (ANSI_X3.4-1968) to UTF-32. > This normally should not happen, please file a bug report. > 0x7fa147668bd0 > cert = <optimized out> > tls_c = 0x7fa14768f490 > tls_log = <optimized out> > __func__ = "tls_accept" > #14 0x00007fa14b0f7540 in tls_h_read_f (c=0x7fa1475c0dc0, > flags=0x7ffebd9647d0) at tls_server.c:1153 > r = 0x7fa1475c0ee8 > bytes_free = 16383 > bytes_read = <optimized out> > read_size = <optimized out> > ssl_error = 0 > ssl_read = 0 > ssl = 0x7fa147668bd0 > rd_buf = > "\026\003\003\004\016\v\000\004\n\000\004\a\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\026\0270\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006\003U\004\003\f\versaimfs.ch0\036\027\r230302163519Z\027\r291230163519Z0`1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003"... > wr_buf = > "\026\003\003\000A\002\000\000=\003\003\371\204\326\361\262-9\300\344gV\2316\373\235D\314\225u8\v}\215\254DOWNGRD\001\000\3000\000\000\025\377\001\000\001\000\000\v\000\004\003\000\001\002\000#\000\000\000\027\000\000\026\003\003\a\267\v\000\a\263\000\a\260\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\r>0\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006"... > rd = {buf = 0x7ffebd944480 "\026\003\003\004\016\v", pos = 1405, > used = 1405, size = 65536} > wr = {buf = 0x7ffebd954480 "\026\003\003", pos = 0, used = 0, size > = 65536} > tls_c = 0x7fa14768f490 > enc_rd_buf = <optimized out> > n = 0 > flush_flags = 0 > err_src = <optimized out> > ip_buf = '\000' <repeats 63 times> > x = <optimized out> > tls_dbg = <optimized out> > __func__ = "tls_h_read_f" > redo_read = <optimized out> > continue_ssl_read = <optimized out> > __llevel = <optimized out> > __kld = <optimized out> > __llevel = <optimized out> > __kld = <optimized out> > #15 0x000055d2519871b4 in tcp_read_headers (c=c@entry=0x7fa1475c0dc0, > read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:445 > bytes = <optimized out> > remaining = <optimized out> > p = <optimized out> > r = 0x7fa1475c0ee8 > mc = <optimized out> > body_len = <optimized out> > tvnow = {tv_sec = 1742100857, tv_usec = 944923} > tvdiff = <optimized out> > mfline = <optimized out> > mtransid = <optimized out> > __func__ = "tcp_read_headers" > #16 0x000055d251989cef in tcp_read_req (con=0x7fa1475c0dc0, > bytes_read=bytes_read@entry=0x7ffebd9647c8, read_flags=read_flags@entry=0x7ffebd9647d0) > at core/tcp_read.c:1509 > bytes = <optimized out> > total_bytes = 0 > resp = 1 > size = <optimized out> > req = 0x7fa1475c0ee8 > dst = {send_sock = 0x55d251a91020, to = {s = {sa_family = 52024, > sa_data = "\257Q\322U\000\000\002\000\000\000\376\177\000"}, sin = > {sin_family = 52024, sin_port = 20911, sin_addr = {s_addr = 21970}, > sin_zero = "\002\000\000\000\376\177\000"}, sin6 = {sin6_family = 52024, > sin6_port = 20911, sin6_flowinfo = 21970, sin6_addr = {__in6_u = > {__u6_addr8 = > "\002\000\000\000\376\177\000\000\030\000\000\000\000\000\000", __u6_addr16 > = {2, 0, 32766, 0, 24, 0, 0, 0}, __u6_addr32 = {2, 32766, 24, 0}}}, > sin6_scope_id = 0}, sas = {ss_family = 52024, __ss_padding = > "\257Q\322U\000\000\002\000\000\000\376\177\000\000\030", '\000' <repeats > 23 times>, > "\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\262+\226Q\001 > \000\000\200,5L\241\177\000\000 \020\251Q\322U\000\000 > \020\251Q\322U\000\000\200\303\257Q\322U\000\00009SG\241\177\000\000\330G\226\275\376\177\000\000\b\000\000\000\000\000\000", > __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 14 > '\016', proto_pad0 = 0 '\000', proto_pad1 = 0} > c = <optimized out> > ret = <optimized out> > again = <optimized out> > __func__ = "tcp_read_req" > #17 0x000055d25198ebec in handle_io (fm=fm@entry=0x7fa14c352c80, > events=events@entry=1, idx=idx@entry=-1) at core/tcp_read.c:1906 > ret = 8 > n = 0 > read_flags = RD_CONN_SHORT_READ > con = 0x7fa1475c0dc0 > s = 14 > resp = <optimized out> > t = <optimized out> > ee = 0x0 > __func__ = "handle_io" > error = <optimized out> > #18 0x000055d25199469b in io_wait_loop_epoll (repeat=repeat@entry=0, t=2, > h=0x55d251c49d60 <io_w>) at core/io_wait.h:1075 > n = 1 > r = 0 > fm = 0x7fa14c352c80 > revents = 1 > __func__ = "io_wait_loop_epoll" > #19 0x000055d251994e87 in tcp_receive_loop (unix_sock=<optimized out>) at > core/tcp_read.c:2026 > __func__ = "tcp_receive_loop" > #20 0x000055d25197e72c in tcp_init_children (woneinit=woneinit@entry=0x7ffebd964d1c) > at core/tcp_main.c:5391 > r = <optimized out> > i = <optimized out> > reader_fd_1 = 39 > pid = <optimized out> > si_desc = "tcp receiver > (generic)\000\000`M\226\275\376\177\000\000\001\000\000\000\000\000\000\000\210\035\223Q\322U\000\000 > \020\251Q\322U\000\000\220\315\257Q\322U\000\000\220\242/L\241\177\000\000\025\000\000\000\000\000\000\000\004\000\000\000\000\000\000\000%\020\251Q\322U\000\000HU\257Q\322U\000\000e\005\000\000\000\000\000\000 > \020\251Q\322U\000\000\3750\235Q\322U\000" > si = <optimized out> > __func__ = "tcp_init_children" > error = <optimized out> > #21 0x000055d2517c6c7e in main_loop () at main.c:1950 > i = <optimized out> > pid = <optimized out> > si = <optimized out> > si_desc = "udp receiver child=7 sock=10.0.90.1:5060\000\000\000\000\322U\000\000?\342\017K\241\177\000\000\022\000\000\000\377\377\377\377\200\006\265L\241\177\000\000\253m\237L\241\177\000\000\361|\003\000\000\000\000\000\t\000\000\000\000\000\000\000Sat > Mar 15 05:25:32 2025\n\000\264L\241\177\000" > nrprocs = <optimized out> > woneinit = 1 > __func__ = "main_loop" > error = <optimized out> > #22 0x000055d2517bc151 in main (argc=<optimized out>, argv=<optimized > out>) at main.c:3256 > cfg_stream = <optimized out> > c = <optimized out> > r = <optimized out> > tmp = 0x7ffebd966e7f "" > tmp_len = 32673 > port = 5060 > proto = 0 > aproto = 0 > ahost = 0x0 > aport = 0 > options = 0x55d251aa74b8 > ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" > ret = -1 > seed = 3209119183 > rfd = <optimized out> > debug_save = <optimized out> > debug_flag = <optimized out> > dont_fork_cnt = 0 > n_lst = <optimized out> > p = <optimized out> > st = {st_dev = 24, st_ino = 46237, st_nlink = 2, st_mode = 16888, > st_uid = 899, st_gid = 899, __pad0 = 0, st_rdev = 0, st_size = 40, > st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1742012732, tv_nsec = > 217328715}, st_mtim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_ctim = > {tv_sec = 1742012732, tv_nsec = 217328715}, __glibc_reserved = {0, 0, 0}} > l1 = <optimized out> > tbuf = '\000' <repeats 32 times>, > "\030\202\237\275\376\177\000\000@\002\000\000@\003\000\000\001", '\000' > <repeats 23 times>, "@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003", '\000' <repeats 11 times>, "\001", > '\000' <repeats 118 times>... > option_index = 12 > long_options = {{name = 0x55d251a9230b "help", has_arg = 0, flag = > 0x0, val = 104}, {name = 0x55d251a937a4 "version", has_arg = 0, flag = 0x0, > val = 118}, {name = 0x55d251a9826a "alias", has_arg = 1, flag = 0x0, val = > 1024}, {name = 0x55d251a92310 "subst", has_arg = 1, flag = 0x0, val = > 1025}, {name = 0x55d251a92316 "substdef", has_arg = 1, flag = 0x0, val = > 1026}, {name = 0x55d251a9231f "substdefs", has_arg = 1, flag = 0x0, val = > 1027}, {name = 0x55d251a92329 "server-id", has_arg = 1, flag = 0x0, val = > 1028}, {name = 0x55d251a92333 "loadmodule", has_arg = 1, flag = 0x0, val = > 1029}, {name = 0x55d251a9233e "modparam", has_arg = 1, flag = 0x0, val = > 1030}, {name = 0x55d251a92347 "log-engine", has_arg = 1, flag = 0x0, val = > 1031}, {name = 0x55d251a938c1 "debug", has_arg = 1, flag = 0x0, val = > 1032}, {name = 0x55d251a92352 "cfg-print", has_arg = 0, flag = 0x0, val = > 1033}, {name = 0x55d251a9235c "atexit", has_arg = 1, flag = 0x0, val = > 1034}, {name = 0x55d251a92363 "all-errors", has_arg = 0, flag = 0x0, val = > 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} > __func__ = "main" > [Inferior 1 (process 1782236) detached] > ---end 1782236 ------------------------------------------------------- > > ``` > > > > Does anybody have an idea what this could be? I never saw that with > previous versions, and now we can see it on several instances, but we are > yet unable to reproduce. > > > > Not sure if this might be related, but we also see many messages like `Mar > 17 13:39:03 ttel /usr/sbin/kamailio[2882127]: CRITICAL: <core> > [core/tcp_main.c:5558]: tcp_timer_check_connections(): message processing > timeout on connection id: 402 (state: 0) - closing` > > > > Best regards > > Mathias > >

1 0

Dispatcher module resets URI parameters
by Marat Gareev 22 Mar '25

22 Mar '25

Hello, I encountered a problem that ds_select_domain function does not save URI parameters. I found workaround: if (!ds_select_domain( "1", 4, 3 )) { send_reply("502", "Bad Gateway"); exit; } if (!strempty($(ou{uri.params}))) { $ru = $ru+";"+$(ou{uri.params}); } But this can lead to duplicates if the URI in the dispatcher list contains the same parameter. Is there any other reliable way to keep original URI parameters while using the dispatcher? Thanks

2 1

send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)
by Mathias Schneuwly 20 Mar '25

20 Mar '25

Hi We are using kamailio 5.8.4. Recently, we noticed, that after a few days, we see the following messages from Kamailio `2025 Mar 17 10:22:11 ttel CRITICAL: <core> [core/pass_fd.c:193]: send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)`. When this happens, devices are no longer able to register. At the moment we have no idea what might be wrong. Unfortunately, the internet does not reveal much information regarding this issue. In one issue related to Kamailio ( https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…), I found the command `kamctl trap` and when I execute that, I see one issue, which might be related, but I'm just guessing... ``` ---start 1782236 ----------------------------------------------------- [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 $1 = 26 $2 = {pid = 1782236, unix_sock = 36, idx = 0, status = 1, rank = 17, desc = "tcp receiver (generic) child=0", '\000' <repeats 97 times>} #0 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 No symbol table info available. #1 0x00007fa14ca04830 in pthread_rwlock_wrlock () from /usr/lib/libc.so.6 No symbol table info available. #2 0x00007fa14ac20b49 in CRYPTO_THREAD_write_lock () from /usr/lib/libcrypto.so.3 No symbol table info available. #3 0x00007fa14adbd5da in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #4 0x00007fa14adbd9ca in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #5 0x00007fa14adbc907 in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #6 0x00007fa14adbd26c in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #7 0x00007fa14adbd68e in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #8 0x00007fa14abe75c6 in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #9 0x00007fa14abe840b in EVP_RAND_generate () from /usr/lib/libcrypto.so.3 No symbol table info available. #10 0x00007fa14acf9282 in RAND_bytes_ex () from /usr/lib/libcrypto.so.3 No symbol table info available. #11 0x00007fa14b06cce8 in ?? () from /usr/lib/libssl.so.3 No symbol table info available. #12 0x00007fa14b05bdf7 in ?? () from /usr/lib/libssl.so.3 No symbol table info available. #13 0x00007fa14b0ef036 in tls_accept (c=c@entry=0x7fa1475c0dc0, error=error@entry=0x7ffebd9443b8) at tls_server.c:457 ret = <optimized out> ssl = warning: could not convert 'ssl_st' from the host encoding (ANSI_X3.4-1968) to UTF-32. This normally should not happen, please file a bug report. 0x7fa147668bd0 cert = <optimized out> tls_c = 0x7fa14768f490 tls_log = <optimized out> __func__ = "tls_accept" #14 0x00007fa14b0f7540 in tls_h_read_f (c=0x7fa1475c0dc0, flags=0x7ffebd9647d0) at tls_server.c:1153 r = 0x7fa1475c0ee8 bytes_free = 16383 bytes_read = <optimized out> read_size = <optimized out> ssl_error = 0 ssl_read = 0 ssl = 0x7fa147668bd0 rd_buf = "\026\003\003\004\016\v\000\004\n\000\004\a\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\026\0270\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006\003U\004\003\f\versaimfs.ch0\036\027\r230302163519Z\027\r291230163519Z0`1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003"... wr_buf = "\026\003\003\000A\002\000\000=\003\003\371\204\326\361\262-9\300\344gV\2316\373\235D\314\225u8\v}\215\254DOWNGRD\001\000\3000\000\000\025\377\001\000\001\000\000\v\000\004\003\000\001\002\000#\000\000\000\027\000\000\026\003\003\a\267\v\000\a\263\000\a\260\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\r>0\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006"... rd = {buf = 0x7ffebd944480 "\026\003\003\004\016\v", pos = 1405, used = 1405, size = 65536} wr = {buf = 0x7ffebd954480 "\026\003\003", pos = 0, used = 0, size = 65536} tls_c = 0x7fa14768f490 enc_rd_buf = <optimized out> n = 0 flush_flags = 0 err_src = <optimized out> ip_buf = '\000' <repeats 63 times> x = <optimized out> tls_dbg = <optimized out> __func__ = "tls_h_read_f" redo_read = <optimized out> continue_ssl_read = <optimized out> __llevel = <optimized out> __kld = <optimized out> __llevel = <optimized out> __kld = <optimized out> #15 0x000055d2519871b4 in tcp_read_headers (c=c@entry=0x7fa1475c0dc0, read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:445 bytes = <optimized out> remaining = <optimized out> p = <optimized out> r = 0x7fa1475c0ee8 mc = <optimized out> body_len = <optimized out> tvnow = {tv_sec = 1742100857, tv_usec = 944923} tvdiff = <optimized out> mfline = <optimized out> mtransid = <optimized out> __func__ = "tcp_read_headers" #16 0x000055d251989cef in tcp_read_req (con=0x7fa1475c0dc0, bytes_read=bytes_read@entry=0x7ffebd9647c8, read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:1509 bytes = <optimized out> total_bytes = 0 resp = 1 size = <optimized out> req = 0x7fa1475c0ee8 dst = {send_sock = 0x55d251a91020, to = {s = {sa_family = 52024, sa_data = "\257Q\322U\000\000\002\000\000\000\376\177\000"}, sin = {sin_family = 52024, sin_port = 20911, sin_addr = {s_addr = 21970}, sin_zero = "\002\000\000\000\376\177\000"}, sin6 = {sin6_family = 52024, sin6_port = 20911, sin6_flowinfo = 21970, sin6_addr = {__in6_u = {__u6_addr8 = "\002\000\000\000\376\177\000\000\030\000\000\000\000\000\000", __u6_addr16 = {2, 0, 32766, 0, 24, 0, 0, 0}, __u6_addr32 = {2, 32766, 24, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 52024, __ss_padding = "\257Q\322U\000\000\002\000\000\000\376\177\000\000\030", '\000' <repeats 23 times>, "\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\262+\226Q\001 \000\000\200,5L\241\177\000\000 \020\251Q\322U\000\000 \020\251Q\322U\000\000\200\303\257Q\322U\000\00009SG\241\177\000\000\330G\226\275\376\177\000\000\b\000\000\000\000\000\000", __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 14 '\016', proto_pad0 = 0 '\000', proto_pad1 = 0} c = <optimized out> ret = <optimized out> again = <optimized out> __func__ = "tcp_read_req" #17 0x000055d25198ebec in handle_io (fm=fm@entry=0x7fa14c352c80, events=events@entry=1, idx=idx@entry=-1) at core/tcp_read.c:1906 ret = 8 n = 0 read_flags = RD_CONN_SHORT_READ con = 0x7fa1475c0dc0 s = 14 resp = <optimized out> t = <optimized out> ee = 0x0 __func__ = "handle_io" error = <optimized out> #18 0x000055d25199469b in io_wait_loop_epoll (repeat=repeat@entry=0, t=2, h=0x55d251c49d60 <io_w>) at core/io_wait.h:1075 n = 1 r = 0 fm = 0x7fa14c352c80 revents = 1 __func__ = "io_wait_loop_epoll" #19 0x000055d251994e87 in tcp_receive_loop (unix_sock=<optimized out>) at core/tcp_read.c:2026 __func__ = "tcp_receive_loop" #20 0x000055d25197e72c in tcp_init_children (woneinit=woneinit@entry=0x7ffebd964d1c) at core/tcp_main.c:5391 r = <optimized out> i = <optimized out> reader_fd_1 = 39 pid = <optimized out> si_desc = "tcp receiver (generic)\000\000`M\226\275\376\177\000\000\001\000\000\000\000\000\000\000\210\035\223Q\322U\000\000 \020\251Q\322U\000\000\220\315\257Q\322U\000\000\220\242/L\241\177\000\000\025\000\000\000\000\000\000\000\004\000\000\000\000\000\000\000%\020\251Q\322U\000\000HU\257Q\322U\000\000e\005\000\000\000\000\000\000 \020\251Q\322U\000\000\3750\235Q\322U\000" si = <optimized out> __func__ = "tcp_init_children" error = <optimized out> #21 0x000055d2517c6c7e in main_loop () at main.c:1950 i = <optimized out> pid = <optimized out> si = <optimized out> si_desc = "udp receiver child=7 sock=10.0.90.1:5060\000\000\000\000\322U\000\000?\342\017K\241\177\000\000\022\000\000\000\377\377\377\377\200\006\265L\241\177\000\000\253m\237L\241\177\000\000\361|\003\000\000\000\000\000\t\000\000\000\000\000\000\000Sat Mar 15 05:25:32 2025\n\000\264L\241\177\000" nrprocs = <optimized out> woneinit = 1 __func__ = "main_loop" error = <optimized out> #22 0x000055d2517bc151 in main (argc=<optimized out>, argv=<optimized out>) at main.c:3256 cfg_stream = <optimized out> c = <optimized out> r = <optimized out> tmp = 0x7ffebd966e7f "" tmp_len = 32673 port = 5060 proto = 0 aproto = 0 ahost = 0x0 aport = 0 options = 0x55d251aa74b8 ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 3209119183 rfd = <optimized out> debug_save = <optimized out> debug_flag = <optimized out> dont_fork_cnt = 0 n_lst = <optimized out> p = <optimized out> st = {st_dev = 24, st_ino = 46237, st_nlink = 2, st_mode = 16888, st_uid = 899, st_gid = 899, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_mtim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_ctim = {tv_sec = 1742012732, tv_nsec = 217328715}, __glibc_reserved = {0, 0, 0}} l1 = <optimized out> tbuf = '\000' <repeats 32 times>, "\030\202\237\275\376\177\000\000@ \002\000\000@\003\000\000\001", '\000' <repeats 23 times>, "@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003", '\000' <repeats 11 times>, "\001", '\000' <repeats 118 times>... option_index = 12 long_options = {{name = 0x55d251a9230b "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55d251a937a4 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55d251a9826a "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55d251a92310 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55d251a92316 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55d251a9231f "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x55d251a92329 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x55d251a92333 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55d251a9233e "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55d251a92347 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55d251a938c1 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55d251a92352 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x55d251a9235c "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x55d251a92363 "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" [Inferior 1 (process 1782236) detached] ---end 1782236 ------------------------------------------------------- ``` Does anybody have an idea what this could be? I never saw that with previous versions, and now we can see it on several instances, but we are yet unable to reproduce. Not sure if this might be related, but we also see many messages like `Mar 17 13:39:03 ttel /usr/sbin/kamailio[2882127]: CRITICAL: <core> [core/tcp_main.c:5558]: tcp_timer_check_connections(): message processing timeout on connection id: 402 (state: 0) - closing` Best regards Mathias

2 6

Kamailio v5.8.6 Released
by Daniel-Constantin Mierla 20 Mar '25

20 Mar '25

Hello, Kamailio SIP Server v5.8.6 stable release is out. This is a maintenance release of the latest stable branch, 5.8, that includes fixes since the release of v5.8.5. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.8.x. Deployments running previous v5.8.x versions are strongly recommended to be upgraded to v5.8.6. For more details about version 5.8.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2025/03/kamailio-v5-8-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note that 5.8.x is currently the previous stable release series, the latest is 6.0.x and v6.0.1 was released on March 10, 2025. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 0

Releasing v5.8.6
by Daniel-Constantin Mierla 20 Mar '25

20 Mar '25

Hello, I am considering to release Kamailio v5.8.6 (out of branch 5.8) on Thursday, March 20, 2025. If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. The most of the commits are backported, should any be found missing, reply to sr-dev mailing list. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 1

Issue with async_cdp_callback() of MAR diameter message
by Minello, Loredana 18 Mar '25

18 Mar '25

Hello, I have an issue during the registration phase with the Diameter MAR procedure. The issue is as follows: 1. I perform a registration. 2. The MAR is correctly sent using the function: ims_www_challenge("REG_MAR_REPLY", "$var(auth_realm)"); 3. Upon receiving the MAA, after executing async_cdp_callback(), the execution does not return to the Kamailio reply route indicated (REG_MAR_REPLY). I tried replacing t_continue with t_continue_skip_timer in the async_cdp_callback() function of the MAR (see below), and everything works correctly. //tmb.t_continue(data->tindex, data->tlabel, data->act); tmb.t_continue_skip_timer(data->tindex, data->tlabel, data->act); free_saved_transaction_data(data); return; Note: When I send the SAR, I do not have this issue, but I noticed that in the corresponding async_cdp_callback(), the t_continue_skip_timer function is used. Do you think the modification I made to async_cdp_callback() for the MAR is correct? Why does t_continue not work? Thanks.

1 0

dispatcher not distributing well?
by David Villasmil 17 Mar '25

17 Mar '25

Hello guys, i have a kamilio with a dispatcher list in db like +------------------------------------------------+----------------------------------------------+----------------------------+ | id | setid | destination | flags | priority | attrs | description | register_datetime | +------+-------+---------------------+-------+----------+------------------------------+---------------+---------------------+ | 3239 | 430 | sip:gateway-08:5080 | 0 | 10 | duid=gateway-08;weight=50 | gateway-08 | 2023-03-21 00:19:44 | | 3246 | 430 | sip:gateway-11:5080 | 0 | 10 | duid=gateway-11;weight=50 | gateway-11 | 2023-05-15 23:00:28 | | 3247 | 430 | sip:gateway-12:5080 | 0 | 10 | duid=gateway-12;weight=50 | gateway-12 | 2023-05-15 23:06:57 | | 3249 | 430 | sip:gateway-14:5080 | 0 | 10 | duid=gateway-14;weight=50 | gateway-14 | 2023-05-15 23:24:44 | | 3276 | 430 | sip:gateway-15:5080 | 0 | 10 | duid=gateway-15;weight=50 | gateway-15 | 2024-05-01 19:43:19 | | 3277 | 430 | sip:gateway-16:5080 | 0 | 10 | duid=gateway-16;weight=50 | gateway-16 | 2024-05-01 19:51:16 | | 3278 | 430 | sip:gateway-1:5080 | 0 | 10 | duid=gateway-17;weight=50 | gateway-17 | 2024-05-01 19:58:13 | | 3279 | 430 | sip:gateway-17:5080 | 0 | 10 | duid=gateway-18;weight=50 | gateway-18 | 2024-05-01 20:06:44 | | 3280 | 430 | sip:gateway-3:5080 | 0 | 10 | duid=gateway-19;weight=50 | gateway-19 | 2024-05-01 20:14:50 | | 3281 | 430 | sip:gateway-2:5080 | 0 | 10 | duid=gateway-20;weight=50 | gateway-20 | 2024-05-01 20:23:25 | +------+-------+---------------------+-------+----------+------------------------------+---------------+---------------------+ and i'm dispatching with if(!ds_select_dst("$var(dispatcher_id)", "10")) { xlog("[DISPATCH]: ds_select_dst FAILED!'\n"); send_reply("404", "No destination"); exit; } still kamailio isn't distributing at all but for some reason is favoring high-description gateways: kamctl rpc dlg.list 5 gateway-20:5080;transport=udp" 2 gateway-19:5080;transport=udp" it's forwarding calls mostly to gateway-20, gateway-19, gateway-18, gateway-17... in descending order... Why is kamailio doing that? i'd expected it to distribute to all based on the call load on each gateway. Thanks all! Regards, David Villasmil email: david.villasmil.work(a)gmail.com

3 4

Recommendations for paid work
by Anthony Ford 14 Mar '25

14 Mar '25

Hi Can anyone recommend someone that can help us upgrade our 2 Kamailio servers please. After several failed attempts to do this ourselves, it is time to call in the professionals. 5.6.0-dev to the latest The current set up is 2 servers working in tandem, redis and mysql plus nebula. We do have a test server also attached, that can be used for testing. Thanks Tony

6 5

add_contact_alias modifies only one Contact address
by James Browne 13 Mar '25

13 Mar '25

- https://kamailio.org/docs/modules/5.8.x/modules/nathelper.html#nathelper.f.… This add_contact_alias() function changes only the first Contact address in a REGISTER request, even though it's normal (RFC3261, 10.2) for a REGISTER to have multiple Contact addresses. This seems to me to be a kamailio bug. For example, a user might remove one binding while adding a second, in a REGISTER request. If kamailio relays this while adding an alias to only the expires=0 binding, then the new binding may be stored incorrectly in the registrar. James

2 4

Server selecting TCP transport
by Jon Bonilla (Manwe) 13 Mar '25

13 Mar '25

Hi all Using 5.8.4 I have a trunk with a permanent registration created by rpc in the location table. It looks like this: kamcmd> ul.lookup location sbc.mydomain.com { AoR: sbc.mydomain.com Contacts: { Contact: { Address: sip:xxx@sbc.mydomain.com Expires: -102739 Q: 1 Call-ID: dfjrewr12386fd6-343(a)kamailio.rpc CSeq: 1 User-Agent: kamailio SIP Router - RPC Server Received: [not set] Path: <sip:192.168.255.202:5060;lr> State: CS_SYNC Flags: 0 CFlags: 0 Socket: [not set] Methods: 0 Ruid: ulcx-67c9e2ff-19f8-1 Instance: [not set] Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 0 Last-Keepalive: 1741899218 KA-Roundtrip: 0 Last-Modified: 0 } } } In this situation the proxy sends the request to 192.168.255.202 which is a kamailio load balancer which is responsible for sending the call to the customer. The problem is that kamailio, when relaying this request, first performs TCP srv lookup and tries to send the request via TCP. There's no transport=tcp in the address. The lb's dns settings are: dns_try_ipv6=no dns_retr_time=1 dns_retr_no=1 dns_use_search_list=no use_dns_cache=on use_dns_failover=on dns_srv_lb=on dns_try_naptr=no dns_sctp_pref=1 dns_tcp_pref=1 dns_tls_pref=1 dns_udp_pref=1 Seems like this kamailio tries TCP SRV first, and then TLS and then UDP if the previous doesn't bring results. But no NAPTR is enabled. I don't know why it will choose TCP over UDP in this case. -- PekePBX, the multitenant PBX solution https://pekepbx.com

1 0

SDP Truncation When Relaying from WebSocket to UDP – Expected Behavior?
by Pavan Kumar 13 Mar '25

13 Mar '25

Hello Kamailio Community, I recently encountered an interesting behavior when using Kamailio to relay SIP messages from a WebSocket client to FreeSWITCH over UDP. *Observed Behavior:* - The WebSocket client sends an *INVITE* with a large SDP. - Kamailio forwards this request over UDP to FreeSWITCH. - Upon inspection, the *SDP in the relayed message appears truncated*. (Probably MTU limit) - *Surprisingly, the call still establishes successfully*, and there are no noticeable issues with audio or call setup. *My Questions:* 1. *Is this expected behavior?* Should Kamailio automatically truncate SDP when relaying from WebSocket to UDP? 2. *Could this be working accidentally?* For example, is FreeSWITCH handling the partial SDP gracefully by default? 3. *Should I be concerned about potential failures in different scenarios?* (e.g., ICE candidate loss, missing codec negotiation) I would appreciate any insights from the community on whether this is a known or expected behavior in Kamailio, or if it might be a configuration issue. Thanks in advance for your help! Best regards, Pavan Kumar

4 5

Need help using Kamailio IMS and Open5GS for 5G core
by Pete Kay 13 Mar '25

13 Mar '25

Hi I am able to compile Kamailio IMS and Open5GS. The instruction in https://open5gs.org/open5gs/docs/tutorial/02-VoLTE-setup/ is for 4G using Diameter. For 5G, we need to use HTTP protocol. Does anyone know if there is any guide on how to configure Kamailio IMS and Open5GS on 5G core using HTTP protocol for PCRF ? Thanks for millions for all your help. Pete

2 1

Re: upgrading process
by Anthony Ford 12 Mar '25

12 Mar '25

Thanks Ben Really appreciate your response Tony From: Ben Kaufman via sr-users <sr-users(a)lists.kamailio.org> Reply to: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Date: Wednesday, 12 March 2025 at 16:20 To: "sr-users(a)lists.kamailio.org" <sr-users(a)lists.kamailio.org> Cc: Ben Kaufman <bkaufman(a)bcmone.com> Subject: [SR-Users] Re: upgrading process Luckily there usually aren't a lot of breaking changes in Kamailio updates, and config files are mostly back compatible. That doesn't mean that there are never changes, but it does mean that the number of issues to resolve is usually small. * wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc There shouldn't really be any changes needed to config for the patch/fix versions like that (third decimal place) so those should be fine (and is good practice if you're not able to quickly update to a supported version for any reason), but it shouldn't be necessary to touch every incremental version to upgrade Kamailio. Every major release has an upgrade guide from the pervious version, so in your case: * 5.6 to 5.7: https://www.kamailio.org/wikidocs/install/upgrade/5.6.x-to-5.7.0/ * 5.7 to 5.8: https://www.kamailio.org/wikidocs/install/upgrade/5.7.x-to-5.8.0/ * 5.8 to 6.0: https://www.kamailio.org/wikidocs/install/upgrade/5.8.x-to-6.0.0/ It still shouldn't be necessary to touch each individual version while upgrading. I'd recommend reading through these docs in order taking note of the following: * Look for potentially breaking changes in the core. I don't see any in those documents, but a good example would be if upgrading from 4.x to 5.x how fifo was deprecated. * Look for modules changes. Mostly you'll see things like new features which shouldn't be breaking. A few modules were deprecated/archived in 5.8 ( app_sqlang, and auth_identity). Sometimes modules have small breaking changes in them as well, for example in 6.0 the dialog module dropped support for the dlg_flag parameter. Check your kamailio configs to see if any of these listed changes will impact you. * Follow any DB upgrade changes. These are usually simple changes - things like adding an index to a column, or changing a varchar(n) datatype to be varchar(n+y) which won't break your existing config. Another reply correctly points out that you should watch for changes to the version table. This is possibly a situation where a conflict could arise: The version required for one table might be 1 in 5.6 and 2 in 6.0. It might be worth while to copy the existing version table to a new table (like version_60 for example), and use kamailio's version_table parameter to use the new version table on the updated config. (note: The upgrade guides don't show any table version changes, so you probably don't need to do this). Finally, as a recommendation, smoke test your config in docker. You might not have the container setup in a way to actually receive SIP messages, but "does the config file load correctly" is a nice thing to have resolved ahead of time. * Regards, Kaufman ________________________________ From: Anthony Ford via sr-users <sr-users(a)lists.kamailio.org> Sent: Wednesday, March 12, 2025 9:30 AM To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org> Cc: Anthony Ford <tony.ford(a)apalo.co.uk> Subject: [SR-Users] upgrading process CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi I need some help please. I am very inexperienced with Kamailio, and am trying to work out how to upgrade without rewriting any of the current config. I am going from 5.6.0 to 6.0.0 and wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc. until I need to make a bigger step, and may have to change tables etc. In the document for upgrading 5.6.x to 5.7.x it says make change to Watch table, but I have no watch table. Very confused. Thanks Tony

1 0

CANCEL suspension and forking
by Alex Balashov 12 Mar '25

12 Mar '25

Hi, When a CANCEL is received and matches a known INVITE transaction, it is forked to all existing branches of that INVITE transaction, at least with these settings: modparam("tm", "cancel_b_method", 2) modparam("tm", "failure_reply_mode", 3) I have a mobile endpoint that is slow to be pushed awake and reregister, tsilo-style, and by the time it finally appears on the scene, the underlying INVITE transaction has been terminated. Accordingly, that endpoint receives no CANCEL. You might ask why that's a problem, if it also didn't receive a forked INVITE. The problem is that Apple's CallKit requires interactive presentation of VoIP APNS notifications as though they are "calls", leading to the phenomenon of what might be called "ghost calls" extrinsically to the actual mobile application. Anyway, I am aware of numerous possible solutions to this problem in principle; most involve sending an out-of-band SIP message to signify an alternative cancellation of the call. However, wonder if I am missing some best-practical approach, perhaps through an overlooked TM facility, or some way of keeping the transaction alive longer than the CANCEL from the UAC would ordinarily require? I don't see how that would work, but thought better to ask. Thanks! -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

3 4

upgrading process
by Anthony Ford 12 Mar '25

12 Mar '25

Hi I need some help please. I am very inexperienced with Kamailio, and am trying to work out how to upgrade without rewriting any of the current config. I am going from 5.6.0 to 6.0.0 and wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc. until I need to make a bigger step, and may have to change tables etc. In the document for upgrading 5.6.x to 5.7.x it says make change to Watch table, but I have no watch table. Very confused. Thanks Tony

3 3

Set TTL for skipped NAPTR record due to all IPs are unreachable
by Mathias Schneuwly 11 Mar '25

11 Mar '25

Hi I've a question regarding skipped NAPTR records. In our setup, we are using quite big DNS TTLs (860400). If there is an issue on the target server, the NAPTR record is marked as skipped "Mark to skip _sips._tcp.... NAPTR record due to all IPs are unreachable" until the TTL is expired. Since our TTLs are so big, the destination is no longer reachable during this time, even if the server is reachable again. I've seen that I can set "dns_cache_max_ttl" to reduce the time, but this is of course for all cached DNS records. Is there a way to set how long a NAPTR record is skipped or disable the feature at all? Or maybe skip the NAPTR only for the current dialog or transaction? Thanks for your help Best regards Mathias

2 7

Kamailio v6.0.1 Released
by Daniel-Constantin Mierla 10 Mar '25

10 Mar '25

Hello, Kamailio SIP Server v6.0.1 stable release is out. This is a maintenance release of the latest stable branch, 6.0, that includes fixes since the release of v6.0.1. There is no change to database schema or configuration language structure that you have to do on previous installations of v6.0.x. Deployments running previous v6.0.x versions are strongly recommended to be upgraded to v6.0.1. For more details about version 6.0.1 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2025/03/kamailio-v6-0-1-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 0

Releasing v6.0.1
by Daniel-Constantin Mierla 10 Mar '25

10 Mar '25

Hello, I am considering to release Kamailio v6.0.1 (out of branch 60) on Monday, March 10, 2025. If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 1

Kamailio with Presence Module and Publishing by Asterisk
by Ludovic GRANGE 05 Mar '25

05 Mar '25

Hi, I'm having a problem managing the presence between Kamailio and Asterisk. I have configured Kamailio as a presence server. Asterisk sends presence information via publishing sip request. My softphone which uses Kamailio as a presence server and as a proxy has 2 BLFs configured. On a first call, the presence status is displayed on the 2 keys. But for the 2nd call, only the extension receiving the call has its status changed on the BLF. Via sngrep, the Publishing requests arrive on Kamailio but the DB is not updated because the e-tag does not match. If I wait until the end of the expiry period (60s for the test), the DB is flushed and the 1st call works again. Could you please help me? Thank you Translated with DeepL.com (free version) -- Bien cordialement, Bande verticale Prosoluce Ludovic Grange Administrateur systèmes & réseaux Picto mailludovic.grange(a)prosoluce.fr <mailto:ludovic.grange@prosoluce.fr> Picto tél 05 31 61 62 25 <tel:+33531616225> Picto webwww.prosoluce.fr <https://www.prosoluce.fr> Logo Prosoluce

3 5

Best practices for proxy protocol and TLS offloading
by Alex Balashov 04 Mar '25

04 Mar '25

Hello, I am converting a Kamailio WSS/TLS gateway to pure TCP, with an external HAProxy handling TLS termination and emitting the proxied connection as plain TCP. I am using the PROXYv2 protocol, with `tcp_accept_haproxy=yes`, to convey the upstream network and transport-layer reachability info into Kamailio. I am trying to figure out best practices for mapping the contacts on those connections to the proxied connections themselves. For registrations, tcp_force_alias() (with `tcp_accept_aliases=yes`) works well, and inbound calls go to the right place. However, I'm not quite sure what to do with other flows, such as, for example, in-dialog requests on inbound calls going to the TLS endpoints. There are obviously a lot of possibilities, all or most of which I've tinkered with. These generally involve either {s.replace}-ing `;transport=tls` with `;transport=tcp` in the contacts received from the client, or using the traditional `nathelper` contact alias / RURI alias bag of tricks. However, I don't like the former solution because it leads to a non-compliant R-URI going to the endpoint (it's not the ;transport it sent in its contact), and I don't like the latter because it seems like there are too many moving parts. When tcp_force_alias() works so well for registrations, there must be some small linchpin I'm missing for normal request-reply flows. What is it? Thanks in advance! -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

2 4

Topos Module Questions
by David Tek 04 Mar '25

04 Mar '25

Hello, I am trying to configure the Topos module and have some questions. # topos:msg-outgoing vs topos:msg-sending https://www.kamailio.org/docs/modules/5.8.x/modules/topos.html#topos.e.msg_… I am trying to understand the difference between these two event routes(beyond the content of the SIP message ). I notice that both are invoked when OPTIONS are generated by the local Kamailio server but only msg-sending is invoked for messages transiting the Kamailio( ie proxied, not locally generated). Is there some difference in how these event_routers are invoked beyond the content of the SIP message? # tops -> requests/replies When I am in event_route[topos:msg-sending] { and invoke 'drop', does this apply to the current message or does it apply to the transaction? I have a Kamailio node with devices on either side. Let's call side A untrusted and side B trusted. I want TOPOS happening against the untrusted device but not the trusted device. I have found that when I invoke 'drop' on a request coming from A to B, it disables TOPOS not only on that packet, but also the reply comes from B back to A, TOPOS isn't applied when the reply exits Kamailio towards A. So if I call 'drop' on the request coming from A to B, the reply coming from B to A has no TOPOS applied. How do I get TOPOS applied to all traffic facing a particular device while leaving that traffic un-stripped when the same traffic is interacting with other devices that are trusted? Thanks, David

2 2

Torso Sex Toy for Men & Women
by feifeiwangf＠uusextoy.com 04 Mar '25

04 Mar '25

The sex doll torso is a very light mini sex doll. Usually, its weight is 4kg to 20kg. These sex doll torsos are made of TPE or silicone. Of course, they are all very safe materials. https://www.sextorso.com/

3 2

SHA-256 HASH
by Social Boh 04 Mar '25

04 Mar '25

Hello list, is it possible create a user using sha-256 hash? My goal is Asterisk PBX Register ----- sha-256 digest authentication -> Kamailio Regards -- --- I'm SoCIaL, MayBe

2 3

KEMI logging function name output
by Dmitry Sytchev 28 Feb '25

28 Feb '25

Hi all! By default logging from KEMI with KSR.log() is prefixed with something like this: <core> [core/kemi.c:152]: sr_kemi_core_log(): Can we somehow disable this not to print it every time with every message? Thanks! [image: image.png] -- Best regards, Dmitry Sytchev

2 2

SNMP thresholds
by Sergio Charrua 27 Feb '25

27 Feb '25

Hi all! we have set SNMP stats on our production server. The server is only receiving 1% of the calls, less than 1 CAPS, but we are receiving some SNMP alarms that are a bit weird to us. [image: image.png] This is an example. As we were unsure about the thresholds to be set for Msg Queue, we set Minor to 20 and Major to 100, which resulted in some alarms when we exceeded the Major threshold. From our understanding, the Max Major MSG Queue threshold was 2176, which obviously generated an alarm. But we can't understand why when a Msg Queue depth of 1280 generated an Minor Threshold alarm when the threshold is 20!! Why not generate a Major Threshold alarm instead, as it did reach the Major Threshold ? Also, does anyone have a clue on how to estimate Major and Minor thresholds? How does this Msg Queue handler work? Is it Kamailio's level or on OS/Kernel level that it gets the statistics from? Apart from the official Kamailio SNMPStats docs, any doc or article one would share? greatly appreciated. ( I so much hate SNMP!!! :) ) Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

1 0

Tweaking TCP/TLS connection timers
by Ihor Olkhovskyi 27 Feb '25

27 Feb '25

Hello, I'm observing a bit strange behavoir of Kamailio, but maybe I'm wrong in my assumptions. In some cases Kamailio just closes absolutely valid TCP connection, as I see it in Wireshark [image: image.png] At the same time I do see in Kamailio logs a lots of lines with tcp_timer_check_connections(): message processing timeout on connection id: XXXXX (state: 0) - closing I see that many TCP connections are closing (and it's ok as we have mobile devices connected and loosing connections for them is ok) But for me this connection is perfectly ok looking on TCP keepalives, what can cause this behavoir? I have these TCP options tcp_connect_timeout=30 tcp_conn_wq_max=63536 tcp_crlf_ping=yes tcp_delayed_ack=yes tcp_fd_cache=yes tcp_keepalive=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=10 tcp_linger2=30 Kamailio 5.8.3 Any hints are appreciated. -- Best regards, Ihor (Igor)

2 2

Kamailio and TLS-PSK Support
by Юрій Пивоваров 27 Feb '25

27 Feb '25

Dear Kamailio Community, I am currently exploring the possibility of configuring Kamailio to use TLS-PSK (Pre-Shared Key) for secure SIP signaling. Has anyone successfully configured Kamailio to work with TLS-PSK? If so, could you share any guidance, configuration examples, or relevant modules that need to be adjusted? In this setup, the SIP client will be a device with very limited resources, making it impossible to use certificates. This is why I am specifically looking into a TLS-PSK solution. I have also tried configuring stunnel as a proxy and set listen = tcp:127.0.0.1:5061 in kamailio config, but I haven't been able to get it working. Any suggestions on what might be missing or misconfigured? Thank you in advance for your help!

1 0

Drop RTP Flow and move to another point
by Social Boh 26 Feb '25

26 Feb '25

Hello List, before spending much time on solving this scenario, I'd like to know if this kind of operation can be done using some Kamailio function (maybe dlg_req_within?) or other method. The scenario is: a B2B-1 server call two different destinations, one is a SIP trunk and another is another B2B-2. Both calls go through Kamailio which uses RTPEngine for the media flow. The idea is to drop the first B2B from RTP Flow (leave for signaling) when both calls are answered and leave everything to Kamailio-RTPEngine, like: LegA: Kamailio-RTPEngine -> B2B-2 LegB: Kamailio-RTPEngine -> SIP trunk Thank you in Advance Regards --- I'm SoCIaL, MayBe

1 1

PRACK Retransmission and 408 Timeout Issue in Kamailio
by 高秉寬 26 Feb '25

26 Feb '25

Dear Kamailio Developers, I am using Kamailio as a SIP server to facilitate a phone call, but I am encountering an issue where the call cannot be established due to Kamailio sending a 408 Request Timeout to the caller. Issue Details: - A (Caller) sends an initial INVITE to Kamailio, which then forwards it to B (Callee). The INVITE contains the following Supported header: Supported: timer,100rel,replaces,precondition,from-change,histinfo,tdialog I suspect the *precondition* option may be relevant to the issue. - *B* responds with a *183 Session Progress* message, which includes: Require: 100rel,precondition Kamailio correctly forwards this response to *A.* - *A* then sends a *PRACK* request to Kamailio. However, this request contains: Require: sec-agree Supported: timer Notably, *precondition* is absent from both the *Require* and *Supported* headers. - Kamailio forwards this *PRACK* to *B*, and *B* responds with *200 OK*, including: Supported: 100rel,from-change,tdialog - However, Kamailio does not seem to acknowledge *B's 200 OK* and instead *keeps retransmitting the PRACK* to *B*. B responds with *200 OK* again, but the cycle repeats. - After three retransmissions of *PRACK*, Kamailio eventually sends *408 Request Timeout* to *A*, leading *A* to send a *CANCEL* request. Device Used: - *Caller (A):* Asus ROG Phone 5 - *Callee (B):* Asus ROG Phone 6 Both are commercially available mobile phones. Possible Cause: According to *3GPP TS 24.229, Subclause 5.1.3.1*, If the received response with an SDP body includes a Require header with > the "precondition" option-tag, the originating UE shall include a Require > header with the "precondition" option-tag in responses with an SDP body to > subsequent requests that include an SDP body and include the "precondition" > option-tag in either the Supported or Require header field received > in-dialog. In this case: - The *183 Session Progress* from *B* contains Require: *precondition*. - The subsequent *PRACK* from *A* does not include *precondition* in either *Require* or *Supported*. Could this mismatch be the reason Kamailio keeps retransmitting *PRACK* and ignoring *B's 200 OK*? Or could there be another factor causing Kamailio to behave this way? If additional details are needed, please let me know. Best regards, Ping Kuan Kao

3 4

Issue with registrations
by Anthony Ford 26 Feb '25

26 Feb '25

Hi Version = 5.6.0-dev0 We are seeking help to resolve an issue with registering devices to 3CX (All 3CX servers, have tried 8 different ones) . all the auth info including passwords etc are identical on the 3cx servers. We use Kamailio to register mobile sim cards to 3rd party sip servers i.e. 3CX. We send the normal Username, server addresses and auth details but are experiencing failures with 3CX rejecting the registration and return Proxy Auth failure 407. We have noticed in the pcaps from both sides that the expire value is changing from 180 as an example to 0. As an example In the uac reg_dump the values are : l_uuid: +447529135850<tel:+447529135850> l_username: +447529135850<tel:+447529135850> l_domain: sbc-mt.asim.apalo.io<http://sbc-mt.asim.apalo.io/>;transport=udp r_username: 1001 r_domain: egte.3cx.uk<http://egte.3cx.uk/> realm: <null string> auth_username: FdlHDC1IvA auth_password: extracted auth_ha1: none auth_proxy: sip:egte.3cx.uk:5060 expires: 60 flags: 0 diff_expires: -1738853736 timer_expires: 0 reg_init: 1738850836 reg_delay: 0 contact_addr: k01.asim.apalo.io<http://k01.asim.apalo.io/>;transport=tcp socket: <null string> [cid:image001.png@01DB86AB.2701F190] [cid:image002.png@01DB86AB.2701F190] [cid:image003.png@01DB86AB.2701F190] Looking forward to hearing from you. Many thanks Tony Ford

3 3

REG_MAR_REPLY never get executed
by stinktohighheaven＠gmail.com 26 Feb '25

26 Feb '25

Using Kamailio v5.3, based on the example for scscf found here: https://github.com/kamailio/kamailio/blob/master/misc/examples/ims/scscf/ka… after calling ims_www_challenge("REG_MAR_REPLY", "$var(realm)", "$var(alg)"); the control never goes to REG_MAR_REPLY route block, but it goes to the start of the requet_route block. here is the kamailio.cfg script: request_route { ....... /* Handle Registrations */ if (is_method("REGISTER")) { route(REGISTER); exit; } ...... } /** * Handling of REGISTER requests */ route[REGISTER] { ...... #!ifdef WITH_AUTH if (!ims_www_authenticate("$var(realm)")) { #!else if ($var(alg) == "3GPP-Digest" && !ims_www_authenticate("$var(realm)")) { #!endif if ($? == -2) { send_reply("403", "Authentication Failed"); exit; } else if ($? == -3) { send_reply("400", "Bad Request"); exit; } else if ($? == -9) { xdbg("Authentication re-sync requested\n"); ims_www_resync_auth("REGISTER_RESYNC_REPLY", "$var(realm)"); exit; } else { /* user has not been authenticated. Lets send a challenge via 401 Unauthorized */ xdbg("About to challenge! auth_ims\n"); ims_www_challenge("REG_MAR_REPLY", "$var(realm)", "$var(alg)"); exit; } } else { xdbg("Auth succeeded\n"); /* We need to check if this user is registered or not */ if (!impu_registered("location")) { save("PRE_REGISTER_SAR_REPLY", "location"); exit; } else { isc_match_filter_reg("1", "location"); save("REGISTER_SAR_REPLY", "location"); exit; } } } } /** * Handling of REGISTER MAR replies */ route[REG_MAR_REPLY] { xlog("L_DBG","maa_return code is $avp(s:maa_return_code)\n"); /* this is async so to know status we have to check the reply avp */ switch ($avp(s:maa_return_code)) { case 1: /* success */ xdbg("MAR success - 401/407 response sent from module\n"); break; case -1: /* failure */ xerr("MAR failure - error response sent from module\n"); break; case -2: /* error */ xerr("MAR error - sending error response now\n"); send_reply("503", "MAR failed"); break; default: xerr("Unknown return code from MAR, value is [$avp(s:maa_return_code)]\n"); send_reply("503", "Unknown response code from MAR"); break; } exit; } and here's the log: 12(18) ERROR: *** cfgtrace:request_route=[REGISTER] c=[/usr/local/etc/kamailio/kamailio.cfg] l=757 a=27 n=ims_www_challenge 12(18) DEBUG: ims_auth [authorize.c:293]: challenge(): Looking for route block [REG_MAR_REPLY] 12(18) INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [-2] 12(18) DEBUG: ims_auth [authorize.c:317]: challenge(): Need to challenge for realm [ims.mnc071.mcc432.3gppnetwork.org] 12(18) DEBUG: ims_auth [authorize.c:324]: challenge(): Checking if REGISTER is authorized for realm [ims.mnc071.mcc432.3gppnetwork.org]... 12(18) DEBUG: ims_auth [authorize.c:1449]: get_auth_userdata(): Searching auth_userdata for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 12(18) DEBUG: ims_auth [authorize.c:460]: challenge(): Suspending SIP TM transaction 12(18) DEBUG: ims_auth [authorize.c:1529]: multimedia_auth_request(): Sending MAR 12(18) DEBUG: ims_auth [cxdx_mar.c:574]: cxdx_send_mar(): Successfully sent async diameter 70(76) INFO: ims_auth [cxdx_avp.c:137]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp (avp_code = 297, vendor_id = 0) 70(76) DEBUG: ims_auth [authorize.c:1303]: new_auth_vector(): new auth-vector with ck [d2deb48b5b3b614ba9112396e3c036fe] with status 0 70(76) DEBUG: ims_auth [authorize.c:1560]: pack_challenge(): setting QOP str used is [, qop="auth"] 70(76) DEBUG: ims_auth [authorize.c:1562]: pack_challenge(): QOP str used is [, qop="auth"] 70(76) DEBUG: ims_auth [authorize.c:1449]: get_auth_userdata(): Searching auth_userdata for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 70(76) DEBUG: ims_auth [authorize.c:1458]: get_auth_userdata(): Found auth_userdata 70(76) DEBUG: ims_auth [authorize.c:1682]: add_auth_vector(): Adding auth_vector (status 1) for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org / IMPI 432710000010044(a)ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 70(76) DEBUG: ims_auth [cxdx_mar.c:486]: async_cdp_callback(): DBG:UAR Async CDP callback: ... Done resuming transaction 70(76) INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [1] 70(76) ERROR: tm [t_suspend.c:197]: t_continue_helper(): active transaction not found 70(76) DEBUG: ims_auth [cxdx_mar.c:87]: free_saved_transaction_data(): Freeing saved transaction data: async 11(17) ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/usr/local/etc/kamailio/kamailio.cfg] l=380 a=5 n=route

4 8

tm stats on prometheus
by Alexis Fidalgo 25 Feb '25

25 Feb '25

Hello all, i found that tm stats (kamcmd tm.stats) are not present in the response of xhttp_prom (prometheus), so in new configurations that we applied, we have no information/stats on reply codes. Is there a way to add this information to the xhttp_prom response? thanks in advance. regards

2 4

debug memory usage by AVP
by Sergey Safarov 25 Feb '25

25 Feb '25

In the "kamcmd mod.stats all shm" output i see to big value for "create_avp" metric Module: core { tcpconn_new(1205): 35104 counters_prefork_init(211): 61952 create_avp(178): 20737248 cfg_clone_str(132): 304 cfg_shmize(221): 1248 main_loop(1381): 16 Is possible to print AVP list and APV content without kamailio config change and restart?

1 0

Kamailio uses an ephemeral IP port instead of the port defined in $fs
by Leonid Fainshtein 24 Feb '25

24 Feb '25

Hi, I am using Kamailio v.5.8.4 on Ubuntu 24.04, kernel 6.8.0-51-generic In the configuration script I explicitly set $fs="udp:adrr:port". In normal situations, it works properly and I see that the UDP SIP requests are sent from the requested IP and port. Due to some reasons, free space on the server root filesystem was exhausted. I cleaned up the file system and everything looked good except the fact that Kamailio started to send messages from ephemeral IP ports instead of the port defined in $fs. Restart of Kamailio didn't solve the problem. But the server reboot fixed the issue. I don't understand how the lack of free disk space can cause such a problem and I'm afraid that there is another reason that I am missing. Has anybody seen such a problem? Best regards, Leonid

3 3

Outdated location information on deleted registrations
by Mathias Schneuwly 19 Feb '25

19 Feb '25

Hi I'm using Kamailio 5.8.4 and the python KEMI module. When I move the registration from one device to another, I can see for a while two entries with 'kamctl ul show' where the Expires parameter of the "old" registration is set to "deleted" and the "new" registration shows the seconds until the registration expires. "Address": "sips:200101@10.0.1.130:42323 ;transport=tls", "Expires": "deleted", -- "Address": "sips:200101@10.0.1.129:56374 ;transport=tls", "Expires": 3600, So far so good. When I try to fetch the actual registration address using "registrar.reg_fetch_contacts" or "registrar.lookup_xavp", I'm always getting the "old" deleted registration address instead of the new address as long as the deleted record is not removed. Feb 18 10:05:51 ttel /usr/sbin/kamailio[2356327]: WARNING: {1 511 INVITE 952600514-5060-52(a)BA.A.C.BCI} <core> [core/kemi.c:157]: sr_kemi_core_log(): reg_fetch_contacts: sips:200101@10.0.1.130:42323;transport=tls Feb 18 10:05:51 ttel /usr/sbin/kamailio[2356327]: WARNING: {1 511 INVITE 952600514-5060-52(a)BA.A.C.BCI} <core> [core/kemi.c:157]: sr_kemi_core_log(): lookup_xavp: aor=200101, uri=sips:200101@10.0.1.130:42323;transport=tls, socket=tls:10.0.1.1:5061, dsturi=None I also see that the database is only updated after the deleted entry is removed. Until then, the database still contains the old address. Btw, I'm using "modparam("usrloc", "db_mode", 2)", which would explain the delayed persisting into the database. 62|uloc-67b44aae-23f48e-2|200101||sips:200101@10.0.1.130:42323 ;transport=tls|||2460724.91858218|-1.0|482845299-5060-1(a)BA.A.B.BDA|2002|2460724.87691551|0|0|Grandstream GXV3350 1.0.3.52|tls:10.0.1.1:5061 |7135|<urn:uuid:00000000-0000-1000-8000-C074AD188038>|1|0|52|0|16 I'm asking myself whether the behavior is correct that "registrar.reg_fetch_contacts" and "registrar.lookup_xavp" are returning the deleted information instead of the "new" registration information? If yes, is there another way how I could get the "new" registration information? I'm not really interested in the old outdated information... Best regards Mathias

2 2

Info: maintenance work for kamailio.org server on Tuesday, Feb 18, 2025
by Daniel-Constantin Mierla 18 Feb '25

18 Feb '25

Hello, there is a planned mainenance work on the infrastructure for the server hosting kamailio.org services (among them: the main website, wiki, mailing lists) on next week, Tuesday, February 18, 2025, to start about 10:00am Berlin time (CET). Expect some intervals of unavailability, we hope they will be short and most of them not noticeable for the majority accessing these services during the day. Once the work is finished, an announcement will be sent out. The apt repository, github project and the matrix chat channels should not be affected, they can be accessed as usual and can be used a backup communication channels if anyone observes something that has to be addressed. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 2

Asterisk ConfBridge behind Kamailio+Rtpengine
by Rahul mm 18 Feb '25

18 Feb '25

Dear all, Thanks for the amazing product ! I’m trying my hands on a scenario involving Asterisk for video_sfu and a bunch of webrtc and sip clients. The condition is that every call must essentially be a conference call for the participants to add more dynamically. I front ended asterisk with Kamailio and RTPEngine for ssl offloading, load balancing, and registrations. So when one user is present in the conference (his invite SDP containing one audio and one video line) i get local video and MoH back, but when another user joins in and a re-invite is send from asterisk containing two video lines - one for the sendrecv and other for send only, rtpengine doesn’t process the sendonly video line - keeps it as is RTP/AVP instead of making it *UDP/TLS/RTP/SAVPF.* *Is there a way to achieve that? or I’m on the wrong path ?* BR, RM

1 0

Kamailio - asterisk registration issue & transparent proxy
by Enzo Damato 17 Feb '25

17 Feb '25

Hi. I'm working on setting up kamailio as a load balancer for some asterisk instances. I've build a configuration that is working for the most part, but I am encountering issues with calls from the asterisk instances to users who's registrations were processed through the kamailio instance. When these users register, asterisk saves thier AOR as the address of the kamailio instance, and then subsequently tires to send invites to kamailio, instead of to the UAC. Since kamailio just proxied the registration, without actually registering the user, it doesn't know what to do with the invite, and the call fails. I would like to configure kamailio to rewrite the sip requests so that all traffic appears to be coming from the end user, rather than from the kamailio instance, essentially making the proxy transparent. Is this possible? Thank you, Enzo Damato

4 6

Prioritize specific codecs
by Temilolu Fayomi 17 Feb '25

17 Feb '25

Hello, I am working with inbound calls on kamailio (specifically fax), and was wondering if there was a way to re-prioritize the codecs found in the sdp of an invite. I've looked at using the sdpops module, but haven't been able to re-arrange the priority of the codecs listed. I've tried removing codecs to help incoming faxes switch over to t38 per my upstream providers instructions (calls will do a t38 re-invite if the g729a is the highest priority). I am just looking for which direction to go from here or if I misunderstand the nature of faxing and kamailio. Thank you in advance, Temilolu Fayomi

3 3

Constant crashes across versions
by Jon Bonilla (Manwe) 17 Feb '25

17 Feb '25

Hi all I have a setup of several proxies behind a load balancer and all of them have several coredumps every day. I've tried versions 5.3, 5.5 and 5.8 and all of them crash I didn't have dbgsym packages installed but now I've built a 5.8.4 version in one of them and can gdb the coredumps. Can't see anything particular and I'm wondering if I'm doing anything wrong. I'm descompressing the coredump with lz4cat. Sometimes I see that the system generates 3 coredumps at the same time. I've tried running gdb in one of them and exec "bt full" I usually see "can't access memory" in some of them but inb others I don't see anything relevant. I'm attaching one coredump. I don't even know if I'm doing it properly. Could you please guide me to how to debug what's going on? thanks

2 4

Info: sipexer v1.2.0 released
by Daniel-Constantin Mierla 11 Feb '25

11 Feb '25

Hello, a short note to announce that that sipexer v1.2.0 was released: - https://github.com/miconda/sipexer/releases/tag/v1.2.0 It is a modern and flexible SIP testing cli tool that can be used to send SIP signalling messages over UDP/TCP/TLS/WebSocket. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 0

DNS Unlinked Warnings
by John Larsen 10 Feb '25

10 Feb '25

Hi Everyone, We recently attempted an upgrade from kamailio 5.5.7 to 5.7.6. We immediately started to receive a log of warning logs similar to `dns_hash_put_shm_unsafe(): unlinked item 0x7f08799dcd90` The code shows that this warning log was added to the DNS cache in september 2023 - but its unclear what it means to have an unlinked item exactly? Is anyone able to shed any light on how DNS entries might become unlinked, and what the implications of it are? thanks John Larsen John Larsen Tech Lead EJohn.Larsen(a)symbio.global W symbio.global This communication is intended only for the person to whom it is addressed and may contain confidential material. If you received this communication in error, please inform the sender immediately and delete all copies. Please think of the environment before printing this email.

2 1

switch between "sips:" and "sip:" schema
by James Lipski 10 Feb '25

10 Feb '25

Hello, I have a kamailio installation where it's basically doing transport protocol translation. To go into more detail, I have a UA communicating over TLS towards kamailio/ and kamailio forwards the request to a freeswitch installation via UDP, so call-flow is as follows: UA <-- (TLS) --> Kamailio <-- (UDP) --> Freeswitch For the most part, this does work/ it's only when I use a UA that uses "sips:" as the schema instead of "sip:" where issues occur -- in my current topology, freeswitch has some weird behavior where it doesn't disconnect the call properly. At least based on my testing, I believe the issue is relating to the schema -- as the UA in question does have the ability to switch between schemas/ when using "sip:" instead of "sips:" over TLS, no issues with the same call-flow. In the event that I do come across a UA that doesn't have that ability, I was wondering if kamailio has the ability to switch schemas when it sends traffic over the UDP connection. I'm able to replace most aspects of the packet with "sip:" however the only header which contains the "sips:" schema is the contact header. With this alone, it propagates to the B-leg side (UDP side) of the call; and will cause freeswitch to not disconnect calls properly. I'm using the topos module to obfuscate my topology, not sure if that matters. -------- For example, on the A-leg side of the call, kamailio receives this: INVITE sips:12125551000@dev-sip.server.com:5061 SIP/2.0 Via: SIP/2.0/TLS 172.16.1.194:5061;branch=z9hG4bK236557042;rport;alias From: <sips:100000000@dev-sip.server.com>;tag=444048970 To: <sips:12125551000@dev-sip.server.com> Call-ID: 1326419916-5061-4(a)BHC.BG.B.BJE CSeq: 21 INVITE Contact: <sips:100000000@172.16.1.194:5061;transport=tls> Proxy-Authorization: Digest username="100000000", realm="dev-sip.server.com", nonce="Z6Ig0WeiH6Vdxtvej0I3XGCTUAEfh+0/", [uri="sips:12125551000@dev-sip.server.com](mailto:uri=)", response="43c1487d077db36a70fffdd1e25b3b52", algorithm=MD5 Max-Forwards: 70 User-Agent: Grandstream HT812 1.0.57.1 Supported: replaces, path, timer, eventlist Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE Content-Type: application/sdp Accept: application/sdp, application/dtmf-relay Content-Length: 1034 v=0 o=100000000 8000 8000 IN IP4 172.16.1.194 s=SIP Call c=IN IP4 172.16.1.194 t=0 0 m=audio 5004 RTP/SAVP 0 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=crypto:1 AEAD_AES_256_GCM inline:UlX3PAjNBP/aQwtwyf5ymsfJciB+VdFxMElO5zLVooUqmcEzZ8YyQQk9stI=|2^32 ------------------------------------------------------ On the B-leg side of the call, kamailio forwards the following to freeswitch: INVITE sip:12125551000@fs.server.com SIP/2.0 Via: SIP/2.0/UDP 10.64.52.113:5080;branch=z9hG4bK1552.89ec9666294034a5611f908f2a6a427e.0;i=f From: "Test" <sip:16461234567@dev-sip.server.com>;tag=444048970 To: <sip:12125551000@fs.server.com> Call-ID: 1326419916-5061-4(a)BHC.BG.B.BJE CSeq: 21 INVITE Max-Forwards: 15 Supported: replaces, path, timer, eventlist Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE Content-Type: application/sdp Accept: application/sdp, application/dtmf-relay Content-Length: 316 Contact: <sips:btpsh-67a21ca2-2dbe86-1@10.64.52.113:5080> v=0 o=100000000 8000 8000 IN IP4 10.64.52.113 s=SIP Call c=IN IP4 10.64.52.113 t=0 0 m=audio 13060 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv a=ptime:20 -------------------------------------------------- As with the above, I was wondering if there is a way within kamailio to switch schemas on the b-leg side of this call example; specifically is there a way to update the contact header so it doesn't use the "sips:" schema when it traverses the UDP connection. Thank you for you time.

4 5

Auth_ephemeral module setup
by Anoop L 04 Feb '25

04 Feb '25

Hi, I'm trying to understand and setup Auth_ephemeral for authentication. My goal is to authenticate users dynamically using an web service for that I bumped into auth_ephemeral module. In the module how is a request made to the web service? Are username and password fetched from Pseudo-Variables variable? Is this module to be worked with xhttp module for http requests? Any help is much appreciated.

1 0

Auth_ephemeral Module Setup
by anoop96115＠outlook.com 04 Feb '25

04 Feb '25

Hi, I'm trying to understand and setup Auth_ephemeral for authentication. My goal is to authenticate users dynamically using an web service for that I bumped into auth_ephemeral module. In the module how is a request made to the web service? Are username and password fetched from Pseudo-Variables variable? Is this module to be worked with xhttp module for http requests? Any help is much appreciated.

1 0

Testing Kamailio IMS Modules with IPSec as P-CSCF
by Saeed Mogharian 03 Feb '25

03 Feb '25

Hi, I’m looking for suggestions on how to test Kamailio IMS modules, specifically for the IMS registration process over IPSec when Kamailio is configured as the P-CSCF node. Are there any scripts or IMS clients available that can help with this? Thanks in advance!

2 1

Kamailio 6.0 presentation at FOSDEM 2025
by Henning Westerholt 31 Jan '25

31 Jan '25

Hello, just a quick announcement, that tomorrow afternoon will be a presentation about Kamailio 6.0 at the FOSDEM conference in Brussels, Belgium [1]. Usually all the talks in this room are streamed online as well. I am happy also to meet during the conference to chat about Kamailio or other topics, just send me a (direct) message. Best regards, Henning [1] https://fosdem.org/2025/schedule/event/fosdem-2025-5978-kamailio-6-0-develo… -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

1 0

Strange memory stats
by Barry Flanagan 30 Jan '25

30 Jan '25

Hi, I have a 5.8.4 runing on Bookworm that after a while reports very strange memory stats like this: shmem.fragments: '729' shmem.free_size: '18446744009887078560' shmem.max_used_size: '67043934736' shmem.real_used_size: '67043698528' shmem.total_size: '3221225472' shmem.used_size: '67034971568' The settings are: SHM_MEMORY=3072 PKG_MEMORY=256 The shmem.free_size and max_used/max_size seem quite wrong. The output of "mod.stats all shm" shows the below: - 'Module: jsonrpcs' - Total: 0 - 'Module: core' - Total: 7891296 - 'Module: rr' - Total: 0 - 'Module: dialog' - Total: 146144 - 'Module: permissions' - Total: 130672 - 'Module: auth' - Total: 0 - 'Module: topoh' - Total: 0 - 'Module: sl' - Total: 14048 - 'Module: siptrace' - Total: 79184 - 'Module: sqlops' - Total: 0 - 'Module: acc' - Total: 0 - 'Module: xlog' - Total: 0 - 'Module: dmq' - Total: 1520 - 'Module: avpops' - Total: 0 - 'Module: rtpengine' - Total: 69328 - 'Module: db_mysql' - Total: 0 - 'Module: geoip2' - Total: 32 - 'Module: pv' - Total: 0 - 'Module: registrar' - Total: 0 - 'Module: textops' - Total: 0 - 'Module: htable' - Total: 6375584 - 'Module: tsilo' - Total: 74048 - 'Module: usrloc' - Total: 554240 - 'Module: tm' - Total: 6812224 - 'Module: websocket' - Total: 2551536 - 'Module: pike' - Total: 6880 - 'Module: tls' - Total: 5462960 - 'Module: tmx' - Total: 21968 - 'Module: kex' - Total: 3536 - 'Module: cfgutils' - Total: 128 - 'Module: sipdump' - Total: 32 - 'Module: domain' - Total: 5920 - 'Module: dispatcher' - Total: 20144 Thanks! -Barry

2 8

Kamailio v6.0.0 Released - new major version is out
by Daniel-Constantin Mierla 29 Jan '25

29 Jan '25

Kamailio v6.0.0 is out – it comes with 5 new modules and important updates to the core components and existing modules. The increment of the first version number reflects several important updates, among them: multi-threaded option for UDP receiving, option for specifying a range of ports to listen to, support for expressions with variables for most of the module functions parameters, internal libraries are directly inked to the core, support to use cmake to compile and install Kamailio. You can read a bit more detailed release notes at: * https://www.kamailio.org/w/kamailio-v6.0-0-release-notes/ Many thanks to all developers and community members that made possible this release. v6.0.0 brings more flexibility and optimizations across many existing components and modules, new parameters, functions, variables and transformations. Enjoy Kamailio v6.0.0! Thank you for flying Kamailio! Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users