sr-users January 2026

sr-users@lists.kamailio.org

19 participants
29 discussions

Info: Kamailio World 2026 - Call for presentations
by Daniel-Constantin Mierla 16 Feb '26

16 Feb '26

Hello, a short note to inform that the Call For Presentations is now open for Kamailio World 2026. Everyone is welcome to submit proposal for presentations to share the knowledge about Kamailio or Real Time Communication services, security, high availability, scalability, etc. Submission form and more details are available at: - https://www.kamailioworld.com/k2026/call-for-speakers/ 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

Question about iFC support for SIP response-code based voicemail forwarding
by 高秉寬 05 Feb '26

05 Feb '26

Hello Kamailio Community, I am currently using *Kamailio v6.0.3* as an IMS SIP core integrated with a 5G core network, and I would like to ask a question regarding *voicemail service* integration using *iFC* (initial filter criteria). The below is my deployment overview: - Kamailio is deployed as *three separated IMS roles*, each running in its own K8s pod: P-CSCF, S-CSCF, and I-CSCF. - The configuration files are largely based on the following Open5GS IMS examples: - P-CSCF: https://github.com/herlesupreeth/docker_open5gs/blob/master/pcscf/kamailio_… - S-CSCF: https://github.com/herlesupreeth/docker_open5gs/blob/master/scscf/kamailio_… - I-CSCF: https://github.com/herlesupreeth/docker_open5gs/blob/master/icscf/kamailio_… - A third-party Application Server, *Asterisk*, is deployed in a separate K8s pod and is intended to act as a voicemail server. The target behavior is a typical IMS voicemail scenario: 1. UE A calls UE B. 2. If UE B rejects the call or is unreachable (e.g. the SIP response code as 486 Busy Here, 480 Temporarily Unavailable, etc.), the call should be forwarded to the voicemail server (Asterisk), allowing UE A to leave a voice message. Originally, I planned to rely on *iFC in the S-CSCF* to trigger forwarding to the voicemail application server. However, from my understanding of the current *ims_isc* implementation in Kamailio, iFC trigger points are evaluated only on the initial request context (method, header, session case, etc.), and do not support conditions based on SIP response status codes returned from the UE. My questions are therefore: 1. Is my understanding correct that, in Kamailio v6.0.3, iFC cannot be triggered conditionally based on the SIP response codes (e.g. 486/480/408) received from the terminating UE? 2. If this functionality is not supported, is there a recommended or existing method within Kamailio IMS to forward calls to a voicemail server (such as Asterisk) when the terminating UE fails? I would appreciate any clarification or references to existing implementations or best practices. Thank you very much for your time and for the continued development of Kamailio. -- Best regards, Ethan

2 2

Testing the Kamailio Outbound Module
by 13715209697＠139.com 02 Feb '26

02 Feb '26

Hi, team # Testing the Kamailio Outbound Module Kamailio version: 6.0.5 OS: Debian 12 Kamailio IP: 192.168.149.18, Port: 5060 FreeSWITCH (REGISTRAR) IP: 192.168.149.18, Port: 6666 MicroSIP IP: 192.168.149.35, transport protocol: TCP ## Signaling Flows MicroSIP => REGISTER => Kamailio => FreeSWITCH, this is OK MicroSIP => INVITE => Kamailio => FreeSWITCH, this is OK also However, executing `fs_cli -x 'show registrations as xml'` on FreeSWITCH returns the following: ```xml <result row_count="1"> <row row_id="1"> <reg_user>1001</reg_user> <realm>192.168.149.18</realm> <token>992b228842f841fda057da1883e5317a</token> <url>sofia/internal/sip:1001@192.168.149.35:49676;transport=TCP;ob;fs_path=%3Csip%3A192.168.149.18%3Blr%3E</url> <expires>1769678856</expires> <network_ip>192.168.149.18</network_ip> <network_port>5060</network_port> <network_proto>tcp</network_proto> <hostname>debian</hostname> <metadata></metadata> </row> </result> ``` Command executed: `fs_cli -x 'originate user/1001 &park'` The INVITE message is as follows: ``` INVITE sip:1001@192.168.149.35:59527;transport=TCP;ob SIP/2.0 Via: SIP/2.0/UDP 192.168.149.18:6666;rport;branch=z9hG4bK0mU9ryZD57S0p Route: <sip:192.168.149.18;lr> Max-Forwards: 70 From: <sip:0000000000@192.168.149.18>;tag=97mDae4gQHXFa To: <sip:1001@192.168.149.35:59527;transport=TCP;ob> Call-ID: a59d2625-7790-123f-979c-0800279269e8 CSeq: 110284145 INVITE Contact: <sip:mod_sofia@192.168.149.18:6666> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: outbound, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 764 X-FS-Support: update_display,send_info Remote-Party-ID: <sip:0000000000@192.168.149.18>;party=calling;screen=yes;privacy=off ``` ... However, the log shows "client to registrar" instead of "registrar to client". What is the reason for this? The contents of kamailio.cfg are as follows: ``` #!KAMAILIO # # Edge proxy configuration # listen=tcp:192.168.149.18:5060 listen=udp:192.168.149.18:5060 #!subst "/REGISTRAR_IP/192.168.149.18/" #!subst "/REGISTRAR_PORT/6666/" #!substdef "/FLOW_TIMER/20/" ####### Global Parameters ######### auto_aliases=no debug=2 log_stderror=no log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " fork=yes children=4 alias="example.com" #mpath="/usr/lib64/kamailio/modules" tcp_connection_lifetime=30 # FLOW_TIMER + 10 force_rport=yes ####### Modules Section ######## loadmodule "tm.so" loadmodule "sl.so" loadmodule "outbound.so" loadmodule "rr.so" loadmodule "path.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "stun.so" # ----------------- setting module-specific parameters --------------- # ----- tm params ----- modparam("tm", "failure_reply_mode", 3) # ----- rr params ----- modparam("rr", "append_fromtag", 0) ####### Routing Logic ######## request_route { route(REQINIT); if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } route(WITHINDLG); t_check_trans(); if (is_method("REGISTER")) { remove_hf("Route"); add_path(); $du = "sip:REGISTRAR_IP:REGISTRAR_PORT"; } else { if (is_method("INVITE|SUBSCRIBE")) record_route(); if (@via[2] == "") { # From client so route to registrar... xinfo("client to registrar\n"); if ($rU == $null) { sl_send_reply("484", "Address Incomplete"); exit; } remove_hf("Route"); $du = "sip:REGISTRAR_IP:REGISTRAR_PORT"; } else { # From registrar so route using "Route:" headers... xinfo("registrar to client\n"); if (!loose_route()) { switch($rc) { case -2: sl_send_reply("403", "Forbidden"); exit; default: xlog("L_ERR", "in request_route\n"); sl_reply_error(); exit; } } t_on_failure("FAIL_OUTBOUND"); } } route(RELAY); } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } route[REQINIT] { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } route[WITHINDLG] { if (has_totag()) { if (!loose_route()) { switch($rc) { case -2: sl_send_reply("403", "Forbidden"); exit; default: if (is_method("ACK")) { if ( t_check_trans() ) { route(RELAY); exit; } else { exit; } } sl_send_reply("404","Not Found"); } } else { if (is_method("NOTIFY")) { record_route(); } route(RELAY); } exit; } } onreply_route { if (!t_check_trans()) { drop; } if ($rm == "REGISTER" && $rs >= 200 && $rs <= 299) { remove_hf("Flow-Timer"); if ($(hdr(Require)[*])=~"outbound") insert_hf("Flow-Timer: FLOW_TIMER\r\n", "Call-ID"); } } failure_route[FAIL_OUTBOUND] { if (t_branch_timeout() && !t_branch_replied()) { send_reply("430", "Flow Failed"); } } ```

1 2

rtpengine: Reduce lock contention during ping timer
by Rajneesh Soni 01 Feb '26

01 Feb '26

Hi, I've identified a lock contention issue in the rtpengine module's ping timer that can significantly impact call processing under certain conditions. **Problem:** The `rtpengine_ping_check_timer()` function, triggered periodically by `ping_interval`, holds locks on `rtpp_set_list` for the entire duration of pinging all rtpengine nodes. Normally, this works find, but when rtpengine instances become unreachable, the lock is held for an long time. For example: - 2 unreachable rtpengine nodes - 1000ms command timeout - 5 retries per node - locks held for ~10 seconds **Proposed Solution:** Split the ping operation into three phases: 1. **Phase 1 (with lock):** Create a snapshot of node pointers 2. **Phase 2 (without lock):** Perform actual ping operations on the snapshot 3. **Phase 3 (with lock):** update node state Since rtpengine nodes are never freed during runtime, the pointers in the snapshot remain valid throughout the ping cycle so lock is not required. I have implemented and tested this change in my deployment. Should I submit a pull request, or is there a preferred alternative approach? regards, Rajneesh

3 4

Kamailio at FOSDEM 2026
by Henning Westerholt 31 Jan '26

31 Jan '26

Hello, I will be present at FOSDEM, the largest open-source conference in Brussels, Belgium, today and tomorrow. If you want to meet for a drink this or tomorrow afternoon to chat about Kamailio topics, just send me a (direct) e-mail. Cheers, Henning Westerholt

1 0

Found an error in the NATS documentation
by 13715209697＠139.com 30 Jan '26

30 Jan '26

Hi, Team Found an error in the NATS documentation https://www.kamailio.org/docs/modules/stable/modules/nats.html modparam("nats", "nats_url", "nats://user1:pass1127.0.1.2:4222") // with auth

2 1

Info: Registration to Kamailio World 2026 is open!
by Daniel-Constantin Mierla 29 Jan '26

29 Jan '26

Hello, a quick note to announce that the registration for the next Kamailio World Conference (May 7-8, 2026) is now open! The event take place at the same location in the beautiful city center of Berlin like in 2025! More details are available at: * https://www.kamailioworld.com/k2026/ Call for presentations is also open, there is already a group of very interesting submissions, we aim to publish details about a selection of them in the near future. Looking forward to meeting many of you in Berlin! 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

Re: Kamailio + Dispatcher + UAC
by darren＠cartr.co.za 28 Jan '26

28 Jan '26

Hi Mark, Sounds like you and I are in the same boat. I’ve been at this for a few days now and the issue remains the same, as soon as I add the UAC auth to the invite my carrier stops responding and then Kamailio just retransmits until it times out. My opinion is that the carrier does not like the record route and other headers added by Kamailio in order to do its job and they simply drop the request. I have decided to leave carrier connectivity to the PBX and I dropped Asterisk for FreeSWITCH as it performs way better than Asterisk in terms of call concurrency. Kind regards Darren Carter

3 2

Kamailio + Dispatcher + UAC
by darren＠cartr.co.za 28 Jan '26

28 Jan '26

I have been trying to get outbound calls to work, and my trunk provider required authentication for outbound calls. My trunk is registered with UAC and I use Dispatcher to select the correct trunk for the CLI making the call. I just can’t seem to get it working, my trunk does not know how to replay to my authenticated invite and Kamailio just retransmits until it times out. Perhaps someone can point me in the right direction, I have looked everywhere and tried so many different appraches. The call flow should be Client Phone -> Kamailio -> Trunk and replies, Trunk -> Kamailio -> Client Phone. # Dispatch requests route[DISPATCH] { if ($var(dispatcher_set) == $null || $var(dispatcher_set) == "") { xlog("L_INFO", "[$ci] DISPATCHER: No dispatcher set configured\n"); return; } # DISPATCHER_OUTBOUND_SET # DISPATCHER_INBOUND_SET # DISPATCHER_ASTERISK_SET switch($var(dispatcher_set)) { case DISPATCHER_OUTBOUND_SET: if (!ds_select_dst(DISPATCHER_OUTBOUND_SET, "4")) { xlog("L_ERR", "[$ci] DISPATCHER: No available outbound dispatcher destinations\n"); sl_send_reply("503", "Service Unavailable"); exit; } xlog("L_INFO", "[$ci] DISPATCHER: Going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs)) from set $var(dispatcher_set)\n"); $du = "sip:{{ kamailio_sip_host }}:{{ kamailio_sip_port }}"; $avp(auth_user) = $xavp(_dsdst_=>attrs=>auth_user); $avp(auth_pass) = $xavp(_dsdst_=>attrs=>auth_pass); $avp(auth_realm) = $xavp(_dsdst_=>attrs=>auth_realm); if (is_method("INVITE")) { t_on_failure("TRUNK_AUTH"); t_relay(); exit; } break; case DISPATCHER_INBOUND_SET: if (!ds_select_dst(DISPATCHER_INBOUND_SET, "4")) { xlog("L_ERR", "[$ci] DISPATCHER: No available inbound dispatcher destinations\n"); sl_send_reply("503", "Service Unavailable"); exit; } break; case DISPATCHER_ASTERISK_SET: if (!ds_select_dst(DISPATCHER_ASTERISK_SET, "4")) { xlog("L_ERR", "[$ci] DISPATCHER: No available Asterisk dispatcher destinations\n"); sl_send_reply("503", "Service Unavailable"); exit; } break; default: xlog("L_ERR", "[$ci] DISPATCHER: Invalid dispatcher set $var(dispatcher_set)\n"); sl_send_reply("500", "Internal Server Error"); exit; } t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } # Failure route - outbound trunk auth challenge handling failure_route[TRUNK_AUTH] { if (t_is_canceled()) { xlog("L_INFO", "[$ci] TRUNK_AUTH: Transaction canceled\n"); exit; } if (t_check_status("401|407")) { xlog("L_INFO", "[$ci] TRUNK_AUTH: Received auth challenge for outbound trunk\n"); if ($avp(auth_user) == $null || $avp(auth_pass) == $null || $avp(auth_realm) == $null) { xlog("L_WARN", "[$ci] TRUNK_AUTH: Missing UAC auth credentials, skipping uac_auth\n"); exit; } uac_auth(); t_relay(); exit; } } Kind regards Darren Carter

3 2

Development is open for future release of v6.2.x series
by Daniel-Constantin Mierla 27 Jan '26

27 Jan '26

Hello, the branch 6.1 was created, therefore the master branch is open for adding new features, to be part of future release series v6.2.x. Any bug fix committed to master that applies to 6.1.x or older stable branches should be backported as usual with "git cherry-pick -x ..." to appropriate branches like 6.1 or 6.0. Expect that v6.1.0 will be released in a few weeks from now. Based on the workflow used during the past years, the next future release v6.2.0 should be out after about 10 months of development, plus 1-2 months of testing, so sometime during the last part of 2026 or the beginning of 2027. 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

2 1

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