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
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 miconda@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-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-
Daniel-Constantin Mierla -
Henning Westerholt