Situation tested in our Lab to find how clients handle such situations.
;; QUESTION SECTION:
;_sip._udp.dev-cpereg.devtel.imp.ch. IN SRV
;; ANSWER SECTION:
_sip._udp.dev-cpereg.devtel.imp.ch. 299 IN SRV 0 0 5060 dev-sbc01.devtel.imp.ch.
_sip._udp.dev-cpereg.devtel.imp.ch. 299 IN SRV 0 0 5060 dev-sbc02.devtel.imp.ch.
So when using the hostname “dev-cpereg.devtel.imp.ch” as endpoint and registrar, asterisk does perform SRV lookups and uses either of those two SBC for communication.
So for testing, one SBC is unreachable.
Adding qualify_frequency=60 I would have expected Asterisk to detect the one which is down and only use the reachable SBC.
Unfortunately I observer the contrary. Asterisk seems to randomly send OPTIONS to either of the two and is getting into a reachable / unreachable flapping situation for both, registrations AND outbound calls.
Have I missed some config options?
Even if the host being down is sending back icmp port unrechable, this does not cause asterisk to immediately use the other IP address when using UDP.
Using TCP/TLS seems to solve that issue (due to the working connection staying open I guess).
You have the priority and weight the same for both records. You’re basically balancing them equally so each time an SRV lookup is performed, you’ll get the result you’re getting. You need to change this so the priority is 0 for one and perhaps 5 for the other which will make priority 0 be used first and if its down/not responding it will use the next priority.
So you need something like this: Note that 0 is the highest priority for SRV.
_sip._udp.dev-cpereg.devtel.imp.ch. 299 IN SRV 0 0 5060 dev-sbc01.devtel.imp.ch.
_sip._udp.dev-cpereg.devtel.imp.ch. 299 IN SRV 5 0 5060 dev-sbc02.devtel.imp.ch.
Thank you, but in ‘normal’ operation, I would like to equally balance the traffic when both are up. If I prioritize one of them, it will get all traffic, right?