sr-users March 2026

sr-users@lists.kamailio.org

30 participants
36 discussions

Kamailio db_redis & usrloc: Cannot Retrieve Location via Username from redis-cli
by xf han 01 Apr '26

01 Apr '26

Dear Kamailio Community, I encounter an issue when using db_redis with the usrloc module. Below are my relevant Kamailio configurations: # kamailio 6.1.1 modparam("db_redis", "schema_path", "/usr/share/kamailio/db_redis") modparam("db_redis", "keys", "location=entry:ruid&usrdom:username,domain&timer:expires") modparam("usrloc", "timer_interval", 60) modparam("usrloc", "timer_procs", 1) modparam("usrloc", "use_domain", 0) modparam("usrloc", "db_url", "redis://localhost:6379/0") modparam("usrloc", "db_mode", 3) After user 1001 successfully registers, I execute the KEYS * command in redis-cli, and the output is as follows: redis-cli KEYS * 1) "location::index::timer" 2) "location:entry::uloc-69cb7f3b-499e-1" 3) "location:timer::2026-03-31 16:01:59" My question: I cannot find the corresponding user location information via the username in redis-cli. Could anyone help me solve this problem? Thank you very much! Best regards,

1 2

Could not relay BYE to wss client
by igor.goncharovsky＠gmail.com 27 Mar '26

27 Mar '26

Hello, While developing config for WebRTC proxy. Issue I have - inability to forward BYE from UDP side to WebRTC. We have updated to 5.8.8 with no luck.Issue we have shown in log bellow: we have an error message that tells Via could not be built. Mar 20 18:42:17 pbxKamaTestSBC /usr/local/kamailio/sbin/kamailio[1390086]: DEBUG: call_1774014127984617813|BYE|<null><core> [core/msg_translator.c:1859]: check_boundaries(): no multi-part body Mar 20 18:42:17 pbxKamaTestSBC /usr/local/kamailio/sbin/kamailio[1390086]: WARNING: call_1774014127984617813|BYE|<null><core> [core/msg_translator.c:3036]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found Mar 20 18:42:17 pbxKamaTestSBC /usr/local/kamailio/sbin/kamailio[1390086]: ERROR: call_1774014127984617813|BYE|<null><core> [core/msg_translator.c:2100]: build_req_buf_from_sip_req(): could not create Via header Mar 20 18:42:17 pbxKamaTestSBC /usr/local/kamailio/sbin/kamailio[1390086]: ERROR: call_1774014127984617813|BYE|<null>tm [t_fwd.c:484]: prepare_new_uac(): could not build request Mar 20 18:42:17 pbxKamaTestSBC /usr/local/kamailio/sbin/kamailio[1390086]: ERROR: call_1774014127984617813|BYE|<null>tm [t_fwd.c:1764]: t_forward_nonack(): failure to add branchest I have tried to display tcp connection id from within the branch, but with no luck. I have printed $nh(u) and $nh(P) before t_relay() and it shows the correct URI and transport to be used. TCP connection id also shows correct and connection alive for the moment of BYE sent. Is there any known issue in that part? What tools could be additionally used to debug it? $nh(u) and $nh(P): sip:10.15.151.59:43786;transport=ws ws connection id to 10.15.151.59:43786 is: 2 # kamcmd ws.dump used_asc { connections: { 2: wss:10.15.151.59:43786 -> wss:10.1.97.53:5443 (state: OPEN, last used 2s ago, sub-protocol: sip) 1: wss:10.15.151.59:43798 -> wss:10.1.97.53:5443 (state: OPEN, last used 2s ago, sub-protocol: sip) } info: { wscounter: 2 truncated: no } }

2 1

about sip message
by zhaobin 27 Mar '26

27 Mar '26

I try send sip message from freeswitch to webrtc sip client,then kamailio send back 500 error. I have some question about this: 1:image show kamailio sl module send this error.Why sip message is trans by sl module,not tm module? 2:about error show (2/SL),i know SL is sl module,and 2 is what? 3:so i must get debug log to get more infomations about this error?

4 7

doubt using rtpengine_delete
by descartin＠bts.io 26 Mar '26

26 Mar '26

Hi, We are observing an unexpected behavior when using Kamailio together with rtpengine and would like to understand if this is expected or if there is a way to control it. Environment: Kamailio version: 6.0.4 rtpengine version: 12.5.1.48 (mr12.5.1 branch) Transport: UDP NG control socket Observation: From the rtpengine logs, we consistently see that every delete command is preceded by a query command for the same call, coming from the same Kamailio instance and even the same source port. Mar 19 08:51:05 mia-rtpengine-6 rtpengine[109401]: INFO: [SD7kus901-8c2067aa09bf3bfafd4b18ca3df0eeb9-v300g00010]: [control] Received command 'query' from 192.168.9.56:49983 Mar 19 08:51:05 mia-rtpengine-6 rtpengine[109401]: INFO: [SD7kus901-8c2067aa09bf3bfafd4b18ca3df0eeb9-v300g00010]: [control] Replying to 'query' from 192.168.9.56:49983 (elapsed time 0.000043 sec) Mar 19 08:51:05 mia-rtpengine-6 rtpengine[109401]: INFO: [SD7kus901-8c2067aa09bf3bfafd4b18ca3df0eeb9-v300g00010]: [control] Received command 'delete' from 192.168.9.56:49983 Mar 19 08:51:05 mia-rtpengine-6 rtpengine[109401]: INFO: [SD7kus901-8c2067aa09bf3bfafd4b18ca3df0eeb9-v300g00010]: [control] Replying to 'delete' from 192.168.9.56:49983 (elapsed time 0.000036 sec) We are not explicitly calling rtpengine_query() anywhere in our Kamailio configuration. Our usage is limited to rtpengine_offer(), rtpengine_answer(), and rtpengine_delete(). Is this query before delete expected behavior (e.g. implicitly triggered by rtpengine_delete() to retrieve statistics)? If so, is there any way to disable this behavior so that rtpengine_delete() does not trigger a query? related issue ?¿ Seems under high load conditions, we have observed that the NG control socket (UDP) occasionally becomes congested. For example, we have seen cases where the rtpengine server receive queue (Recv-Q) for the control socket grows significantly (hundreds of thousands of bytes), indicating that rtpengine is not draining the socket fast enough. ss -lunp | grep 7772 UNCONN 214272 0 192.168.9.129:7772 0.0.0.0:* users:(("rtpengine",pid=3320,fd=9)) this issue could have some relation with an overload of control commands, in some particular scenarios if we have these parameters set for rtpengine instances selection? modparam("rtpengine", "queried_nodes_limit", 2) modparam("rtpengine", "rtpengine_retr", 2) modparam("rtpengine", "rtpengine_tout_ms", 350) Thanks in advance for your help. David Escartín

4 3

Kamailio with 2 daisy-chained rtpengine
by Lyubomir Yatanski 24 Mar '26

24 Mar '26

Hi, I have an IMS setup with Kamailio, where the attached phone is in private network. 2 rtpengines are required to bridge between networks: 1. with 2 network interfaces - internal and external 2. with single interface in the external network (required as this interface is known to a firewall, not under my control) I'm trying to daisy-chain the 2 rtpengine instances so media path could be established, by following the documentation: modparam("rtpengine", "rtpengine_sock", "1 == udp:X.X.X.X:9910") modparam("rtpengine", "rtpengine_sock", "2 == udp:Y.Y.Y.Y:9910") after that in the script on INVITE: set_rtpengine_set("1", "2"); rtpengine_manage("internal, external"); and on the answer: set_rtpengine_set("1", "2"); rtpengine_manage("external, internal"); The behaviour I was expecting was in the offer to see only the IP of rtpengine of setid 2 and on the answer to see the internal address of the rtpengine of setid 1. What I'm actually observing is both addresses of the 2 rtpengines get appended on both directions and this seems to confuse the phone as no RTP is flowing. I'll appreciate any help, suggestions or guidance. Regards, Lyubomir Yatanski

1 0

possible performance regression in Kamailio 6.1 release related to TCP/TLS
by Henning Westerholt 24 Mar '26

24 Mar '26

Hello, we have noticed a possible performance regression related to TCP/TLS in the Kamailio 6.1.x release when installed from packages or from source with cmake, and in Kamailio 6.0 releases only when installed from source with cmake. There was a change introduced by mistake that disabled certain polling functionality related to the internal TCP stack. It can be observed at startup, or by executing "kamailio -I". See below for further information. This was fixed today in git master, 6.1 and 6.0 branches. Commit ids are: 54572ce96, f1a333b37b, b906c409. I believe that it should be only noticeable if you are having a high number of connected devices and/or a high connection rate. The mentioned fix will be included in the next minor releases of 6.1 and 5.8., as usual. Best regards, Henning Westerholt 1. Verification in log files * Affected: kamailio: INFO: <core> [core/tcp_main.c:5264]: init_tcp(): using poll as the io watch method (auto detected) * Unaffected: kamailio: INFO: <core> [core/tcp_main.c:5264]: init_tcp(): using epoll_lt as the io watch method (auto detected) 1. Verification in Kamailio binary: * Affected: $ kamailio -I | grep "poll methods" TCP poll methods: poll * Unaffected: $ kamailio -I | grep "poll methods" TCP poll methods: poll, epoll_lt, epoll_et, sigio_rt, select -- Kamailio & VoIP services - https://gilawa.com<https://gilawa.com/>

1 1

Expired tls cert for deb.kamailio.org
by Daniel Donoghue 24 Mar '26

24 Mar '26

Hello, It seems the tls certificate for deb.kamailio.org expired yesterday. With every blessing, — Daniel Donoghue Sent from my iPhone

2 1

INFO: Publishing CVEs for last months
by Daniel-Constantin Mierla 23 Mar '26

23 Mar '26

Hello, it has been decided to publish a few CVEs related to issues discovered during the past months. Depending on the deployment type and enabled components/used config functions, the security impact can be considered high, therefore is strongly recommended to upgrade your Kamailio installations to the latest maintained stable versions (6.1.1, 6.0.6 or 5.8.8) to ensure your instances are safe once the CVEs details are out. The publishing of the CVEs will be done in a couple of days, but not sooner than 2 days from now. Cheers, 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 7-8, 2026 - Berlin, Germany -- kamailioworld.com

1 0

Kamailio 5.8.5 Compatibility with RHEL 9 (Follow-up)
by m13556006811_1 20 Mar '26

20 Mar '26

Hi all, I posted this question 5 days ago and it was held for approval (I wasn't a list member then). Now I've subscribed to the list, so I'm resending to check: Are there any known compatibility issues when deploying Kamailio 5.8.5 on RHEL 9? Any configuration tweaks needed? Thanks!

3 2

Replacing certain route blocks with KEMI scripts
by Dries De Gendt 19 Mar '26

19 Mar '26

Hi, I was wondering if it is possible of keeping the request_route as native configuration, while replacing certain route blocks such as AUTH/REGISTRAR with python KEMI instead? The idea is to implement RFC8898, which basically requires me to challenge for bearer token and validate it afterwards if returned by the client. For my convencience, I had defined the AUTH and REGISTRAR block in python KEMI, and was calling them as such: request_route { ... $var(auth_route_ret) = python_exec("ksr_route_auth", "test\n"); xlog("$var(debug_level)", "[KSR_AUTH] Return code Kamailio is $var(auth_route_ret)"); if ($var(auth_route_ret) == -255) { exit; } ... $var(registrar_route_ret) = python_exec("ksr_route_registrar", "test\n"); xlog("$var(debug_level)", "[KSR_REGISTRAR] REGISTRAR return code Kamailio is $var(registrar_route_ret)"); if ($var(registrar_route_ret) == -255) { exit; } ... } While the register itself seems to work, it seems that other blocks seem to fail as they would likely expect KSR? ERROR: {1 112367482 INVITE f0af27cd-9d75-123f-79a9-b4e9b8034b4e} <core> [core/kemi.c:3772]: sr_kemi_cbname_lookup_idx(): index 1 is out of range Any idea if this would be possible, or should I determine wether to go native cfg or KEMI? Best regards, Dries

3 3

2026

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 March 2026