sr-users March 2025

sr-users@lists.kamailio.org

44 participants
39 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

[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

[Serusers] Digest Authentication with Tenor DX
by Ashutosh Kumar 29 Apr '25

29 Apr '25

Hi, Does someone have any idea/experience with Quintum DX radius server's support for digest mode authentication. The Access-Request packets sent by SER are getting an error back. Guide. Regards, Ashutosh Kumar Chetu, Inc. Ph : 1(305) 402 6724 - Witin US Ph : 91 120 5323340 - Outside US Fax:1 (305) 832 5987 For more information, please visit http://www.chetu.com

2 1

How to place a delay between cancelling branch and retrying next one on timer expiry?
by Alex A 15 Apr '25

15 Apr '25

Hi All, I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one. *Background: * Running Kamailio 5.6.x Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2 On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged… ) *Script config: * onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } } route(NATDETECT); #!ifdef WITH_RTPENGINE route(RTPMANAGE); #!endif } route[RELAY] { if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); } if (!t_relay()) { sl_reply_error(); } exit; } route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); } failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER"); } *Call Flows: * The above fix works well when an explicit error reply is received back. *error reply SIP exchange: * SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected. however does not work when NO reply is received at all and the timer expires. *Current timer expiry SIP exchange: * SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch I am looking to CANCEL branch0 before the sleep delay runs Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408). Any suggestions on how to handle this would be greatly appreciated. TIA

6 11

DMQ read message too large
by Calvin E. 31 Mar '25

31 Mar '25

We are seeing errors like this when synchronizing htables over DMQ: ERROR: <core> [core/udp_server.c:677]: udp_rcv_loop(): read message too large: 60793 We have no issues with other UDP fragments caused by STIR/SHAKEN headers. Our socket buffers are sufficiently large (SO_RCVBUF is initially 26214400). Does DMQ have a receive message size limit less than what it can send? Is DMQ intended for htables under a certain total size? We tried to configure DMQ to use a TCP listener with ;transport=tcp on the notification and server address, but the DMQ traffic was still sent as UDP. The example in the documentation shows TLS, but we haven't tried that. -Calvin E.

2 3

Intermediate CDRs
by Sergio Charrua 31 Mar '25

31 Mar '25

Hi all! I have been googling, and reading documentation, but I could not find any solution. How can I implement intermediate CDRs with Kamailio ACC module (or any other module) ? For example, on long duration calls, I 'm required to save call status on a CDR, resulting in intermediate CDR lines for the call (which will result in multiple CDR lines per long duration calls). Any clue on how to implement this? Did anyone achieved that with Kamailio ACC module? Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

4 3

Multiple code modules
by David Cunningham 28 Mar '25

28 Mar '25

Hello, We have a requirement to load two code modules for use by kamailio.cfg, the reason being that we can't (won't, for business reasons) modify the first module and so need to add a second for our own code. Ideally we would load two Perl modules instead of the single module that's currently loaded like this: modparam( "app_perl", "filename", "/path/to/our/custom/Kamailio.pm" ) But I'm not sure how to load two modules like this. Otherwise, does anyone know if it's safe to load both a Perl module and a Python module? Then we could at least implement both required parts, one in Perl and one in Python. Thanks in advance for any help. -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

1 0

[ratelimit module] doubts about behavior
by juliofabian6385＠hotmail.es 26 Mar '25

26 Mar '25

I am reading https://kamailio.org/docs/modules/devel/modules/ratelimit.html and I want Kamailio, before an avalanche of calls (INVITE), to start discarding calls that exceed a threshold in 1 second, for example. So in summary I have prepared the module as follows: loadmodule "ratelimit.so" modparam("ratelimit", "timer_interval",1) modparam("ratelimit", "pipe", "1:TAILDROP:10") request_route { . . if (is_method("INVITE")) { if (!rl_check_pipe("1")) { sl_send_reply("503","Limiting"); exit; } } . . } As I understand from the documentation, this gives me a counter (one per INVITE) equal to 10, which resets after 1 second. In other words, if I receive 30 INVITES in 1 second, it will discard 20. From here, I have two questions between what I understand and what I see in the logs. FIRST QUESTION: I've made several SIPP calls in one second. I've run several tests, and the first reset of the counter always happens approximately timer_interval/2. From then on, the counter resets exactly every timer_interval. Am I doing something wrong? ########## RUNNING LOGS ########## 2025-03-26T18:59:20.509696381Z 0(1) DEBUG: <core> [core/cfg.y:2165]: yyparse(): loading module ratelimit.so 2025-03-26T18:59:20.509698675Z 0(1) DEBUG: <core> [core/sr_module.c:533]: ksr_locate_module(): found module to load </usr/lib/kamailio/modules/ratelimit.so> 2025-03-26T18:59:20.509702249Z 0(1) DEBUG: <core> [core/sr_module.c:587]: ksr_load_module(): trying to load </usr/lib/kamailio/modules/ratelimit.so> 2025-03-26T18:59:20.509704682Z 0(1) DEBUG: <core> [core/kemi.c:3463]: sr_kemi_modules_add(): adding module: ratelimit 2025-03-26T18:59:20.509707031Z 0(1) DEBUG: <core> [core/cfg.lex:2095]: pp_define(): defining id: MOD_ratelimit 2025-03-26T18:59:20.509815384Z 0(1) DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'ratelimit' matches module 'ratelimit' 2025-03-26T18:59:20.509817770Z 0(1) DEBUG: <core> [core/sr_module.c:850]: find_param_export(): found <timer_interval> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509820319Z 0(1) DEBUG: <core> [core/modparam.c:135]: set_mod_param_regex(): found <timer_interval> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509822755Z 0(1) DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'ratelimit' matches module 'ratelimit' 2025-03-26T18:59:20.509825068Z 0(1) DEBUG: <core> [core/sr_module.c:850]: find_param_export(): found <pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509827468Z 0(1) DEBUG: <core> [core/modparam.c:135]: set_mod_param_regex(): found <pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509829943Z 0(1) DEBUG: ratelimit [ratelimit.c:925]: parse_pipe_params(): pipe: [1|TAILDROP|10] 2025-03-26T18:59:20.510800378Z 0(1) DEBUG: <core> [core/sr_module.c:758]: find_mod_export_record(): found export of <rl_check_pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.519776933Z 0(1) DEBUG: <core> [core/sr_module.c:1031]: init_mod(): ratelimit ########## LOGS WHEN APPLY RATELIMIT ########## 2025-03-26T19:01:02.095676663Z 1(7) DEBUG: {1 1 INVITE 1-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.095679040Z 1(7) DEBUG: {1 1 INVITE 1-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=1 load=0.0 network_load=0 => ACCEPT . . 2025-03-26T19:01:02.272879226Z 2(8) DEBUG: {1 1 INVITE 10-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.272881671Z 2(8) DEBUG: {1 1 INVITE 10-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=10 load=0.0 network_load=0 => ACCEPT 2025-03-26T19:01:02.292599816Z 2(8) DEBUG: {1 1 INVITE 11-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.292602425Z 2(8) DEBUG: {1 1 INVITE 11-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=11 load=0.0 network_load=0 => DROP . . 2025-03-26T19:01:02.492680874Z 1(7) DEBUG: {1 1 INVITE 21-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.492694107Z 1(7) DEBUG: {1 1 INVITE 21-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=21 load=0.0 network_load=0 => DROP 2025-03-26T19:01:02.513079779Z 2(8) DEBUG: {1 1 INVITE 22-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.513088852Z 2(8) DEBUG: {1 1 INVITE 22-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=22 load=0.0 network_load=0 => DROP 2025-03-26T19:01:02.532804253Z 1(7) DEBUG: {1 1 INVITE 23-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.532808087Z 1(7) DEBUG: {1 1 INVITE 23-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=2 counter=1 load=0.1 network_load=0 => ACCEPT When the countdown restarts, it's "19:01:02.53" hours, and when it started, it was "19:01:02.09" hours. It doesn't reach the second. The drop system works well, but if my limit was 25 calls, I would have accepted the 22 I counted in the first second, plus the other 25 from the second number 2. Second question: There's a warning about a performance penalty in Kamailio when timer_interval is too small, so I've decided to set it to 2 just for practical purposes. So what should happen is that the counter would accept up to 10 calls in 2 seconds. But in the logs, what I see is the opposite: it accepts 20 calls in 2 seconds. Maybe it's supposed to work that way, and I'm misunderstanding the documentation? As optional information: Kamailio is running on a Google virtual machine, 12MB of RAM, 3 processors, 2 of which are dedicated. I'm using SIPP for load testing, and different call rates have been validated before testing the module. Sorry if my first post in this community was too long or is there more information missing :) . Thanks in advance

1 0

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