Thanks, I will!
the t_on_reply("PROBE_REPLY") works when probing gets replied, but the
t_on_failure("PROBE_FAILURE") is not available, so it is no use at
all....(I was testing it, but no luck)
dispatcher:dst-up and dispatcher:dst-down are only available when there is
a transaction that detects a state transition (from UP to DOWN and
vice-versa), so if kamailio starts and the endpoint is already on state
DOWN, and probe fails while there is no transaction it will not call event
dispatcher:dst-down which is an issue as the goal is to call EVAPI script
with confirmation of the endpoint's status.... switching to flags=2 (start
Active) should fix both events BUT it seems dispatcher is ignoring flags=2.
any solution is welcome.
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
*www.kahea.ai <http://www.kahea.ai> / www.voip.pt <http://www.voip.pt>*
*OpenTelecom* - Consulting for Telecoms, Lda
Tel.: +351 <callto:+351+91+104+12+66>91 631 11 44
Email : *[email protected] <[email protected]>*
This message and any files or documents attached are strictly confidential
or otherwise legally protected.
It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.
On Wed, Mar 11, 2026 at 4:18 PM Henning Westerholt <[email protected]> wrote:
> Hello,
>
>
>
> try to set ds_timer_mode to 1 to use a dedicated timer for that many
> destinations and really short probing frequency.
>
>
>
> If you are using ds_probing_mode 1 it should continue to probe even when
> there is a failure.
>
>
>
> I don’t fully understand the reason behind using the tm event routes for
> this job. There are dispatcher event routes, and you can just query the
> dispatcher destination UP/DOWN status in the script as well with
> ds_is_active.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* Sergio Charrua via sr-users <[email protected]>
> *Sent:* Mittwoch, 11. März 2026 13:55
> *To:* Kamailio (SER) - Users Mailing List <[email protected]>
> *Cc:* Sergio Charrua <[email protected]>
> *Subject:* [SR-Users] Dispatcher Probing issues
>
>
>
> Hi all,
>
> I'm having issues to get the dispatcher probing settings right.
> the requirements are:
> - when Kamailio starts, it needs to probe all endpoints to check
> availablility (nearly 5000 endpoints, in total) by probing each one of
> them, sending SIP OPTIONS every ds_ping_interval=5
> - when receiving a valid reply (ds_ping_reply_codes set toclass=2), and
> after ds_inactive_threshold=2, Kamailio should send an EVAPI message to
> inform endpoint is UP
> - htable gw_last is reset with key=IP:PORT of endpoint, value = timestamp)
> - htable gw_probe is reset with key=IP:PORT of endpoint, value = 0 (NOT
> PROBING)
>
> - when receiving an invalid reply or timeout, and after
> ds_probing_threshold=3, Kamailio should send an EVAPI message to inform
> endpoint is DOWN
> - htable gw_last is reset (key=IP:PORT of endpoint , value = $null) and
> htable gw_probe reset with key=IP:PORT value = 1 (PROBING)
>
> - an htable gw_last with autoexpire=60s will launch a probe to the
> endpoint set in the key of gw_last (key=IP:PORT , value = timestamp).
> Once probing, it should send an EVAPI message with the endpoint's status
> (UP or DOWN) respecting the ds_inactive_threshold and ds_probing_threshold
> parameters.
> - and htable gw_probe with key=IP:PORT is updated to 1
> - probing is started by updating dispatcher's endpoint status using:
> jsonrpc_exec('{"jsonrpc":"2.0","method":"dispatcher.set_state", "params" :
> ["ip", 1, "' + $var(endpointIPPort) + '" ] }');
>
> - I have events like dispatcher:dst-up and dispatcher:dst-down, where it
> resets gw_last and sets gw_probe to respective values, depending on probing
> response.
>
> My issues:
> - Kamailio is starting with all endpoints set as FLAGS=IP and starts
> probing all endpoints
> - if endpoint fails replying to SIP Options, because it is offline, and
> there is a TIMEOUT, it will be set with FLAGS=IX *AND* Probing stops
> without any instructions from my script; AND dispatcher:dst-down is never
> called
> - if endpoint replies OK to SIP Options, dispatcher:dst-up is not called
> neither so I cannot reset gw_probe and gw_last values.
> - I have event_route[tm:local-request] who detects the sending of the SIP
> OPTIONS and implements t_on_reply("PROBE_REPLY") and
> t_on_failure("PROBE_FAILURE").
> if SIP Options receives a reply, endpoint is UP, t_on_reply("PROBE_REPLY")
> is launched as expected; if SIP Options fails,
> t_on_failure("PROBE_FAILURE") is not called.
> - when the gw_last expires (every 60s) and starts Probing the endpoint, it
> is never on 60s but always after 70s of last probe period, and in time it
> increases up to 85s. Why??
> - SIP OPTIONS retransmissions are indeed correct: 0.5s + 1s + 2s + 4s then
> timeout (as per TM fr_timer=10000 setting)
>
>
>
> Questions:
>
> - what dispatcher settings should I use to achieve my goal? I have been
> playing with ds_probing_mode and with dispatcher's list FLAGS value, but no
> results so far....
>
> - any solution?
>
> NOTES:
> - dispatcher is only used for probing, not failover or call distribution
>
> Current Dispatcher definitions:
> modparam("dispatcher", "db_url",
> "cluster://k1")
> modparam("dispatcher", "ds_ping_interval", 5)
>
> modparam("dispatcher", "ds_ping_method", "OPTIONS")
>
> modparam("dispatcher", "ds_ping_from", "
> sip:[email protected]")
> modparam("dispatcher", "ds_probing_threshold", 3)
> modparam("dispatcher", "ds_inactive_threshold", 2)
>
> modparam("dispatcher", "ds_ping_latency_stats", 1)
> modparam("dispatcher", "ds_probing_mode", 0)
>
> modparam("dispatcher", "ds_latency_estimator_alpha", 200)
>
> modparam("dispatcher", "reload_delta", 0)
>
> modparam("dispatcher", "flags", 0)
>
> modparam("dispatcher", "ds_ping_reply_codes", "class=2")
>
> modparam("dispatcher", "xavp_dst",
> "DISPATCHER_DST")
> modparam("dispatcher", "ds_timer_mode", 0)
>
> Current TM definitions:
> modparam("tm", "auto_inv_100", 1)
> modparam("tm", "failure_reply_mode", 3)
> modparam("tm", "fr_timer", 10000)
> modparam("tm", "fr_inv_timer", 120000
> modparam("tm", "max_inv_lifetime", 180000
> modparam("tm", "max_noninv_lifetime", 32000)
> modparam("tm", "retr_timer1", 500)
> modparam("tm", "retr_timer2", 4000)
> modparam("tm", "wt_timer", 5000)
> modparam("tm", "cancel_b_method", 2)
>
> Current Dispatcher list:
>
> +----+-------+--------------------+-------+----------+----------------+-------------+
> | id | setid | destination | flags | priority | attrs |
> description |
>
> +----+-------+--------------------+-------+----------+----------------+-------------+
> | 4 | 1 | sip:10.20.0.6:5060 | 9 | 1 | cc=1;duid=sbc1 |
> |
>
> +----+-------+--------------------+-------+----------+----------------+-------------+
>
> Atenciosamente / Kind Regards / Cordialement / Un saludo,
>
>
>
> *Sérgio Charrua*
>
> *www.kahea.ai <http://www.kahea.ai> / www.voip.pt <http://www.voip.pt>*
>
> *OpenTelecom* - Consulting for Telecoms, Lda
> Tel.: +351 <callto:+351+91+104+12+66>91 631 11 44
>
> Email : *[email protected] <[email protected]>*
>
> This message and any files or documents attached are strictly confidential
> or otherwise legally protected.
>
> It is intended only for the individual or entity named. If you are not the
> named addressee or have received this email in error, please inform the
> sender immediately, delete it from your system and do not copy or disclose
> it or its contents or use it for any purpose. Please also note that
> transmission cannot be guaranteed to be secure or error-free.
>
>
>
>
>
>
>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
[email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
