sr-users July 2025

sr-users@lists.kamailio.org

56 participants
50 discussions

dynamic selection of authentication algorithm
by Juha Heinanen 28 Oct '25

28 Oct '25

How about this new function that sets the algorithm? -- Juha iff --git a/src/modules/auth/auth_mod.c b/src/modules/auth/auth_mod.c index 534ad9e20f..4e3a584d22 100644 --- a/src/modules/auth/auth_mod.c +++ b/src/modules/auth/auth_mod.c @@ -74,6 +74,10 @@ int w_consume_credentials(struct sip_msg *msg, char *s1, char *s2); * Check for credentials with given realm */ int w_has_credentials(struct sip_msg *msg, char *s1, char *s2); +/* + * Set authentication algorithm + */ +int w_auth_algorithm(struct sip_msg *msg, char *alg, char* s2); static int pv_proxy_authenticate( struct sip_msg *msg, char *realm, char *passwd, char *flags); @@ -170,6 +174,8 @@ static cmd_export_t cmds[] = { REQUEST_ROUTE}, {"pv_auth_check", (cmd_function)w_pv_auth_check, 4, fixup_pv_auth_check, 0, REQUEST_ROUTE}, + {"auth_algorithm", w_auth_algorithm, 1, fixup_spve_null, 0, + REQUEST_ROUTE}, {"bind_auth_s", (cmd_function)bind_auth_s, 0, 0, 0}, {0, 0, 0, 0, 0, 0} @@ -475,6 +481,35 @@ int w_has_credentials(sip_msg_t *msg, char *realm, char *s2) return -1; } return ki_has_credentials(msg, &srealm); + +} +/** + * + */ +int w_auth_algorithm(sip_msg_t *msg, char* alg, char* s2) +{ + if (fixup_get_svalue(msg, (gparam_t*)alg, &auth_algorithm) < 0) { + LM_ERR("failed to get algorithm value\n"); + return -1; + } + + if (strcmp(auth_algorithm.s, "MD5") == 0) { + hash_hex_len = HASHHEXLEN; + calc_HA1 = calc_HA1_md5; + calc_response = calc_response_md5; + } + else if (strcmp(auth_algorithm.s, "SHA-256") == 0) { + hash_hex_len = HASHHEXLEN_SHA256; + calc_HA1 = calc_HA1_sha256; + calc_response = calc_response_sha256; + } + else { + LM_ERR("Invalid algorithm provided." + " Possible values are \"\", \"MD5\" or \"SHA-256\"\n"); + return -1; + } + + return 1; } #ifdef USE_NC

5 13

SIP Trunk registration In Kamailio
by tanmoykarmakar10＠gmail.com 14 Oct '25

14 Oct '25

I want to register SIP Trunk directly in Kamailio. How can I register the SIP trunk in Kamailio. Please find the below sample SIP trunk details. Network IP 10.2.2.2 Subnet Mask 255.255.255.252 Customer IP 10.3.3.3 Gateway IP 10.1.1.1 SBCIP 10.4.4.4 Username 12345678 Password 1234 Please help me with configuration to register SIP trunk in kamailio.

4 4

Support for TLS server_name extension (aka SNI=server name indication)
by Barry Flanagan 04 Sep '25

04 Sep '25

Hi, Back in Kamailio 1.5, the release notes state: "support for TLS server_name extension (aka SNI=server name indication)" However, I cannot find any indication of this in the current TLS docs, and trying to set tls_server_name or server_name in tls.cfg fails with "unsupported option". Is this actually supported? Thanks. -Barry Flanagan

5 7

SDP Issue on NAT environment
by Nathan C 02 Sep '25

02 Sep '25

Hello, I have a kamailio on SITE A using a public IP. I'm trying to setup another kamailio on SITE B with NAT. When I try to make a call from SITE B to SITE A, the call is initiated but when comes the SDP my equipment on SITE B does not reply to SDP sent by kamailio on SITE A. I made some test and use only Public IP between the 2 sites and it works properly. So I think that I have a problem on my NAT configuration or maybe I'm missing something. Can someone help me one this problem ? Do you have an idea on what could be blocking. Thank in advance for your help. Regards, Nathan

3 6

[4.2] how to send out BYE successfully to close a TCP/TLS connection which misses the connection ID?
by Jack Wang 02 Sep '25

02 Sep '25

For some reasons, My settings will cause kamailio to be restarted even if there were connections connected to it. And when one SIP client in a connection wanted to hangup the call with a WebRTC Client (SIP over websocket) after the proxy-restarting, local client was closed, however , the other side was not. >From the log below it seems that the connection missed. Jan 30 18:19:31 ./kamailio[27857]: WARNING: <core> [msg_translator.c:2777]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found Jan 30 18:19:31 ./kamailio[27857]: ERROR: tm [t_msgbuilder.c:1365]: assemble_via(): assemble_via: via building failed Jan 30 18:19:31 ./kamailio[27857]: ERROR: tm [t_msgbuilder.c:1545]: build_uac_req(): build_uac_req(): Error while assembling Via Jan 30 18:19:31 ./kamailio[27857]: ERROR: tm [uac.c:379]: t_uac_prepare(): t_uac: Error while building message So, Is it equivalent to connection ID missing? And is there any way to make Websocket found the connection? Btw, after proxy-restarting for seconds , I typed `sh kamctl stats` : websocket:ws_current_connections = 1 It showed that the WebRTC Client will re-connect automatically, So I think this connection could be found by proxy, Any suggestion? Thanks :)

2 3

$http_rs shows 401 even when final response is 201 (http_async_query + Basic Auth)
by Joel Serrano 13 Aug '25

13 Aug '25

Hi all, I'm seeing some unexpected behavior from $http_rs when using http_async_query() to send a POST request to an endpoint that requires Basic (username/password) authentication. When I use: ``` $http_req(username) = "someuser"; $http_req(password) = "somepass"; ``` the request goes through and the server responds with a *201 Created*, as expected. The response body ($http_rb) contains the correct result. However, $http_rs still shows *401 Unauthorized*. I believe this happens because curl receives a 401 challenge first, then retries with the provided credentials and gets the correct 201. It seems $http_rs is reflecting the status from the initial challenge rather than the final response. This is on Kamailio v6.0.1. As a workaround, I tried manually setting the *Authorization* header like this: ``` $var(credentials) = "someuser:somepass"; $http_req(hdr) = "Authorization: Basic " + $(var(credentials){s.encode.base64}); ``` In that case, $http_rs correctly shows 201. Is it expected for $http_rs to stay at 401 in the first scenario? Or should it reflect the final status code after curl completes the full request cycle? Thanks, Joel.

2 3

Dispatcher failover to the next least loaded destination
by i.ribakov＠zaleos.net 05 Aug '25

05 Aug '25

Hi all, I'm wondering if it is currently supported to perform failover while respecting the call load distribution algorithm. What makes me doubt this is possible is the following wording in the documentation: > The rest of the destination list is taken in order of the entries in set - anyhow, until a re-route to next destination happens, the load on each address can change. From it it's not clear if ds_next_dst() will simplify use next entry from the AVP list or if it will attempt to intelligently choose next entry from the AVP list taking into the account updated call load of the remaining entries.

3 3

Unknown character set utf8mb4
by Igor Potjevlesch 05 Aug '25

05 Aug '25

Hello, We move to fresh version of Kamailio 6. We have a MySQL backend in an old version. We have many errors like this: ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:393]: db_do_update(): error while submitting query ERROR: dialog [dlg_db_handler.c:1000]: update_dialog_dbinfo_unsafe(): could not update database info ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:158]: db_do_query_internal(): error while submitting query ERROR: avpops [avpops_impl.c:328]: ops_dbload_avps(): db_load failed ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:158]: db_do_query_internal(): error while submitting query ERROR: avpops [avpops_impl.c:328]: ops_dbload_avps(): db_load failed It looks like the accounting module is not affected because we have writes in acc table. Registrar is affected because dump from location to location table is not working. Is there a way to make it work with older version of MySQL? Regards, Igor. -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

2 5

Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical)
by Sandro Gauci 31 Jul '25

31 Jul '25

Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical) - CVSS v4.0 - Exploitability: High - Complexity: Low - Vulnerable system: Medium - Subsequent system: Medium - Exploitation: High - Security requirements: High - Vector: https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N… - Other references: CVE-2025-53399 (https://www.cve.org/CVERecord?id=CVE-2025-53399) - Fixed versions: >= mr13.4.1.1 (https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1) - Enable Security Advisory: https://github.com/EnableSecurity/advisories/tree/master/ES2025-01-rtpengin… - Tested vulnerable versions: mr13.3.1.4 and lower - Timeline: - First report: 2025-04-24 - Triaged: 2025-04-30 - Fix provided for testing: 2025-05-05 - Various back and forth and more fixes: 2025-05 / 2025-06 - Vendor applied all fixes satisfactorily to master branch: 2025-06-05 - Enable Security verified and confirmed fix: 2025-06-26 - Vendor release with fix (mr13.4.1.1): 2025-07-03 - Enable Security advisory: 2025-07-31 DESCRIPTION Media servers often support source address learning to dynamically adapt to network conditions and client behavior. This is especially useful in scenarios involving NAT where the source IP and port of incoming RTP packets may differ from what was initially signaled via SDP over SIP. However, this mechanism can be exploited for two types of attacks if malicious packets are accepted as legitimate: 1. RTP Bleed - when a victim's media (e.g., audio) can be redirected to an attacker-controlled host 2. RTP Inject – when attackers can insert arbitrary RTP packets into active calls Note: Neither of these attacks requires the attacker to act as a man-in-the-middle. Additionally, when rtpengine relays SRTP packets in vulnerable versions, it does not validate their authentication tag, also allowing RTP Bleed and RTP Inject despite the use of SRTP which should guarantee confidentiality and integrity. Instead of dropping packets with missing or invalid authentication tags, it forwards them for processing. The purpose of this advisory is to describe security fixes that aim to fully address or at least mitigate these RTP Bleed and RTP Inject attacks wherever possible. While complete elimination of these vulnerabilities may not always be achievable due to the inherent nature of RTP learning mechanisms, the fixes provide significant improvements in security posture. TECHNICAL DETAILS Rtpengine provides the following learning modes through the --endpoint-learning option: - delayed (default): waits 3 seconds before learning the source address from the first RTP packet received after the delay. - immediate: learns the address from the very first incoming packet, with no delay. - no-learning: disables learning entirely, which is the only mode that is not vulnerable but can break connectivity for clients behind NAT. - heuristic: combines a 3-second delay with a ranking system that prefers addresses matching the original SDP, falling back to partial matches or any observed address if necessary. Additionally, rtpengine supports an optional strict source flag that forces continued inspection of source addresses and ports of incoming RTP packets. It does this after the learning phase, enforcing what was previously learned. The strict source flag is meant to prevent RTP Inject but needs the learning mode to work as expected for it to also work correctly. The often recommended mitigation is to make use of SRTP, with the assumption that rtpengine would discard any RTP packets that fail the authentication tag check. However, in rtpengine mr13.3.1.4 and lower, this was not found to be the case when using SDES-SRTP. The following is a behavior matrix for rtpengine versions mr13.3.1.4 and lower showing different learning modes and flags. This table shows that none of the learning modes nor strict source mitigated the attacks described, except for the combination of strict source with no-learning: | Delayed | Heuristic | No learning | Immediate | no strict source | Inject, Bleed | Inject, Bleed | Inject only | Inject, Bleed | strict source | Inject, Bleed | Inject, Bleed | No Inject or Bleed | Inject, Bleed | The same behavior occurred whether rtpengine relayed plaintext RTP or SDES-SRTP. The heuristic flag did not prevent RTP Bleed or RTP Inject attacks, even when the correct IPs and ports are exchanged over SDP. With the updated version, rtpengine's heuristic behavior was changed so that the learning modes behave as expected, giving administrators the opportunity to mitigate these vulnerabilities while still handling NAT complexities. The following is the same behavior matrix, but with the fixed version: | Delayed | Heuristic | No learning | Immediate | no strict source | Inject, Bleed | Inject, <5 packets Bleed | Inject only | Inject, Bleed | strict source | Inject, Bleed | <5 packets Inject, <5 packets Bleed | No Inject or Bleed | Inject, Bleed | This means that with the updated version, the heuristic mode limits attacks to at most the first 5 packets for both injection and bleeding. We believe that in many live environments, the recommended setup would be to use heuristic learning with strict source, which keeps the flexibility of endpoint learning while significantly mitigating RTP inject and RTP bleed attacks. In the case of SDES-SRTP, we also recommend using heuristic learning mode with strict source, which keeps the flexibility of endpoint learning while mitigating RTP inject and RTP bleed. However, for complete protection with SRTP, a patch specific to SRTP was introduced by adding a new recrypt flag. This flag forces rtpengine to decrypt and then re-encrypt RTP packets, thus validating the authentication tag before any further processing. This ensures that unauthenticated packets are discarded. This new flag should be used in addition to the previously recommended learning mode and flag. Patched version behavior matrix for SDES-SRTP, with and without recrypt: | Delayed | Heuristic | No-learning | Immediate | Without recrypt | Inject, Bleed | Inject, <5 packets Bleed | Inject only | Inject, Bleed | With recrypt | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | There is the special case of DTLS-SRTP, typically used for WebRTC environments, which was found vulnerable to RTP Bleed but not RTP Inject. This was due to the logic applied in this case, where learning mode occurred before the RTP packets were properly validated. This has also received a security fix. IMPACT In the case of plaintext RTP, this vulnerability allows attackers to perform RTP Inject as well as RTP Bleed. RTP Inject affects the integrity of the media while RTP Bleed affects the confidentiality of calls. In cases where rtpengine is relaying plaintext RTP as well as when it relays SRTP (in vulnerable versions), the vulnerabilities will cause Denial of Service because the RTP packets will be sent to the attacker instead of the legitimate recipient. HOW TO REPRODUCE THE ISSUE To reproduce this issue in a reliable manner, a security tester needs three different parties each with their own IP address: 1. Vulnerable rtpengine server 2. An attacker node 3. A victim user node Steps: 1. Run tcpdump on the attacker node to monitor for incoming packets from the target: tcpdump -iany -w /tmp/rtpbleed.pcap src host <target_ip> and not icmp 2. Save the following Python script as sprayrtp.py: import socket, argparse parser = argparse.ArgumentParser(description="Spray simple RTP packets over a port range") parser.add_argument("target", help="Target IP address") parser.add_argument("start_port", type=int, help="First UDP port to spray") parser.add_argument("end_port", type=int, help="Last UDP port to spray") args = parser.parse_args() rtppacket=[0x80, 0x0, 0xee, 0x3c, 0x4, 0x42, 0xa2, 0xc1, 0xef, 0xa, 0x7, 0xde] rtppacket+=[0x0 for _ in range(160)] sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) while True: for port in range(args.start_port, args.end_port + 1): sock.sendto(bytes(rtppacket), (args.target, port)) 3. Run the script on the attacker node against the target: python3 sprayrtp.py <target_ip> <start_port> <end_port> 4. From the victim user node, place a number of calls that make use of SRTP. 5. Observe that tcpdump on the attacker node will show incoming packets from the vulnerable target. Note: a SIP signaling server such as Kamailio or OpenSIPS is usually part of the setup as well. SOLUTIONS AND RECOMMENDATIONS It is recommended to upgrade to a fixed version, and to either disable learning entirely or use the heuristic learning mode in conjunction with the strict source flag. When using SDES-SRTP, it is recommended to use both strict source and recrypt flags for complete protection. While fixes for the heuristic mode were backported to earlier versions, the new recrypt flag is only available in the latest version. In the case of DTLS-SRTP, a fix was made so that SRTP validation occurs before learning mode. We highly recommend upgrading to access these security features. The first version that includes the fixes is available at https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1. ABOUT ENABLE SECURITY Enable Security (https://www.enablesecurity.com) provides quality penetration testing to help protect your real-time communications systems against attack. DISCLAIMER The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. DISCLOSURE POLICY This report is subject to Enable Security's vulnerability disclosure policy which can be found at https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy.

2 2

No audio Over VPN
by Fernando Lopes 31 Jul '25

31 Jul '25

Hello everyone, I'm having some issues with SIP when the VPN is active. I'm running a Docker container inside WSL. My WSL IP is 172.31.217.74, and my machine's IP is 192.168.1.77. When I connect to the VPN, I get the IP 192.168.1.129. When I place a call, I see this log. I've tried disabling ICE, setting the public IP of the SIP server in MicroSIP, and manually specifying my local machine IP. This does change the c= and a= parameters in the SDP, but it still doesn't work. Everything works fine without the VPN. I need the VPN active to access certain endpoints, but SIP stops working once it's connected. INVITE sip:100@localhost;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.31.208.1:54367;rport;branch=z9hG4bKPjb591721e91454d2bae56a9edfc645ebe;alias Max-Forwards: 70 From: "6001" <sip:6001@localhost>;tag=daa078657d2949e68935f308beeb8b89 To: <sip:100@localhost> Contact: "6001" <sip:6001@172.31.208.1:54367;transport=TCP;ob>;+sip.ice Call-ID: 49c169a9e92d4b23ad70709636ccab4f CSeq: 13400 INVITE Route: <sip:172.31.217.74;transport=tcp;lr> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.21.6 Content-Type: application/sdp Content-Length: 1345 v=0 o=- 3962710251 3962710251 IN IP4 192.168.1.129 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4030 RTP/AVP 8 0 96 97 98 9 99 100 101 102 103 c=IN IP4 192.168.1.129 b=TIAS:64000 a=rtcp:4001 IN IP4 192.168.1.129 ... a=ice-ufrag:1d266809 a=ice-pwd:2f7e2ef6047a47d832ed0f55 a=candidate:Hc0a80181 1 UDP 2130706431 192.168.1.129 4030 typ host a=candidate:Hc0a8014d 1 UDP 2130706175 192.168.1.77 4030 typ host a=candidate:Hc0a83801 1 UDP 2130705919 192.168.56.1 4030 typ host a=candidate:Hac1fd001 1 UDP 2130705663 172.31.208.1 4030 typ host a=candidate:Hc0a80181 2 UDP 2130706430 192.168.1.129 4001 typ host a=candidate:Hc0a8014d 2 UDP 2130706174 192.168.1.77 4001 typ host a=candidate:Hc0a83801 2 UDP 2130705918 192.168.56.1 4001 typ host a=candidate:Hac1fd001 2 UDP 2130705662 172.31.208.1 4001 typ host Does anyone know where the problem may be?

4 5

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 July 2025