sr-users

sr-users@lists.kamailio.org

4 participants
37456 discussions

Dialog + DMQ: dlg_ontimeout() triggered on wrong node!
by Benoît Panizzon 23 Nov '23

23 Nov '23

Hello World! Kamailio 5.5 in use. I wonder, how I could prevent this issue. modparam("dialog", "send_bye", 1) modparam("dialog", "default_timeout", 21600) in the corresponding route: $dlg_ctx(timeout_route) = "DIALOG_TIMEOUT"; dlg_manage(); Dialog starts on Node01 and it's variables, status and timer are DMQ synced to Node02 As both nodes have the same information, I guess both arm the timeout trigger and sometimes the wrong node is more trigger friendly. If dlg_ontimeout() is triggered on Node02 then: * No Bye is send, as Node02 is not handling that Dialog. * Dialog is removed from Memory on Node02 and state synced back to Node01 * Dialog is removed from Memory on Node01 too, but NOT from database [*1] * Dialog CDR is never commited on Node01 * Call is never sent to timeout_route And subsequent in dialog messages on Node01 result in: dlg_onroute(): unable to find dialog Did I misconfigure something? Is there a way to make sure the timer is NOT triggered on the node not handling the dialogue? Shall I try by setting the default_timeout and then use a timeout_avp to set that timeout slightly lower AFTER the dialog has started? Or would this be synced to the other node too? I found out, session timer changes are not synced after an initial timer was synced, so you can not extend the session timer after setting a initial timeout. So maybe this is also true for dialog timeout? [*1] this also explains why upon restarting kamailio, the dialog suddenly is back and after timing out again, a CDR is then written with a way too long duration. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 3

set_body() adding or replacing existing body?
by Benoit Panizzon 23 Nov '23

23 Nov '23

Hi I'm trying to change the lifetime timer on a KDMQ dialog message before handing it with dmq_handle_message(); if(has_body("application/json") && $fU == 'dialog') { if (jansson_get("lifetime", $rb, "$var(lifetime)")) { xlog("L_INFO", "$cfg(route): DIALOG JSON action: $var(action) state: $var(state) lifetime: $var(lifetime)\n"); $var(new_lifetime) = $var(lifetime) + 60; $var(newrb) = $rb; jansson_set("integer", "lifetime", $var(new_lifetime), "$var(newrb)"); xlog("L_INFO", "$cfg(route): DIALOG JSON NEW: $var(newrb)\n"); set_body("$var(newrb)","application/json"); msg_apply_changes(); } } dmq_handle_message(); exit; The JSON string looks good after that manipulation, it contains the updated lifetime. But dmq_handle_message() does not seem to get the body anymore. So I wonder what set_body() exactly does. Is it replacing the body or appending to it? Is there a way to crank up debug output in the dialog and/or dmq module? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 1

Kamailio v5.6.5 Released
by Daniel-Constantin Mierla 23 Nov '23

23 Nov '23

Hello, Kamailio SIP Server v5.6.5 stable release is out. This is a maintenance release of the latest stable branch, 5.6, that includes fixes since the release of v5.6.4. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.6.x. Deployments running previous v5.6.x versions are strongly recommended to be upgraded to v5.6.5. Note that 5.6 is the second last stable branch, still officially maintained by Kamailio development team. The latest stable branch is 5.7, with v5.7.3 being release out of it. For more details about version 5.6.5 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/11/kamailio-v5-6-5-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training -- asipto.com

1 0

Releasing v5.6.5
by Daniel-Constantin Mierla 23 Nov '23

23 Nov '23

Hello, I am considering to release Kamailio v5.6.5 (out of branch 5.6) later this week (likely on Thursday or Friday, Nov 23/24, 2023). If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training -- asipto.com

1 1

Crash on core/mem/q_malloc.c
by Igor Potjevlesch 22 Nov '23

22 Nov '23

Hello! I'm facing an issue 2/3 times a day with the following errors in the logs: Nov 22 00:09:02 /usr/local/sbin/kamailio[3720]: CRITICAL: <core> [core/mem/q_malloc.c:150]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0c0c000, abcdefed)[0x7f9600b754f8:0x7f9600b75530]! Memory allocator was called from core: core/re.c:430. Fragment marked by core: db_res.c:139. Exec from core/mem/q_malloc.c:391. Nov 22 00:09:02 /usr/local/sbin/kamailio[3720]: CRITICAL: <core> [core/mem/q_malloc.c:155]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten [0x7f9600b75460:0x7f9600b75498] - fragment marked by tm: t_fwd.c:230 Nov 22 00:09:02 abrt-hook-ccpp: Process 3720 (kamailio) of user 0 killed by SIGABRT - ignoring (repeated crash) Do you have any idea where it could come from? I'm running Kamailio 5.6.4. Regards, Igor. -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

2 2

Obsoleting unmaintained modules
by Daniel-Constantin Mierla 21 Nov '23

21 Nov '23

Hello, during the Kamailio Developers Meeting 2023 in Dusseldorf that took place last week, it was proposed to obsolete modules that seem to be unmaintained and no activity about them was noticed during the past years. It is quite some overhead in packaging them and trying to keep them compiling when they have external dependencies, therefore such step should spare some resources in the future. The list (see below) was built based on the options of those present at the meeting, now we want to discuss it on the larger communities of developers and users. If you are using any of these modules or you think any of them worth keeping, reply with the names of the modules that you want to be kept. The proposed action is to relocate the obsoleted modules to a new git repository "kamailio-obsolete" to still keep some visibility to them and in the eventually of future interest on any of them, it can be reintroduced in the main repository. Next is the initial list of modules proposed to be considered obsolete: - app_java - app_lua_sr - app_mono - app_python - app_sqlang - auth_identity - call_control - db2_ldap - db2_ops - db_cassandra - db_perldvdb - dnssec - domainpolicy - h350 - mediaproxy - osp - peering - print - print_lib - pua_xmpp - ratelimit - uid_auth_db - uid_avp_db - uid_domain - uid_gflags - uid_uri_db - uri_db - xmpp - xprint Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training -- asipto.com

3 5

UAC DNS SRV timeout
by Sergiu Pojoga 17 Nov '23

17 Nov '23

Hi, Setup: kamailio acting as a UAC needs to register with a server whose outbound proxy is DNS SRV based only, there's no A record on the proxy's FQDN. The provider advertises two SRV records. ;; ANSWER SECTION: _sips._tcp.sip.provider.com. 10 IN SRV 10 50 5061 sip11-sip.provider.com. _sips._tcp.sip.provider.com. 10 IN SRV 15 50 5061 sip10-sip.provider.com. Everything was working fine, until the provider changed the SRV priority, putting a lower priority on the host that is actually down at the moment. In this case, sip11-sip.provider.com is DOWN and sip10-sip.provider.com is UP. Now, what's happening is Kamailio tries to REGISTER with the lower priority host, gets no reply back (TCP connection doesn't get established). It then takes 30 seconds for Kamailio to try the host with the higher priority, registering successfully. And so it goes for every re-register: failure => 30 seconds => register OK. The same happens for INVITES to the downstream: INVITE => timeout => 30 seconds => INVITE (other host 200 OK). I've tried to play with TCP and DNS params, but so far no luck: no matter what I did - it took the same 30 seconds for Kamailio to detect failure and retry the secondary host. Any suggestions will be highly appreciated. Kamailio 5.6.4 (x86_64/linux) 239d0a tcp_connection_lifetime=3604 tcp_max_connections=60 tcp_connect_timeout=10 tcp_keepalive = yes tcp_crlf_ping=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=30 tcp_reuse_port=1 tcp_accept_no_cl=yes tcp_rd_buf_size=16384 use_dns_cache = on use_dns_failover = on dns_srv_loadbalancing = on dns_try_naptr = on dns_try_ipv6=no dns_try_naptr=no dns_use_search_list=no dns_retr_time=1 dns_retr_no=3 Thanks --Sergiu

1 0

auth_check : sip user / authentication user mismatch
by Jawaid Bazyar 17 Nov '23

17 Nov '23

Hi, I am trying to register an endpoint as follows: REGISTER sip:siptest.booger.net SIP/2.0 Via: SIP/2.0/UDP X.X.X.X.76:31114;branch=z9hG4bK223420485;rport From: sip:1720XXXXXXX@siptest.booger.net;tag=962873337 To: sip:1720XXXXXXX@siptest.booger.net Call-ID: 2053687751-32761-1(a)EH.BJI.BAE.HG CSeq: 2067 REGISTER Contact: sip:1720XXXXXXX@X.X.X.X:31114;reg-id=2;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B82A1C58B>" Authorization: Digest username="654fe87c-67ff-42dd-8d5e-79786a99713c", realm="siptest.booger.net", nonce="ZVaJtmVWiIrsuWc5hkzM3MUUUs8MgRFR", uri=sip:siptest.booger.net, response="119a3b6426cdcfa037bf1825b69139a5", algorithm=MD5 X-Grandstream-PBX: true Max-Forwards: 70 User-Agent: Grandstream GXP2170 1.0.11.64 Supported: path Expires: 120 MAC: 00:0b:82:a1:c5:8b Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 Note that the Authorization username differs from the To-From username. This is intentional, as I am testing use of randomly generated credential . This worked with this endpoint directly against Asterisk, for instance. However, registering against Kamailio now, I am getting: Nov 16 21:24:26 vs-rs01 /usr/sbin/kamailio[584855]: DEBUG: {1 2067 REGISTER 2053687751-32761-1(a)EH.BJI.BAE.HG} auth_db [authorize.c:503]: auth_check(): authentication username mismatch with from/to username Even though I have this set in the config: if (!auth_check("$fd", "subscriber", 0)) { // default 1, change to 0 to skip check 0 is supposed to mean no user checks performed. I am doing this because I want to use the complex credentials for authentication, but want the endpoint to tell me the phone number in an INVITE to/from, instead of putting in the extremely long credential. Is there a way to get Kamailio to accept different SIP User ID and Authentication ID fields? Thanks, Jawaid

2 2

pv cache limit is going to be exceeded
by Ali Taher 17 Nov '23

17 Nov '23

Hello all, I'm using the following Lua script to fetch data from Redis, which is in form of list: function split(str, delimiter) for token in string.gmatch(str, "[^" .. delimiter .. "]+") do return token end end function contains(mainString, subString) return string.find(mainString, subString, 1, true) ~= nil end function longest_match_acode() local currentSeconds = os.time() local milliseconds = os.clock() * 1000 local ddate = os.date("%Y-%m-%d %H:%M:%S", currentSeconds) .. string.format(".%03d", milliseconds) KSR.xlog.xinfo("starting date:" ..ddate) local size = 0 local result local acode = "29192" local inputbcode = "4474173" local delimiter = ":" while size == 0 do local currentSeconds = os.time() acode = string.sub(acode, 1, string.len(acode) - 1) KSR.ndb_redis.redis_cmd("srvN", "LRANGE price:" .. acode .." 0 -1", "r") size = tonumber(KSR.pv.get("$redis(r=>size)")) end local left = 0 local right = size - 1 while left <= right do local currentSeconds = os.time() local milliseconds = os.clock() * 1000 local ddate = os.date("%Y-%m-%d %H:%M:%S", currentSeconds) .. string.format(".%03d", milliseconds) resultRight = tostring(KSR.pv.get("$redis(r=>value[" .. right .. "])")) resultLeft = tostring(KSR.pv.get("$redis(r=>value[" .. left .. "])")) local bcodeLeft = split(resultLeft, delimiter) local bcodeRight = split(resultRight, delimiter) if contains(inputbcode, bcodeRight) then KSR.xlog.xinfo("Input bcode contains bcode value from Redis: " .. resultRight .. " at index: " .. right .. " with date: " .. ddate) end if contains(inputbcode, bcodeLeft) then KSR.xlog.xinfo("Input bcode contains bcode value from Redis: " .. resultLeft .. " at index: " .. left .. " with date: " .. ddate) end left = left + 1 right = right - 1 end local currentSeconds = os.time() local milliseconds = os.clock() * 1000 local ddate = os.date("%Y-%m-%d %H:%M:%S", currentSeconds) .. string.format(".%03d", milliseconds) KSR.xlog.xinfo("ending date:" ..ddate) end function ksr_request_route() if KSR.is_INVITE() then longest_match_acode() KSR.sl.send_reply("404", "Not found"); end end I'm getting the following warning in the log : WARNING: LUA {INVITE}: <core> [core/pvapi.c:340]: pv_cache_add(): pv cache limit is going to be exceeded - pkg memory may get filled with pv declarations I think the issue is in the following lines: resultRight = tostring(KSR.pv.get("$redis(r=>value[" .. right .. "])")) resultLeft = tostring(KSR.pv.get("$redis(r=>value[" .. left .. "])")) the list coming from Redis has around 30k items, which I'm iterating through using value[x] which is exhausting the pv declaration as per my understanding. How to overcome this issue? Is it possible to save the list as an array variable and then iterate through that array? Regards,

2 3

Kamailio v5.7.3 Released
by Daniel-Constantin Mierla 17 Nov '23

17 Nov '23

Hello, Kamailio SIP Server v5.7.3 stable release is out. This is a maintenance release of the latest stable branch, 5.7, that includes fixes since the release of v5.7.2. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.7.x. Deployments running previous v5.7.x versions are strongly recommended to be upgraded to v5.7.3. For more details about version 5.7.3 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/11/kamailio-v5-7-3-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - www.kamailioworld.com

1 0

Jump to page:

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