sr-users August 2025

sr-users@lists.kamailio.org

38 participants
31 discussions

Guidance on installing Kamailio 5.2.x with specific modules
by Arthur Quinot 29 Aug '25

29 Aug '25

Hello Kamailio Team, I am working on a project that has a specific requirement to use Kamailio version 5.2.x. I understand that this is an older and unsupported version, but due to external constraints, upgrading to a newer version is not feasible at this moment. My goal is to install Kamailio 5.2.x and use it with the following modules: kamailio-extra-modules kamailio-json-modules kamailio-lua-modules kamailio-postgres-modules kamailio-redis-modules kamailio-systemd-modules I have been looking through the documentation and installation guides for version 5.2.x. However, I would greatly appreciate some guidance from the community on the best approach to achieve this specific setup. Could you please advise on the recommended installation method (from source or packages, if still available) to ensure compatibility between the Kamailio 5.2.x core and these modules? Specifically, I would like to know: Is it still possible to install Kamailio 5.2.x with this set of modules using a package manager on a specific Linux distribution (e.g., Debian 12)? If compiling from source is the recommended path, are there any known compatibility issues or patches required to build this version with the specified modules? Are there any other potential challenges or important considerations I should be aware of when working with this older version? Any advice or pointers to relevant documentation would be extremely helpful. I appreciate your understanding and support. Thank you! [image: Foto] Arthur Quinot Solvefy/Cloud [image: Email Icon] arthur(a)solvefy.cloud [image: Site Icon] solvefy.cloud

2 2

How can the 200 OK response to a CANCEL request be modified in Kamailio?
by Olivier Thomas 29 Aug '25

29 Aug '25

Hello everyone ! I am trying to modify the "200 OK canceling" response that is locally generated by Kamailio when handling a CANCEL request. So far, I haven’t found a way to do this. Specifically, I would like to change the host part of the From and To headers in that response. Is there a way to perform such a modification? Thanks a lot, Regards, Olivier

2 2

Pike module using apt install
by Martin Nyström 29 Aug '25

29 Aug '25

Hi, I’ve created my own Docker image for Kamailio 5.8 but I am struggling to find in which dependency or lib the Pike module resides. Is it only available when building? None of the below seems to make pike.so available. RUN apt-get update && apt-get install -y \ kamailio \ kamailio-mysql-modules \ kamailio-tls-modules \ kamailio-extra-modules \ kamailio-utils-modules \ kamailio-secsipid-modules \ kamailio-json-modules Thanks, /M

2 2

Kamailio + Asterisk: MESSAGE Routing Issue (483 Too Many Hops)
by Fernando Lopes 26 Aug '25

26 Aug '25

Hello everyone, I’m having some problems routing a MESSAGE from Asterisk to a WebRTC client. Regular calls work fine, but MESSAGE handling is failing. Kamailio: 10.5.0.8 Asterisk: 10.5.0.2 I suspect the problem could be one of two things: ->The CSeq values don’t match (CSeq: 2 MESSAGE vs CSeq: 49306 MESSAGE). ->The To and From headers might be preventing Kamailio from knowing where to send the reply. Has anyone seen this behavior before? Any suggestions on how to correctly route MESSAGEs through Kamailio to WebRTC clients? Here are some logs: MESSAGE sip:7@172.31.217.74 SIP/2.0 Transport: udp Record-Route: <sip:172.31.217.74:5001;r2=on;lr;ftag=124pqf5crm;nat=yes> Record-Route: <sip:172.31.217.74:8087;transport=ws;r2=on;lr;ftag=124pqf5crm;nat=yes> Via: SIP/2.0/UDP 172.31.217.74:5001;branch=z9hG4bK43b3.e83a57badbec3df404fc69a3c7f0e666.0 Via: SIP/2.0/WSS ip9sqfgevvko.invalid;rport=59806;received=172.31.208.1;branch=z9hG4bK324262 To: <sip:7@172.31.217.74> From: "916c67e8-652f-49ea-b288-2bbbee8dbf21" <sip:User1@172.31.217.74>;tag=124pqf5crm CSeq: 2 MESSAGE Call-ID: s1djti0r9egfcvi1n4aa Max-Forwards: 69 Authorization: Digest algorithm=MD5, username="User1", realm="xxxxx", nonce="1756131542/ed3931083af68713eb56098000b661ec", uri="sip:7@172.31.217.74", response="3a474fc4f735e602a7b1940d0c9da564", opaque="10b0b5293ff53cc5", qop=auth, cnonce="0reui7po4gfn", nc=00000001 Supported: outbound User-Agent: SIP.js/0.21.1 Content-Type: text/plain Content-Length: 68 {"message":"ola","sessionId":"feff3811-f3b4-4dd7-8125-af9fe80dd523"} Some log from asterisk: pjsip:User1/sip:916c67e8-652f-49ea-b288-2bbbee8dbf21@10.5.0.8:5001;x-ast;transport=udp,"MaxTalk" <sip:7@172.31.217.74>,"ChatApp xxxxx" <sip:916c67e8-652f-49ea-b288-2bbbee8dbf21@10.5.0.8:5001;x-ast>" <--- Transmitting SIP request (687 bytes) to UDP:10.5.0.8:5001 ---> MESSAGE sip:916c67e8-652f-49ea-b288-2bbbee8dbf21@10.5.0.8:5001;transport=udp;x-ast SIP/2.0 Via: SIP/2.0/UDP 10.5.0.2:4040;rport;branch=z9hG4bKPj782df7e5-c4b7-4f74-98ff-611d39069cc5 From: "MaxTalk" <sip:7@172.31.217.74>;tag=645539f3-3177-436a-88f6-ac7f64735fd4 To: "ChatApp xxxxx" <sip:916c67e8-652f-49ea-b288-2bbbee8dbf21@10.5.0.8;x-ast> Contact: <sip:User1@10.5.0.2:4040> Call-ID: 2af343eb-67f5-4458-ba07-37b830169ec7 CSeq: 49306 MESSAGE Max-Forwards: 70 User-Agent: Asterisk PBX 18.24.3 Content-Type: text/plain Content-Length: 138 Olá! Como posso ajudar-te hoje? Se tiveres alguma dúvida sobre a plataforma da xxxxx ou qualquer outra questão, estou aqui para ajudar. <--- Received SIP response (476 bytes) from UDP:10.5.0.8:5001 ---> SIP/2.0 483 Too Many Hops Via: SIP/2.0/UDP 10.5.0.2:4040;received=10.5.0.2;rport=4040;branch=z9hG4bKPj782df7e5-c4b7-4f74-98ff-611d39069cc5 From: "MaxTalk" <sip:7@172.31.217.74>;tag=645539f3-3177-436a-88f6-ac7f64735fd4 To: "ChatApp xxxxx" <sip:916c67e8-652f-49ea-b288-2bbbee8dbf21@10.5.0.8;x-ast>;tag=19162a7003f0e5d10acb0ff84f0e52ca.11182266 Call-ID: 2af343eb-67f5-4458-ba07-37b830169ec7 CSeq: 49306 MESSAGE Server: kamailio (5.7.6 (x86_64/linux)) Content-Length: 0 Thank you.

3 8

Best Practices for Scaling Kamailio in a Large VoIP Deployment
by חוה לוי 19 Aug '25

19 Aug '25

I now also need to use Kamilio with a lot of incoming calls. I would love to hear how you got on.

2 1

Job offer VoIP software developer
by Henning Westerholt 18 Aug '25

18 Aug '25

Hello, we are looking for a new VoIP software developer colleague to join and grow our international team. More detail about the position can be found at: https://gilawa.com/en/about/careers If you are interested, please send me a (direct) email. Please include the information described in the linked job description. Best regards, Henning Westerholt -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

1 0

Question Regarding Flags Behavior in Dialog Callback
by serdar.gucluer＠netgsm.com.tr 18 Aug '25

18 Aug '25

Hi all, I'm using the pua_dialoginfo module to publish peer state changes to target servers. I was hoping to control which states are published by using the disable_caller_publish_flag and disable_callee_publish_flag parameters. To debug this, I added some logs in pua_dialoginfo.c, and it seems that the flags information coming from the dialog callback does not reflect the updated flag settings from the script configuration. Here is a simplified scenario from my configuration: route[WITHINDLG] { if (has_totag()) { if (loose_route()) { if(!isdsturiset()) handle_ruri_alias(); if (is_method("REFER")) { sl_send_reply("403", "Not allowed"); exit; } if (is_method("ACK")) route(NATMANAGE); if (is_method("BYE|ACK")) { xlog("L_WARN", "[$ci] - WITHINDLG worked for $rm -> script flag : $sF --- branch flags : $bF --- Transaction flags : $mF \r\n"); setflag(PDLGINFO_CALLEE); xlog("L_WARN", "[$ci] - WITHINDLG worked for $rm -> script flag : $sF --- branch flags : $bF --- Transaction flags : $mF \r\n"); } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) exit; if (is_method("ACK")) { if (t_check_trans()) t_relay(); else exit; } sl_send_reply("404","Not here"); } exit; } } DEBUG: pua_dialoginfo [pua_dialoginfo.c:461]: __dialog_sendpublish(): confirmed - from_uri: sip:xxx@mydomain.com DEBUG: pua_dialoginfo [pua_dialoginfo.c:462]: __dialog_sendpublish(): confirmed - to_uri: sip:yyy@mydomain DEBUG: pua_dialoginfo [pua_dialoginfo.c:463]: __dialog_sendpublish(): confirmed - callid: 43005250998501278412250319c7836b DEBUG: pua_dialoginfo [pua_dialoginfo.c:464]: __dialog_sendpublish(): confirmed - from_tag: xk3431808229 DEBUG: pua_dialoginfo [pua_dialoginfo.c:465]: __dialog_sendpublish(): confirmed - req_uri: sip:yyy@mydomain DEBUG: pua_dialoginfo [pua_dialoginfo.c:466]: __dialog_sendpublish(): confirmed - from_contact: sip:xxx@1.1.1.1:1111 DEBUG: pua_dialoginfo [pua_dialoginfo.c:467]: __dialog_sendpublish(): confirmed - uuid: padi-68946f96-3beb95-1 DEBUG: pua_dialoginfo [pua_dialoginfo.c:469]: __dialog_sendpublish(): confirmed - lifetime: 3600 DEBUG: pua_dialoginfo [pua_dialoginfo.c:470]: __dialog_sendpublish(): confirmed - disable_caller_publish: 0 DEBUG: pua_dialoginfo [pua_dialoginfo.c:471]: __dialog_sendpublish(): confirmed - disable_callee_publish: 0 DEBUG: pua_dialoginfo [pua_dialoginfo.c:477]: __dialog_sendpublish(): confirmed - pubruris_caller: sip:xxx@mydomain DEBUG: pua_dialoginfo [pua_dialoginfo.c:483]: __dialog_sendpublish(): confirmed - pubruris_callee: sip:yyy@mydomain DEBUG: pua_dialoginfo [pua_dialoginfo.c:487]: __dialog_sendpublish(): confirmed - checking caller publish conditions... DEBUG: pua_dialoginfo [pua_dialoginfo.c:488]: __dialog_sendpublish(): confirmed - dlginfo->disable_caller_publish: 0 DEBUG: pua_dialoginfo [pua_dialoginfo.c:489]: __dialog_sendpublish(): confirmed - disable_caller_publish_flag: 8 DEBUG: pua_dialoginfo [pua_dialoginfo.c:490]: __dialog_sendpublish(): confirmed - request is NOT NULL DEBUG: pua_dialoginfo [pua_dialoginfo.c:492]: __dialog_sendpublish(): confirmed - request->flags: 0x20 DEBUG: pua_dialoginfo [pua_dialoginfo.c:494]: __dialog_sendpublish(): confirmed - bit checked: (1 << 8) = 0x100, result = NOT SET WARNING: <script>: [43005250998501278412250319c7836b] - WITHINDLG worked for ACK -> script flag : 00000000 --- branch flags : 00000040 --- Transaction flags : 00000020 WARNING: <script>: [43005250998501278412250319c7836b] - WITHINDLG worked for ACK -> script flag : 00000000 --- branch flags : 00000040 --- Transaction flags : 00000220 My question is: Is there a mistake in how I’m using or setting the flags? Or, if not, how can I ensure that the updated flag values are correctly propagated to the dialog callback events? Any insights would be greatly appreciated. Thanks in advance! Serdar

2 3

Unable to access HTTP request headers using microhttpd module
by i.ribakov＠zaleos.net 15 Aug '25

15 Aug '25

I'm trying to access the value of HTTP X header inside "event_route[microhttpd:request]" as follows: ``` xlog("L_INFO", "$mhttpd(H:X-Foo)\n"); ``` But I'm getting null. I also tried non-X headers `$mhttpd(H:Content-Type)` but still no luck. When running with DEBUG logs, I'm not seeing any hints as to what might be going wrong: ``` { "time": "2025-08-05T15:34:33.177582092Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: ctl [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177649420Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: jsonrpcs [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177667928Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: usrloc [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177695097Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/utils/sruid.c", "line": 127, "function": "sruid_init", "logprefix": "", "message": "root for sruid is [ulcx-1-68922489-21-] (0 / 19)" } { "time": "2025-08-05T15:34:33.177713396Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: tm [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177742450Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "tm", "file": "callid.c", "line": 138, "function": "child_init_callid", "logprefix": "", "message": "callid: '78f687a61e6a21b7-33(a)10.52.0.100'" } { "time": "2025-08-05T15:34:33.177751949Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: tmx [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177768432Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "tmx", "file": "tmx_mod.c", "line": 249, "function": "child_init", "logprefix": "", "message": "rank is (-2)" } { "time": "2025-08-05T15:34:33.177777023Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: sl [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177792318Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: uac [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177807544Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: ndb_redis [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177827100Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "ndb_redis", "file": "redis_client.c", "line": 259, "function": "redisc_init", "logprefix": "", "message": "Connecting to 22.22.22.102:6379" } { "time": "2025-08-05T15:34:33.178143906Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "ndb_redis", "file": "redis_client.c", "line": 271, "function": "redisc_init", "logprefix": "", "message": "rsrv->ctxRedis = 0x5df7e046fb40" } { "time": "2025-08-05T15:34:33.178464903Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: htable [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178536771Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "htable", "file": "htable.c", "line": 267, "function": "child_init", "logprefix": "", "message": "rank is (-2)" } { "time": "2025-08-05T15:34:33.178576651Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: corex [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178620093Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: dialog [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178664304Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: rtpengine [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178765506Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: nathelper [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178805176Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: dispatcher [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178846034Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: http_client [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178887870Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "http_client", "file": "http_client.c", "line": 414, "function": "child_init", "logprefix": "", "message": "*** http_client module initializing process 33" } { "time": "2025-08-05T15:34:33.178919788Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: microhttpd [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178961414Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "microhttpd", "file": "microhttpd_mod.c", "line": 603, "function": "microhttpd_server_run", "logprefix": "", "message": "preparing to listen on 10.52.0.100 :8081" } ... { "time": "2025-08-05T15:34:34.375701559Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "microhttpd", "file": "microhttpd_mod.c", "line": 521, "function": "ksr_microhttpd_request", "logprefix": "", "message": "incoming data: [{\"jsonrpc\":\"2.0\",\"method\":\"core.version\",\"id\":1}]" } { "time": "2025-08-05T15:34:34.375729356Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "microhttpd", "file": "microhttpd_mod.c", "line": 553, "function": "ksr_microhttpd_request", "logprefix": "", "message": "executing event_route[microhttpd:request] (5)" } { "time": "2025-08-05T15:34:34.375793262Z", "idx": 22, "pid": 33, "level": "INFO", "module": "xlog", "file": "xlog.c", "line": 283, "function": "", "logprefix": "", "message": "<null>" } ``` Am I missing something or is this a bug? P.S. all other pre-fetched request data is fine (I checked path and body).

3 3

Why does $T(id_index) return 0 even though t_suspend() is executed successfully?
by mm e 15 Aug '25

15 Aug '25

if(t_suspend()) { xlog("L_NOTICE", "==> processing suspended in transaction [$T(id_index):$T(id_label)] "); } else { xlog("L_ERR", "t_suspend err"); exit; } Sometimes, I get this log==> processing suspended in transaction [0:13614] "，as far as I know, 0 means that the value cannot be obtained. Executing t_continue(tindex, tlabel, rtname) with parameter 0 will fail.by the way, It's a question of probability.

2 2

$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

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