Hello, for the records, the master branch has no new cofiguration option to control better when the event route is executed. Still not possible for the rpc command, because it has a different code path, but for the case of keepalive based detection or config marking of detination.
Also, the use of the function to mark the destination inactive has immediate effect, no longer counting failed attempts like with the keepalive. There was also some issue in matching the destination on keepalive responses, the code was refactored to clone the target address as well as get access to it via the existing module variable class. Previous version just linking the internal r-uri field of the faked request, could fail in some cases. Because of the code changes, I backported code as in master and then removed the exports of the new functions/parameters, so the 6.0 works fine, but without the new feature of controlling the execution of the event route. Cheers, Daniel On Tue, Jul 8, 2025 at 4:52 PM Henning Westerholt <h...@gilawa.com> wrote: > Hello Daniel, > > regarding 1) - I think common practise is to execute a state change > immediately if done from an administrator by RPC or configuration functions > and don't wait for the probing threshold/interval. This is e.g. how haproxy > is doing it, and also other modules, like carrierroute (which don't support > probing intervals, to be fair). > > About 2) - I think executing the event routes also for RPC and > configuration functions changes would be more consistent. In the end the > destination becomes available or gets disabled, and the consumer in the cfg > don't care why. > > Cheers, > > Henning > > -----Original Message----- > From: Daniel-Constantin Mierla via sr-dev <sr-dev@lists.kamailio.org> > Sent: Tuesday, June 24, 2025 3:48 PM > To: Kamailio (SER) - Development Mailing List <sr-dev@lists.kamailio.org> > Cc: Daniel-Constantin Mierla <mico...@gmail.com> > Subject: [sr-dev] Dispatcher coherence: marking destinations and running > event routes > > Hello, > > there is (still) some incoherence in dispatcher module regarding the > marking of a destination (e.g., to inactive state) and execution of event > route. > > First, which I tried to address earlier today, was that ds_mark_dst() was > taking in consideration the value of ds_probing_threshold, which was > intended for keepalives, so the use of the function was not having any > effect (as documented) till it was used so many times as the parameter > value, probably not noticed so far because the default value for the > parameter is 1. Similar would be for setting destination active and the > value of ds_inactive_threshold. > > Going on the same execution path as with setting the state of a > destination based on keepalives, the use of ds_mark_dst() results in > running the event routes, which I am not sure it is really expected. But > then, setting the state of a destination via RPC is not running event > routes and it was done immediately via reinitialising the state, without > any relation to ds_probing_threshold or ds_inactive_threshold. > > So the questions would be: > > 1) the documented way is the expected one on admin-instructed state update > (via config functions or rpc), respectively do it immediately, without > considering ds_probing_threshold or ds_inactive_threshold? It is like now > in git master branch, but for many years the config functions took in > consideration the parameters. > > 2) shall event routes be executed only on SIP keepalives, or also on > admin-instructed state update (via config functions or rpc)? Or leave it > only for keepalives and config functions, like it is now, with updating > documentation to be clear. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla (@ asipto.com) > twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, > Training and Development Services -- asipto.com > > _______________________________________________ > Kamailio - Development Mailing List -- sr-dev@lists.kamailio.org To > unsubscribe send an email to sr-dev-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > -- Daniel-Constantin Mierla - https://www.asipto.com - Kamailio Consultancy And Training Services - https://twitter.com/miconda - https://www.linkedin.com/in/miconda
_______________________________________________ Kamailio - Development Mailing List -- sr-dev@lists.kamailio.org To unsubscribe send an email to sr-dev-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
