sr-users January 2026

sr-users@lists.kamailio.org

19 participants
31 discussions

Kamailio + Dispatcher + UAC
by darren＠cartr.co.za 28 Jan '26

28 Jan '26

I have been trying to get outbound calls to work, and my trunk provider required authentication for outbound calls. My trunk is registered with UAC and I use Dispatcher to select the correct trunk for the CLI making the call. I just can’t seem to get it working, my trunk does not know how to replay to my authenticated invite and Kamailio just retransmits until it times out. Perhaps someone can point me in the right direction, I have looked everywhere and tried so many different appraches. The call flow should be Client Phone -> Kamailio -> Trunk and replies, Trunk -> Kamailio -> Client Phone. # Dispatch requests route[DISPATCH] { if ($var(dispatcher_set) == $null || $var(dispatcher_set) == "") { xlog("L_INFO", "[$ci] DISPATCHER: No dispatcher set configured\n"); return; } # DISPATCHER_OUTBOUND_SET # DISPATCHER_INBOUND_SET # DISPATCHER_ASTERISK_SET switch($var(dispatcher_set)) { case DISPATCHER_OUTBOUND_SET: if (!ds_select_dst(DISPATCHER_OUTBOUND_SET, "4")) { xlog("L_ERR", "[$ci] DISPATCHER: No available outbound dispatcher destinations\n"); sl_send_reply("503", "Service Unavailable"); exit; } xlog("L_INFO", "[$ci] DISPATCHER: Going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs)) from set $var(dispatcher_set)\n"); $du = "sip:{{ kamailio_sip_host }}:{{ kamailio_sip_port }}"; $avp(auth_user) = $xavp(_dsdst_=>attrs=>auth_user); $avp(auth_pass) = $xavp(_dsdst_=>attrs=>auth_pass); $avp(auth_realm) = $xavp(_dsdst_=>attrs=>auth_realm); if (is_method("INVITE")) { t_on_failure("TRUNK_AUTH"); t_relay(); exit; } break; case DISPATCHER_INBOUND_SET: if (!ds_select_dst(DISPATCHER_INBOUND_SET, "4")) { xlog("L_ERR", "[$ci] DISPATCHER: No available inbound dispatcher destinations\n"); sl_send_reply("503", "Service Unavailable"); exit; } break; case DISPATCHER_ASTERISK_SET: if (!ds_select_dst(DISPATCHER_ASTERISK_SET, "4")) { xlog("L_ERR", "[$ci] DISPATCHER: No available Asterisk dispatcher destinations\n"); sl_send_reply("503", "Service Unavailable"); exit; } break; default: xlog("L_ERR", "[$ci] DISPATCHER: Invalid dispatcher set $var(dispatcher_set)\n"); sl_send_reply("500", "Internal Server Error"); exit; } t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } # Failure route - outbound trunk auth challenge handling failure_route[TRUNK_AUTH] { if (t_is_canceled()) { xlog("L_INFO", "[$ci] TRUNK_AUTH: Transaction canceled\n"); exit; } if (t_check_status("401|407")) { xlog("L_INFO", "[$ci] TRUNK_AUTH: Received auth challenge for outbound trunk\n"); if ($avp(auth_user) == $null || $avp(auth_pass) == $null || $avp(auth_realm) == $null) { xlog("L_WARN", "[$ci] TRUNK_AUTH: Missing UAC auth credentials, skipping uac_auth\n"); exit; } uac_auth(); t_relay(); exit; } } Kind regards Darren Carter

3 2

Development is open for future release of v6.2.x series
by Daniel-Constantin Mierla 27 Jan '26

27 Jan '26

Hello, the branch 6.1 was created, therefore the master branch is open for adding new features, to be part of future release series v6.2.x. Any bug fix committed to master that applies to 6.1.x or older stable branches should be backported as usual with "git cherry-pick -x ..." to appropriate branches like 6.1 or 6.0. Expect that v6.1.0 will be released in a few weeks from now. Based on the workflow used during the past years, the next future release v6.2.0 should be out after about 10 months of development, plus 1-2 months of testing, so sometime during the last part of 2026 or the beginning of 2027. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, May 7-8, 2026 - Berlin, Germany -- kamailioworld.com

2 1

Branch 6.1 has been created
by Daniel-Constantin Mierla 27 Jan '26

27 Jan '26

Hello, the branch 6.1 has been created, to be used for releasing v6.1.x series. To check out this branch, the following commands can be used: git clone https://github.com/kamailio/kamailio kamailio-6.1 cd kamailio-6.1 git checkout -b 6.1 origin/6.1 Pushing commits in this branch: git push origin 6.1:6.1 Note that 6.1 is an official stable branch, so only bug fixes, missing kemi exports (discuss on sr-dev if not sure) or improvements to documentation or helper tools can be pushed to this branch. As usual, if there is a bug fixed, commit and push first to master branch and then cherry pick to 6.1 branch: git cherry-pick -x COMMITID In few weeks, the first release from branch 6.1 will be out, respectively Kamailio v6.1.0. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, May 7-8, 2026 - Berlin, Germany -- kamailioworld.com

1 0

rtpengine v4/v6 translation
by Ihor Olkhovskyi 22 Jan '26

22 Jan '26

Hello, It's more about rtpengine, than Kamailio, but as I'm using it via Kamailio, decided to ask here. I'm building IPv4/IPv6 dual-stack system and currently got stuck on rtpengine part. Overall schema is like this Client <---SRTP (v4/v6)---> Kamailio/rtpengine <----RTP(v4)----> Asterisk When I'm using IPv4 on a client, audio is being transmitted ok, but if with the same parameters I'm using IPv6 on a client, despite all correct in SDP (means rtpengine detects IPv6 addresses), sees incoming traffic to IPv6 interface and sayng forwarding it to IPv4, there is no traffic on IPv4 going out, What I found puzzling, that when using IPv4-only, final statls looks like Final packet stats: --- Tag 'bHWck2I1B' (label 'leg_A'), created 0:41 ago for branch '' --- subscribed to media with monologue tag '872ed199-e68c-41f3-928e-284a52c9da7f' (index: 1) --- subscription for media with monologue tag '872ed199-e68c-41f3-928e-284a52c9da7f' (index: 1) ------ Media #1 (audio over RTP/SAVPF) using PCMA/8000 --------- Port <server_ip_v4>:24530 <> <client_ip_v4>:7078 , SSRC e5809e3e, in 529 p, 90988 b, 0 e, 30 ts, out 459 p, 86292 b, 0 e --------- Port <server_ip_v4>:24531 <> <client_ip_v4>:7079 (RTCP), SSRC e5809e3e, in 9 p, 1776 b, 10 e, 30 ts, out 2 p, 240 b, 0 e --- SSRC e5809e3e ------ Average MOS 4.3, lowest MOS 4.3 (at 0:05), highest MOS 4.3 (at 0:05) lost:0 ------ respective (avg/min/max) jitter 0/0/0 ms, RTT-e2e 11.3/13.0/13.0 ms, RTT-dsct 10.5/12.1/12.1 ms, packet loss 0/0/0% --- Tag '872ed199-e68c-41f3-928e-284a52c9da7f' (label 'leg_B'), created 0:41 ago for branch 'cp-srtp' --- subscribed to media with monologue tag 'bHWck2I1B' (index: 1) --- subscription for media with monologue tag 'bHWck2I1B' (index: 1) ------ Media #1 (audio over RTP/AVP) using PCMA/8000 --------- Port <server_ip_v4>:27240 <> <asterisk_ip_v4>:12694, SSRC 13cdaf27, in 459 p, 78948 b, 0 e, 30 ts, out 529 p, 90988 b, 0 e --------- Port <server_ip_v4>:27241 <> <asterisk_ip_v4>:12695 (RTCP), SSRC 13cdaf27, in 2 p, 200 b, 0 e, 30 ts, out 9 p, 1776 b, 0 e Note, for the both Media streams codec is shown, But on IPv6 I see Final packet stats: --- Tag 'EDfwrVO8t' (label 'leg_A'), created 0:41 ago for branch '' --- subscribed to media with monologue tag 'eb643ca2-42c5-42ec-b55f-4b0ae15b5d8a' (index: 1) --- subscription for media with monologue tag 'eb643ca2-42c5-42ec-b55f-4b0ae15b5d8a' (index: 1) ------ Media #1 (audio over RTP/SAVPF) using PCMA/8000 --------- Port <server_ip_v6>:27264 <> <client_ip_v6>:7200 , SSRC 1d2284d4, in 562 p, 96664 b, 1 e, 30 ts, out 0 p, 0 b, 0 e --------- Port <server_ip_v6>:27265 <> <client_ip_v6>:7201 (RTCP), SSRC 1d2284d4, in 9 p, 1152 b, 23 e, 30 ts, out 0 p, 0 b, 0 e --- Tag 'eb643ca2-42c5-42ec-b55f-4b0ae15b5d8a' (label 'leg_B'), created 0:41 ago for branch 'cp-srtp' --- subscribed to media with monologue tag 'EDfwrVO8t' (index: 1) --- subscription for media with monologue tag 'EDfwrVO8t' (index: 1) ------ Media #1 (audio over RTP/AVP) *using unknown codec* --------- Port <server_ip_v6>:25990 <> <asterisk_ip_v4>:12226, SSRC 0, in 0 p, 0 b, 0 e, 41 ts, out 562 p, 96664 b, 0 e --------- Port <server_ip_v6>:25991 <> <asterisk_ip_v4>:12227 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 41 ts, out 9 p, 1152 b, 0 e Note the unknown codec in this case Rtpeinge is started with /usr/bin/rtpengine --interface <server_ip_v4> --interface <server_ip_v6> --listen-ng 19999 -m 20000 -M 28000 --sip-source --log-level=6 --log-facility=local5 -o 43200 -s 43200 -a 43200 --offer-timeout=43200 Version: mr13.5.1.3 Invoked with rtpengine_manage(replace-origin replace-session-connection SDES-pad label=leg_A rtcp-mux-demux ICE=remove RTP/AVP via-branch=extra) I'm not using additional explicit bridging, as I've read, that this is outdated already and not used at all. Any hint would be helpful and thanks in advance! -- Best regards, Ihor (Igor)

2 2

Issue adding SIP Trunk UAC Auth
by Mark Boyce 21 Jan '26

21 Jan '26

Hi All Wondering if anyone here has any thoughts on this issue, before I start trying to reverse engineer the config and randomly update things on this server. It’s a little out of date but not the worst I’ve seen :-) Kamailio 5.5.4 Ubuntu 22.04 LTS Arrangement is the typical users phones & ITSP Carrier out in the real world, Asterisk on a private network with Kamailio in the middle. The config is broken up in to a mass of include files so not simple to include I’m afraid. Issue is -> I’ve been asked to add SIP Auth to the ITSP Trunk as they no longer have IP Auth. As it arrived I can see the ITSP Auth being relayed through to the asterisk server rather than being caught at the Kamailio level. I’ve tried to walk through the config and logs but can’t see anything obviously failing or missing. If I add the code below based on the default config and config from this page, ITSP Auth request is answered by Kamailio, but nothing from the ITSP gets sent to Asterisk. https://github.com/kamailio-asterisk/Kamailio-Example/blob/main/Kamailio%20… <https://github.com/kamailio-asterisk/Kamailio-Example/blob/main/Kamailio%20…> request_route { (whole load of security defence stuff) # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); route(KEEPALIVE); # CANCEL processing xlog("L_ALERT","FLOWTRACE: Checking for CANCEL ([$rm] From IP:$si:$sp)\n"); if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle retransmissions if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # authentication route(AUTH); # Create dialog and record user / ip / etc in dlg_vars # if !is_known_dlg() route(MANAGE_DIALOG); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE|REFER")) { record_route(); } # account only INVITEs if (is_method("INVITE")) { route(ACCOUNTING); } ### requests for my local domains # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); ### requests for my local domains if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch invite to subscriber, PSTN or PBX route(ROUTE_INVITE); } # Decide who to send the Invite out to route[ROUTE_INVITE] { # We only care about INVITES if(!is_method("INVITE")) return; (source type and destination type identified) # now route to destination switch ($dlg_var(destination_type)) { case "trunk": route(TOPSTN); break; exit; } # PSTN GW route[TOPSTN] { # check if PSTN GW IP is defined if (strempty($sel(cfg_get.pstn.gw_ip))) { xlog("SCRIPT: PSTN routing enabled but pstn.gw_ip not defined\n"); return; } # normalize target number for pstn gateway # - convert leading 00 to + if (starts_with("$rU", "00")) { strip(2); prefix("+"); } if (strempty($sel(cfg_get.pstn.gw_port))) { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); } else { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ":" + $sel(cfg_get.pstn.gw_port); } t_on_failure("TRUNKAUTH"); t_relay(); exit; } failure_route[TRUNKAUTH] { # Catch if already cancelled if (t_is_canceled()) { exit; } if(t_check_status("401|407")) { xlog("L_INFO", "TRUNKAUTH: responding to 401/407\n"); $avp(auser) = “USERNAME"; $avp(apass) = “PASSWORD"; uac_auth(); t_relay(); exit; } } What have I missed :-? Thanks Mark -- Mark Boyce This message contains confidential information. If you received this email by mistake, please let us know and delete it. We ask you to respect any confidential or private information in the email and do not share it unless appropriate to do so. We take precautions to minimise risk but we cannot guarantee the safety, confidentiality and security of the internet. Please carry out your own virus checks on any attachments. We are not liable or bound by the content of this email. Dark Origins Limited is a limited company registered in England and Wales. Registered number: 04877988.

3 6

EVAPI processing delays
by Sergio Charrua 21 Jan '26

21 Jan '26

Hello all, using Kamilio 5.8.2 with EVAPI module, connecting to a Python client. Kamailio is using following modules: jsonrpcs.so db_mysql.so db_cluster.so kex.so corex.so tm.so tmx.so sl.so rr.so pv.so maxfwd.so textops.so textopsx.so siputils.so xlog.so sanity.so ctl.so cfg_rpc.so evapi.so jansson.so rtjson.so dispatcher.so permissions.s app_jsdt.so uac.so xhttp.so xhttp_rpc.so dmq.so dialog.so htable.so The (very reduced) logic is: 1 - INVITE received 2 - send request to EVAPI client with SIP headers transformed into JSON object 3 - receive response from EVAPI client 4 - depending on response type, relay the call with routes supplied in response using RTJSON On its side, EVAPI Client upon receiving request from Kamailio (step #2) 1 - sends request to HTTP REST service requesting routes 2 - receives full RTJSON object (may include custom headers to add or update or remove) 3 - return full RTJSON to Kamailio as a response All this is working fine. *Except* that we noticed that, under testing at 1 Call per minute (not performance testing yet), the delay betway EVAPI step #3 and Kamailio step #3 goes anything between 200ms up to 1.2 seconds! EVAPI client is running on the same node where Kamailio is running too, using 127.0.0.1:8448 for connection. Knowing that there is nothing else running on the server, and that the CAPS is like 1 call per minute, there is no load, no traffic, so why these delays?! Additional settings: # ----- evapi params ----- modparam("evapi", "workers", 4) modparam("evapi", "bind_addr", "127.0.0.1:8448") modparam("evapi", "netstring_format", 1) Some logs: Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949838]: INFO: {1768314358.181270 1949838 2 1 INVITE 3e82133f57c45e0d3995588fc0f2f234(a)10.240.13.68} <script>: local-response - replied locally Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949838]: INFO: {1768314358.181325 1949838 1 1 INVITE 3e82133f57c45e0d3995588fc0f2f234(a)10.240.13.68} <script>: HANDLE_INVITE - suspended transaction 5701 - Label: 625621129 Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: {1768314358.761888 1949871 1 1 OPTIONS 123} <script>: Part 0: 'RESPONSE' Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: {1768314358.761928 1949871 1 1 OPTIONS 123} <script>: Part 1: '5701' Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: {1768314358.761936 1949871 1 1 OPTIONS 123} <script>: Part 2: '625621129' Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: {1768314358.761943 1949871 1 1 OPTIONS 123} <script>: Part 3: '{"action": "ROUTE", "routes": ... Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: {1768314358.762018 1949871 1 1 OPTIONS 123} <script>: evapi:message-received - t_continue for 5701/625621129 Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: {1768314358.762078 1949871 1 1 INVITE 3e82133f57c45e0d3995588fc0f2f234(a)10.240.13.68} <script>: EVAPIRESPONSE - TRANSACTION 5701|6256 Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: {1768314358.762089 1949871 1 1 INVITE 3e82133f57c45e0d3995588fc0f2f234(a)10.240.13.68} <script>: EVAPIRESPONSE - Resumed with RESPONSE ... Above, we can see that Kamailio sends a request to EVAPI client at 1768314358.181325 and response is received by EVAPI client at 1768314358.761888, about 600ms later, which is too much! On the other hand, EVAPI client takes less than 20ms to receive the request, query REST service and reply back to Kamailio. If there were anything else between Kamailio and EVAPI client, I would probably assume there was some network delay somewhere, but both services are running on the same server, which is mostly idle, so no network delay can be found. I even captured packets with tcpdump , on port 8448, and indeed, communications between Kamailio and EVAPI client is like 20 to 30ms max! So, why Kamailio is taking between 500ms to 1sec to process the response received from EVAPI client? at least, this is what it seems doing.... Any clue? Any advice? Greatly appreciated. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua* *www.kahea.ai <http://www.kahea.ai> / www.voip.pt <http://www.voip.pt>* *OpenTelecom* - Consulting for Telecoms, Lda Tel.: +351 <callto:+351+91+104+12+66>91 631 11 44 Email : *sergio.charrua(a)voip.pt <sergio.charrua(a)voip.pt>* This message and any files or documents attached are strictly confidential or otherwise legally protected. It is intended only for the individual or entity named. If you are not the named addressee or have received this email in error, please inform the sender immediately, delete it from your system and do not copy or disclose it or its contents or use it for any purpose. Please also note that transmission cannot be guaranteed to be secure or error-free.

3 5

Branching 6.1 series
by Daniel-Constantin Mierla 21 Jan '26

21 Jan '26

Hello, with the last module as PR merged and a few other PRs to review, I am proposing to branch 6.1 series on next Monday, January 26, 2026. If some one has other opinions/suggestions, let's discuss them. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, May 7-8, 2026 - Berlin, Germany -- kamailioworld.com

1 0

Log times do not match event time
by Sergio Charrua 14 Jan '26

14 Jan '26

Hi all! Can anyone explain why the following log times do not match and seem out of sync? I could not find any reason for this, and neither any docs explaining why/how. Jan 14 16:41:07 ire-lab-kamailio1 kamailio[1473633]: INFO: { 1768405267.124447 1473633 1 1 OPTIONS 123} <script>: evapi:message-received - Received EVAPI message: HEARTBEAT Jan 14 16:41:11 ire-lab-kamailio1 kamailio[1473632]: DEBUG: { 1768400692.108269 1473632 1 1 OPTIONS 123} evapi [evapi_dispatch.c:517]: evapi_recv_client(): {0} [10.20.0.1:54190] - received [9:HEARTBEAT,] (12) (0) Jan 14 16:41:11 ire-lab-kamailio1 kamailio[1473632]: DEBUG: { 1768400692.108269 1473632 1 1 OPTIONS 123} evapi [evapi_dispatch.c:611]: evapi_recv_client(): queueing event route for frame: [HEARTBEAT] (9) Jan 14 16:41:11 ire-lab-kamailio1 kamailio[1473632]: DEBUG: { 1768400692.108269 1473632 1 1 OPTIONS 123} evapi [evapi_dispatch.c:140]: evapi_queue_add(): adding message to queue [HEARTBEAT] Jan 14 16:41:11 ire-lab-kamailio1 kamailio[1473632]: DEBUG: { 1768400692.108269 1473632 1 1 OPTIONS 123} <core> [core/mem/q_malloc.c:402]: qm_malloc(): qm_malloc(0x7fc804ae6000, 42) called from evapi: evapi_dispatch.c: evapi_queue_add(142) Jan 14 16:41:11 ire-lab-kamailio1 kamailio[1473632]: DEBUG: { 1768400692.108269 1473632 1 1 OPTIONS 123} <core> [core/mem/q_malloc.c:449]: qm_malloc(): qm_malloc(0x7fc804ae6000, 48) returns address 0x7fc805afd620 frag. 0x7fc805afd5e0 (size=48) on 1 -th hit Jan 14 16:41:11 ire-lab-kamailio1 kamailio[1473635]: DEBUG: { 1768405257.579389 1473635 1 1 OPTIONS 123} evapi [evapi_dispatch.c:187]: evapi_queue_get(): getting message from queue [HEARTBEAT] Jan 14 16:41:11 ire-lab-kamailio1 kamailio[1473635]: DEBUG: { 1768405257.579389 1473635 1 1 OPTIONS 123} evapi [evapi_dispatch.c:880]: evapi_run_worker(): processing task: 0x7fc805afd620 [HEARTBEAT] The events are sequential and the server is only receiving OPTIONS, nothing else (it is a DEV server). So, if events are sequential, why are there minutes (sometimes hours) of difference between the yellow timestamps and green timestamps? 1768405267.124447 = 14 January 2026 15:41:07.124 1768400692.108269 = 14 January 2026 14:24:52.108 Difference = circa 1h17min .... I understand that the process ($pp or PID) are different, but event times should be sequential, right? Kamailio settings for log prefix: log_prefix_mode = 1 log_prefix="{$TV(Sn) $pp $mt $hdr(CSeq) $ci} " Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

1 0

Kamailio v5.8.7 Released
by Daniel-Constantin Mierla 14 Jan '26

14 Jan '26

Hello, Kamailio SIP Server v5.8.7 stable release is out. This is a maintenance release of the latest stable branch, 5.8, that includes fixes since the release of v5.8.6. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.8.x. Deployments running previous v5.8.x versions are strongly recommended to be upgraded to v5.8.7. For more details about version 5.8.7 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2026/01/kamailio-v5-8-7-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note that 5.8.x is currently the previous stable release series, the latest is 6.0.x and v6.0.5 was released on January 8, 2026. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, May 7-8, 2026 - Berlin, Germany -- kamailioworld.com

1 0

About permissions module
by 赵斌 14 Jan '26

14 Jan '26

I run kamailio 6.0.5 on debian 13,use mysql 8.4 as backend db. Use permissions module at kamailio,insert over 600 addrsses into address table,but i found max_subnets parameter at kamailio doc,default value is 512,my kamailio don`t set it. Reload address over 512,no error or warn at kamailio log,then try to dump address from memory,all address load.So this parameter is no use for permissions module,or this not for limit address to load to memory. Thank you very much.

3 2

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 January 2026