April 2026 - sr-users - kamailio.org

Postgres connections optimization #4342
by Stephane Savonitto 17 Jun '26

17 Jun '26

Hello, On P-CSCF when running we have 200+ permanent connection to postgres db, even if there is no traffic. Is there a way to manage connections dynamically using a pool like using PgBouncer ? Regards, Stéphane

6 10

6.0.2 to 6.1.1 Migration issue: malformed From header no longer reachable in routing script
by m.cazzola＠zaleos.net 19 May '26

19 May '26

Hello, I am writing regarding a behaviour change between Kamailio 6.0.2 and 6.1.1 that is causing one of our system tests to fail. The test sends intentionally malformed SIP INVITE requests and expects a 400 response. The failing cases involve malformed From headers (e.g. an empty From). After reviewing the changelog and tracing the code, we believe the change was introduced in commit cf1c796 (cherry-picked into 6.0.4), which reworks From header parsing in get_hdr_field() to use the shared parse_to_body() function. As a result, a malformed From now causes parse_headers() to return an error earlier in receive.c, before the message reaches the routing script. Previously, the From header parsing failure was caught deep enough in execution for our sanity_check() call in the request route to detect and handle it — sending back a 400 as RFC 3261 implies. Now, the failure happens before the routing script is reached. We have attempted to intercept it in event_route[core:pre-routing] and event_route[core:receive-parse-error], but to no avail. All of our other malformed type messages (e.g. a bad Expires value or invalid RURI) work as intended. Our questions are: Is there any hook, event, or flag we could use to detect and respond to this condition before the message is dropped? If no config-level workaround exists, are there any other alternatives? Thank you in advance for your time. Best regards,  Matteo Cazzola

3 6

Kamailio change rtpengine in mid-cal
by Myng 29 Apr '26

29 Apr '26

I am encountering an issue regarding how Kamailio handles rtpengine node failures mid-call, and I would like to clarify the expected behavior. *The Scenario:* I have a setup with multiple rtpengines (e.g., 4 nodes) all configured in the same pool with setid=0. 1. An initial INVITE arrives, and Kamailio successfully selects *rtpengine-A* for the call. 2. Later in the dialog, a re-INVITE occurs. 3. Coincidentally, *rtpengine-A* is unavailable at that exact moment. 4. Kamailio then automatically switches to a different rtpengine node in the set. *The Question:* Based on my reading of an older issue (#2713 <https://github.com/kamailio/kamailio/issues/2713>), my understanding was that Kamailio should *not* change the rtpengine node mid-call, as a new node will not have the media state for the ongoing session. Could you please confirm if my understanding is correct, or if Kamailio’s default failover behavior for mid-call transactions has changed recently? Thank you for your time and insights!

2 3

Carrier dont manage RR very well
by Benedito Marques 25 Apr '26

25 Apr '26

Hi, I have a scenario where there is a farm of asterisks behind kamailio. For 2 specific carriers, all the outbound calls don't complete. Testing, I've noted that when calling out from kamailio with the Record Route header, the call is lost (the invite does not return). kamailio.com:5060 -> carrier.com:5060 15:49:35.297529 -> INVITE (SDP) > 15:49:35.437412 <- 100 Trying > 15:49:35.437415 <- 100 Giving it a try > 15:49:35.437618 <- 407 Proxy Authentication Required > 15:49:35.440871 -> ACK > 15:49:35.441864 -> INVITE (SDP) > 15:49:35.942011 -> INVITE (SDP) (retransmission) > 15:49:36.941995 -> INVITE (SDP) (retransmission) > 15:49:38.941693 -> INVITE (SDP) (retransmission) > 15:49:42.941991 -> INVITE (SDP) (retransmission) If Record Route is removed, the call completes, but some messages like BYE or ACK turn back to asterisks directly, not through kamailio. Using the same sip account provided by the carrier in softphones and IP phones, it's possible to see that call completes too. The carrier refuses to implement the correct solution (treat Record Route headers correctly to complete the call), so what is the best approach in this situation? Is the usage of topology hiding as an alternative? -- Att, Benedito Marques

2 1

can't use msg_apply_changes() on failure route?
by David Villasmil 23 Apr '26

23 Apr '26

Hello all, I need to make changes on the SDP. The first change is fine on the request route, but i only need to make changes to it in the failure route to set it properly for the failover endpoint. I restore the sdp, but my problem is i can't modify it since i can't manipulate it: # Restore original dual-transport SDP before stripping for new dest -- $avp(orig_sdp) was saved on the initial request route. set_body("$avp(orig_sdp)", "application/sdp"); # Strip unsupported transport for new destination if ( $du =~ "tls" ) { xlogl("L_INFO", "[RTF_CARRIER] TLS dest - stripping RTP/AVP\n"); sdp_remove_transport("RTP/AVP"); } else { xlogl("L_INFO", "[RTF_CARRIER] Non-TLS dest - stripping RTP/SAVP\n"); sdp_remove_transport("RTP/SAVP"); } Any ideas how to accomplish this? Thanks! Regards, David Villasmil email: david.villasmil.work(a)gmail.com

2 1

Topos and TLS
by Martin Nyström 22 Apr '26

22 Apr '26

Hi, How am I expected to handle TLS when using TOPOS? listen=tls:192.168.5.122:5061 advertise foobar.pbx.com:5061 modparam("topos", "storage", "db") modparam("topos", "contact_host", “foobar.pbx.com") modparam("topos", "dialog_expire", 10800) When using TLS, TOPOS sets the contact header as something like this for a 200 OK returned. Contact: <sip:atpsh-69e6453f-a4-4@foobar.pbx.com> Is this valid? Or should it not be foobar.pbx.com:5061;transport=TLS It appears some vendors blindly use the contact header and returns the ACK for an example to a non TLS endpoint, despite the dialog (INVITE) starting out as TLS. /M

3 3

Kamailio v6.1.2 Released
by Daniel-Constantin Mierla 22 Apr '26

22 Apr '26

Hello, Kamailio SIP Server v6.1.2 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.1. 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.2. For more details about version 6.1.2 (including links and guidelines to download the tarball or from GIT repository), visit: - https://www.kamailio.org/w/2026/04/kamailio-v6-1-2-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.2
by Daniel-Constantin Mierla 22 Apr '26

22 Apr '26

Hello, the release of Kamailio v6.1.2 (out of branch 6.1) is considered to be done on Wednesday, April 22, 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

6.1 crashes
by Juha Heinanen 20 Apr '26

20 Apr '26

After updating my sip proxy to latest kamailio 6.1 branch running on Debian Trixie , I have noticed several crashes. syslog has this: 2026-04-19T16:41:19.664532+03:00 box kernel: kamailio[944355]: segfault at 0 ip 0000558b1c9ea97e sp 00007fffa1deb610 er\ ror 6 in kamailio[f297e,558b1c926000+3b0000] likely on CPU 2 (core 0, socket 4) 2026-04-19T16:41:19.664633+03:00 box kernel: Code: 00 00 00 48 8b 57 08 48 8b 07 f3 0f 7e 0d 8a 72 3f 00 48 8b 4f 10 64\ 4c 8b 24 25 28 00 00 00 4c 89 a4 24 88 00 00 00 41 89 f4 <48> 89 02 66 0f 6c ca 48 89 50 08 0f 11 07 48 83 c3 10 74 13\ 48 39 2026-04-19T16:41:19.936157+03:00 box /usr/sbin/kamailio[944455]: CRITICAL: <core> [core/pass_fd.c:284]: receive_fd(): E\ OF on 34 2026-04-19T16:41:20.435008+03:00 box /usr/sbin/kamailio[944292]: ALERT: <core> [main.c:824]: handle_sigs(): child proce\ ss 944355 exited by a signal 11 2026-04-19T16:41:20.435143+03:00 box /usr/sbin/kamailio[944292]: ALERT: <core> [main.c:828]: handle_sigs(): core was ge\ nerated 2026-04-19T16:41:20.435191+03:00 box /usr/sbin/kamailio[944292]: INFO: <core> [main.c:851]: handle_sigs(): terminating \ due to SIGCHLD 2026-04-19T16:41:20.435613+03:00 box /usr/sbin/kamailio[944405]: INFO: <core> [main.c:907]: sig_usr(): signal 15 receiv\ ed ... and core dump shows this: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 warning: 44 ./nptl/pthread_kill.c: No such file or directory (gdb) where #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007f7f7ef509ff in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89 #2 0x00007f7f7eefbcc2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f7f7eee44ac in __GI_abort () at ./stdlib/abort.c:77 #4 0x0000558b1c926d45 in ?? () #5 <signal handler called> #6 0x00007f7f7efb4907 in __GI_sched_yield () at ../sysdeps/unix/syscall-template.S:120 #7 0x0000558b1cc6c7ed in timer_del_safe () #8 0x0000558b1c9f8899 in destroy_dns_cache () #9 0x0000558b1c932537 in cleanup () #10 0x0000558b1c9332ed in ?? () #11 0x0000558b1c933fd3 in handle_sigs () #12 0x0000558b1c9395fd in main_loop () #13 0x0000558b1c92ae91 in main () Any ideas? -- Juha

2 7

Attempt to remove unwanted media streams has no effect
by David Villasmil 20 Apr '26

20 Apr '26

Hello all, It's been a while! I'm receiving from freeswitch an INVITE with both RTP/AVP and RTP/SAVP. Providers don0t like this, they want to see a single audio stream offer, and i want to remove the non-supported stream on kamailio, since i have to mix and match on failover. I see kamailio attempting to remove the streams but it has no effect whatsoever, you'll see below enumerating the streams to remove, but doesn't actually removes them... (i didn't print out the SDP, it's done by the module, so it should be ok, furthermore that's what i see being forwarded): ``` 5(13) DEBUG: INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1374]: sdp_remove_transport(): attempting to search for transport type: [RTP/AVP] 5(13) DEBUG: INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1390]: sdp_remove_transport(): stream 0 of 0 - transport [RTP/SAVP] 5(13) DEBUG: INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1390]: sdp_remove_transport(): stream 1 of 0 - transport [RTP/AVP] 5(13) DEBUG: INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1398]: sdp_remove_transport(): removing transport stream: RTP/AVP 5(13) DEBUG: INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1390]: sdp_remove_transport(): stream 2 of 0 - transport [RTP/SAVP] 5(13) DEBUG: INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1390]: sdp_remove_transport(): stream 3 of 0 - transport [RTP/AVP] 5(13) DEBUG: INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1398]: sdp_remove_transport(): removing transport stream: RTP/AVP 5(13) DEBUG: INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 textops [textops.c:2524]: ki_set_body(): new body: [v=0 o=FreeSWITCH 1776432039 1776432040 IN IP4 1.2.3.4 s=FreeSWITCH c=IN IP4 1.2.3.4 t=0 0 m=audio 25032 RTP/SAVP 0 8 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:13 CN/8000 a=crypto:1 AEAD_AES_256_GCM_8 inline:SJqvkk2FLvI0tOHPkn7Ac8TkrADNB7buSM6h9ZTBZHHh1OV9uOkGV1DF1DU= a=crypto:2 AEAD_AES_256_GCM inline:jnzCFpgWPjCIAz13r3vCfqbGzxE1x30DJl/0xOVWWS1m34Ka+dD1c45GQX4= a=crypto:3 AEAD_AES_128_GCM_8 inline:B4mysNibq+BH01ASVvceC7g69HmZUHrYtMVmDA== a=crypto:4 AEAD_AES_128_GCM inline:NLVvi1aEW+oWM+AQtV/5hKgMR274BscLBZAJRw== a=crypto:5 AES_256_CM_HMAC_SHA1_80 inline:eE3dGn207RnrLSeeTvSP05vUnQax7jATdiizGrVS9mxJQo/pcvvMlhoJdSYT+w== a=crypto:6 AES_192_CM_HMAC_SHA1_80 inline:VDveo9syEdOzxaIn9dpcMfG5ygdOv68yCpAnYwA8f0YlY51lElk= a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:8025UxyTFme6casTeasbrPYUt/ta2yoZGlQFvags a=crypto:8 AES_256_CM_HMAC_SHA1_32 inline:Ux9cBuGGe1Ft8knU7ZeWqnrOETHIqmVGjOTdi78GesXti6wO1ud0gvneW2JT+Q== a=crypto:9 AES_192_CM_HMAC_SHA1_32 inline:kxmHW+oXsu0NuCOwW3uXRmlMAgT1+2GUZjK2ExPC8sD2Xckonms= a=crypto:10 AES_CM_128_HMAC_SHA1_32 inline:MigohPAYbhU2QbJCRN6UUXcKIRAdhFur6EMDAziM a=crypto:11 AES_CM_128_NULL_AUTH inline:R9Aw9RUizWe8r07U8oV02fU+nQ4FkGmkhGflcoPY a=ptime:20 m=audio 25032 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:13 CN/8000 a=ptime:20 m=video 23724 RTP/SAVP 102 b=AS:1024 a=rtpmap:102 VP8/90000 a=rtcp-fb:102 ccm fir a=rtcp-fb:102 ccm tmmbr a=rtcp-fb:102 nack a=rtcp-fb:102 nack pli a=crypto:1 AEAD_AES_256_GCM_8 inline:EzIhXMiY/IU6pwGdiwIGs43YlIoBYrNyiK8XR1lc3auF3qf2GNCIrADZh8k= a=crypto:2 AEAD_AES_256_GCM inline:rSsEBQWi3qlC6nOcYD+xoz8Ux2dlPZDFf2zUOKR6XREkwvbExgQp1RCOjsQ= a=crypto:3 AEAD_AES_128_GCM_8 inline:nwMmmSlFJjhgrqCujnsXV2nFsCBpmkeZ9y5FMA== a=crypto:4 AEAD_AES_128_GCM inline:bAWJtV65VMLHXVvfHwbgwBEYa5Fqi0t9DCB2zg== a=crypto:5 AES_256_CM_HMAC_SHA1_80 inline:5m+7Gpqd1AIK8gEAMwti3yrS/cf5ig75Z9OSAAnjT6X8fDG9rBnYVZu0n9pyWg== a=crypto:6 AES_192_CM_HMAC_SHA1_80 inline:zbzJ7sGdUdytETroy6Txg4YU/qBjl1/JKR7VadHx8y61tfTfEaA= a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:5UiBkGVL9s/CjGIb3SPODZkTwJcfCipkiGZH4KI6 a=crypto:8 AES_256_CM_HMAC_SHA1_32 inline:KzBizz3SfxkK8n3MRvA70hCT9X95imVZldDAWzeHEjobSzzEGbAyc7YCZFYE1g== a=crypto:9 AES_192_CM_HMAC_SHA1_32 inline:hwSaAGg6n6loiNLIqg30ZAVaor5pm/ds8Llf2ti95pYR2kGPG3Y= a=crypto:10 AES_CM_128_HMAC_SHA1_32 inline:3/cf0KoXXso4L3+vpL95iBe3Nnu+QGdZxIDC1ulq a=crypto:11 AES_CM_128_NULL_AUTH inline:61izsKf/RCgzBtsNAAiTe+3w1sW/8GP6oET7cWcK m=video 23724 RTP/AVP 102 b=AS:1024 a=rtpmap:102 VP8/90000 a=rtcp-fb:102 ccm fir a=rtcp-fb:102 ccm tmmbr a=rtcp-fb:102 nack a=rtcp-fb:102 nack pli ] ``` Any help is greatly appreciated, thanks! Regards, David Villasmil email: david.villasmil.work(a)gmail.com

5 6