sr-users February 2026

sr-users@lists.kamailio.org

30 participants
27 discussions

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

Multiple double record routes in one BYE message
by Ibe Van de Veire 20 Feb '26

20 Feb '26

Dear Kamailio User Group, I am working on a project that uses Kamailio as an SBC. The SBC is configured as a multihomed device. It has an interface on the public side of the network and an interface on the internal (lan) side of the network. I successfully configured the SBC to handle calls in all directions (ext to ext, int to ext, ext to int). However, the call termination using BYE SIP messages does not seem to work in some situations. When performing a call from an external device to another external device (hairpinning), the termination sent from the callee does not reach the caller. Using sngrep, I can see the following flow for the BYE message: 1. BYE leaves callee 2. BYE is received by public interface of the sbc 3. BYE is passed to the private interface of the sbc 4. BYE is passed to the registrar on the internal network 5. BYE is passed back to the internal interface of the sbc 6. SBC responds with 404 not here CALLEE SBC (Public) SBC (Private) REGISTRAR | | | | |-------BYE--------->| | | | | | | | |~~~~(Internal)~~>| | | | | | | | |-------BYE-------->| | | | | | | |<------BYE---------| | | | | | |<~~~~(Internal)~~| | | | | | |<---404 Not Here----| | | | | | | The bye message contains the following record routes in the first step: Route: sip:6EAVHmFKfnIZxwFfgit29EJXQU1aMHI=@SBC_PUB_IP:62530;r2=on;lr;nat=yes Route: sip:6EAVHmFKfnIZxwFfgit29EJXQU1aMHI=@SBC_LAN_IP;r2=on;lr;nat=yes Route: sip:REGISTRAR_IP;lr;ftag=DomYqO1BCMhe-giL2X3KfBsMzgI7lEa9 Route: sip:SBC_LAN_IP;r2=on;lr;nat=yes Route: sip:SBC_PUB_IP:62530;r2=on;lr;nat=yes As you can see, the SBC uses double record routing to handle the multihomed setup. In the next step (step2 -> step3), the SBC does remove two record routes, and the record route list looks as following: Route: <sip:6EAVHmFKfnIZxwFfgit29EJXQU1aMHI=@SBC_LAN_IP;r2=on;lr;nat=yes> Route: <sip:REGISTRAR_IP;lr;ftag=DomYqO1BCMhe-giL2X3KfBsMzgI7lEa9> Route: <sip:SBC_LAN_IP;r2=on;lr;nat=yes> The loose_route() function seems to remove the wrong pair from the list. I would expect the following output: Route: sip:REGISTRAR_IP;lr;ftag=DomYqO1BCMhe-giL2X3KfBsMzgI7lEa9 Route: sip:SBC_LAN_IP;r2=on;lr;nat=yes Route: sip:SBC_PUB_IP:62530;r2=on;lr;nat=yes I feel like the rr module can not handle the multiple "double record routes" and matches the wrong entries. RR does in fact recognize the SBC_LAN_IP as an "own IP" because in the last step, the last 2 parts of the double record routing are also removed. Because all of this, in the last step, the internal interface of the SBC receives a BYE message without any record routes. This results in a dead end. Does someone know how I can tell Kamailio to remove the right pair of record routes. Is there a workaround for this? Am I doing something wrong? Kind regards Ibe Van de Veire System Engineer ibe.vandeveire(a)vrt.be<mailto:YOUR_NAME@vrt.be> Auguste Reyerslaan 52 B-1043 Brussel [VRT logo]<https://www.vrt.be/> [VRT Banner]<https://www.bit.ly/VRTHandtekening> -- Disclaimer -- Vlaamse Radio- en Televisieomroeporganisatie Auguste Reyerslaan 52 1043 Brussel nv van publiek recht BTW BE 0244.142.664 RPR Brussel VRT Gebruikersvoorwaarden <http://www.vrt.be/gebruiksvoorwaarden>

3 4

Is AI the Future of Construction or Just Another Tech Trend?
by alexs＠compindia.com 19 Feb '26

19 Feb '26

Artificial Intelligence is rapidly reshaping the construction industry. From predictive scheduling and cost estimation to real-time safety monitoring and equipment optimization, AI is improving efficiency across job sites. How are firms adopting AI tools for better decision-making and risk reduction? Is AI delivering measurable ROI, or are challenges slowing adoption? Let’s discuss practical experiences and insights.

1 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