sr-users March 2026

sr-users@lists.kamailio.org

30 participants
38 discussions

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

12 Mar '26

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#dispatc… 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? 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+66>91 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 1

Dispatcher Probing issues
by Sergio Charrua 11 Mar '26

11 Mar '26

Hi all, I'm having issues to get the dispatcher probing settings right. the requirements are: - when Kamailio starts, it needs to probe all endpoints to check availablility (nearly 5000 endpoints, in total) by probing each one of them, sending SIP OPTIONS every ds_ping_interval=5 - when receiving a valid reply (ds_ping_reply_codes set toclass=2), and after ds_inactive_threshold=2, Kamailio should send an EVAPI message to inform endpoint is UP - htable gw_last is reset with key=IP:PORT of endpoint, value = timestamp) - htable gw_probe is reset with key=IP:PORT of endpoint, value = 0 (NOT PROBING) - when receiving an invalid reply or timeout, and after ds_probing_threshold=3, Kamailio should send an EVAPI message to inform endpoint is DOWN - htable gw_last is reset (key=IP:PORT of endpoint , value = $null) and htable gw_probe reset with key=IP:PORT value = 1 (PROBING) - an htable gw_last with autoexpire=60s will launch a probe to the endpoint set in the key of gw_last (key=IP:PORT , value = timestamp). Once probing, it should send an EVAPI message with the endpoint's status (UP or DOWN) respecting the ds_inactive_threshold and ds_probing_threshold parameters. - and htable gw_probe with key=IP:PORT is updated to 1 - probing is started by updating dispatcher's endpoint status using: jsonrpc_exec('{"jsonrpc":"2.0","method":"dispatcher.set_state", "params" : ["ip", 1, "' + $var(endpointIPPort) + '" ] }'); - I have events like dispatcher:dst-up and dispatcher:dst-down, where it resets gw_last and sets gw_probe to respective values, depending on probing response. My issues: - Kamailio is starting with all endpoints set as FLAGS=IP and starts probing all endpoints - if endpoint fails replying to SIP Options, because it is offline, and there is a TIMEOUT, it will be set with FLAGS=IX *AND* Probing stops without any instructions from my script; AND dispatcher:dst-down is never called - if endpoint replies OK to SIP Options, dispatcher:dst-up is not called neither so I cannot reset gw_probe and gw_last values. - I have event_route[tm:local-request] who detects the sending of the SIP OPTIONS and implements t_on_reply("PROBE_REPLY") and t_on_failure("PROBE_FAILURE"). if SIP Options receives a reply, endpoint is UP, t_on_reply("PROBE_REPLY") is launched as expected; if SIP Options fails, t_on_failure("PROBE_FAILURE") is not called. - when the gw_last expires (every 60s) and starts Probing the endpoint, it is never on 60s but always after 70s of last probe period, and in time it increases up to 85s. Why?? - SIP OPTIONS retransmissions are indeed correct: 0.5s + 1s + 2s + 4s then timeout (as per TM fr_timer=10000 setting) Questions: - what dispatcher settings should I use to achieve my goal? I have been playing with ds_probing_mode and with dispatcher's list FLAGS value, but no results so far.... - any solution? NOTES: - dispatcher is only used for probing, not failover or call distribution Current Dispatcher definitions: modparam("dispatcher", "db_url", "cluster://k1") modparam("dispatcher", "ds_ping_interval", 5) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_from", " sip:dispatcher@10.20.0.4") modparam("dispatcher", "ds_probing_threshold", 3) modparam("dispatcher", "ds_inactive_threshold", 2) modparam("dispatcher", "ds_ping_latency_stats", 1) modparam("dispatcher", "ds_probing_mode", 0) modparam("dispatcher", "ds_latency_estimator_alpha", 200) modparam("dispatcher", "reload_delta", 0) modparam("dispatcher", "flags", 0) modparam("dispatcher", "ds_ping_reply_codes", "class=2") modparam("dispatcher", "xavp_dst", "DISPATCHER_DST") modparam("dispatcher", "ds_timer_mode", 0) Current TM definitions: modparam("tm", "auto_inv_100", 1) modparam("tm", "failure_reply_mode", 3) modparam("tm", "fr_timer", 10000) modparam("tm", "fr_inv_timer", 120000 modparam("tm", "max_inv_lifetime", 180000 modparam("tm", "max_noninv_lifetime", 32000) modparam("tm", "retr_timer1", 500) modparam("tm", "retr_timer2", 4000) modparam("tm", "wt_timer", 5000) modparam("tm", "cancel_b_method", 2) Current Dispatcher list: +----+-------+--------------------+-------+----------+----------------+-------------+ | id | setid | destination | flags | priority | attrs | description | +----+-------+--------------------+-------+----------+----------------+-------------+ | 4 | 1 | sip:10.20.0.6:5060 | 9 | 1 | cc=1;duid=sbc1 | | +----+-------+--------------------+-------+----------+----------------+-------------+ 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+66>91 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.

3 3

topos_htable autoexpire not working
by Ivan Ribakov 11 Mar '26

11 Mar '26

I have Kamailio 6.0.6. I'm using topos module with topos_htable storage backend. Since enabling topos+topos_htable in production I observed slow but steady shared memory consumption increase to the point where Kamailio ultimately runs out of shared memory. In attempt to create an MRE, I have boiled down the config to the following module params: modparam("topos", "storage", "htable") modparam("topos", "branch_expire", 60) modparam("topos", "dialog_expire", 60) modparam("topos", "clean_interval", 60) modparam("topos", "rr_update", 1) modparam("topos", "methods_noinitial", "OPTIONS,NOTIFY") modparam("topos", "contact_host", KAM_ROUTER_PRIVATE_IP) modparam("topos_htable", "topos_htable_dialog", "topos_dialog=>size=14;autoexpire=60") modparam("topos_htable", "topos_htable_transaction", "topos_transaction=>size=14;autoexpire=60") My expectation is that this config will only store up to a minute of topos data, at which point htable autoexpiry will start freeing up shared memory. I set up a SIPp test that throws a call at Kamilio that routes to non-existing destination and INVITE TX times out after 5sec and 408 is returned to the SIPp UAC. I'm generating 200 calls per second up to 1K concurrent calls. Below are the prettified core.shmmem output for first 2 minutes with topos/topos_htable enabled: | Timestamp | Total | Free | Used | Real_Used | Max_Used | Fragments | |:------------|:----------|:---------|:---------|:------------|:-----------|------------:| | 21:12:25 | 100.00 MB | 94.71 MB | 5.29 MB | 5.29 MB | 5.29 MB | 1 | | 21:12:35 | 100.00 MB | 42.13 MB | 57.87 MB | 57.87 MB | 57.87 MB | 2 | | 21:12:45 | 100.00 MB | 35.59 MB | 65.16 MB | 64.41 MB | 65.16 MB | 38 | | 21:12:55 | 100.00 MB | 30.79 MB | 69.79 MB | 69.21 MB | 69.79 MB | 55 | | 21:13:05 | 100.00 MB | 30.43 MB | 70.87 MB | 69.57 MB | 70.87 MB | 70 | | 21:13:15 | 100.00 MB | 26.33 MB | 73.67 MB | 73.67 MB | 73.67 MB | 2 | | 21:13:25 | 100.00 MB | 24.50 MB | 76.12 MB | 75.50 MB | 76.12 MB | 222 | | 21:13:35 | 100.00 MB | 21.30 MB | 78.91 MB | 78.70 MB | 78.91 MB | 244 | | 21:13:45 | 100.00 MB | 18.66 MB | 82.26 MB | 81.34 MB | 82.26 MB | 283 | | 21:13:55 | 100.00 MB | 17.54 MB | 83.72 MB | 82.46 MB | 83.72 MB | 323 | | 21:14:05 | 100.00 MB | 14.49 MB | 86.74 MB | 85.51 MB | 86.74 MB | 357 | | 21:14:15 | 100.00 MB | 14.85 MB | 86.74 MB | 85.15 MB | 86.74 MB | 332 | | 21:14:25 | 100.00 MB | 14.00 MB | 86.97 MB | 86.00 MB | 86.97 MB | 263 | And here are the results for the same test with topos/topos_htable disabled: | Timestamp | Total | Free | Used | Real_Used | Max_Used | Fragments | |:------------|:----------|:---------|:---------|:------------|:-----------|------------:| | 21:16:00 | 100.00 MB | 94.62 MB | 5.38 MB | 5.38 MB | 5.38 MB | 1 | | 21:16:10 | 100.00 MB | 44.01 MB | 55.99 MB | 55.99 MB | 55.99 MB | 1 | | 21:16:20 | 100.00 MB | 40.60 MB | 59.49 MB | 59.40 MB | 59.49 MB | 2 | | 21:16:30 | 100.00 MB | 43.20 MB | 59.49 MB | 56.80 MB | 59.49 MB | 6 | | 21:16:40 | 100.00 MB | 41.02 MB | 59.49 MB | 58.98 MB | 59.49 MB | 3 | | 21:16:50 | 100.00 MB | 41.83 MB | 59.49 MB | 58.17 MB | 59.49 MB | 4 | | 21:17:00 | 100.00 MB | 40.20 MB | 60.15 MB | 59.80 MB | 60.15 MB | 3 | | 21:17:10 | 100.00 MB | 40.58 MB | 60.81 MB | 59.42 MB | 60.81 MB | 12 | | 21:17:20 | 100.00 MB | 40.49 MB | 60.81 MB | 59.51 MB | 60.81 MB | 15 | | 21:17:30 | 100.00 MB | 38.81 MB | 61.19 MB | 61.19 MB | 61.19 MB | 2 | | 21:17:40 | 100.00 MB | 38.46 MB | 62.50 MB | 61.54 MB | 62.50 MB | 7 | | 21:17:50 | 100.00 MB | 36.74 MB | 63.27 MB | 63.26 MB | 63.27 MB | 2 | | 21:18:00 | 100.00 MB | 37.51 MB | 63.27 MB | 62.49 MB | 63.27 MB | 7 | In both cases dlg.stats shows no more than 1K active dialogs. However shmmem does not appear to be freed up after 60sec with topos/topos_htable enabled. Is my understanding of the "autoexpire" incorrect or is this a bug in topos/topos_htable? *IVAN RIBAKOV* Lead Engineer *__________________________________________* CAIT, Campus Montegancedo, Pozuelo de Alarcón 28223 Madrid - Spain [image: https://www.linkedin.com/company/18014823] <https://www.linkedin.com/company/18014823>

3 2

How to route a specific reply instead of triggering failure route? (Handling 422 reply)
by Benoit Panizzon 11 Mar '26

11 Mar '26

Hi Gang Not using the timer module. I just stumbled over an issue when a CPE replies with 422. I have set-up a failure route to be used when resolving the location of a registered cpe fails or if that cpe returns an error. I react on most cases like re-routing to voicemail etc. But in case of a 422 I would like to send that reply back to the caller so the call can be re-attempted with a lower session timer. For this to work, I need to route the reply back to the origin. Using t_send_reply() from within the failure route creates a new reply, missing the required Min-Se header from the original reply. Is there something like a t_route_reply()? Of would I need to extract the Min-SE header from the reply and then append it again to the reply generated with t_send_reply()? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 2

execution continues after exit?
by Benoit Panizzon 09 Mar '26

09 Mar '26

Hi Team I'm just noticed that this code is not terminating with the exit on Kamailio 5.8: $var(enabled) is 'no' This is run as part of authentication on INVITE and REGISTER method. if ($var(enabled) != "yes") { xlog("L_ERROR", "$cfg(route): $aU enabled is $var(enabled), rejecting\n"); send_reply("403","Account disabled"); exit; } xlog("L_ERROR", "$cfg(route): If enabled was no, I should not be run\n"); Why is code after exit still being executed? What am I missing? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 3

Surviving the Night Shift: A Guide to Playing Five Nights at Freddy's
by total.otter.hycl＠hidingmail.com 07 Mar '26

07 Mar '26

Hey everyone! Welcome back to the blog. If you are a fan of video games, you probably already know that the horror genre comes in all shapes, sizes, and styles. Sometimes, the absolute most terrifying gaming experiences aren't the ones with massive budgets and complex combat systems, but rather the ones that make you feel completely defenseless. A perfect example of this is the iconic survival horror title, Fnaf. It took the gaming community by storm with its incredibly unique premise, deep hidden lore, and unforgettable jump-scares. Today, I want to talk about how to dive into this game, understand its mechanics, and actually survive your first few stressful nights at Freddy Fazbear’s Pizza. https://fnafgamefree.com The Gameplay: Managing Paranoia The setup of the game is brilliantly simple but highly effective. You play as a newly hired night security guard working at a family pizza restaurant. Your shift runs from midnight to 6 AM. The catch? The restaurant's beloved animatronic mascots wander the building on their own at night, and if they happen to find you in your office, your shift ends very badly. Unlike most games where you can run or hide, here you sit in a single office chair and cannot move. Your only survival tools are a network of grainy security cameras, a couple of hallway lights, and two heavy steel doors. However, you have a strictly limited power supply. Every time you flip up the camera monitor, turn on a hallway light, or close a security door, you drain the battery. If your power runs out before 6 AM hits, the lights go pitch black, the doors open wide, and you are left completely vulnerable in the dark. It is a masterful balancing act of intense resource management and creeping paranoia.

1 0

Kamailio v5.8.8 Released
by Daniel-Constantin Mierla 06 Mar '26

06 Mar '26

Hello, Kamailio SIP Server v5.8.8 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.7. 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.8. Note that 5.8 is now the third last stable branch, v5.8.8 being the last planned released in the 5.8.x series. The latest two stable branch are 6.0 and 6.1, with v6.1.1 being released two days ago. For more details about version 5.8.8 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2026/03/kamailio-v5-8-8-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 World Conference, May 7-8, 2026 - Berlin, Germany -- kamailioworld.com

1 0

latest kamailio 6.1.x rtpengine dtmf events segfault
by Rob Boardman 06 Mar '26

06 Mar '26

Hi All, I've updated to 6.1.1 from 5.8.7 to take advantage of the new dialog refer options, but I have been using the rtpengine dtmf-events. The problem is every time a dtmf event is received the kamailio segfaults 2026-03-05T16:09:23.210394+00:00 kamailio-dev kernel: kamailio[3994]: segfault at 10 ip 0000748e5f6ff967 sp 00007fff8b35fcb0 error 4 in rtpengine.so[11967,748e5f6f6000+52000] likely on CPU 1 (core 0, socket 0) 2026-03-05T16:09:23.210422+00:00 kamailio-dev kernel: Code: 5f c1 05 00 4d 29 e2 31 ff c7 85 e8 7d ff ff 04 00 00 00 44 89 95 d8 7d ff ff 48 8d 8d d0 7d ff ff ba fe 00 00 00 49 8d 77 18 <41> ff 57 10 85 c0 0f 89 27 fb ff ff 41 8b 1e 4c 8b a5 80 7d ff ff 2026-03-05T16:09:23.663516+00:00 kamailio-dev kamailio[3996]: 11(3996) CRITICAL: <core> [core/pass_fd.c:284]: receive_fd(): EOF on 4 2026-03-05T16:09:23.668949+00:00 kamailio-dev kamailio[3985]: 0(3985) ALERT: <core> [main.c:824]: handle_sigs(): child process 3994 exited by a signal 11 2026-03-05T16:09:23.669581+00:00 kamailio-dev kamailio[3985]: 0(3985) ALERT: <core> [main.c:828]: handle_sigs(): core was generated I have checked to ensure the rtpengine.so is the correct version and it is showing 6.1.1 Could anyone off any advise? Thanks for all your help Regards 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.

2 1

Releasing v5.8.8
by Daniel-Constantin Mierla 06 Mar '26

06 Mar '26

Hello, I am considering to release Kamailio v5.8.8 (out of branch 5.8) on Friday, Mar 6, 2026. 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 developers that pushed commits that should be backported in that branch, check to see if they are done or not. If no major regression will be introduced, this will be the last release from the 5.8.x series, to mark the end of packaging support for it. Currently 6.0.x and 6.1.x are the latest two maintained branches. 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 1

Some modules about kamailio 6.1
by zhaobin 05 Mar '26

05 Mar '26

Hello: I upgrade my kamailio from 6.0.5 to 6.1.my server os is debian13,kamailio and some modules install from apt repositories,other mudules build from sources.For example maxfwd,branch is 6.1.Start kamailio show me error like this. 0(1) ERROR: <core> [core/sr_module.c:389]: ksr_version_control(): module version mismatch for /usr/lib/x86_64-linux-gnu/kamailio/modules/maxfwd.so; core: kamailio 6.1.0 (x86_64/Linux); module: kamailio 6.1.0 (x86_64/linux) So i don't understand why version mismatch. Thank you

2 5

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