Hello,

On 20/08/15 10:38, Waite, Hugh 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.

is this going to be a flag or a new value for ds_probing_mode? Not clear for me yet what you thought of.

I was thinking of a new flag, but it might be for "skip-probing", if that makes it easier to keep it compatible with current values -- haven't really analyzed the impact and which type (do-probing/skip-probing) is better.

Cheers, Daniel

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

*From:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Daniel-Constantin Mierla *Sent:* 20 August 2015 08:57 *To:* Kamailio (SER) - Users Mailing List *Subject:* Re: [SR-Users] dispatcher gateway probing in 4.3

Hello,

if no combination of probing_mode (http://kamailio.org/docs/modules/stable/modules/dispatcher.html#dispatcher.p...) and probing flags (http://kamailio.org/docs/modules/stable/modules/dispatcher.html#idp1992504) is not suitable for what you need, then this use case need to be added.

Cheers, Daniel

On 19/08/15 23:11, Joseph Dickson wrote:

Greetings..



I'm fairly new to Kamailio, and am having fun so far...  I'm using
the latest 4.3 rpm version on Centos 7.



I'm using Kamailio to front end a pair of FreeSwitch SBC boxes in
an active/active config..  My plan is to use dispatcher to load
balance calls between them.  This is working fine.. the problem
that I'm bumping into is that the gateway probing options in
dispatcher seem not to fit my use case..



In addition to the two SBC gateways, I also have a few external
gateways that I want to load balance between also using
dispatcher.  The problem is that I can't send options packets to
these gateways -- they don't respond to them.  This means I can't
just configure dispatcher to probe all gateways (probing_method=1)
because it will mark these gateways as inactive..



It looks like every other configuration of probing_method only
probes a gateway until the state is determined, and then it stops
probing.  probing_method=2 does not appear to be used at all in
the code..



Am I doing this wrong?  Or is this just an area of dispatcher that
needs some improvement?  Looking at the code, I can probably add
the functionality that I need, but I don't want to go that route
if I'm just missing how this is usually done..



Thanks,



--

/*Joseph Dickson*/

E: jdickson@evolvetsi.com <mailto:jdickson@evolvetsi.com>






_______________________________________________

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list

sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla http://twitter.com/#!/miconda http://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com

---

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

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@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@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@evolvetsi.com

On Thu, Aug 20, 2015 at 4:38 AM, Waite, Hugh hugh.waite@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