sr-users February 2026

sr-users@lists.kamailio.org

30 participants
29 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

Inquiry about rtpengine subscribe functionality
by xf han 05 Mar '26

05 Mar '26

Hi, Team I have reviewed the documentation at https://www.kamailio.org/docs/modules/6.1.x/modules/rtpengine.html I have the following questions: 1. Which SRS (Session Recording Server) has been tested with rtpengine_subscribe？ 2. Should the Content-Type be application/sdp or multipart/mixed? ``` onreply_route[1] { ... if (has_body("application/sdp")) { rtpengine_answer(); rtpengine_subscribe_request("all siprec", "$avp(siprec_offer)", "$avp(siprec_to_tag)", "siprec_streams"); xinfo("SIPREC participant $xavp(siprec_streams[0]=>tag) with label $xavp(siprec_streams[0]=>label[0])\n"); xinfo("SIPREC participant $xavp(siprec_streams[1]=>tag) with label $xavp(siprec_streams[0]=>label[0])\n"); #use the above steam information to build the siprec xml metadata, will just send sdp in this example $dlg_var(orig_to_tag) = $tt; $dlg_var(siprec_contact) = "sip:uac@" + $Ri; $dlg_var(siprec_to_tag) = $avp(siprec_to_tag); t_uac_send("INVITE","sip:siprec@siprec_server.example.com", "siprec_server.example.com", "", "To: <$tu>\r\n" + "From: <$fu>\r\n" + "Contact: <$dlg_var(siprec_contact)>\r\n" + "Content-Type: application/sdp\r\n", $avp(siprec_offer)); } ... } ``` The documentation mentions application/sdp, but when I tested with OpenSIPS 3.4's siprec module, it used multipart/mixed. https://github.com/drachtio/drachtio-siprec-recording-server/blob/main/test… This example also shows multipart/mixed.

1 1

Releasing v6.1.1
by Daniel-Constantin Mierla 04 Mar '26

04 Mar '26

Hello, The release of Kamailio v6.1.1 (out of branch 6.1) is considered to be done on Wednesday, Mar 4, 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. 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

Re: [sr-dev] Re: SO_REUSEPORT
by Henning Westerholt 27 Feb '26

27 Feb '26

Hello, your memory cfg is wrong, you need to reverse it. Use: -m 2048 -M 32 For example. Note the 128MB private memory is a lot, usually this is not needed. Shared memory could be more, depending on your system and load requirements. Cheers, Henning From: Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com> Sent: Freitag, 27. Februar 2026 12:17 To: Henning Westerholt <hw(a)gilawa.com>; sr-users(a)lists.kamailio.org Cc: Sarju Garg <sarju(a)goldilocks-tech.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi Henning, Thank you for your quick response. As requested, please find below the relevant details. The corresponding logs are attached for your reference. We tested the following shared and private memory configuration: /usr/local/sbin/kamailio -M 2048 -m 128 -f /usr/local/etc/kamailio/kamailio_obd_missedcall.cfg -DD -E & However, we are still encountering the same error (please see the attached logs). Could you please review and advise on the next steps? If any additional information is required from our side, please let me know. Regards Chandra Bhan Kumar ________________________________ From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Sent: Friday, February 27, 2026 2:49 PM To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Cc: Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>; Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Subject: RE: [sr-dev] Re: SO_REUSEPORT (switching to sr-users list) Hello, did you increase the private and shared memory pool settings? The default values are not suitable for larger tests and production environments. Cheers, Henning -- Kamailio services – https://gilawa.com<https://gilawa.com/> From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Sent: Freitag, 27. Februar 2026 02:18 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>; Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>; Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi Henning, we've set up our servers and are currently seeing about 2000 CPS. At 5000 CPS, Kamailio shuts down with memory logging errors. We have an environment setup with 2 server each having 12 core and 64 GB RAM. One acting as sipp stub for generating load and second as simple application where when INVITE is received, it reject the call (4xx) and hit a HTTP trigger in async mode. Transaction module is used to keep track of it. Do we have any ready reference guide for troubleshooting or any help how to go about fixing this point. My understanding is it Kamalio setup should be able to handle 20k CPS for such simple application. Not sure replacing HTTP trigger with Kamalio or UDP hit may add more CPS handling capacity. Regards Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Friday, 20 February 2026 at 12:11 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: "camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>" <camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>>, Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>>, Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>, Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Subject: RE: [sr-dev] Re: SO_REUSEPORT Hello, usually, one would be interesting in measuring CPS/CAPS throughput or concurrent calls. TPS is not such a common metric for a VoIP system. But anyhow, its is not possible from the outside to guess if 20k TPS would be realistic in your setup. You might even run into limitation from the testing side with sipp. As said, usually you are getting issues with IO dependencies, e.g. databases or similar. A realistic setup would usually not use only one server for this load, as you want to have a high-available setup probably. As said, do some load tests on your side and see what you are getting. Then start analysing and eventual tuning, repeat the test and so on. Cheers, Henning -- Kamailio services – https://gilawa.com<https://gilawa.com/> From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Sent: Freitag, 20. Februar 2026 03:53 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>; Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>; Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi Henning, We have an environment setup with 2 server each having 12 core and 64 GB RAM. One acting as sipp stub for generating load and second as simple application where when INVITE is received, it reject the call and hit a HTTP trigger. We expect around 20000 TPS on this setup. Is this realistic expectation.? Regards, Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Thursday, 19 February 2026 at 5:18 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>>, "camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>" <camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>>, Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>, Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Subject: RE: [sr-dev] Re: SO_REUSEPORT Hello, I think Kamailio is using for the UDP server the SO_SEADDR flag, which is somehow similar as the SO_REUSEPORT. Kamailio is used in installation up to millions of customer devices. So, in many cases, the scaling challenges you are having are not related to Kamailio but to other infrastructure, e.g. a database or similar. I would suggest you setup a test environment for the performance requirements you are having and then doing some actual benchmarks. Cheers, Henning From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Sent: Donnerstag, 19. Februar 2026 11:09 To: Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Cc: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>>; camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>; Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>; Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT HI Sergey, Thanks. It supports connecting multiple child processes to a single UDP queue, but not sure if it does port reuse at UDP. There is a parameter for tcp_reuse_port. I understand if the tuple (src ip/port and Dest ip/port) is same, then there will be multiple consumers (connection parameter to create worker thread) . So multiple process will be waiting on single queue If I refer example in cook book , children=4 listen=udp:127.0.0.1:5080 listen=udp:127.0.0.1:5070 listen=udp:127.0.0.1:5060 4 children each would be created for 3 different ports, but in my case, it would be children=4 listen=udp:127.0.0.1:5080 As my IP / port is only one. However, I want 3 different queues to be created. As per the internet * SO_REUSEPORT: This socket option allows multiple threads or processes to bind to the same UDP port, each with its own socket and receive queue, which helps avoid contention on a single receive buffer lock in multi-core systems. Now since I have 3 different sources, I want to create 3 UDP queues with each having 4 consumers… I hope I can explain my problem, and hence using the SO_REUSEPORT option in UDP Regards Sarju But if src ip/port is different, like 3 src/ip sending to same dest ip/port,then 3 UDP queue is created and then multiple consumer will listen on 3 different queue. From: Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Date: Thursday, 19 February 2026 at 12:09 PM To: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Cc: "Kamailio (SER) - Development Mailing List" <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>>, "camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>" <camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>>, Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>, Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Kamailio supports port reuse. You just need to enable this feature in the config file and then start several Kamailio copies. For example using different systemd units. If I am not wrong, Kamailio supports distributing load to different processes forks on different cores. This is a present out of box and you do not need to do anything more. Just need to create additional UDP childrens. Sergey On Thu, Feb 19, 2026 at 1:23 AM Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> wrote: Hi, I am exploring REUSE_PORT Option for UDP. I am getting high TPS on single UDP port say 5060. Our customer will send the complete load from one IP and one port only. And from my side I have one IP and one port. As per my understanding in that case tuple antropy cannot be achieved so was thinking if REUSE_PORT. Can be done to have parallel queue and as per Linux document, the multiple queue on same port is created. My TPS requirement is about 20000 and try to see if how to architect the same. Regards Sarju From: Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Date: Wednesday, 18 February 2026 at 1:44 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>>, "camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>" <camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>>, Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>, Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT for UTP transport all message to the same IP:PORT address use the same port when send via same socket. On Wed, Feb 18, 2026 at 9:31 AM Henning Westerholt via sr-dev <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> wrote: Hello, please describe what you are wanting to achieve. When we are talking about re-using ports in the SIP Kamailio context, usually its about TCP connections. This is supported from Kamailio when activated in the core. Cheers, Henning -- Kamailio services – https://gilawa.com > -----Original Message----- > From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> > Sent: Mittwoch, 18. Februar 2026 03:57 > To: Federico Cabiddu <federico.cabiddu(a)gmail.com<mailto:federico.cabiddu@gmail.com>> > Cc: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; Kamailio (SER) - Development > Mailing List <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>>; giacomo.vacca(a)gmail.com<mailto:giacomo.vacca@gmail.com>; M S > <shaheryarkh(a)gmail.com<mailto:shaheryarkh@gmail.com>>; camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>; Chandrabhan Kumar > <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>; sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> > Subject: SO_REUSEPORT > > Hi all, > > > I want a help to understand if the reuse port feature is supported in the UDP > sockets. > > > I tried to have a look into the code but could not find much detail, > > > The link provides the development information is available, but it does not talk > about it. > > > > > Regards > Sarju > > _______________________________________________ Kamailio - Development Mailing List -- sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org<mailto:sr-dev-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender!

1 0

Re: [sr-dev] Re: SO_REUSEPORT
by Henning Westerholt 27 Feb '26

27 Feb '26

(switching to sr-users list) Hello, did you increase the private and shared memory pool settings? The default values are not suitable for larger tests and production environments. Cheers, Henning -- Kamailio services – https://gilawa.com<https://gilawa.com/> From: Sarju Garg <sarju(a)goldilocks-tech.com> Sent: Freitag, 27. Februar 2026 02:18 To: Henning Westerholt <hw(a)gilawa.com>; Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org> Cc: camille.oudot(a)orange.com; Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com>; Sergey Safarov <s.safarov(a)gmail.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi Henning, we've set up our servers and are currently seeing about 2000 CPS. At 5000 CPS, Kamailio shuts down with memory logging errors. We have an environment setup with 2 server each having 12 core and 64 GB RAM. One acting as sipp stub for generating load and second as simple application where when INVITE is received, it reject the call (4xx) and hit a HTTP trigger in async mode. Transaction module is used to keep track of it. Do we have any ready reference guide for troubleshooting or any help how to go about fixing this point. My understanding is it Kamalio setup should be able to handle 20k CPS for such simple application. Not sure replacing HTTP trigger with Kamalio or UDP hit may add more CPS handling capacity. Regards Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Friday, 20 February 2026 at 12:11 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: "camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>" <camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>>, Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>>, Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>, Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Subject: RE: [sr-dev] Re: SO_REUSEPORT Hello, usually, one would be interesting in measuring CPS/CAPS throughput or concurrent calls. TPS is not such a common metric for a VoIP system. But anyhow, its is not possible from the outside to guess if 20k TPS would be realistic in your setup. You might even run into limitation from the testing side with sipp. As said, usually you are getting issues with IO dependencies, e.g. databases or similar. A realistic setup would usually not use only one server for this load, as you want to have a high-available setup probably. As said, do some load tests on your side and see what you are getting. Then start analysing and eventual tuning, repeat the test and so on. Cheers, Henning -- Kamailio services – https://gilawa.com<https://gilawa.com/> From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Sent: Freitag, 20. Februar 2026 03:53 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>; Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>; Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi Henning, We have an environment setup with 2 server each having 12 core and 64 GB RAM. One acting as sipp stub for generating load and second as simple application where when INVITE is received, it reject the call and hit a HTTP trigger. We expect around 20000 TPS on this setup. Is this realistic expectation.? Regards, Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Thursday, 19 February 2026 at 5:18 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>>, "camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>" <camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>>, Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>, Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Subject: RE: [sr-dev] Re: SO_REUSEPORT Hello, I think Kamailio is using for the UDP server the SO_SEADDR flag, which is somehow similar as the SO_REUSEPORT. Kamailio is used in installation up to millions of customer devices. So, in many cases, the scaling challenges you are having are not related to Kamailio but to other infrastructure, e.g. a database or similar. I would suggest you setup a test environment for the performance requirements you are having and then doing some actual benchmarks. Cheers, Henning From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Sent: Donnerstag, 19. Februar 2026 11:09 To: Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Cc: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>>; camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>; Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>; Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT HI Sergey, Thanks. It supports connecting multiple child processes to a single UDP queue, but not sure if it does port reuse at UDP. There is a parameter for tcp_reuse_port. I understand if the tuple (src ip/port and Dest ip/port) is same, then there will be multiple consumers (connection parameter to create worker thread) . So multiple process will be waiting on single queue If I refer example in cook book , children=4 listen=udp:127.0.0.1:5080 listen=udp:127.0.0.1:5070 listen=udp:127.0.0.1:5060 4 children each would be created for 3 different ports, but in my case, it would be children=4 listen=udp:127.0.0.1:5080 As my IP / port is only one. However, I want 3 different queues to be created. As per the internet * SO_REUSEPORT: This socket option allows multiple threads or processes to bind to the same UDP port, each with its own socket and receive queue, which helps avoid contention on a single receive buffer lock in multi-core systems. Now since I have 3 different sources, I want to create 3 UDP queues with each having 4 consumers… I hope I can explain my problem, and hence using the SO_REUSEPORT option in UDP Regards Sarju But if src ip/port is different, like 3 src/ip sending to same dest ip/port,then 3 UDP queue is created and then multiple consumer will listen on 3 different queue. From: Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Date: Thursday, 19 February 2026 at 12:09 PM To: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Cc: "Kamailio (SER) - Development Mailing List" <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>>, "camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>" <camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>>, Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>, Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Kamailio supports port reuse. You just need to enable this feature in the config file and then start several Kamailio copies. For example using different systemd units. If I am not wrong, Kamailio supports distributing load to different processes forks on different cores. This is a present out of box and you do not need to do anything more. Just need to create additional UDP childrens. Sergey On Thu, Feb 19, 2026 at 1:23 AM Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> wrote: Hi, I am exploring REUSE_PORT Option for UDP. I am getting high TPS on single UDP port say 5060. Our customer will send the complete load from one IP and one port only. And from my side I have one IP and one port. As per my understanding in that case tuple antropy cannot be achieved so was thinking if REUSE_PORT. Can be done to have parallel queue and as per Linux document, the multiple queue on same port is created. My TPS requirement is about 20000 and try to see if how to architect the same. Regards Sarju From: Sergey Safarov <s.safarov(a)gmail.com<mailto:s.safarov@gmail.com>> Date: Wednesday, 18 February 2026 at 1:44 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Cc: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>>, "camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>" <camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>>, Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>, Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Subject: Re: [sr-dev] Re: SO_REUSEPORT for UTP transport all message to the same IP:PORT address use the same port when send via same socket. On Wed, Feb 18, 2026 at 9:31 AM Henning Westerholt via sr-dev <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> wrote: Hello, please describe what you are wanting to achieve. When we are talking about re-using ports in the SIP Kamailio context, usually its about TCP connections. This is supported from Kamailio when activated in the core. Cheers, Henning -- Kamailio services – https://gilawa.com > -----Original Message----- > From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> > Sent: Mittwoch, 18. Februar 2026 03:57 > To: Federico Cabiddu <federico.cabiddu(a)gmail.com<mailto:federico.cabiddu@gmail.com>> > Cc: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; Kamailio (SER) - Development > Mailing List <sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>>; giacomo.vacca(a)gmail.com<mailto:giacomo.vacca@gmail.com>; M S > <shaheryarkh(a)gmail.com<mailto:shaheryarkh@gmail.com>>; camille.oudot(a)orange.com<mailto:camille.oudot@orange.com>; Chandrabhan Kumar > <chandrabhan.kumar(a)goldilocks-tech.com<mailto:chandrabhan.kumar@goldilocks-tech.com>>; sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> > Subject: SO_REUSEPORT > > Hi all, > > > I want a help to understand if the reuse port feature is supported in the UDP > sockets. > > > I tried to have a look into the code but could not find much detail, > > > The link provides the development information is available, but it does not talk > about it. > > > > > Regards > Sarju > > _______________________________________________ Kamailio - Development Mailing List -- sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org<mailto:sr-dev-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender!

1 0

Kamailio v6.1.0 Released - new major version is out
by Daniel-Constantin Mierla 27 Feb '26

27 Feb '26

Kamailio v6.1.0 is out – it comes with 4 new modules and significant updates to the core components and existing modules. You can read a bit more detailed release notes at: * https://www.kamailio.org/w/kamailio-v6.1-0-release-notes/ Many thanks to all developers and community members that made possible this release. v6.1.0 brings more flexibility and optimizations across many existing components and modules, new parameters, functions, variables and transformations. Enjoy Kamailio v6.1.0! Thank you for flying Kamailio! 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

3 3

db_text module and deb packages
by Federico Cabiddu 24 Feb '26

24 Feb '26

Hi all, we've started to test the latest 6.1.x packages and we've realized that the db_text module is no longer included in the kamailio deb package. The change was meant to be done in this commit in 2022: https://github.com/kamailio/kamailio/commit/398e808719520b054fce25a722b9b79… but was effective from this one: https://github.com/kamailio/kamailio/commit/a9cebb564be125fa55d5cabfab6a5f8…. We extensively use db_text module in our deployments , we build kamailio's debian packages using https://github.com/kamailio/pkg-kamailio-docker (thanks Victor ;-)), going through the years from sid to trixie, and we've never had an issue with the module (nor compiling or using it). Is there any reason why the module has been removed from the debian package? Cheers, Federico

4 4

Intermittent TLS inbound failure behind HAProxy, Kamailio opens new TCP to HAProxy ephemeral port and gets RST
by joeygo＠gmail.com 23 Feb '26

23 Feb '26

Hello, We see an intermittent issue in our on premise deployments with Kamailio behind HAProxy. After several hours of idle time, some mobile clients cannot receive inbound calls, although they remain registered and can place outbound calls. Topology: Mobile Client → Internet → Customer Firewall → HAProxy → Kamailio Transport is SIP over TLS. HAProxy works in TCP mode and terminates nothing. It forwards TLS to Kamailio. Client behavior • REGISTER with Expires 600 seconds • Re-register every 7 minutes • TLS connection from client to HAProxy stays up • Outbound calls from client work • During the failure window, client continues to send REGISTER and receives 200 OK Failure scenario • Several devices placed idle overnight • In the morning, some cannot receive inbound calls • Kamailio tries to send INVITE to the contact • Kamailio opens a new TCP connection to HAProxy IP and an ephemeral port • HAProxy responds with RST Example log from Kamailio: INFO: request_route: method [INVITE] from [sip:UE_2@domain.com] to [sip:UE_1@domain.com] ERROR: tcpconn_1st_send(): connect 10.233.124.50:40398 failed (RST) Connection refused ERROR: tcpconn_1st_send(): 10.233.124.50:40398: connect & send failed WARNING: t_send_branch(): sending request on branch 0 failed PCAP confirms: • Kamailio sends SYN to 10.233.124.50:40398 • HAProxy replies RST, ACK Important observations 1. usrloc contact host and port match the peer address seen in tls.list (src_ip + src_port). 2. At the time of failure, the client is still able to send REGISTER and get 200 OK. 3. If the same client initiates a call, the call is established successfully. It looks like Kamailio sometimes fails to match the stored contact to an existing TLS connection and attempts to open a new TCP connection to the Contact host:port. In our case, Contact host resolves to HAProxy IP and port. Questions 1. Under which conditions does Kamailio decide to open a new TCP connection to the Contact instead of reusing an existing TLS connection? 2. If connection ID lookup fails, is fallback to active connect the expected behavior? Environment • Kamailio versions: 5.8.5, 6.0.5 (reproduced on both) • HAProxy: TCP mode, no TLS termination • Clients uses TLS only, no UDP Kamailio relevant configuration: tcp_connection_lifetime=605 modparam("registrar", "max_expires", 600) modparam("registrar", "use_path", 1) modparam("usrloc", "handle_lost_tcp", 1) modparam("usrloc", "close_expired_tcp", 1) HAProxy configuration: frontend client-kamailio-sip mode tcp option tcpka timeout client 600 default_backend server-kamailio-sip backend server-kamailio-sip from haproxytech mode tcp option tcpka timeout connect 30s timeout server 600s timeout tunnel 600s Any guidance on correct architectural pattern or configuration for SIP TLS behind HAProxy would be appreciated. Thank you. Joey.

3 8

Mobile App Development Company in USA
by michael.july82＠gmail.com 23 Feb '26

23 Feb '26

Leading mobile app development company in USA offering end-to-end solutions from strategy to deployment. https://appdevelopment.com/services/mobile-app-development/

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