sr-users March 2026

sr-users@lists.kamailio.org

30 participants
38 discussions

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

There is no index for the sipp module at https://kamailio.org/docs/modules/devel/
by xf han 18 Mar '26

18 Mar '26

Hi, Team There is no index for the sipp module at https://kamailio.org/docs/modules/devel/

1 0

segfault error 6 in tm.so
by Сергей Приймак 17 Mar '26

17 Mar '26

Dear All, kindly asking to have a look at following error. When I use event_route in a way like below: event_route[dispatcher:dst-down] { xlog("Destination down: $rm $rd \n"); if(is_in_subnet($rd, "192.168.131.0/24")) { if(ds_select_dst("1", "0")) { xlog("L_ERR", "Next available destination: $dd\n"); t_newtran(); http_async_query("http://192.168.131.21:8080/recovercall.cgi?oldip=$rd&newip=$dd", "HTTP_REPLY"); } } } in case some destination is down, I experiencing following problem: 2026-03-17T13:24:53.778421+02:00 kam1 /usr/local/sbin/kamailio[2102]: ERROR: <script>: Destination down: OPTIONS 192.168.131.20 2026-03-17T13:24:53.779095+02:00 kam1 kernel: kamailio[2102]: segfault at 678 ip 00007f5eb5395d06 sp 00007fff26462980 error 6 in tm.so[112d06,7f5eb5290000+127000] likely on CPU 1 (core 1, socket 0) 2026-03-17T13:24:53.779138+02:00 kam1 kernel: Code: 8b 05 4e 32 05 00 89 10 b8 ff ff ff ff e9 d6 1a 00 00 48 8b 45 c8 48 8b 80 f0 00 00 00 48 8b 95 48 ff ff ff 8b 92 78 06 00 00 <89> 90 78 06 00 00 e8 80 56 f5 ff 85 c0 0f 89 69 03 00 00 48 8b 05 2026-03-17T13:24:53.780890+02:00 kam1 /usr/local/sbin/kamailio[2102]: ERROR: <script>: Next available destination: 192.168.131.21 2026-03-17T13:24:53.781758+02:00 kam1 /usr/local/sbin/kamailio[2102]: INFO: tm [t_lookup.c:1886]: t_newtran(): attempt to create transaction for a faked request - try to avoid it 2026-03-17T13:24:53.782445+02:00 kam1 /usr/local/sbin/kamailio[2102]: NOTICE: tm [tm.c:1748]: w_t_newtran(): transaction already in process 0x7f5eb6a550f0 2026-03-17T13:24:53.836181+02:00 kam1 /usr/local/sbin/kamailio[2127]: CRITICAL: <core> [core/pass_fd.c:284]: receive_fd(): EOF on 78 2026-03-17T13:24:53.837291+02:00 kam1 /usr/local/sbin/kamailio[2053]: ALERT: <core> [main.c:815]: handle_sigs(): child process 2102 exited by a signal 11 2026-03-17T13:24:53.837625+02:00 kam1 /usr/local/sbin/kamailio[2053]: ALERT: <core> [main.c:819]: handle_sigs(): core was not generated 2026-03-17T13:24:53.837829+02:00 kam1 /usr/local/sbin/kamailio[2053]: INFO: <core> [main.c:842]: handle_sigs(): terminating due to SIGCHLD Kamailio version 6.1.1

3 2

"No space left on device" error for TCP read?
by Sebastian Damm 16 Mar '26

16 Mar '26

Hi, We are running some Kamailio proxies with a lot of TLS clients. And they log a lot of TCP "noise" during the day, like those messages: ERROR: <core> [core/tcp_read.c:267]: tcp_read_data(): error reading: Connection timed out (110) ([]:29265 -> []:5061) ERROR: <core> [core/tcp_read.c:267]: tcp_read_data(): error reading: Connection reset by peer (104) ([]:12013 -> []:5061) That's when connections close, apparently. (BTW, those are original messages, I did not remove IP addresses.) But sometimes I see this line: ERROR: <core> [core/tcp_read.c:267]: tcp_read_data(): error reading: No space left on device (28) ([]:62892 -> []:5061) To me, this does not make sense. Can somebody explain what this means? Do I have to tweak something somewhere? Thanks, Regards, Sebastian

2 1

Kamailio and Mongodb Module Load Error
by Temilolu Fayomi 13 Mar '26

13 Mar '26

Hi All, I am currently working with kamailio version 6.0.1 and mongodb version 8.0.17. I'm successfully connecting to my mongodb database which is a replica set. I'm using the address backend for the permissions module and in my mongo replica set I have the correct table version 6 with the correct table name. My fields follow the format id, grp, ip_addr, mask, port and tag. Even though I've tried deleting and readding the table name and version and my one table test entry, I get the following errors below. ERROR: db_mongodb [mongodb_dbase.c:1065]: db_mongodb_query(): failed to store result ERROR: db_mongodb [mongodb_dbase.c:1074]: db_mongodb_query(): failed to do the query ERROR: <core> [lib/srdb1/db.c:412]: db_table_version(): error in db_query ERROR: <core> [lib/srdb1/db.c:473]: db_check_table_version(): querying version for table address ERROR: permissions [address.c:510]: init_addresses(): Error during version check for db table: address, check database structure. ERROR: permissions [permissions.c:702]: mod_init(): failed to initialize the allow_address function ERROR: <core> [core/sr_module.c:1040]: init_mod(): Error while initializing module permissions (/usr/lib/x86_64-linux-gnu/kamailio/modules/permissions.so) Is the permissions module incompatible with mongo? Any help is appreciated! Thank you, Temi

2 2

6.0.2 to 6.1.1 Migration issue: malformed From header no longer reachable in routing script
by m.cazzola＠zaleos.net 13 Mar '26

13 Mar '26

Hello, I am writing regarding a behaviour change between Kamailio 6.0.2 and 6.1.1 that is causing one of our system tests to fail. The test sends intentionally malformed SIP INVITE requests and expects a 400 response. The failing cases involve malformed From headers (e.g. an empty From). After reviewing the changelog and tracing the code, we believe the change was introduced in commit cf1c796 (cherry-picked into 6.0.4), which reworks From header parsing in get_hdr_field() to use the shared parse_to_body() function. As a result, a malformed From now causes parse_headers() to return an error earlier in receive.c, before the message reaches the routing script. Previously, the From header parsing failure was caught deep enough in execution for our sanity_check() call in the request route to detect and handle it — sending back a 400 as RFC 3261 implies. Now, the failure happens before the routing script is reached. We have attempted to intercept it in event_route[core:pre-routing] and event_route[core:receive-parse-error], but to no avail. All of our other malformed type messages (e.g. a bad Expires value or invalid RURI) work as intended. Our questions are: Is there any hook, event, or flag we could use to detect and respond to this condition before the message is dropped? If no config-level workaround exists, are there any other alternatives? Thank you in advance for your time. Best regards,  Matteo Cazzola

3 4

Dlg_refer_cid not working as expected or is it me?
by Rob Boardman 12 Mar '26

12 Mar '26

HI I'm trying to use dlg_refer_cid and the refer happens and everything seems OK, but the system seems to automatically send a BYE on the 202 Accept, it doesn't go through the notify trying notify/ringing handshake and in my case during testing other end of the refer Invite to leg c ends a 480 temp unavailable, but the call is already completed in the a-b dialog so cannot be taken back is this correct behaviour? Thanks for your help Rob Rob Boardman Solution Architect Tel: 03330147908 Email: Robert.Boardman(a)gamma.co.uk This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster(a)gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at Arbeta, 11 Northampton Road, Manchester, M40 5BP and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.

3 2

Kamailio v6.1.0 peerstate module missing in rpm
by Dries De Gendt 12 Mar '26

12 Mar '26

Hi, The release of Kamailio v6.1.0 comes with 4 new modules, such as the peerstate module. I've just updated my Kamailio but it looks like the peerstate module isn't present in the rpm. According to this page https://www.kamailio.org/docs/modules/6.1.x/ , the status is still "New" instead of "Released". Any idea when it will be included in the rpm's (or available as seperate rpm)? Best regards, Dries

2 4

missing parameter in 6.1.1 source code
by Sergio Charrua 12 Mar '26

12 Mar '26

(copied from sr-users list) Hello, I was trying to play with dispatcher's ds_ping_fr_timer parameter in Kamailio 6.1.1 as documented in https://www.kamailio.org/docs/modules/6.1.x/modules/dispatcher.html#dispatch... but apparently it is not available in source code, so Kamailio fails starting saying the parameter does not exist. Same for parameter ds_ping_fr_timeout . I have downloaded Kamailio 6.1.1 source code (from https://www.kamailio.org/pub/kamailio/6.1.1/src/) and verified in dispatch.h. Indeed the parameter is missing. Can anyone check & confirm please? meanwhile.... it seems that ds_ping_fr_timeout is available in code, but not documented, and that ds_ping_fr_timer is documented but not found in code. Maybe a typo or a missing commit ? In changelog I do see: commit d71560794239668a9488ef2aca8330307779a6c8 Author: Daniel-Constantin Mierla miconda(a)gmail.com Date: Fri Jun 6 15:00:45 2025 +0200 dispatcher: docs for ds_ping_fr_timer modparam commit df0e36fbb0dc1139acd6c5d92dc3f986cca73af2 Author: Daniel-Constantin Mierla miconda(a)gmail.com Date: Fri Jun 6 14:55:02 2025 +0200 dispatcher: new modparam ds_ping_fr_timeout - ability to set the transaction fr_timeout value for the OPTIONS pings requests Or am I missing something? On docs I find this https://www.kamailio.org/docs/modules/6.1.x/modules/dispatcher.html#dispatch... but when setting the parameter, I get the following ERROR on startup: Mar 12 12:34:54 ire-lab-kamailio1 kamailio[41230]: ERROR: <core> [core/modparam.c:217]: set_mod_param_regex(): parameter <ds_ping_fr_timer> of type <2:int> not found in module <dispatcher> Mar 12 12:34:54 ire-lab-kamailio1 kamailio[41230]: CRITICAL: <core> [core/cfg.y:4125]: yyerror_at(): parse error in config file /data/kamailio/.local/kamailio/IRE1/config_files/kamailio_dis.cfg, line 98, column 49: Can't set module parameter Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua* *www.kahea.ai http://www.kahea.ai / www.voip.pt http://www.voip.pt* *OpenTelecom* - Consulting for Telecoms, Lda Tel.: +351 callto:+351+91+104+12+6691 631 11 44 Email : *sergio.charrua(a)voip.pt sergio.charrua(a)voip.pt* This message and any files or documents attached are strictly confidential or otherwise legally protected. It is intended only for the individual or entity named. If you are not the named addressee or have received this email in error, please inform the sender immediately, delete it from your system and do not copy or disclose it or its contents or use it for any purpose. Please also note that transmission cannot be guaranteed to be secure or error-free.

1 0

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