sr-dev

sr-dev@lists.kamailio.org

3 participants
45196 discussions

[kamailio/kamailio] "dns_hash_put(): unlinked item" downgrade of the WARN messages to INFO (Issue #4287)
by hubgurujr 01 Jul '25

01 Jul '25

hubgurujr created an issue (kamailio/kamailio#4287) Seeing a lot of warning messages in logs, running version: kamailio 5.8.4 (x86_64/linux) 1e6738, but I think this is false positive and should be informational, not a warning. Jun 10 14:14:17 siprouter1-pve186 /usr/local/sbin/kamailio[8111]:WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b9fcc0 Jun 10 14:14:19 siprouter1-pve186 /usr/local/sbin/kamailio[8122]:WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe():unlinked item 0x7fa0f9b9fcc0 This is occurring when a DNS URL changes IP but I see no processing issues with SIP Messages. [emal-thread.txt](https://github.com/user-attachments/files/20776557/emal-th… -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4287 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4287(a)github.com>

2 16

[kamailio/kamailio] tm: allow pending forked REGISTER auths being handled the same way as… (PR #4304)
by ovoshlook 01 Jul '25

01 Jul '25

… forked INVITEs auths #### Pre-Submission Checklist - [*] Commit message has the format required by CONTRIBUTING guide - [*] Commits are split per component (core, individual modules, libs, utils, ...) - [*] Each component has a single commit (if not, squash them into one commit) - [*] No commits to README files for modules (changes must be done to docbook files #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [*] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ *] Tested changes locally - [ ]* Related to issue #[4266](https://github.com/kamailio/kamailio/issues/4266) #### Description If a Negative reply for forked REGISTER comes after the first 200 response, it won't be ignored by Kamailio and will be processed the same way as replies processed for the INVITEs You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4304 -- Commit Summary -- * tm: allow pending forked REGISTER auths being handled the same way as forked INVITEs auths -- File Changes -- M src/modules/tm/t_reply.c (15) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4304.patch https://github.com/kamailio/kamailio/pull/4304.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4304 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4304(a)github.com>

2 5

[kamailio/kamailio] branch_failure_route does not handle reply while wt_timer period (Issue #4266)
by IgorG 01 Jul '25

01 Jul '25

IgorrG created an issue (kamailio/kamailio#4266) ### Description While implementing mid-register inspired by pull request (https://github.com/kamailio/kamailio/pull/3360) we found the case when it goes impossible to handle responses for registrar servers. In case some of registrars busy and respond with 401 after 200ok received - it is not possible using any routes and configuration options to handle responses received in branch transactions. According to documentation I think that setting wt_timer should allow to absorb and handle responses on failure-route while transaction kept in memory. In fact wt_timer does not affect handling responses in any way. ![Image](https://github.com/user-attachments/assets/14feb472-91ea-4028-8780-1fee1d4ee0e8) ### Troubleshooting To reproduce this case we have configured sipp to response instant with 200ok on registration request. #### Reproduction To reproduce issue SIPP could be setup as one of the dispatcher nodes with instant 200ok reply to register. Kamailio should use following configuration snippet: https://github.com/ovoshlook/kamailio-mid-registrar-config-snippets/blob/ma… #### Log Messages REGISTER|401tm [t_lookup.c:912]: t_reply_matching(): t_reply_matching: hash 12337 label 0 branch 1 REGISTER|401tm [t_lookup.c:986]: t_reply_matching(): reply (0x7f1fc67f83a8) matched an active transaction (T=0x7f1fc0f0f740)! REGISTER|401tm [t_lookup.c:1122]: t_check_msg(): msg (0x7f1fc67f83a8) id=13/1915035 global id=13/1915035 T end=0x7f1fc0f0f740 REGISTER|401tm [t_reply.c:2363]: reply_received(): transaction found - T:0x7f1fc0f0f740 branch:1 REGISTER|401tm [t_reply.c:2376]: reply_received(): original status uas=200, uac[1]=0 local=0 is_invite=0) REGISTER|401tm [t_reply.c:1363]: t_should_relay_response(): ->>>>>>>>> T_code=200, new_code=401 REGISTER|401tm [t_reply.c:1374]: t_should_relay_response(): final reply already sent REGISTER|401tm [t_reply.c:1625]: t_should_relay_response(): finished with rps discarded - uas status: 200 ### Possible Solutions  ### Additional Information * **Kamailio Version** ``` version: kamailio 5.6.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 16:35:08 Jun 5 2023 with gcc 10.2.1 ``` * **Operating System**: ``` No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye Linux pbxKamaTest 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4266 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4266(a)github.com>

3 2

Ideas for developer meeting 1: Markdown in docs
by Richard Chan 01 Jul '25

01 Jul '25

Great work kamailio devs in releasing 6.0.2 and the continuing work on master branch. Wishing you a restful weekend and while you are at it, here are some ideas, probably half-baked, for your consideration. Background: Kamailio uses XML for documentation that is followed by an automatic task that renders to plaintext(README file) for the repo and HTML for the website Proposal - Use Markdown for docs/ Author docs/ in Markdown - no rendering in-repo - website will need a static site generator that can create the internal links Benefits - markdown is a common mark-up tool for plaintext that has sufficient semantic richness for kamailio - most developers are familiar with markdown especially from Github, other git-forges - avoids the in-repo rendering step - most git-forges can render the markdown file on-screen so that there is less iteration required if there are typos in xml. It is also easier for the developer to validate their docs prior to pushing to master branch Work Required: - evaluate and implement the static site generator - the in-repo README generator can be slowly phased out Regards Richard (Shih-Ping)

2 1

git:master:fee83561: core: dns cache - destroy the item directly on remove
by Daniel-Constantin Mierla 01 Jul '25

01 Jul '25

Module: kamailio Branch: master Commit: fee835616425723f81b433b561aba54fbfd17045 URL: https://github.com/kamailio/kamailio/commit/fee835616425723f81b433b561aba54… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2025-07-01T14:43:01+02:00 core: dns cache - destroy the item directly on remove --- Modified: src/core/dns_cache.c --- Diff: https://github.com/kamailio/kamailio/commit/fee835616425723f81b433b561aba54… Patch: https://github.com/kamailio/kamailio/commit/fee835616425723f81b433b561aba54… --- diff --git a/src/core/dns_cache.c b/src/core/dns_cache.c index 2ed1b21f143..cb343a81184 100644 --- a/src/core/dns_cache.c +++ b/src/core/dns_cache.c @@ -508,7 +508,8 @@ inline static void _dns_hash_remove_entry( LM_DBG("item %p with high refcnt %d (%s:%u)\n", e, atomic_get_int(&e->refcnt), fpath, line); } - dns_hash_put(e); + /* item unlinked - destroy it */ + dns_destroy_entry(e); } #define _dns_hash_remove(e) _dns_hash_remove_entry(e, __FILE__, __LINE__)

1 0

git:master:5108e3c5: core: dns cache - lower the log levels for put and remove operations
by Daniel-Constantin Mierla 01 Jul '25

01 Jul '25

Module: kamailio Branch: master Commit: 5108e3c529790b1bc97e160ae841f238aa1bda4a URL: https://github.com/kamailio/kamailio/commit/5108e3c529790b1bc97e160ae841f23… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2025-07-01T13:11:22+02:00 core: dns cache - lower the log levels for put and remove operations --- Modified: src/core/dns_cache.c --- Diff: https://github.com/kamailio/kamailio/commit/5108e3c529790b1bc97e160ae841f23… Patch: https://github.com/kamailio/kamailio/commit/5108e3c529790b1bc97e160ae841f23… --- diff --git a/src/core/dns_cache.c b/src/core/dns_cache.c index 6c5f8c38e1b..2ed1b21f143 100644 --- a/src/core/dns_cache.c +++ b/src/core/dns_cache.c @@ -180,7 +180,7 @@ void dns_hash_put_entry( /* atomic_sub_long(dns_cache_total_used, e->total_size); */ dns_destroy_entry(e); } else if(e->next == NULL && e->prev == NULL) { - LM_WARN("unlinked item %p rc %d (%s:%u)\n", e, + LM_INFO("unlinked item %p rc %d (%s:%u)\n", e, atomic_get_int(&e->refcnt), fpath, line); } } @@ -505,7 +505,7 @@ inline static void _dns_hash_remove_entry( e->last_used_lst.next = e->last_used_lst.prev = 0; *dns_cache_mem_used -= e->total_size; if(atomic_get_int(&e->refcnt) > 1) { - LM_INFO("item %p with high refcnt %d (%s:%u)\n", e, + LM_DBG("item %p with high refcnt %d (%s:%u)\n", e, atomic_get_int(&e->refcnt), fpath, line); } dns_hash_put(e);

1 0

Ideas for developer meeting 2b: Teach TCP sockets that they are TLS proxies
by Richard Chan 01 Jul '25

01 Jul '25

Ideas for developer meeting 2b: Teach TCP sockets that they are TLS proxies Background: This is a follow-on for Proposal 2 - it is for each of use TLS offloading to external proxies. When using external TLS/TCP bridges users encounter a mismatch when the URI/socket matcher cannnot find a matching TLS socket. Users can work around this by forcing t_relay_to but it is not a natural map. Some dancing with record-route headers is usually necessary Proposal 2b This proposal is to have a marker in config file on TCP listeners that they are in fact proxy'd TLS connections. So the look-and-feel should be TLS except that they skip mod_tls processing. When the config searches for matching socket this type of TLS-proxy will be found. Benefits: - can sidestep more exotic mod_tls problems with OpenSSL; user just offloads to HAProxy et al - seamless config: these proxy'ied sockets have enough metadata that look like TLS socket for URIs, record-route etc handling Richard (Shih-Ping)

2 1

Ideas for developer meeting 2: Rearchitect TLS
by Richard Chan 01 Jul '25

01 Jul '25

(Apologies for the long wall of text) Ideas for developer meeting 2: Rearchitect TLS Background: Kamailio uses OpenSSL in fork() for load balancing (TLS followed by SIP).The TLS state must be in shared memory so that each worker can pick up where the previous worker has left off. Over the years this has caused much friction - only OpenSSL 3 and wolfSSL can be used in this manner because they include hooks for memory management Problems with current architecture Original OpenSSL 3+ has gone heavily down the way of using pthreads, especially thread-local variables. OpenSSL lookalikes - boringSSL, libreSSL, AWS-LC - don't support memory management to redirect functions to shared memory pools A pure GPL library like GnuTLS also not enable memory management hooks Today Kamailio is "fighting" its primary TLS provider, namely OpenSSL 3. We require pthread symbol overrides (which is a code smell) and have to do thread local tricks for the workers to have a clean state. With OpenSSL 3 - Kamailio users have an unhappy relationship with memory management. Structures are duplicated per worker(SSL_CTX) to avoid unexpected failures when an SSL object derived from worker A is used in worker B. Using a single SSL_CTX in the main process - in an attempt to conserve memory - has not been solved yet (my assessment is that this problem can be solved within the current architecture). History It seems that Kamailio code base has vestiges of when TLS was handled in core (possibly the TCP manager process?). Proposal 2 This proposal has the spirit that we should not be fighting the libraries we use especially if this library is a key component of many distributions/containers with many eyes on the way we use and abuse OpenSSL. The Zen of OpenSSL(I just made that up) would suggest we embrace their path forward and have Kamailio work within that boundary. The GPL of Kamailio would also suggest that we should validate this approach with the ability to use something like GnuTLS. This proposal is to perform TLS in a thread-pool in the TCP manager so that all TLS related operations are confined to a single process. When the TCP manager terminates or initiates TLS it should perform TLS in a hairpin socketpair(managed by a thread pool). The socket fd used in sendmsg/recvmsg with the worker is this internal proxy'ied socket but carries metadata about the original connection. In other words: Kamailio TCP manager internally implements a TLS/TCP bridge like Nginx/HAProxy do with HTTPS/HTTP or TLS/TCP. These proxies send headers so the worker is informed about the nature of the original connection. Benefits - use OpenSSL/AWS-LC/boringSSL/libreSSL in the way they are intended to be used; even GnuTLS - no pthreads hackery - a well-defined boundary for TLS operations, certificate and key management: allowing for easier scrutiny and audit The offloading of both TLS/SIP dates from the days when threading was poor on Linux. Today that is no longer the case, so the TLS Manager could handle all TLS and the worker should handle SIP/TCP. In fact this proposal was inspired by the recent work on UDP enhancement. Optional riff: we may be able to off-load TLS entirely to HAProxy(or any other TLS/TLS bridge). Instead of handling TLS ourselves Kamailio creates a new type of listener/speaker haproxy-in, haproxy-out. Kamailio "knows" that these sockets are not SIP traffic but internal hairpins to decrypt/encrypt the streams via HAProxy et al. Think of Kamailio as using HAProxy as a filter object: the sendmsg/recvmsg will use the haproxy-in socket (which is what the worker will see - TCP only). See the sidenode below. t_relay would have to taught that it doesn't need to look for "real" TLS sockets but instead a proxy socket should suffice. Sidenote: Today TLS can be solved with external TLS/TCP bridges. The main issue with this approach is the config file occasionally needs to force TCP otherwise Kamailio will look for a non-existent TLS socket - so it is not an entirely happy experience for users. Richard (Shih-Ping)

2 1

git:master:40837145: microhttpd: rework resetting the data field
by Daniel-Constantin Mierla 01 Jul '25

01 Jul '25

Module: kamailio Branch: master Commit: 4083714575e2cb7500c67fb8a0b99ff371bf8576 URL: https://github.com/kamailio/kamailio/commit/4083714575e2cb7500c67fb8a0b99ff… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2025-07-01T13:05:43+02:00 microhttpd: rework resetting the data field --- Modified: src/modules/microhttpd/microhttpd_mod.c --- Diff: https://github.com/kamailio/kamailio/commit/4083714575e2cb7500c67fb8a0b99ff… Patch: https://github.com/kamailio/kamailio/commit/4083714575e2cb7500c67fb8a0b99ff… --- diff --git a/src/modules/microhttpd/microhttpd_mod.c b/src/modules/microhttpd/microhttpd_mod.c index ff486ac7dd6..7bc6586aaf3 100644 --- a/src/modules/microhttpd/microhttpd_mod.c +++ b/src/modules/microhttpd/microhttpd_mod.c @@ -535,14 +535,10 @@ static enum MHD_Result ksr_microhttpd_request(void *cls, if(_ksr_mhttpd_ctx.data.s != NULL) { free(_ksr_mhttpd_ctx.data.s); } + _ksr_mhttpd_ctx.data.s = NULL; + _ksr_mhttpd_ctx.data.len = 0; if(cstream->data.len > 0) { - if(_ksr_mhttpd_ctx.data.s != NULL) { - free(_ksr_mhttpd_ctx.data.s); - } _ksr_mhttpd_ctx.data = cstream->data; - } else { - _ksr_mhttpd_ctx.data.s = NULL; - _ksr_mhttpd_ctx.data.len = 0; } free(cstream); _ksr_mhttpd_ctx.cinfo = MHD_get_connection_info(

1 0

Issues with Kamailio + RTPEngine Integration: ACK Handling and Media Flow in WSS Scenario
by Roman Dcoz 01 Jul '25

01 Jul '25

Hello community, We're currently facing a couple of issues in our setup involving Kamailio (v6.1.0-dev1), RTPEngine, and FreeSWITCH, primarily with WebRTC/WSS endpoints and media handling. I would appreciate any guidance or suggestions to help resolve them. Issue 1: ACK Dropped Due to .invalid Hostname – Call Drops After 32s We are experiencing a problem when using t_on_reply() where ACKs fail to route correctly, resulting in the following error: <core> [core/resolve.c:1773]: sip_hostport2su(): could not resolve hostname: "2f3d6480-4e78-11f0-a25d-ad05fd2deba0.invalid" <core> [core/forward.c:536]: forward_request_mode(): bad host name 2f3d6480-4e78-11f0-a25d-ad05fd2deba0.invalid, dropping packet sl [sl_funcs.c:430]: sl_reply_error(): stateless error reply used: Unresolvable destination (478/SL) This causes ACKs to fail and calls to drop after 32 seconds (likely due to lack of ACK for 200 OK). Here is my WITHINDLG function. route[WITHINDLG] { if (has_totag()) { if (is_method("ACK")) { # Fix invalid domains before forwarding if ($du =~ ".invalid") { xlog("L_WARN", "Fixing ACK destination for invalid domain: $ru\n"); handle_ruri_alias(); } xlog("L_INFO", "Processing ACK for call ID: $ci $ru\n"); if (t_check_trans()) { xlog("L_INFO", "Stateful ACK - relaying\n"); route(RELAY); exit; } else { xlog("L_WARN", "Stateless ACK - relaying anyway to ensure call stability $proto $ru\n"); route(RELAY); exit; } } if (loose_route()) { xlog("L_INFO", "Loose routing enabled for $rm\n"); if ($du == "") { if (!handle_ruri_alias()) { xlog("L_ERR", "Bad alias <$ru>\n"); sl_send_reply("400", "Bad Request"); exit; } } route(DLGURI); if (is_method("BYE")) { setflag(FLT_ACC); # Do accounting setflag(FLT_ACCFAILED); # Even if the transaction fails } if (is_method("NOTIFY")) { record_route(); } route(RELAY); exit; } else { if (is_method("SUBSCRIBE") && uri == myself) { xlog("L_INFO", "Processing in-dialog SUBSCRIBE request\n"); exit; } if (is_method("ACK")) { xlog("L_WARN", "Standalone ACK detected, ignoring\n"); exit; } sl_send_reply("404", "Not Here"); exit; } } } Questions: Is there a more reliable way to handle .invalid hostnames in $du/$ru caused by upstream or downstream Contact headers? Should I forcibly rewrite $du/$ru or avoid using t_on_reply() for certain scenarios? Issue 2: Media Not Flowing Correctly – RTPEngine Flags for WSS ➝ Freeswitch ➝ WSS We’re testing a WebRTC (WSS) → Freeswitch → WebRTC (WSS) flow, where Freeswitch is generating media with media_webrtc=true. The general flow is: Device Registred on Kamailio (WSS client) → Freeswitch → Kamailio/RTPEngine → WSS client Our branch logic is as follows: route[LOCATION] { t_on_branch("BRANCH_MEDIA"); lookup("location"); t_relay(); exit; } branch_route[BRANCH_MEDIA] { if (is_method("INVITE")) { xlog("L_INFO", "BRANCH_MEDIA.......................................\n"); xlog("L_INFO", "Request for $proto $ru $du"); if ($ru =~ "transport=ws") { xlog("L_INFO", "This is a WSS phone call request to $proto $ru"); if (sdp_with_transport_like("RTP/SAVPF")) { rtpengine_offer("ICE=force-relay replace-origin DTLS=passive"); xlog("L_INFO", "[REPLY_WS_TO_WS]Request to REPLY_WS_TO_WS"); t_on_reply("REPLY_WS_TO_WS"); }else { rtpengine_offer("trust-address replace-origin replace-session-connection ICE=force RTP/SAVPF SDES-off rtcp-mux-offer"); xlog("L_INFO", "[REPLY_FROM_WS]Request to REPLY_FROM_WS"); t_on_reply("REPLY_FROM_WS"); } } else if ($proto =~ "ws") { $var(rtpengine_offer_flags) = "trust-address replace-origin replace-session-connection rtcp-mux-demux ICE=remove UDP/TLS/RTP/SAVP"; t_on_reply("REPLY_TO_WS"); rtpengine_offer("$var(rtpengine_offer_flags)"); } else { $var(rtpengine_offer_flags) = "trust-address replace-origin replace-session-connection rtcp-mux-demux ICE=remove RTP/AVP"; t_on_reply("MANAGE_CLASSIC_REPLY"); rtpengine_offer("$var(rtpengine_offer_flags)"); } } route(NATMANAGE); } onreply_route[REPLY_WS_TO_WS] { if(status=~"[12][0-9][0-9]") { rtpengine_answer("ICE=force-relay replace-origin DTLS=passive"); route(NATMANAGE); } if (nat_uac_test("1")) { fix_nated_contact(); } } onreply_route[REPLY_TO_WS] { if (is_method("INVITE") && has_totag() && t_check_status("200")) { xlog("L_INFO", "[REPLY_TO_WS]Reply from webrtc client: $rs"); $var(rtpengine_REPLY_TO_WS_flags) = "trust-address replace-origin replace-session-connection SDES-off ICE=force"; route(NATMANAGE); xlog("L_INFO","[REPLY_TO_WS] RTP Engine Flags Answer--------->: $var(rtpengine_REPLY_TO_WS_flags)\n"); rtpengine_answer("$var(rtpengine_REPLY_TO_WS_flags)"); } if (nat_uac_test("1")) { fix_nated_contact(); } } onreply_route[REPLY_FROM_WS] { if(status=~"[12][0-9][0-9]") { rtpengine_answer("trust-address replace-origin replace-session-connection DTLS=passive ICE=remove RTP/AVP rtcp-mux-demux label=$fU"); xlog("L_INFO", "----- $fU | Change RTP sources for WS reply $rs in REPLY_FROM_WS- M=$rm R=$ru F=$fu T=$tu IP=$pr:$si:$sp -----\n"); route(NATMANAGE); } if (nat_uac_test("1")) { fix_nated_contact(); } } onreply_route[MANAGE_CLASSIC_REPLY] { if (is_method("INVITE") && has_totag() && t_check_status("200")) { xlog("L_INFO", "[MANAGE_CLASSIC_REPLY]Boring reply from softphone: $rs"); $var(rtpengine_flags) = "rtcp-mux-demux DTLS=off SDES-on ICE=remove RTP/SAVP inject-DTMF"; route(NATMANAGE); xlog("L_INFO","[MANAGE_CLASSIC_REPLY] RTP Engine Flags Answer--------->: $var(rtpengine_flags)\n"); rtpengine_answer("$var(rtpengine_flags)"); } if (nat_uac_test("1")) { fix_nated_contact(); } } Despite this, media is not flowing properly between WSS clients, and we're suspecting either the wrong RTPEngine flags or SDP modifications. Questions: Is this the correct way to differentiate flags based on WSS versus UDP endpoints? Is it recommended to split branch_route vs onreply_route in this manner? Any help or suggestions from the community would be greatly appreciated. Thanks in advance! Best regards,

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev