27 Jun
2023
27 Jun
'23
7:51 p.m.
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
3 Jul
3 Jul
5:12 a.m.
(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
9:51 a.m.
Just following up on this; Should an ACK absorbed by the SL module get counted as a
dropped request?
Kaufman
From: Kaufman <bkaufman(a)bcmone.com>
Sent: Tuesday, June 27, 2023 6:52 PM
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
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
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
10:23 a.m.
Hello,
this is a design limitation of the internal callbacks for pre-config
processing, where "selected" modules can get the request before config
is executed and they can return back if the processing of the request
should continue or not. This mechanism is used by sl module to detect
the ACKs and in such cases it returns "do not process the request
further" and the core stats count it as dropped request.
I expect that this behaviour is there more or less from the beginning of
core:drop_requests, but I also get the point of view that is not really
the case of dropping the request because of error, it is just processing
as it is supposed to be.
Now, as with every "un/expected" behaviour that is there for very very
long time, it is the question about what people consider to be the right
way to move on: keep it as it is (eventually with better docs about it)
because it is what people got use to (and expect to have) or simply
change it ... plus the variant to make a param to control it :-) ...
Cheers,
Daniel
On 03.07.23 15:51, Kaufman wrote:
Just following up on this; Should an ACK absorbed by the SL module
get counted as a dropped request?
*Kaufman*
*From:*Kaufman <bkaufman(a)bcmone.com>
*Sent:* Tuesday, June 27, 2023 6:52 PM
*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*
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - www.kamailioworld.com
11:37 a.m.
Daniel,
Thank you. That answers the question. Knowing this, I can just get the difference between
the dropped and absorbed counter and go with that to get the number of "dropped, but
not dropped by SL ACK handling" count.
Kaufman
Sr. VoIP Engineer - BCM One
+1.612.735.9309
bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
24 hour client support: +1.855.639.6300
From: Daniel-Constantin Mierla <miconda(a)gmail.com>
Sent: Monday, July 3, 2023 9:24 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Kaufman
<bkaufman(a)bcmone.com>
Subject: Re: [SR-Users] Re: SL absorbed ACK is counted as dropped by core.drop_requests
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello,
this is a design limitation of the internal callbacks for pre-config processing, where
"selected" modules can get the request before config is executed and they can
return back if the processing of the request should continue or not. This mechanism is
used by sl module to detect the ACKs and in such cases it returns "do not process the
request further" and the core stats count it as dropped request.
I expect that this behaviour is there more or less from the beginning of
core:drop_requests, but I also get the point of view that is not really the case of
dropping the request because of error, it is just processing as it is supposed to be.
Now, as with every "un/expected" behaviour that is there for very very long
time, it is the question about what people consider to be the right way to move on: keep
it as it is (eventually with better docs about it) because it is what people got use to
(and expect to have) or simply change it ... plus the variant to make a param to control
it :-) ...
Cheers,
Daniel
On 03.07.23 15:51, Kaufman wrote:
Just following up on this; Should an ACK absorbed by the SL module get counted as a
dropped request?
Kaufman
From: Kaufman <bkaufman@bcmone.com><mailto:bkaufman@bcmone.com>
Sent: Tuesday, June 27, 2023 6:52 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org><mailto:sr-users@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
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com/>
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio World Conference - www.kamailioworld.com<http://www.kamailioworld.com/>
327
days inactive
333
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Kaufman