sr-users January 2026

sr-users@lists.kamailio.org

19 participants
31 discussions

Kamailio & Asterisk SIP Registration Forwarding - Asterisk replies 401 Unauthorized
by Ben Fitzgerald 17 Apr '26

17 Apr '26

Hi, I've been following this integration tutorial http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb and have a successful registration and I can even make calls through my asterisk box. However what is unusual to me is that every time a phone registers with Kamailio, that is forwarded to Asterisk (as expected), yet Asterisk replies with 401 Unauthorized. Oddly enough the phone registers and can still make calls. What worries me is that as we scale to 100's of cps, this seemingly erroneous message may slow down Asterisk because it's trying to handle authentication for users which have already been authenticated by Kamailio. If this behavior is expected, then that would be good to know as well. This is the sip debug from ASTERISK (I have replaced IP's with the names of the servers): <--- SIP read from TCP:kamailio:41205 ---> REGISTER sip:asteriskIP:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP kamailio;branch=z9hG4bK998f.2846e405000000000000000000000000.0 To: <sip:40081@asteriskIP> From: <sip:40081@asteriskIP>;tag=32fda68bf54efeeb04e3edc67b53c63d-cfb0 CSeq: 10 REGISTER Call-ID: 0005ce130bcee5c4-26538@kamailio Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0 (x86_64/linux)) Contact: <sip:40081@kamailio:5060> Expires: 3600 <-------------> --- (11 headers 0 lines) --- Sending to kamailio:5060 (no NAT) Sending to kamailio:5060 (no NAT) <--- Transmitting (no NAT) to kamailio:5060 ---> SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP kamailio;branch=z9hG4bK998f.2846e405000000000000000000000000.0;received= kamailio From: <sip:40081@asteriskIP>;tag=32fda68bf54efeeb04e3edc67b53c63d-cfb0 To: <sip:40081@asteriskIP>;tag=as404bac9a Call-ID: 0005ce130bcee5c4-26538@ kamailio CSeq: 10 REGISTER Server: Asterisk PBX 11.6-cert2 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="262b338e" Content-Length: 0 <------------> Scheduling destruction of SIP dialog '0005ce130bcee5c4-26538@ kamailio' in 32000 ms (Method: REGISTER) Scheduling destruction of SIP dialog '0005ce130bcee5c4-26538@ kamailio' in 32000 ms (Method: REGISTER) Really destroying SIP dialog '0005ce130bcee5c1-26536@ kamailio' Method: REGISTER ========================= sip.conf for kamailio trunk: [kamailio-inbound] type=friend dtmfmode=auto host=kamailioIP allow=all context=sipout insecure=port,invite canreinvite=no ======================== Asterisk version: 11.6-cert2 Kamailio version: 4.3 Benjamin Fitzgerald LETS Corporation (925) 235-1154 ben(a)letscorp.us *******Confidential Notice: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please delete this message from all computers and contact Orion Systems/LETS Corp immediately by return e-mail and/or telephone at (925) 566-5600

4 8

problems using kamailio
by Peter Walber 17 Apr '26

17 Apr '26

Hello, I try to use kamailio as webrtc-sip-gateway between my openhab smart home system and my doorbird doorbell with phone and camera. I try to use the product of "https://github.com/florian-h05/webrtc-sip-gw". Which integrates kamailio together with rtpengine to the gateway. I want to use openhab as SIP Client and have a Telekom Speedport Smart 4 Router on the other side. The webrtc-sip-gw from florian-h05 shall be the software between Openhab and the speedport smart 4. On the speedport smart router the SIP Server is enabled and configured. I can sucessfully call with zoiper extern phone numbers. The doorbird als is configured correctly. I can call the doorbird with my zioper softphone using the SIP interface of the doorbird. The runtime system is a docker container on debian 12. I want to call the doorbird by SIP from my openhab SIP client. I can initiate the call, but it doesn't establish Here is the log from the docker container. --------------------------------------------------------------------------------------------------- 2025-08-07T07:46:57.384687165Z 9(52) INFO: <script>: HTTP Request Received 2025-08-07T07:46:57.391479050Z 9(52) INFO: <script>: START: REGISTER from sip:**73@speedport.ip (IP:192.168.2.185:39510) 2025-08-07T07:46:57.391516534Z 9(52) INFO: <script>: Current Contact header: <sip:v0fds0hl@fe8ojuo7pnkl.invalid;transport=ws>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:243e461d-f0cb-4c09-9a63-f57c9bba8d6b>";expires=600 2025-08-07T07:46:57.391526535Z 9(52) INFO: <script>: Setting new Contact header: <sip:**73@192.168.2.209:5060> 2025-08-07T07:47:00.195739350Z 9(52) INFO: <script>: START: INVITE from sip:**73@speedport.ip (IP:192.168.2.185:39510) 2025-08-07T07:47:00.195800424Z 9(52) INFO: <script>: Current Contact header: <sip:v0fds0hl@fe8ojuo7pnkl.invalid;transport=ws;ob> 2025-08-07T07:47:00.195811886Z 9(52) INFO: <script>: Setting new Contact header: <sip:v0fds0hl@fe8ojuo7pnkl.invalid;transport=ws;ob;alias=192.168.2.185~39510~6;alias=192.168.2.185~39510~6> 2025-08-07T07:47:00.196163528Z 9(52) INFO: <script>: MANAGE_BRANCH: New branch [0] to sip:**72@speedport.ip 2025-08-07T07:47:00.196181228Z 9(52) INFO: <script>: NATMANAGE branch_id:0 ruri: sip:**72@speedport.ip, method:INVITE, status:<null>, extra_id: z9hG4bK44082210, rtpengine_manage: replace-origin replace-session-connection via-branch=extra rtcp-mux-demux SDES-off ICE=remove RTP/AVP 2025-08-07T07:47:00.196608235Z INFO: [penvq8f06ehafutk9ivf]: [control] Received command 'offer' from 127.0.0.1:50790 2025-08-07T07:47:00.196625247Z NOTICE: [penvq8f06ehafutk9ivf]: [core] Creating new call 2025-08-07T07:47:00.198519843Z INFO: [penvq8f06ehafutk9ivf]: [control] Replying to 'offer' from 127.0.0.1:50790 (elapsed time 0.001979 sec) 2025-08-07T07:47:01.927528447Z 9(52) INFO: <script>: START: CANCEL from sip:**73@speedport.ip (IP:192.168.2.185:39510) 2025-08-07T07:47:01.927577111Z 9(52) INFO: <script>: Current Contact header: <null> 2025-08-07T07:47:01.927586439Z 9(52) INFO: <script>: Setting new Contact header: <null> 2025-08-07T07:47:09.169489716Z 7(50) INFO: <script>: WebSocket connection from 192.168.2.185:39510 has closed *2025-08-07T07:47:27.355185671Z 2(45) WARNING: tm [../../core/forward.h:203]: msg_send_buffer(): TCP/TLS connection for WebSocket could not be found* 2025-08-07T07:47:27.914769340Z 9(52) INFO: <script>: HTTP Request Received 2025-08-07T07:47:27.951608347Z 9(52) INFO: <script>: START: REGISTER from sip:**73@speedport.ip (IP:192.168.2.185:44816) 2025-08-07T07:47:27.951663073Z 9(52) INFO: <script>: Current Contact header: <sip:lebth4eq@fe8ojuo7pnkl.invalid;transport=ws>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:39eac0ca-0aea-4526-a5c7-0516bc8a2d71>";expires=600 2025-08-07T07:47:27.951915520Z 9(52) INFO: <script>: Setting new Contact header: <sip:**73@192.168.2.209:5060> 2025-08-07T07:47:30.168546446Z 2(45) INFO: <script>: BRANCH FAILED: z9hG4bK4408221 + 0INFO: [penvq8f06ehafutk9ivf]: [control] Received command 'delete' from 127.0.0.1:36296 2025-08-07T07:47:30.168587880Z INFO: [penvq8f06ehafutk9ivf]: [core] Deleting call branch '' (via-branch 'z9hG4bK44082210') 2025-08-07T07:47:30.168597011Z INFO: [penvq8f06ehafutk9ivf]: [core] Call branch '' (via-branch 'z9hG4bK44082210') deleted, no more branches remaining 2025-08-07T07:47:30.168605215Z INFO: [penvq8f06ehafutk9ivf]: [core] Deleting entire call 2025-08-07T07:47:30.168612883Z INFO: [penvq8f06ehafutk9ivf]: [core] Final packet stats: 2025-08-07T07:47:30.168620604Z INFO: [penvq8f06ehafutk9ivf]: [core] --- Tag 'utenlull77', created 0:30 ago for branch '' 2025-08-07T07:47:30.168628359Z INFO: [penvq8f06ehafutk9ivf]: [core] --- subscribed to '' 2025-08-07T07:47:30.168636445Z INFO: [penvq8f06ehafutk9ivf]: [core] --- subscription for '' 2025-08-07T07:47:30.168645446Z INFO: [penvq8f06ehafutk9ivf]: [core] ------ Media #1 (audio over UDP/TLS/RTP/SAVPF) using unknown codec 2025-08-07T07:47:30.168653691Z INFO: [penvq8f06ehafutk9ivf]: [core] --------- Port 192.168.2.209:23484 <> 192.168.2.185:60650, SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:47:30.168661939Z INFO: [penvq8f06ehafutk9ivf]: [core] --- Tag '', created 0:30 ago for branch 'z9hG4bK44082210' 2025-08-07T07:47:30.168669844Z INFO: [penvq8f06ehafutk9ivf]: [core] --- subscribed to 'utenlull77' 2025-08-07T07:47:30.168677713Z INFO: [penvq8f06ehafutk9ivf]: [core] --- subscription for 'utenlull77' 2025-08-07T07:47:30.168685661Z INFO: [penvq8f06ehafutk9ivf]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec 2025-08-07T07:47:30.168693705Z INFO: [penvq8f06ehafutk9ivf]: [core] --------- Port 192.168.2.209:23472 <> :0 , SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:47:30.168718608Z INFO: [penvq8f06ehafutk9ivf]: [core] --------- Port 192.168.2.209:23473 <> :0 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:47:30.168728065Z INFO: [penvq8f06ehafutk9ivf]: [control] Replying to 'delete' from 127.0.0.1:36296 (elapsed time 0.000505 sec) *2025-08-07T07:47:30.169042099Z 2(45) INFO: <script>: Failure: <null> 2(45) WARNING: tm [../../core/forward.h:203]: msg_send_buffer(): TCP/TLS connection for WebSocket could not be found* 2025-08-07T07:47:30.265075785Z 9(52) INFO: <script>: START: INVITE from sip:**73@speedport.ip (IP:192.168.2.185:44816) 2025-08-07T07:47:30.265125134Z 9(52) INFO: <script>: Current Contact header: <sip:lebth4eq@fe8ojuo7pnkl.invalid;transport=ws;ob> 2025-08-07T07:47:30.265135557Z 9(52) INFO: <script>: Setting new Contact header: <sip:lebth4eq@fe8ojuo7pnkl.invalid;transport=ws;ob;alias=192.168.2.185~44816~6;alias=192.168.2.185~44816~6> 2025-08-07T07:47:30.265484502Z 9(52) INFO: <script>: MANAGE_BRANCH: New branch [0] to sip:**72@speedport.ip 2025-08-07T07:47:30.265664116Z 9(52) INFO: <script>: NATMANAGE branch_id:0 ruri: sip:**72@speedport.ip, method:INVITE, status:<null>, extra_id: z9hG4bK16860370, rtpengine_manage: replace-origin replace-session-connection via-branch=extra rtcp-mux-demux SDES-off ICE=remove RTP/AVP 2025-08-07T07:47:30.265819591Z INFO: [412n0o8dedgair81t70p]: [control] Received command 'offer' from 127.0.0.1:50790 2025-08-07T07:47:30.265979425Z NOTICE: [412n0o8dedgair81t70p]: [core] Creating new call 2025-08-07T07:47:30.267497852Z INFO: [412n0o8dedgair81t70p]: [control] Replying to 'offer' from 127.0.0.1:50790 (elapsed time 0.001599 sec) 2025-08-07T07:47:30.469565385Z 9(52) INFO: <script>: START: CANCEL from sip:**73@speedport.ip (IP:192.168.2.185:44816) 2025-08-07T07:47:30.469629711Z 9(52) INFO: <script>: Current Contact header: <null> 2025-08-07T07:47:30.469645116Z 9(52) INFO: <script>: Setting new Contact header: <null> 2025-08-07T07:47:41.207672567Z 7(50) INFO: <script>: WebSocket connection from 192.168.2.185:44816 has closed 2025-08-07T07:47:57.917754216Z 2(45) WARNING: tm [../../core/forward.h:203]: msg_send_buffer(): TCP/TLS connection for WebSocket could not be found 2025-08-07T07:48:00.230412646Z 2(45) INFO: <script>: BRANCH FAILED: z9hG4bK1686037 + 0INFO: [412n0o8dedgair81t70p]: [control] Received command 'delete' from 127.0.0.1:36296 2025-08-07T07:48:00.230457143Z INFO: [412n0o8dedgair81t70p]: [core] Deleting call branch '' (via-branch 'z9hG4bK16860370') 2025-08-07T07:48:00.230466718Z INFO: [412n0o8dedgair81t70p]: [core] Call branch '' (via-branch 'z9hG4bK16860370') deleted, no more branches remaining 2025-08-07T07:48:00.230475640Z INFO: [412n0o8dedgair81t70p]: [core] Deleting entire call 2025-08-07T07:48:00.230483968Z INFO: [412n0o8dedgair81t70p]: [core] Final packet stats: 2025-08-07T07:48:00.230491909Z INFO: [412n0o8dedgair81t70p]: [core] --- Tag 'hc7h5imu96', created 0:30 ago for branch '' 2025-08-07T07:48:00.230518917Z INFO: [412n0o8dedgair81t70p]: [core] --- subscribed to '' 2025-08-07T07:48:00.230528302Z INFO: [412n0o8dedgair81t70p]: [core] --- subscription for '' 2025-08-07T07:48:00.230537387Z INFO: [412n0o8dedgair81t70p]: [core] ------ Media #1 (audio over UDP/TLS/RTP/SAVPF) using unknown codec 2025-08-07T07:48:00.230545867Z INFO: [412n0o8dedgair81t70p]: [core] --------- Port 192.168.2.209:23400 <> 192.168.2.185:46431, SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:48:00.230554949Z INFO: [412n0o8dedgair81t70p]: [core] --- Tag '', created 0:30 ago for branch 'z9hG4bK16860370' 2025-08-07T07:48:00.230563124Z INFO: [412n0o8dedgair81t70p]: [core] --- subscribed to 'hc7h5imu96' 2025-08-07T07:48:00.230570851Z INFO: [412n0o8dedgair81t70p]: [core] --- subscription for 'hc7h5imu96' 2025-08-07T07:48:00.230578827Z INFO: [412n0o8dedgair81t70p]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec 2025-08-07T07:48:00.230587091Z INFO: [412n0o8dedgair81t70p]: [core] --------- Port 192.168.2.209:23494 <> :0 , SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:48:00.230595631Z INFO: [412n0o8dedgair81t70p]: [core] --------- Port 192.168.2.209:23495 <> :0 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:48:00.230603868Z INFO: [412n0o8dedgair81t70p]: [control] Replying to 'delete' from 127.0.0.1:36296 (elapsed time 0.000253 sec) *2025-08-07T07:48:00.230753116Z 2(45) INFO: <script>: Failure: <null> 2(45) WARNING: tm [../../core/forward.h:203]: msg_send_buffer(): TCP/TLS connection for WebSocket could not be found* --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- especially the bold lines confuse me. Why is the TCP/TLS closed and can not be found ? Could that be the problem ?* * * * Thanks for some help and best regards Peter* *

7 15

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

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