[SR-Users] Re: SL absorbed ACK is counted as dropped by core.drop_requests

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 &lt;miconda(a)gmail.com&gt; Sent: Monday, July 3, 2023 9:24 AM To: Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt;rg>; Kaufman &lt;bkaufman(a)bcmone.com&gt; 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/>