sr-users March 2026

sr-users@lists.kamailio.org

30 participants
38 discussions

Kamailio v6.0.6 Released
by Daniel-Constantin Mierla 05 Mar '26

05 Mar '26

Hello, Kamailio SIP Server v6.0.6 stable release is out. This is a maintenance release of the stable branch 6.0, that includes fixes since the release of v6.0.5. There is no change to database schema or configuration language structure that you have to do on previous installations of v6.0.x. Deployments running previous v5.8.x versions are strongly recommended to be upgraded to v6.0.6. For more details about version 6.0.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2026/03/kamailio-v6-0-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note that 6.0.x is currently the previous stable release series, the latest is 6.1.x and v6.1.1 was released on March 4, 2026. 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

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.0.6
by Daniel-Constantin Mierla 05 Mar '26

05 Mar '26

Hello, I am considering to release Kamailio v6.0.6 (out of branch 6.0) on Thursday, Mar 5, 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. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

1 1

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

04 Mar '26

Hello, Kamailio SIP Server v6.1.1 stable release is out. This is a maintenance release of the latest stable branch, 6.1, that includes fixes since the release of v6.1.0. There is no change to database schema or configuration language structure that you have to do on previous installations of v6.1.x. Deployments running previous v6.1.x versions are strongly recommended to be upgraded to v6.1.1. For more details about version 6.1.1 (including links and guidelines to download the tarball or from GIT repository), visit: - https://www.kamailio.org/w/2026/03/kamailio-v6-1-1-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

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: Transaction Management
by Henning Westerholt 03 Mar '26

03 Mar '26

Hello, it is a bit difficult to follow all your different messages. This mailing list is for non-commercial support, and sometimes people can be busy or don’t know how to reply, so you might get not fast feedback. If you are in a time-critical project, you can always consider contacting one of the companies providing Kamailio services. You can find a list on https://www.kamailio.org/w/business-directory/ Cheers, Henning From: Sarju Garg <sarju(a)goldilocks-tech.com> Sent: Dienstag, 3. März 2026 06:05 To: Henning Westerholt <hw(a)gilawa.com>; sr-users(a)lists.kamailio.org; miconda(a)gmail.com; jh(a)tutpro.com Cc: Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com> Subject: Re: Transaction Management Hi , I want to understand how these transactions are cleared in Kamalio once they are created. Below, thing we are seeing transaction count as around 48000 which should be cleared ideally. I assume this 4800 is the count of outstanding call in the system. Below is the history of previous messages. Regards Sarju From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Date: Monday, 2 March 2026 at 6:10 PM To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>, "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>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi, I am running a load of 5000 with a cap of 50000 outstanding call using SIPP. The flow is as follows: 1. SIPP send the INVITE to kamalio 2. Kamalio send 100 trying 3. Kamalio open transaction and send HTTP for async to external system 4. External System send HTTP response 5. Kamalio send 480 to SIPP 6. SIPP send ACK I do not assume this call flow to take more than 1 second so count of max call should not max 2*5000 – 10000 but it is going upto 50000 which means the calls are there for 10 second in system. Can someone help what to look out for ? Regards Sarju From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Date: Monday, 2 March 2026 at 5:48 PM To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>, "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>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi, If I use HTTP/1.1, I am not able to use Connection: keep alive option as the connection is getting closed. What is the way to use Connection keep alive option in HTTP async request? Regards Sarju From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Date: Monday, 2 March 2026 at 5:41 PM To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>, "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>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi , I want to use HTTP/2 for sending the request to network instead of HTTP/1.1 while using async worker. Can someone suggest how to use HTTP/2? Regards Sarju From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Date: Monday, 2 March 2026 at 5:37 PM To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>, "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>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi, modparam("http_async_client", "connection_timeout", 1000) modparam("http_async_client", "timeout", 2000) I understand connection_timeout is the timeout for making HTTP connection, but timeout is the read timeout, where you wait for response. But timeout is not working. Can you confirm if there is something like this. Regards Sarju From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Date: Monday, 2 March 2026 at 5:29 PM To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>, "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>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi Henning, I need one clarification The flow is as follows: 1. SIPP send the INVITE to kamalio 2. Kamalio send 100 trying 3. Kamalio open transaction and send HTTP for async to external system 4. External System send HTTP response 5. Kamalio send 480 to SIPP 6. SIPP send ACK If we want to use async, transaction module is important. But if send 480 response before sending HTTP, then we get error. It look like call session ends if we send 480 and hence HTTP async fails. I want to delink SIP call flow with HTTP hit. I want to complete the SIP flow and the may be intimate the partner about the call thru HTTP. Can this be done? Should I use kafka here instead of HTTP and may be transaction module may be not required as well. Regards Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Monday, 2 March 2026 at 3:39 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 Hello, if you send UDP traffic to Kamailio, then it should distribute it to all UDP workers. If you observe it otherwise, please report back. Cheers, Henning From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Sent: Montag, 2. März 2026 10:52 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; 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>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi Henning, I agree, but since the UDP tuple is only 1, having multiple connection workers and HTTP async workers may increase the overhead of context switching, etc., considering the nature of the application. I am trying to benchmark it, but seeing that if some benchmark reports exist for a certain workload, which can be considered a benchmark and then the configuration is done accordingly. I will share result soon. Regards Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Monday, 2 March 2026 at 2:07 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 Hello Sarju, if you are having 12 CPU cores, you should utilize them. Use system observation tools like top etc.. to see how many workers are actually busy. You can also observe UDP queues, see worker details with kamcmd/kamctl. Kamailio worker can be configured for protocols and also modules for HTTP etc.. Cheers, Henning From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Sent: Sonntag, 1. März 2026 01:38 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; 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>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Thanks. It worked.. I just wanted to know one thing We have an environment set up with 2 server each having 12 cores and 64 GB RAM. On first server we have two stubs: 1) sipp stub for sending SIP load and 2) nginx with lua script to receive the HTTP requests and send responses On second server, we have our applicaiton on Kamalio using native script. The script is a 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. I want to set the connection and worker count in the program. I am first running load for 5000 TPS. My understanding is that since the SIP load is coming from same tuple, there will be no multiple queues (concept of port reuse) . So having multiple connection may increase contention. What should be the ideal size. I think 4 should be good enough? How can I check in logs how many instances are needed. The same for worker thread, the nginx is not doing much time and just need to log the request. So 4 async_workers should be enough too. We are currently testind and experiencing connection timeout between kamailo and nginx. Current connection and async workers are 8 and http connection timeout is 2000 ms. Regards Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Friday, 27 February 2026 at 4:50 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: 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>> Subject: RE: [sr-dev] Re: SO_REUSEPORT 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<mailto:chandrabhan.kumar@goldilocks-tech.com>> Sent: Freitag, 27. Februar 2026 12:17 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Cc: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@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 02 Mar '26

02 Mar '26

Hello, if you send UDP traffic to Kamailio, then it should distribute it to all UDP workers. If you observe it otherwise, please report back. Cheers, Henning From: Sarju Garg <sarju(a)goldilocks-tech.com> Sent: Montag, 2. März 2026 10:52 To: Henning Westerholt <hw(a)gilawa.com>; sr-users(a)lists.kamailio.org Cc: Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT Hi Henning, I agree, but since the UDP tuple is only 1, having multiple connection workers and HTTP async workers may increase the overhead of context switching, etc., considering the nature of the application. I am trying to benchmark it, but seeing that if some benchmark reports exist for a certain workload, which can be considered a benchmark and then the configuration is done accordingly. I will share result soon. Regards Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Monday, 2 March 2026 at 2:07 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 Hello Sarju, if you are having 12 CPU cores, you should utilize them. Use system observation tools like top etc.. to see how many workers are actually busy. You can also observe UDP queues, see worker details with kamcmd/kamctl. Kamailio worker can be configured for protocols and also modules for HTTP etc.. Cheers, Henning From: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@goldilocks-tech.com>> Sent: Sonntag, 1. März 2026 01:38 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; 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>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Thanks. It worked.. I just wanted to know one thing We have an environment set up with 2 server each having 12 cores and 64 GB RAM. On first server we have two stubs: 1) sipp stub for sending SIP load and 2) nginx with lua script to receive the HTTP requests and send responses On second server, we have our applicaiton on Kamalio using native script. The script is a 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. I want to set the connection and worker count in the program. I am first running load for 5000 TPS. My understanding is that since the SIP load is coming from same tuple, there will be no multiple queues (concept of port reuse) . So having multiple connection may increase contention. What should be the ideal size. I think 4 should be good enough? How can I check in logs how many instances are needed. The same for worker thread, the nginx is not doing much time and just need to log the request. So 4 async_workers should be enough too. We are currently testind and experiencing connection timeout between kamailo and nginx. Current connection and async workers are 8 and http connection timeout is 2000 ms. Regards Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Friday, 27 February 2026 at 4:50 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: 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>> Subject: RE: [sr-dev] Re: SO_REUSEPORT 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<mailto:chandrabhan.kumar@goldilocks-tech.com>> Sent: Freitag, 27. Februar 2026 12:17 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Cc: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@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 02 Mar '26

02 Mar '26

Hello Sarju, if you are having 12 CPU cores, you should utilize them. Use system observation tools like top etc.. to see how many workers are actually busy. You can also observe UDP queues, see worker details with kamcmd/kamctl. Kamailio worker can be configured for protocols and also modules for HTTP etc.. Cheers, Henning From: Sarju Garg <sarju(a)goldilocks-tech.com> Sent: Sonntag, 1. März 2026 01:38 To: Henning Westerholt <hw(a)gilawa.com>; sr-users(a)lists.kamailio.org Cc: Chandrabhan Kumar <chandrabhan.kumar(a)goldilocks-tech.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT Thanks. It worked.. I just wanted to know one thing We have an environment set up with 2 server each having 12 cores and 64 GB RAM. On first server we have two stubs: 1) sipp stub for sending SIP load and 2) nginx with lua script to receive the HTTP requests and send responses On second server, we have our applicaiton on Kamalio using native script. The script is a 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. I want to set the connection and worker count in the program. I am first running load for 5000 TPS. My understanding is that since the SIP load is coming from same tuple, there will be no multiple queues (concept of port reuse) . So having multiple connection may increase contention. What should be the ideal size. I think 4 should be good enough? How can I check in logs how many instances are needed. The same for worker thread, the nginx is not doing much time and just need to log the request. So 4 async_workers should be enough too. We are currently testind and experiencing connection timeout between kamailo and nginx. Current connection and async workers are 8 and http connection timeout is 2000 ms. Regards Sarju From: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> Date: Friday, 27 February 2026 at 4:50 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: 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>> Subject: RE: [sr-dev] Re: SO_REUSEPORT 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<mailto:chandrabhan.kumar@goldilocks-tech.com>> Sent: Freitag, 27. Februar 2026 12:17 To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Cc: Sarju Garg <sarju(a)goldilocks-tech.com<mailto:sarju@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

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