[SR-Users] Failover with SRV records

[marius zbihlei]

On 11/29/2010 06:03 AM, Eric Hiller wrote:
> Sorry all for the second question of the night as I go through working 
> out bugs in my setup. I want to use SRV records to loadbalance across 
> hosts. This works great, when all the hosts listed in the SRV are up. 
> However, I want kamailio to use the next host if the current hosts 
> fails. I tried just setting up a new branch, but kamailio keeps using 
> the same SRV entry over and over on that transaction, only a new 
> transaction seems to give kamailio a chance to use a different SRV 
> entry. Any ideas as to how I can force kamailio to try the next SRV 
> entry if the first one fails?
>
> For example I t_relay to 2.domain.com which has a 
> _sip._udp.2.domain.com entry for hostA and hostB. If hostB is down, 
> but kamialio decides to send to hostB it just keeps doing so even 
> though hostA is perfectly up it doesn't try for it. Is there a way to 
> remove hostB from the kamailio try list? Or as an alternative to do a 
> manual SRV lookup on 2.domain.com and then put then in a variable and 
> go through them one by one manually?
>
> Ideas? Thanks
> -Eric
Hello,

Kamailio does not use ICMP replies to check if a host is reachable on a 
UDP sendto(). This means that ICMP port unreachable errors are not 
handled by K and so the same host is retried on TM retransmits. Host 
selection of both A records and SRV records is done based on weights 
returned from the DNS query(so it is balanced)

For a INVITE you can use  fr_timer to very low values (5 seconds) and 
fr_inv_timer to larger value. If no 100 is received than the fr_timer 
kicks in and depending on the disable_dns_failover core parameter 
another host is tried. The order of retry is this: Regardless of 
disable_dns_failover param, other A records are tried (if no 0x4 flag is 
given to t_relay (at least in K1.5)), then , is dns_failover is active, 
other SRV records, then NAPTR.

Check the TM documentation for more info.

Marius

P.S. This is on K 1.5 . I hope 3.0/3.1 still has this . I think dns 
caching has changed so you need to recheck the parameters I gave.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20101129/b487ed02/attachment.htm>