sr-users April 2026

sr-users@lists.kamailio.org

30 participants
26 discussions

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

Failover-Failback without any Load-Balancing
by Kama User 19 Apr '26

19 Apr '26

Hi. I'm trying to make failover-failback without any Load-Balancing with kamailio paired with HiPath 3800. Ubuntu 20.04, kamailio 5.5.7 # dispatcher.list 1 sip:192.168.1.10:5060 0 0 p=primary 1 sip:192.168.1.11:5060 0 0 p=secondary # IP Addresses of Kamailio Server listen=udp:10.0.0.203:5060 listen=tcp:10.0.0.203:5060 listen=tls:10.0.0.203:5060 # --- Module Parameters --- modparam("tm", "fr_timer", 10000) modparam("tm", "fr_inv_timer", 60000) modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "flags", 2) modparam("dispatcher", "force_dst", 1) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_interval", 10) modparam("dispatcher", "ds_probing_mode", 1) # Probes all nodes, even if inactive modparam("dispatcher", "ds_probing_threshold", 2) modparam("dispatcher", "ds_inactive_threshold", 5) # --- Routing Logic --- request_route { if (is_method("INVITE|REGISTER")) { if (!ds_select_dst("1", "8")) { sl_send_reply("503", "No servers available"); exit; } xlog*("Selected Destination $rd/$du \n"); t_on_failure("FAILOVER"); t_relay(); } } failure_route[FAILOVER] { if (t_check_status("503|408")) { xlog("Failed Destination $rd/$du \n"); if (ds_next_dst()) { t_on_failure("FAILOVER"); t_relay(); } } } When both PBXs are online I check the log file and see that Selected Destination is 10.0.0.203/sip:10.0.0.65. I also check via sngrep: if both PBXs are up I see OPTIONS to both of them 10.0.0.65 and 10.0.0.75 When I shutdown 10.0.0.65, log file says Failed Destination is 10.0.0.203/sip:10.0.0.65 and that's it. ds_next_dst not triggering at all. Thanks in advance.

4 13

Re: how to get all non-execluded modules to single kamailio Debian package?
by Juha Heinanen 19 Apr '26

19 Apr '26

Just to complete this topic, I managed to do it by: 1) removing all other packages except kamailio from debian/control 2) added LOTS of modules to debian/rules EXCLUDED_MODULES list 3) added my local module to MOD_LIST_UTILS list The process would have been MUCH easier, if there would have been INCLUDED_MODULES list. Also, when new modules are introduced, I would not need to do anything. -- Juha

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users April 2026