<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [X] Commit message has the format required by CONTRIBUTING guide
- [X] Commits are split per component (core, individual modules, libs, utils, ...)
- [X] Each component has a single commit (if not, squash them into one commit)
- [X] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [X] 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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [ ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
The documentation shows a wrong example for the modparam "method_filter".
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3505
-- Commit Summary --
* xlog: fix docs example for modparam methods_filter
-- File Changes --
M src/modules/xlog/doc/xlog_admin.xml (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3505.patchhttps://github.com/kamailio/kamailio/pull/3505.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3505
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3505(a)github.com>
(adding sr-dev)
Hello,
I only had a quick look to the code, but at least the sl module stats seems to look fine:
int sl_filter_ACK(struct sip_msg *msg, unsigned int flags, void *bar)
[...]
if(memcmp(tag_str->s, sl_tag.s, sl_tag.len) == 0) {
LM_DBG("SL local ACK found -> dropping it!\n");
update_sl_filtered_acks();
void update_sl_filtered_acks(void)
{
(*sl_stats)[process_no].filtered_acks++;
}
unsigned long sl_stats_rcv_acks(void)
{
sl_stats_update();
return _sl_stats_total.filtered_acks;
}
Are you not seeing the increase in the received_ACKs statistics?
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>
From: Kaufman <bkaufman(a)bcmone.com>
Sent: Mittwoch, 28. Juni 2023 01:52
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] SL absorbed ACK is counted as dropped by core.drop_requests
Just checking to see if this is the designed behavior. The SL module will attempt to match ACKs for stateless replies and handle them (absorb them?).
The question I have is that it looks as though this ACK gets counted as dropped by the core.drop_requests from the KEX module. Tested using this config:
#!KAMAILIO
loadmodule "pv"
loadmodule "sl"
loadmodule "xlog"
loadmodule "kex"
loadmodule "corex"
loadmodule "ctl"
modparam("sl", "bind_tm", 0)
route {
xinfo("[$ci] $rm Request. Src:[$si:$sp] RURI:[$ru] To:[$tu] From:[$fu]\n");
sl_send_reply("404", "Not Found");
}
event_route[sl:filtered-ack] {
xnotice("sl:filtered-ack ACK [$ci] to local reply absorbed\n");
}
Then validate by kamcmd stats.fetch core:drop_requests
Is this the designed and "correct" behavior?
Kaufman