October 2025 - sr-users

using dlg_refer
by Robert Boardman 09 Oct '25

09 Oct '25

Hi All, I'm trying to use dlg_refer to separate to legs of a call and send them to another device, I think I have setup the system correctly, everything seems to look ok but the call to dlg_refer doesn't do anything , it doesnt even show in the journal that it is failing, just nothing happens Here is the code: #### REFER caller leg if ($dlg_var(caller_contact) != $null) { xlog("L_INFO", "Sending dlg_refer to caller: $var(conf_uri)\n"); #dlg_refer("caller", "$var(conf_uri)"); xlog("L_INFO", ">>> Attempting dlg_refer to caller: $dlg_var(caller_contact)\n"); if (!dlg_refer("caller", "$var(conf_uri)")) { xlog("L_ERR", "dlg_refer to caller FAILED\n"); } else { xlog("L_INFO", "dlg_refer to caller triggered\n"); } } The dialog state is 4 before the refer is initiated and can be seen from the kamcmd dlg.list. The caller end point allows REFER I've ran out of ideas as to where to look, any pointers would be a fantastic help I'm using Kamailio V5.8.6 Thanks Rob Robert Boardman Solution Architect Tel: 03330147908 Email: Robert.Boardman(a)gamma.co.uk This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster(a)gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at The Scalpel, 18th Floor, 52 Lime Street, London EC3M 7AF and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.

5 5

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