Hi
We have reached 20000 registered CPE and start facing issues.
Am I observing correctly that when ka_mode 4 is enabled, OPTIONS are send simultaneously to all registered CPE and not spread over the interval?
They could be the cause very high pps peaks on network equipment?
If so, is there a way to spread the ka options over time so they don't cause such high peaks?
Or even better, is there a way to enable them for only some customers via a variable?
Mit freundlichen Grüssen
-Benoît Panizzon-
Perhaps it is helpful to ask a more basic question: why are you using server-side keepalives?
On 11 Dec 2023, at 12:56, Benoit Panizzon via sr-users sr-users@lists.kamailio.org wrote:
Hi
We have reached 20000 registered CPE and start facing issues.
Am I observing correctly that when ka_mode 4 is enabled, OPTIONS are send simultaneously to all registered CPE and not spread over the interval?
They could be the cause very high pps peaks on network equipment?
If so, is there a way to spread the ka options over time so they don't cause such high peaks?
Or even better, is there a way to enable them for only some customers via a variable?
Mit freundlichen Grüssen
-Benoît Panizzon-
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi Alex
Perhaps it is helpful to ask a more basic question: why are you using server-side keepalives?
Because of a *stupid* cloud hosted PBX vendor solution.
That vendor is hosting his PBX behind a NAT without SIP ALG.
NAT UDP Timeout 90 seconds!
That vendor refused to send any kind of keep-alive from his cloud PBX instances. Her refuses to increase UDP keep alive. He considers keeping the UDP session alive to be the task of the 'registrar'.
Apparently, all SIP provider in Switzerland send UDP keep alives once per minute to all their customers, as we were the only one, where NAT kept timing out rendering the cloud PBX instance behind NAT unreachable.
So I enabled this to make our 3 customers on that cloud platform happy.
Mit freundlichen Grüssen
-Benoît Panizzon-
:-) Why not just have frequent re-registration intervals?
On 11 Dec 2023, at 13:33, Benoit Panizzon benoit.panizzon@imp.ch wrote:
Hi Alex
Perhaps it is helpful to ask a more basic question: why are you using server-side keepalives?
Because of a *stupid* cloud hosted PBX vendor solution.
That vendor is hosting his PBX behind a NAT without SIP ALG.
NAT UDP Timeout 90 seconds!
That vendor refused to send any kind of keep-alive from his cloud PBX instances. Her refuses to increase UDP keep alive. He considers keeping the UDP session alive to be the task of the 'registrar'.
Apparently, all SIP provider in Switzerland send UDP keep alives once per minute to all their customers, as we were the only one, where NAT kept timing out rendering the cloud PBX instance behind NAT unreachable.
So I enabled this to make our 3 customers on that cloud platform happy.
Mit freundlichen Grüssen
-Benoît Panizzon-
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________
That's a good question. In our scenario, we primarily leverage this option for monitoring purposes. We measure the round-trip time for each endpoint and then populating our time series DB with this data and displaying it in Grafana. We found this method as the most reliable way to obtain accurate network information for each endpoint. Our support team finds it incredibly useful and incorporates it into their daily routines. Although it does add some additional load on our SBC, so far, we haven't encountered any issues due to this. Furthermore, as part of our horizontal scaling strategy, in the event that one server becomes overloaded with traffic, we seamlessly redistribute a subset of customers to another server. However, we are considering relocating this function away from the main SBC. As this feature is not very critical I would be more than happy to move it to a dedicated server with lower priority. I'm curious about your approach to handling this. How do you guys manage a similar setup, and what solutions would you recommend to achieve comparable results?
Thank you.
On Mon, 11 Dec 2023 at 18:42, Alex Balashov via sr-users < sr-users@lists.kamailio.org> wrote:
Perhaps it is helpful to ask a more basic question: why are you using server-side keepalives?
On 11 Dec 2023, at 12:56, Benoit Panizzon via sr-users <
sr-users@lists.kamailio.org> wrote:
Hi
We have reached 20000 registered CPE and start facing issues.
Am I observing correctly that when ka_mode 4 is enabled, OPTIONS are send simultaneously to all registered CPE and not spread over the interval?
They could be the cause very high pps peaks on network equipment?
If so, is there a way to spread the ka options over time so they don't cause such high peaks?
Or even better, is there a way to enable them for only some customers via a variable?
Mit freundlichen Grüssen
-Benoît Panizzon-
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
On 11.12.23 18:56, Benoit Panizzon via sr-users wrote:
Hi
We have reached 20000 registered CPE and start facing issues.
Am I observing correctly that when ka_mode 4 is enabled, OPTIONS are send simultaneously to all registered CPE and not spread over the interval?
They could be the cause very high pps peaks on network equipment?
If so, is there a way to spread the ka options over time so they don't cause such high peaks?
Or even better, is there a way to enable them for only some customers via a variable?
there is a modparam ka_mode to tune a bit where to send the keep-alives, one is done by matching a branch flag used for marking natted devices. If that is not enough because one wants to differentiate between natted endpoints and those that have to get keepalove, then, being open source, one can add support for another ka_mode where a different branch flag can be used to select what contacts should get keepalive.
Cheers, Daniel
-
Alex Balashov -
Benoit Panizzon -
Daniel-Constantin Mierla -
Ilie Soltanici