Hi,

would there be anybody we could pay to make the suggested change? We at sipgate support projects like Kamailio and could sponsor such a fix.

Thanks Christian

Am 21.10.24 um 10:44 schrieb Stefan Mititelu:

Hi,

Yes this is how currently rtpengine module re-detect rtpengines: during SIP routing processing. (e.g. rtpengine_manage())

Yes, lowering "rtpengine_tout_ms" will make rtpp_test() C code function take shorter time => rtpengine_manage() will take shorter time.

Also disabling "aggressive_redetection" modparam helps alot in case when no rtpengines available at all. Thus, redetection of unavailable rtpengine nodes is tried only when their time comes, based on "rtpengine_disable_tout" modparam. Right now, if no rtpengines available at all, and aggressive redetection is enabled(by default), redetection happens for each new SIP message, independent of "rtpengine_disable_tout" modparam. So delays SIP routing alot. (PR: https://github.com/kamailio/kamailio/pull/3992)

This way of detecting rtpengine has, of course, both pros and cons.

I've been thinking of adding another behavior of this node re-detection in code, guarded via new modparam: expose an rtpengine_ping() config function and call it from rtimer. And rtpengine_manage() function will just check if any nodes available, but not ping them anymore. => not sure how much time have for it though.

Thanks, Stefan

On 10/21/24 11:16, Christian Berger via sr-dev wrote:

...

Hi,

we had strange behavior with kamailio when some rtpengines were unreachable, so we looked into the the source code and found this in select_rtpp_node_new():

3323 /* Try to enable if it's time to try. */ 3324 if(node->rn_disabled && node->rn_recheck_ticks <= get_ticks()) { 3325     node->rn_disabled = rtpp_test(node, 1, 0); 3326 }

Does this mean that a ping will be done during rtpengine manage? Is this wise? I mean there are dedicated pings in the background. Doing this in rtpengine manage will only periodically delay the processing of a SIP message. We fear that in high traffic situations this could occupy all threads. Is this a bug?

As a workaround we think setting rtpengine_tout_ms to a lower value might help as it shortens the amount of time the module delays the processing of the SIP message.

What do you think?

Best wishes   Christian Berger

Sounds good.

Thank you, Stefan

On 10/28/24 11:28, Henning Westerholt via sr-dev wrote:

Hello Stefan,

we will look into adding a timer-based approach of detecting offline rtpengine servers.

Cheers,

Henning

...

-----Original Message----- From: Stefan Mititelu via sr-dev sr-dev@lists.kamailio.org Sent: Montag, 21. Oktober 2024 10:44 To: Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org Cc: Christian Berger berger@sipgate.de; Stefan Mititelu stefan.mititelu@govoip.ro Subject: [sr-dev] Re: rtpengine module: Question about re-enabling nodes

Hi,

Yes this is how currently rtpengine module re-detect rtpengines: during SIP routing processing. (e.g. rtpengine_manage())

Yes, lowering "rtpengine_tout_ms" will make rtpp_test() C code function take shorter time => rtpengine_manage() will take shorter time.

Also disabling "aggressive_redetection" modparam helps alot in case when no rtpengines available at all. Thus, redetection of unavailable rtpengine nodes is tried only when their time comes, based on "rtpengine_disable_tout" modparam. Right now, if no rtpengines available at all, and aggressive redetection is enabled(by default), redetection happens for each new SIP message, independent of "rtpengine_disable_tout" modparam. So delays SIP routing alot. (PR: https://github.com/kamailio/kamailio/pull/3992)

This way of detecting rtpengine has, of course, both pros and cons.

I've been thinking of adding another behavior of this node re-detection in code, guarded via new modparam: expose an rtpengine_ping() config function and call it from rtimer. And rtpengine_manage() function will just check if any nodes available, but not ping them anymore. => not sure how much time have for it though.

Thanks, Stefan

On 10/21/24 11:16, Christian Berger via sr-dev wrote:

...

Hi,

we had strange behavior with kamailio when some rtpengines were unreachable, so we looked into the the source code and found this in select_rtpp_node_new():

3323 /* Try to enable if it's time to try. */ 3324 if(node->rn_disabled && node->rn_recheck_ticks <= get_ticks()) { 3325     node->rn_disabled = rtpp_test(node, 1, 0); 3326 }

Does this mean that a ping will be done during rtpengine manage? Is this wise? I mean there are dedicated pings in the background. Doing this in rtpengine manage will only periodically delay the processing of a SIP message. We fear that in high traffic situations this could occupy all threads. Is this a bug?

As a workaround we think setting rtpengine_tout_ms to a lower value might help as it shortens the amount of time the module delays the processing of the SIP message.

What do you think?

Best wishes   Christian Berger

---

Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr- dev-leave@lists.kamailio.org

---

Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-leave@lists.kamailio.org