sr-users October 2025

sr-users@lists.kamailio.org

34 participants
25 discussions

unexpected log_prefix
by 13715209697＠139.com 09 Oct '25

09 Oct '25

kamailio v5.7.4 cat kamailio.cfg log_prefix="$timef(%Y%m%d-%H:%M:%S) LUA {$rm}: " cfgengine "lua" ... but the actual log is: 1(8) INFO: 20251009-14:25:19 LUA {REGISTER}: <core> [core/kemi.c:109]: sr_kemi_core_info(): si==========192.168.1.126, sp==========5060 1(8) INFO: 20251009-14:25:19 LUA {REGISTER}: <core> [core/receive.c:533]: receive_msg(): request-route executed in: 3136 usec 3(10) INFO: 20251009-14:25:19 LUA {REGISTER}: <core> [core/kemi.c:109]: sr_kemi_core_info(): si==========192.168.1.126, sp==========5060 3(10) INFO: 20251009-14:25:19 LUA {REGISTER}: <core> [core/receive.c:533]: receive_msg(): request-route executed in: 8200 usec What is the 1(8) in the first line? How to remove the '1(8) INFO:'? Thanks!

2 2

List of all known Kamailio vulnerabilities
by James Morrison 07 Oct '25

07 Oct '25

I am looking for a list of all known Kamailio vulnerabilities related to version 5.3 and higher. So far I found only two that affect 5.3: CVE-2020-27507 and CVE-2020-28361. Is there any curated list of these vulnerabilities? Any help is much appreciated.

2 3

secsipid certificate issue for STIRSHAKEN
by Martin Nyström 06 Oct '25

06 Oct '25

Hi, I’ve used Peeringhub to generate certificates for STIRSHAKEN. They have given me one 481L.crt and stir_private_key.pem. However, I am having issues using these in Kamailio. All Kamailio does on secsipid_add_identity is return an ambigious error “failed to get identity header body (0)” even with higher debug level. secsipid_add_identity("$fU", "$rU", "A", "$fU", "/etc/kamailio/certificates/stirshaken20251002/481L.crt", "/etc/kamailio/certificates/stirshaken20251002/stir_private_key.pem "); Both the crt and the key have kamailio as owner and chmod 640. I am wondering if the certificates are not compatible with Kamailio. Here’s the result of: openssl x509 -in 481L.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: ec:0b:c0:fb:69:40:35:03:0e:7e:22:8f:12:3e:d3:0e Signature Algorithm: ecdsa-with-SHA256 Issuer: C = US, O = Peeringhub Inc, OU = Certification Authorities, CN = Peeringhub Inc SHAKEN Intermediate CA 2 Validity Not Before: Oct 2 12:12:51 2025 GMT Not After : Oct 2 12:12:51 2026 GMT Subject: C = US, ST = WA, L = Washington DC, O = Connectel AB, CN = SHAKEN 481L 1759407171535 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:ab:b3:21:c9:6e:20:fc:f4:43:89:e6:30:88:1f: 87:3c:38:f5:7d:ac:2c:06:3b:38:f6:11:ba:68:d1: 82:cb:1d:e6:f6:ee:0c:92:ef:66:64:8c:98:73:8b: a2:6a:9d:06:33:62:1d:d3:ec:cd:f1:4f:ee:d2:09: 95:ba:98:ae:f7 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: B8:D8:8C:F6:00:A7:3B:3D:87:58:2C:54:4A:7E:13:6D:F8:71:9B:8D X509v3 Authority Key Identifier: keyid:AE:A1:73:51:88:29:57:11:CA:0C:A9:F4:B1:0A:6E:4E:B8:4B:4D:07 X509v3 Certificate Policies: Policy: 2.16.840.1.114569.1.1.4 1.3.6.1.5.5.7.1.26: 0.....481L X509v3 CRL Distribution Points: Full Name: URI:https://authenticate-api.iconectiv.com/download/v1/crl CRL Issuer: DirName:L = Bridgewater, ST = NJ, CN = STI-PA CRL, C = US, O = STI-PA Signature Algorithm: ecdsa-with-SHA256 30:46:02:21:00:bb:18:07:ee:90:6d:a3:6f:0d:d5:af:49:82: f5:ea:aa:5c:03:74:87:22:28:a2:24:5c:02:05:f6:de:ca:82: c8:02:21:00:87:db:0a:48:2c:a7:7a:6f:87:2e:93:14:9a:04: 34:4d:1b:07:0b:bf:f2:61:37:8c:c5:85:67:68:ac:0c:9d:08 Here’s the filtered result of: openssl pkey -in /etc/kamailio/certificates/stirshaken20251002/stir_private_key.pem -text -noout Private-Key: (256 bit) priv: <FILTERED> pub: 04:ab:b3:21:... ASN1 OID: prime256v1 NIST CURVE: P-256 Thanks for any help, /M

2 2

DMQ Status Flapping Between Active and Pending.
by satyaprakash ch 06 Oct '25

06 Oct '25

Hi, I have *two Kamailio presence servers running version 5.8.4*. I am using *DMQ* to synchronize the active_watchers and presentity tables, but the synchronization does not seem to be occurring consistently. During investigation, I observed that the *DMQ status repeatedly toggles between active and pending*, even though there is *no packet loss* detected. *Output of dmq_nodes:* { host: 192.168.18.96 port: 5070 proto: * resolved_ip: 192.168.18.96 status: pending last_notification: 0 local: 0 } { host: 192.168.18.99 port: 5070 proto: * resolved_ip: 192.168.18.99 status: active last_notification: 0 local: 1 } Any suggestions on what could cause this behavior would be greatly appreciated.

2 3

Kamailio SBC using RTPproxy
by Ibe Van de Veire 01 Oct '25

01 Oct '25

Dear Kamailio community, I am currently developing a VoIP system using 2 instances of Kamailio. One as SBC and one as SIP server. The SBC is configured to work in bridge mode (one NIC on the public side, one NIC on the private side). The SIP server works as expected. But the SBC server seems to have some difficulties to route the RTP traffic. I am using RTPproxy to handle NAT traversals. Currently, I handled the following situations: * Internal to internal call * External (both NAT and CG-NAT) to internal call * Internal to external (both NAT and CG-NAT) call The situation that does not work is the following: * External (both NAT or CG-NAT) to External (both NAT or CG-NAT) The SBC seems to always translate the IN IP4 field from external to internal (as desired when calling from external to internal), but this seems not to be desired when calling from external to external. This way, both external devices try to send the RTP data to the internal (inaccessible) address of the SBC. How can I configure the SBC to stop translating the IN IP4 field when both devices are external? I have the following configuration that talks to the RTPproxy service: ========================== if(nat_uac_test("8")) { if($Ri == "MY_PUBLIC_IP") { rtpproxy_manage("coiew"); } else { rtpproxy_manage("faei"); } } else { rtpproxy_manage("cor"); } ========================== Also, is this the desired way to handle NAT traversal with RTPproxy? Kind regards Ibe Van de Veire System Engineer -- 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>

5 6

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