sr-users June 2025

sr-users@lists.kamailio.org

42 participants
45 discussions

Releasing v6.0.2
by Daniel-Constantin Mierla 25 Jun '25

25 Jun '25

Hello, I am considering to release Kamailio v6.0.2 (out of branch 6.0) on Wednesday, June 25, 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

2 2

kamailio tls module not loading
by Timothy Delin 25 Jun '25

25 Jun '25

Hi everyone, I am facing an issue where I cannot load the TLS module in my Kamailio server. I keep receiving this error message "0(1) ERROR: <core> [core/sr_module.c:529]: ksr_locate_module(): could not find module <tls> in </usr/local/lib64/kamailio/modules> 0(1) CRITICAL: <core> [core/cfg.y:4015]: yyerror_at(): parse error in config file /etc/kamailio/modules/tls.cfg, line 1, column 12-19: failed to load module" The Kamailio that I run has this configuration version: kamailio 5.8.6 (x86_64/linux) 6c71d5 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_SEND_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: 6c71d5 compiled on 04:12:34 Jun 6 2025 with gcc 12.2.1 ------------------------------------------------------------------- #global.cfg debug=2 log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " /* number of SIP routing processes */ children=2 /* Defining interfaces */ #!substdef "!PUBLICIP!$env(PUBLICIP)!" #!substdef "!UDPPORT!$env(UDPPORT)!" #!substdef "!PUBLIC_UDP_SOCKET!udp:PUBLICIP:UDPPORT!" /* Need for TLS Support */ #!substdef "!PUBLIC_TLS_SOCKET!TLS:PUBLICIP:5061!" #!substdef "!COREIP!$env(COREIP)!" #!substdef "!UDPPORT!$env(UDPPORT)!" #!substdef "!CORE_UDP_SOCKET!udp:COREIP:UDPPORT!" #!substdefs "!CORESUBNET!$env(CORESUBNET)!" /* listen addresses */ listen=PUBLIC_UDP_SOCKET listen=CORE_UDP_SOCKET /* Need for TLS Support */ listen=tls:0.0.0.0:5061 #!substdef "!DBUSERNAME!$env(DBUSERNAME)!" #!substdef "!DBPASSWORD!$env(DBPASSWORD)!" #!substdef "!DBHOST!$env(DBHOST)!" #!substdef "!DBNAME!$env(DBNAME)!" #!define DBURL "mysql://DBUSERNAME:DBPASSWORD@DBHOST/DBNAME" #!define HTTP_API_ROUTING_ENDPOINT "http://172.16.254.30:5000/api/routing" ---------------------------------------------------------------- #kamailio.cfg ####### Enable TLS ######## enable_tls=yes ####### Core Modules Section ######## include_file "/etc/kamailio/modules-core.cfg" ####### Global Parameters ######### include_file "/etc/kamailio/globals.cfg" ####### Other Modules Section ######## include_file "/etc/kamailio/modules.cfg" ####### Custom Parameters ######### /* These parameters can be modified runtime via RPC interface * - see the documentation of 'cfg_rpc' module. * * Format: group.id = value 'desc' description * Access: $sel(cfg_get.group.id) or @cfg_get.group.id */ ####### Routing Logic ######## include_file "/etc/kamailio/routes.cfg"

4 7

Dispatcher vs Keepalive
by Sergio Charrua 23 Jun '25

23 Jun '25

Hello all, Just wondering your opinions on this.... The project I'm in uses a REST API to get the routes to relay the call to, and one of the main requirements is whenever an egress gateway is down, inform the REST API about its status, and the same once the gateway is up again. So I was reading the modules docs and was stuck with a question: what would be the best solution to keep track of egress gateways availability? 1 - using Keepalive with DRouting to ping each endpoint's address:port , even though the solution is going to use RTJson with the JSON route list returned from a REST API which makes DRouting virtually useless, unless for using the list of gateways to send OPTIONS too. There is no event:routes to execute every time a gateway is down or up.... 2 - using Dispatcher module to "watch" for each endpoint's availability, and make use of the event:route of the Dispatcher module to inform REST API that the endpoint is down or back up once again. Again, RTJson with the JSON route list returned from the REST API would be used to manage routing. I've done a few tests with Dispatcher, and it was really easy to setup the endpoint "watching" mode as well as the event:routes, but I might give a try on Keepalive if it is the better bet. Would greatly appreciate your opinions and expertise on this. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

2 2

Fwd: RFC3261 rules
by Sergey Safarov 22 Jun '25

22 Jun '25

Could you look at the attached PCAP with OPTIONS message. When OPTIONS message is received, then Kamailio generates error logs like dropping insane message from 10.140.6.38:60083 After checking the PCAP, I see extra %x00 characters after the OPTIONS message in the same UDP frame. Example [image: image.png] I have checked RFC3261 and do not see a definition of "x00" chars. Also in the same RFC, present a reference to the RFC2234 <https://datatracker.ietf.org/doc/html/rfc2234> where is described "space chars", "white space". According to RFC2223, char %x00 cannot be treated as "space" and should be treated as control (CTL) char. Also, RFC3261 does not use "CTL" chars. Using these two RFC, I can conclude, OPTIONS in the attached PCAP breaks RFC requirements, and we can request partner fix this issue on their equipment. Is anything else in the RFC can be used to justify that the given examples of OPTIONS messages violate RFCs? Sergey

7 10

How to reply 484 to uac, and send bye to uas
by 13715209697＠139.com 19 Jun '25

19 Jun '25

Hi team: uac kamailio uas --> invite --> invite <-- 200 ok <-- 484 bye ---> Here is my reply_route: onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if(status=~"[12][0-9][0-9]") { route(NATMANAGE); } if ($rs == 200) { t_reply("484", "Address Incomplete"); if (!t_cancel_callid("$ci", "$cs", "0", "200")) { xerr("t_cancel_callid failed\n"); } return; } return; } but not woking. Thanks! Han 2025-06-17

3 4

What was working Stop working, Send help
by Fernando Lopes 18 Jun '25

18 Jun '25

Hello everyone, I had this problem before https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/t… this was fix, but suddenly with everything the same it stop working, I've tried everything and nothing seems to fix the problem Logs: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 10 INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 11 INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 11 INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 12 INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 12 INFO: rtpengine [rtpengine.c:3040]: rtpp_test(): rtpengine instance <udp:10.0.0.4:2223> found, support for> INFO: jsonrpcs [jsonrpcs_sock.c:471]: jsonrpc_dgram_process(): a new child 0/4164 Started kamailio.service - Kamailio - the Open Source SIP Server. WARNING: <core> [core/tcp_main.c:1301]: find_listening_sock_info(): binding to source address 10.0.0.4:506> INFO: <core> [core/tcp_main.c:3097]: tcpconn_1st_send(): quick connect for 0x7ec47d7cfab8 sock 13 When I run this command I get this sudo kamailio -f /etc/kamailio/kamailio.cfg -DD -E -e loading modules under config path: /usr/lib/x86_64-linux-gnu/kamailio/modules 0(4778) INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Listening on udp: 10.0.0.4 [10.0.0.4]:5060 advertise <PUBLIC IP>:5060 tcp: 10.0.0.4 [10.0.0.4]:5060 advertise <PUBLIC IP>:5060 Aliases: *: 10.0.0.4:* *: <PUBLIC IP>:* 0(4778) INFO: <core> [core/tcp_main.c:5205]: init_tcp(): using epoll_lt as the io watch method (auto detected) 0(4778) INFO: rr [../outbound/api.h:53]: ob_load_api(): unable to import bind_ob - maybe module is not loaded 0(4778) INFO: rr [rr_mod.c:185]: mod_init(): outbound module not available 0(4778) INFO: jsonrpcs [jsonrpcs_sock.c:219]: jsonrpc_dgram_mod_init(): the socket /var/run/kamailio/kamailio_rpc.sock already exists, trying to delete it... 0(4778) INFO: pike [pike.c:93]: pike_init(): PIKE - initializing 0(4778) INFO: pike [ip_tree.c:79]: init_lock_set(): probing 256 set size 0(4778) INFO: <core> [main.c:3189]: main(): processes (at least): 15 - shm size: 67108864 - pkg size: 8388608 0(4778) INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 7 0(4778) INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 7 0(4778) ERROR: <core> [core/tcp_main.c:3260]: tcp_init(): bind(9, 0x74711968d9c8, 16) on 10.0.0.4:5060 : Address already in use 0(4778) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized and have this sudo iptables -L -n -v | grep 5060 12 13188 ACCEPT 17 -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 5 260 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 1 52 ACCEPT 6 -- !br-aeab3c66b5ee br-aeab3c66b5ee 0.0.0.0/0 172.19.0.5 tcp dpt:5060 0 0 ACCEPT 17 -- !br-aeab3c66b5ee br-aeab3c66b5ee 0.0.0.0/0 172.19.0.5 udp dpt:5060

3 3

RTJson current selected route
by Sergio Charrua 17 Jun '25

17 Jun '25

Hi all! doing some integrations with RTJson module for Kamailio 5.8.4, calling a REST API to return the RTJson's JSON object with 1 or multiple route elements. Kamailio converts the whole SIP headers to JSON using a Javascript function, executed by APP_JDST module, and POSTing the resulting object to the REST API via http_async module. I couldn't find a way to get the current selected route, from the RTJson object, once Kamailio iterates through the JSON object (i.e: using rtjson_push_routes or rtjson_next_route). When the RTJson module iterates through the different routes of the JSON object, is there a way to get the JSON part that defines the route currently being used by RTJson? The goal is to return some custom properties set in each route element of the route array. Once those properties are returned, Kamailio should process them. For example, RTJson supports From and To headers modification and appending new headers with the "extras" element, but there is no way that I know of to modify other headers or remove headers depending on the route. Does anyone know how: 1 - to return current route element from the routes array of the RTJson object ? 2 - to modify / remove headers other than the From and To headers, according to the custom values set in the RTJson returned from a REST API ? Thanks in advance! Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

3 4

usrloc deletes other server's data (suspected bug)
by James Browne 17 Jun '25

17 Jun '25

Hi I've two servers sharing the same postgres database, using kamailio's "server_id" value. One has server_id=184 and the other has server_id=186. I've set these parameters. modparam("usrloc", "server_id_filter", 1) modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_ops_ruid", 1) # I've tested this with both 0 and 1. When a user REGISTERs, I see data being written to two tables, as normal, from server 184. update location set expires='2025-06-11 16:31:58' ... server_id=184 ...' where ruid='uloc-b8-684999a9-31e-1' delete from location_attrs where ruid='uloc-b8-684999a9-31e-1' insert into location_attrs (username,ruid,...) values (...'uloc-b8-684999a9-31e-1' ... The problem comes when I start server 186. select contact,... etc. ..., username from location where server_id=186 select username,ruid,aname,atype,avalue from location_attrs delete from location_attrs where ruid='uloc-b8-684999a9-31e-1' What I see is that server 186 always deletes the data from the location_attrs table that belongs to server 184, which I don't think it should do. According to the usrloc documentation, server_id_filter must be set (as I've done) or "Otherwise one instance of proxy cleans records made by another proxy and that breaks its cache." Therefore this looks like a usrloc bug to me. Am I doing something wrong? I'm testing with a commit that was made yesterday (kamailio 6.1.0-dev1). James

2 1

Question about how $rc works
by Joel Serrano 17 Jun '25

17 Jun '25

Hi All, I have a simple doubt: are these snippets the same? *One:* secf_check_country($hdr(X-SRC-IP-CC)); $var(secf_cc_rc) = $rc; if ($var(secf_cc_rc) == -2) { ... *Two:* $var(secf_cc_rc) = secf_check_country($hdr(X-SRC-IP-CC)); if ($var(secf_cc_rc) == -2) { ... They both seem to work, the docs say to use option -one-. In case they do the same, is there a reason I should pick one over the other? Or is this purely cosmetic? Thanks, Joel.

2 2

Re: dns_hash_put(): unlinked item errors
by JR Richardson 17 Jun '25

17 Jun '25

> > On Jun 10, 2025, at 4:00 PM, JR Richardson via sr-users <sr-users(a)lists.kamailio.org> wrote: > > > > Hey Folks, > > > > Running kamailio 5.8.4, haven't needed or used DNS functions > > previously but recently completed clearip integration, which requires > > sip request to use URL instead of IP and resolve where to send > > request. Within hours of adding URL lookups I started getting dns_hash > > unlinked errors. I correlated the log errors to when the URL changed > > IP. I assume the caching is working because kamailio sends to the same > > IP for a few minutes, then switches IP, sends to new IP for a few > > minutes, then switches IP again and this activity continues. > > > > Here are some log errors: > > > > switch IP > > Jun 10 14:14:17 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b9fcc0 > > Jun 10 14:14:19 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b9fcc0 > > > > switch IP > > Jun 10 14:15:00 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b9ee00 > > Jun 10 14:15:03 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b9ee00 > > > > switch IP > > Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8110]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b8e640 > > Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b8e640 > > > > switch IP > > Jun 10 14:20:37 siprouter1-pve186 /usr/local/sbin/kamailio[8109]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b3eb60 > > > > switch IP > > Jun 10 14:21:12 siprouter1-pve186 /usr/local/sbin/kamailio[8117]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b830f0 > > Jun 10 14:21:23 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b830f0 > > > > Here are my DNS config parameters, nothing I've changed made any > > difference. And as far as I can tell I'm not dropping any clearip > > queries. > > dns=no > > rev_dns=no > > use_dns_failover=on > > dns_try_ipv6=no > > > > I did find a patch update for this error back from 2023 and the patch > > is in my /src/core/dns_cache.c as expected but still getting errors. > > > > Any guidance in clearing this error? > > > > Thanks. > > JR > > > Not an answer to your question, but to use failover, use_dns_cache (I believe) needs to be on. > > https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt > > Fred Posner Hi Fred, I read through the DNS docs and believe I have a good understanding, dns_cache is on my default so you don't have to explicitly define it in the config. After further diagnosis I found the dns errors "dns_hash_put(): unlinked item" happen at the same time the DNS query goes out (around 4min30sec to 5min intervals) but the errors in the log don't happen on every DNS query, they only appear when the URL IP changes. This is what I'm seeing, matching timestamps to DNS queries and SIP Invites to clearip. DNS query clearip.com IP#1 no error DNS query clearip.com IP#1 no error DNS query clearip.com IP#2 error DNS query clearip.com IP#1 error DNS query clearip.com IP#1 no error DNS query clearip.com IP#2 error DNS query clearip.com IP#2 no error DNS query clearip.com IP#2 no error DNS query clearip.com IP#1 error Because I'm not seeing any performance or SIP processing issues, I now believe the log entry is a false positive and can be disregarded, I mean it is a warning, but there is no ill effect as far as I can tell, just a lot of log messages, maybe this message should be downgraded to informational? WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item ...... WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item ...... *****(why is this one "shm_unsafe") Thanks. JR

2 1

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 June 2025