sr-users February 2025

sr-users@lists.kamailio.org

34 participants
32 discussions

SNMP thresholds
by Sergio Charrua 27 Feb '25

27 Feb '25

Hi all! we have set SNMP stats on our production server. The server is only receiving 1% of the calls, less than 1 CAPS, but we are receiving some SNMP alarms that are a bit weird to us. [image: image.png] This is an example. As we were unsure about the thresholds to be set for Msg Queue, we set Minor to 20 and Major to 100, which resulted in some alarms when we exceeded the Major threshold. From our understanding, the Max Major MSG Queue threshold was 2176, which obviously generated an alarm. But we can't understand why when a Msg Queue depth of 1280 generated an Minor Threshold alarm when the threshold is 20!! Why not generate a Major Threshold alarm instead, as it did reach the Major Threshold ? Also, does anyone have a clue on how to estimate Major and Minor thresholds? How does this Msg Queue handler work? Is it Kamailio's level or on OS/Kernel level that it gets the statistics from? Apart from the official Kamailio SNMPStats docs, any doc or article one would share? greatly appreciated. ( I so much hate SNMP!!! :) ) Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

1 0

Tweaking TCP/TLS connection timers
by Ihor Olkhovskyi 27 Feb '25

27 Feb '25

Hello, I'm observing a bit strange behavoir of Kamailio, but maybe I'm wrong in my assumptions. In some cases Kamailio just closes absolutely valid TCP connection, as I see it in Wireshark [image: image.png] At the same time I do see in Kamailio logs a lots of lines with tcp_timer_check_connections(): message processing timeout on connection id: XXXXX (state: 0) - closing I see that many TCP connections are closing (and it's ok as we have mobile devices connected and loosing connections for them is ok) But for me this connection is perfectly ok looking on TCP keepalives, what can cause this behavoir? I have these TCP options tcp_connect_timeout=30 tcp_conn_wq_max=63536 tcp_crlf_ping=yes tcp_delayed_ack=yes tcp_fd_cache=yes tcp_keepalive=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=10 tcp_linger2=30 Kamailio 5.8.3 Any hints are appreciated. -- Best regards, Ihor (Igor)

2 2

Kamailio and TLS-PSK Support
by Юрій Пивоваров 27 Feb '25

27 Feb '25

Dear Kamailio Community, I am currently exploring the possibility of configuring Kamailio to use TLS-PSK (Pre-Shared Key) for secure SIP signaling. Has anyone successfully configured Kamailio to work with TLS-PSK? If so, could you share any guidance, configuration examples, or relevant modules that need to be adjusted? In this setup, the SIP client will be a device with very limited resources, making it impossible to use certificates. This is why I am specifically looking into a TLS-PSK solution. I have also tried configuring stunnel as a proxy and set listen = tcp:127.0.0.1:5061 in kamailio config, but I haven't been able to get it working. Any suggestions on what might be missing or misconfigured? Thank you in advance for your help!

1 0

Drop RTP Flow and move to another point
by Social Boh 26 Feb '25

26 Feb '25

Hello List, before spending much time on solving this scenario, I'd like to know if this kind of operation can be done using some Kamailio function (maybe dlg_req_within?) or other method. The scenario is: a B2B-1 server call two different destinations, one is a SIP trunk and another is another B2B-2. Both calls go through Kamailio which uses RTPEngine for the media flow. The idea is to drop the first B2B from RTP Flow (leave for signaling) when both calls are answered and leave everything to Kamailio-RTPEngine, like: LegA: Kamailio-RTPEngine -> B2B-2 LegB: Kamailio-RTPEngine -> SIP trunk Thank you in Advance Regards --- I'm SoCIaL, MayBe

1 1

PRACK Retransmission and 408 Timeout Issue in Kamailio
by 高秉寬 26 Feb '25

26 Feb '25

Dear Kamailio Developers, I am using Kamailio as a SIP server to facilitate a phone call, but I am encountering an issue where the call cannot be established due to Kamailio sending a 408 Request Timeout to the caller. Issue Details: - A (Caller) sends an initial INVITE to Kamailio, which then forwards it to B (Callee). The INVITE contains the following Supported header: Supported: timer,100rel,replaces,precondition,from-change,histinfo,tdialog I suspect the *precondition* option may be relevant to the issue. - *B* responds with a *183 Session Progress* message, which includes: Require: 100rel,precondition Kamailio correctly forwards this response to *A.* - *A* then sends a *PRACK* request to Kamailio. However, this request contains: Require: sec-agree Supported: timer Notably, *precondition* is absent from both the *Require* and *Supported* headers. - Kamailio forwards this *PRACK* to *B*, and *B* responds with *200 OK*, including: Supported: 100rel,from-change,tdialog - However, Kamailio does not seem to acknowledge *B's 200 OK* and instead *keeps retransmitting the PRACK* to *B*. B responds with *200 OK* again, but the cycle repeats. - After three retransmissions of *PRACK*, Kamailio eventually sends *408 Request Timeout* to *A*, leading *A* to send a *CANCEL* request. Device Used: - *Caller (A):* Asus ROG Phone 5 - *Callee (B):* Asus ROG Phone 6 Both are commercially available mobile phones. Possible Cause: According to *3GPP TS 24.229, Subclause 5.1.3.1*, If the received response with an SDP body includes a Require header with > the "precondition" option-tag, the originating UE shall include a Require > header with the "precondition" option-tag in responses with an SDP body to > subsequent requests that include an SDP body and include the "precondition" > option-tag in either the Supported or Require header field received > in-dialog. In this case: - The *183 Session Progress* from *B* contains Require: *precondition*. - The subsequent *PRACK* from *A* does not include *precondition* in either *Require* or *Supported*. Could this mismatch be the reason Kamailio keeps retransmitting *PRACK* and ignoring *B's 200 OK*? Or could there be another factor causing Kamailio to behave this way? If additional details are needed, please let me know. Best regards, Ping Kuan Kao

3 4

Issue with registrations
by Anthony Ford 26 Feb '25

26 Feb '25

Hi Version = 5.6.0-dev0 We are seeking help to resolve an issue with registering devices to 3CX (All 3CX servers, have tried 8 different ones) . all the auth info including passwords etc are identical on the 3cx servers. We use Kamailio to register mobile sim cards to 3rd party sip servers i.e. 3CX. We send the normal Username, server addresses and auth details but are experiencing failures with 3CX rejecting the registration and return Proxy Auth failure 407. We have noticed in the pcaps from both sides that the expire value is changing from 180 as an example to 0. As an example In the uac reg_dump the values are : l_uuid: +447529135850<tel:+447529135850> l_username: +447529135850<tel:+447529135850> l_domain: sbc-mt.asim.apalo.io<http://sbc-mt.asim.apalo.io/>;transport=udp r_username: 1001 r_domain: egte.3cx.uk<http://egte.3cx.uk/> realm: <null string> auth_username: FdlHDC1IvA auth_password: extracted auth_ha1: none auth_proxy: sip:egte.3cx.uk:5060 expires: 60 flags: 0 diff_expires: -1738853736 timer_expires: 0 reg_init: 1738850836 reg_delay: 0 contact_addr: k01.asim.apalo.io<http://k01.asim.apalo.io/>;transport=tcp socket: <null string> [cid:image001.png@01DB86AB.2701F190] [cid:image002.png@01DB86AB.2701F190] [cid:image003.png@01DB86AB.2701F190] Looking forward to hearing from you. Many thanks Tony Ford

3 3

REG_MAR_REPLY never get executed
by stinktohighheaven＠gmail.com 26 Feb '25

26 Feb '25

Using Kamailio v5.3, based on the example for scscf found here: https://github.com/kamailio/kamailio/blob/master/misc/examples/ims/scscf/ka… after calling ims_www_challenge("REG_MAR_REPLY", "$var(realm)", "$var(alg)"); the control never goes to REG_MAR_REPLY route block, but it goes to the start of the requet_route block. here is the kamailio.cfg script: request_route { ....... /* Handle Registrations */ if (is_method("REGISTER")) { route(REGISTER); exit; } ...... } /** * Handling of REGISTER requests */ route[REGISTER] { ...... #!ifdef WITH_AUTH if (!ims_www_authenticate("$var(realm)")) { #!else if ($var(alg) == "3GPP-Digest" && !ims_www_authenticate("$var(realm)")) { #!endif if ($? == -2) { send_reply("403", "Authentication Failed"); exit; } else if ($? == -3) { send_reply("400", "Bad Request"); exit; } else if ($? == -9) { xdbg("Authentication re-sync requested\n"); ims_www_resync_auth("REGISTER_RESYNC_REPLY", "$var(realm)"); exit; } else { /* user has not been authenticated. Lets send a challenge via 401 Unauthorized */ xdbg("About to challenge! auth_ims\n"); ims_www_challenge("REG_MAR_REPLY", "$var(realm)", "$var(alg)"); exit; } } else { xdbg("Auth succeeded\n"); /* We need to check if this user is registered or not */ if (!impu_registered("location")) { save("PRE_REGISTER_SAR_REPLY", "location"); exit; } else { isc_match_filter_reg("1", "location"); save("REGISTER_SAR_REPLY", "location"); exit; } } } } /** * Handling of REGISTER MAR replies */ route[REG_MAR_REPLY] { xlog("L_DBG","maa_return code is $avp(s:maa_return_code)\n"); /* this is async so to know status we have to check the reply avp */ switch ($avp(s:maa_return_code)) { case 1: /* success */ xdbg("MAR success - 401/407 response sent from module\n"); break; case -1: /* failure */ xerr("MAR failure - error response sent from module\n"); break; case -2: /* error */ xerr("MAR error - sending error response now\n"); send_reply("503", "MAR failed"); break; default: xerr("Unknown return code from MAR, value is [$avp(s:maa_return_code)]\n"); send_reply("503", "Unknown response code from MAR"); break; } exit; } and here's the log: 12(18) ERROR: *** cfgtrace:request_route=[REGISTER] c=[/usr/local/etc/kamailio/kamailio.cfg] l=757 a=27 n=ims_www_challenge 12(18) DEBUG: ims_auth [authorize.c:293]: challenge(): Looking for route block [REG_MAR_REPLY] 12(18) INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [-2] 12(18) DEBUG: ims_auth [authorize.c:317]: challenge(): Need to challenge for realm [ims.mnc071.mcc432.3gppnetwork.org] 12(18) DEBUG: ims_auth [authorize.c:324]: challenge(): Checking if REGISTER is authorized for realm [ims.mnc071.mcc432.3gppnetwork.org]... 12(18) DEBUG: ims_auth [authorize.c:1449]: get_auth_userdata(): Searching auth_userdata for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 12(18) DEBUG: ims_auth [authorize.c:460]: challenge(): Suspending SIP TM transaction 12(18) DEBUG: ims_auth [authorize.c:1529]: multimedia_auth_request(): Sending MAR 12(18) DEBUG: ims_auth [cxdx_mar.c:574]: cxdx_send_mar(): Successfully sent async diameter 70(76) INFO: ims_auth [cxdx_avp.c:137]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp (avp_code = 297, vendor_id = 0) 70(76) DEBUG: ims_auth [authorize.c:1303]: new_auth_vector(): new auth-vector with ck [d2deb48b5b3b614ba9112396e3c036fe] with status 0 70(76) DEBUG: ims_auth [authorize.c:1560]: pack_challenge(): setting QOP str used is [, qop="auth"] 70(76) DEBUG: ims_auth [authorize.c:1562]: pack_challenge(): QOP str used is [, qop="auth"] 70(76) DEBUG: ims_auth [authorize.c:1449]: get_auth_userdata(): Searching auth_userdata for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 70(76) DEBUG: ims_auth [authorize.c:1458]: get_auth_userdata(): Found auth_userdata 70(76) DEBUG: ims_auth [authorize.c:1682]: add_auth_vector(): Adding auth_vector (status 1) for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org / IMPI 432710000010044(a)ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 70(76) DEBUG: ims_auth [cxdx_mar.c:486]: async_cdp_callback(): DBG:UAR Async CDP callback: ... Done resuming transaction 70(76) INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [1] 70(76) ERROR: tm [t_suspend.c:197]: t_continue_helper(): active transaction not found 70(76) DEBUG: ims_auth [cxdx_mar.c:87]: free_saved_transaction_data(): Freeing saved transaction data: async 11(17) ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/usr/local/etc/kamailio/kamailio.cfg] l=380 a=5 n=route

4 8

tm stats on prometheus
by Alexis Fidalgo 25 Feb '25

25 Feb '25

Hello all, i found that tm stats (kamcmd tm.stats) are not present in the response of xhttp_prom (prometheus), so in new configurations that we applied, we have no information/stats on reply codes. Is there a way to add this information to the xhttp_prom response? thanks in advance. regards

2 4

debug memory usage by AVP
by Sergey Safarov 25 Feb '25

25 Feb '25

In the "kamcmd mod.stats all shm" output i see to big value for "create_avp" metric Module: core { tcpconn_new(1205): 35104 counters_prefork_init(211): 61952 create_avp(178): 20737248 cfg_clone_str(132): 304 cfg_shmize(221): 1248 main_loop(1381): 16 Is possible to print AVP list and APV content without kamailio config change and restart?

1 0

Kamailio uses an ephemeral IP port instead of the port defined in $fs
by Leonid Fainshtein 24 Feb '25

24 Feb '25

Hi, I am using Kamailio v.5.8.4 on Ubuntu 24.04, kernel 6.8.0-51-generic In the configuration script I explicitly set $fs="udp:adrr:port". In normal situations, it works properly and I see that the UDP SIP requests are sent from the requested IP and port. Due to some reasons, free space on the server root filesystem was exhausted. I cleaned up the file system and everything looked good except the fact that Kamailio started to send messages from ephemeral IP ports instead of the port defined in $fs. Restart of Kamailio didn't solve the problem. But the server reboot fixed the issue. I don't understand how the lack of free disk space can cause such a problem and I'm afraid that there is another reason that I am missing. Has anybody seen such a problem? Best regards, Leonid

3 3

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