Hello Sebastian,
actually, it’s the fault is by the provider, that they do not manage their DNS records properly. It makes no sense to return non-working systems in the end, but some of them do not care.
I would probably just use the dst_blocklist functionality, probably with a shorter internal TTL.
Regarding the peers that are having only one server which fails, I would just route to another provider in this case, if they can not bother to fix it or to provide redundancy.
You could also implement a script that fetches periodically the SRV record, create a dispatcher cfg from it and then uses dispatcher. You could use active OPTIONS ping probing, or also
manually deactivate the failed hosts for the time period.
Cheers,
Henning
From: Sebastian Damm <sdamm@pascom.net>
Sent: Thursday, December 15, 2022 7:29 AM
To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
Subject: [SR-Users] Dealing with failed SRV peers
Hi,
we have some Kamailios working as outboundproxy. So they get requests from internal systems and send them to different providers. From time to time,
one provider returns a server as primary resource which is currently unavailable.
I guess if the internal systems connected directly to the target, they would remember the failed server and remember to always use the server with second
priority at least until DNS refresh time. In our setup, since every request is "new" for Kamailio, it doesn't remember, which host is reachable or not.
Example:
target: example.com
_sip._udp.example.com SRV resolves to:
10 192.0.2.42 5060
20 198.51.100.42
5060
30 203.0.113.42
5060
192.0.2.42 is unavailable. Still, Kamailio uses it for every new request and failover to 198.51.100.42
occurs only after timeouts hit.
Is there a best practice for solving this? I have played around with the dst_blocklist settings, but that
caused even more trouble because Kamailio started blocking requests to peers that have only one server in the record having a short hickup.
Thanks in advance for every input, as this is causing trouble every time we run into such a situation.
Regards,
Sebastian