sr-users July 2024

sr-users@lists.kamailio.org

42 participants
62 discussions

Possible Kamailio memmory leak - version 5.8.2

by Vanderlei Torres Batistela

Hello all, I am using a very simple scritp with corex module enabled . Normal calls works fine, but a scenario where INVITE does not receive response and the call is released with SIP 408 (request timeout) leads to memmory leak. I verified it making a lot of calls with this scenario and printing the shared memory (using kamcmd core.shmmem) . Its ocurred with modparam("corex", "nio_intercept", 1). If I modify to modparam("corex", "nio_intercept", 0) the memmory leak does not ocurr anymore. The problem also occurs in another scenario where the SIP Cancel message is not responded to. My script has this event route # event route event_route[network:msg] { xlog("L_INFO", "Dentro do Event_Route \n"); if (is_incoming()) { xlog("L_INFO", "Received message '$mb' \n"); $avp(msg) = $mb; xinfo("avp(msg) = $avp(msg)"); } else { xlog("L_INFO", "Sending message '$mb' \n"); $avp(msg) = $mb; }; } Test done wtih 4000 calls: [root@labcom070 kamailio]# kamctl stats shmem { "jsonrpc": "2.0", "result": [ "shmem:fragments = 900", "shmem:free_size = 6180368", "shmem:max_used_size = 66980272", "shmem:real_used_size = 60928496", "shmem:total_size = 67108864", "shmem:used_size = 54884944" ], "id": 393115 } [root@labcom070 kamailio]# kamcmd mod.stats all shm Module: core { create_avp(178): 52257504 counters_prefork_init(211): 53760 cfg_clone_str(132): 112 cfg_shmize(221): 832 main_loop(1381): 16 init_pt(104): 16 init_pt(103): 16 init_pt(102): 6224 cfg_register_ctx(47): 96 init_tcp(5197): 8192 init_tcp(5191): 32768 init_tcp(5182): 16 init_tcp(5175): 16 init_tcp(5167): 16 init_tcp(5161): 16 init_tcp(5149): 16 init_avps(92): 16 init_avps(91): 16 init_dst_blocklist(435): 16384 init_dst_blocklist(427): 16 timer_alloc(494): 96 init_dns_cache(368): 16 init_dns_cache(359): 16384 init_dns_cache(351): 16 init_dns_cache(343): 16 init_timer(264): 16 init_timer(263): 16384 init_timer(262): 16 init_timer(261): 16 init_timer(250): 16 init_timer(218): 16 init_timer(207): 278544 init_timer(206): 16 init_timer(194): 16 cfg_child_cb_new(832): 64 sr_cfg_init(371): 16 sr_cfg_init(364): 16 sr_cfg_init(356): 16 sr_cfg_init(344): 16 sr_cfg_init(332): 16 ksr_shutdown_phase_init(123): 16 rpc_hash_add(118): 16 qm_shm_lock_init(1463): 16 Total: 52687808 } I attached my kamailio script used and a log with one call using the command "kamcmd corex.shm_summary" with modparam("corex", "nio_intercept", 1) and modparam("corex", "nio_intercept", 0) Regards, Vanderlei

4 months

Re: Difference betwwen TM functions in KEMI

by Duarte Rocha

Hello Alex, You're totally right, that was the issue. Thank you so much for the help. Helpful as always. Cheers, Duarte Rocha

4 months

Difference betwwen TM functions in KEMI

by Duarte Rocha

Hello all, I'm using Kamailio with native script and KEMI in Javascript. I noticed that functions from the TM module can have different results if I call them on KEMI or Native script. Is this intended behaviour? Don't they share the state? In order to test this i made the following code : KEMI Code : function ksr_request_route() { try{ if ( KSR.is_method("BYE") ) { print.error("BYE Request KEMI BYE") KSR.route("exists_test") if(KSR.tm.t_exists()) { print.error("KEMI : Transaction exists") } else { print.error("KEMI : Transaction does not exist") } Native Code : route[exists_test] { if( t_exists()) { xerr("Native Script : Transaction exists \n"); } else { xerr("Native Script : Transaction does not exist \n"); } } I've also tried to change function call order but every time I get "Transaction does not exist" on native and "Transaction Exists" on KEMI. Is this intended behaviour? Should I only call tm functions in native or Kemi in order to have consistency ? Thanks in advance, Best Regards,

4 months, 1 week

Dns record not alone?

by Pyry Aaltonen

Hi, I recently updated my testing env to 5.8.1 and after that I’ve been receiving dns_cache.c warning “record not alone”. I found out that it’s been added to quite recent commit: https://github.com/kamailio/kamailio/commit/d8a35b3b6c837b36779e232b65fce61… And that’s probably the why I haven’t seen it before. As far as I know, I have no other problem with dns or anything else than the warning appearing in the logs 😊 I can’t quite get what the warning is about? Clearly refers to dns queries, and with debug I found out that maybe its somehow related to ip which has several domains to pointing it (and queried by one of those domains by this kamailio). Can it be something with the PTR-record? And this warning comes ones every hour, so probably when some ttl expires, and meanwhile the cache is ok with the situation. And as a background, I haven’t done any specific dns-configurations in my config, so settings should be pretty much in defaults. Any advice what I should fix here to get the warning disappear? -Pyry

4 months, 1 week

Add a Header to CANCEL request

by sadik.oualla.mohamed＠gmail.com

Hello all, I am facing an issue with Kamailio when trying to add custom headers to CANCEL requests. My current configuration adds the "Reason" header perfectly: ``` if(!is_present_hf("Reason")){ $var(cause_request) = 31; append_hf("Reason: Q.850;cause=$var(cause_request)\r\n", "CSeq"); msg_apply_changes(); } ``` However, when I attempt to add headers like "X-Reason" or "TestHeader", they are not added: ``` if(!is_present_hf("Reason")){ $var(cause_request) = 31; append_hf("X-Reason: Q.850;cause=$var(cause_request)\r\n", "CSeq"); # or append_hf("TestHeader: Q.850;cause=$var(cause_request)\r\n", "CSeq"); msg_apply_changes(); #nothing changes in the relayed CANCEL request :-/ } ``` I've read in this discussion "https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…" that this might work if sending CANCEL in stateless mode, but I want to keep it stateful. Any suggestions on how to achieve this? Regards, Mohamed.

4 months, 1 week

Changing ksr_tcp_accept_iplimit from default 1024

by Who AmI

Hi list, I hope you are all well? I am currently loadtesting some services internally and I am getting an odd error around TCP connections from the same source IP below: "/usr/sbin/kamailio[1806789]: CRITICAL: <core> [core/tcp_main.c:4459]: handle_new_connect(): hit the limit of connections per source IP (my_ip:39043) - rejecting" Its from the core the error so I was looking at the cookbooks and documentation but cannot get around this specific limit or find a configuration to tweak that fixes it. The limit only affects TCP (will affect TLS as well but I haven't got that far) and is 1024 it seems. Kamailio version is: 5.7.6 OS: Ubuntu 22.04 Things I have done so far: I have set limitNOFILE=65535 in the service file Set the tcp/tls_max_connections at 8192 (default is 2048) Increase the tcp_rd_buf_size to 16k+ The service I am using to loadtest is SIPp with flags "-t tn" for TCP multisocket as this service will have much more than 1024 concurrent TCP connections to it from a single source IP. I think I have missed something basic here as the devel and the source code references: "ksr_tcp_accept_iplimit" here at line 541: https://github.com/kamailio/kamailio/blob/master/src/main.c#L541 I cannot find a way to change this with a configuration line it seems, am I being blind or is my only option to build from source and change this? Many Thanks, John.

4 months, 1 week

Weird telephone-event payload issue - need help

by Tim Bowyer

Hello Everyone, I've been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece. 1. Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. 2. INVITE sent to Asterisk with the same SDP, payload = 96 3. INVITE sent from Asterisk to Client with payload = 101 * 200 OK w/SDP from Client has payload = 101 * 200 OK w/SDP to Kamailio has payload = 96 * 200 OK w/SDP to Carrier has payload = 96 4. Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client 5. Kamailio passes this onto Carrier with media IP of RTPengine 6. 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio 7. Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn't do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier. * Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). * The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). * There's nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer

4 months, 1 week

how to upgrade kamailio minor release from 5.7.5 to 5.7.6

by sadik.oualla.mohamed＠gmail.com

I am currently using Kamailio version 5.7.5, which I installed from the source code. I would like to upgrade to version 5.7.6 but have been unable to find documentation specifically addressing minor upgrades between these minor releases. I have found only wikis detailing the process for upgrading for major releases (like 5.7.x to 5.8.0). Could you please point me to the documentation for my current need or share with me steps on how to perform this minor upgrade? Thank you. Cheers.

4 months, 1 week

How to get the rtpengine IP used by the current call among multiple rtpengines

by mm e

modparam("rtpengine", "rtpengine_sock","udp:192.168.1.3:12221=2 udp:192.168.1.1:12222=1 udp:192.168.1.5:12221=7") When rtpengine_sock is set to multiple rtproxies mode, how to get the id or ip of the rtpengine used in the current call? There is no information returned which rtpengine

4 months, 1 week

How to get the id or ip in the multiple rtproxies for LB with weights。

by mm e

4 months, 1 week

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 July 2024