For any interested, I did a quick fork and change and put in the following
pull request:
https://github.com/kamailio/kamailio/pull/297
I basically just added a new probing mode (3), DS_PROBE_ONLYFLAGGED, which
doesn't reset the probing state. This covers my use case, in that I can
set probing on the gateways that I want to monitor and the probing state
never goes away regardless of up/down status.
Working in my environment..
--
*Joseph Dickson*
Director of IT Systems, Evolve Tele-Services, Inc.
O: 517-332-1019
E: jdickson(a)evolvetsi.com
NOTE: This email message and any attachments are for the sole use of the
intended recipient(s) and may contain confidential and/or privileged
information. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the
sender by replying to this email, and destroy all copies of the original
message.
On Thu, Aug 20, 2015 at 10:30 AM, Joseph Dickson <jdickson(a)evolvetsi.com>
wrote:
Hugh,
Yes, I think you have it exactly.. That's one of the solutions I had
thought of - essentially a new probing_mode where the probing flag is never
cleared on any entry that has the probing flag. The only concern that I
had was that I hadn't dug into the code far enough to figure out what will
prevent a low ping_interval from sending a second probe packet to a gateway
before a response to the first has been received/timed out..
It could also be done with a new set of flags, assuming that not all of
the flags bits are cleared.. one flag that indicates never_probe and one
flag that indicates always_probe, perhaps. This way you could control
which gateways NOT to probe if you used DS_PROBE_ALL, or you could control
which gateways to probe if you used any of the other modes.. though since
the flags are really treated as mutable state once loaded, care would have
to be taken to make sure that the new flags aren't emptied anywhere else in
the code..
--
*Joseph Dickson*
E: jdickson(a)evolvetsi.com
On Thu, Aug 20, 2015 at 4:38 AM, Waite, Hugh <hugh.waite(a)acision.com>
wrote:
> Hello,
>
> This is something I have been thinking about recently as well.
>
>
>
> The current implementation can read flags from the DB (or file etc) but
> the probing flag is only a status and is cleared/set depending on the
> probing_mode, so the value stored in the DB is basically ignored after the
> first probe.
>
> I was going to suggest a new mode, e.g. “probe_if_set” which allows each
> destination to indicate whether it wishes to probe.
>
> Then you can have a set of entries which are all active but do not probe,
> another set which probe all the time and another set that only probe when
> they are inactive. Entries could still be administratively disabled to take
> them out of service.
>
>
>
> Does this sound like what you need Joseph?
>
>
>
> Regards,
>
> Hugh
>
>
>