[SR-Users] ACK and DNS failover

[Daniel-Constantin Mierla]

Hello,

well, the ACK is a request without a response, practically it is a
stateless request, no sip transaction can be created for it because
there is no response to wait for it. That's by design from SIP specs.

In other words, it is no way to know if the target received or not the
ACK. If the ACK is not received, the target is supposed to retransmit
the 200ok, to force retransmission of the ACK.

In the case of tcp/tls, one can leverage transport layer to know that it
could not be transmitted, but for udp is no way, and even more, in sip
transport layer is decoupled from sip singling layer (ie., same
connection can carry traffic for many users, many transactions, etc...).
Also, for tcp/tls, with asynchronous sending, the feedback of not able
to send is not immediate. But can be coded somehow, it's about open
source after all ...

Moreover, ACK does not belong to INVITE transaction and can have a
different path than the INVITE, being a matter of record-route headers.

So lack (or limitations) of DNS failover for ACK comes from the above.

You can either consider this a corner case, if the target servers are
supposed to run always and in case of one becoming unavailable for long
time, the dns is updated accordingly, or, if you know that ACK has to be
sent to the address where 200ok came from, then you can store that in
htable and use it for sending out the ACK (but again, this may not be
the case always according to the specs, but can be in your deployment).

Cheers,
Daniel

On 23.02.22 15:59, Julien Klingenmeyer wrote:
>
> Hello,
>
>  
>
> I use DNS failover feature for routing some calls, and I wonder about
> its limitations.
>
> I noticed that INVITE and ReINVITE requests are correctly routed based
> on SRV priority/weight in case of failure, but ACK requests do not use
> them.
>
>  
>
> Let’s say I have Kamailio A relaying requests to a pool of Kamailios
> B1 and B2 in TLS.
>
> DNS records are the below ones.
>
>  
>
> kamailiob.net.            60 NAPTR 20   100  S SIPS+D2T
> _sips._tcp.kamailiob.net.
>
> _sips._tcp.kamailiob.net.   60 SRV 1    10   5061      
> kamailiob-1.net.    
>
> _sips._tcp.kamailiob.net.   60 SRV 2    10   5061       kamailiob-2.net.
>
>  
>
> If B1 is down, I expect requests being relayed to B2 (because of
> priority 2 in the SRV record).
>
>   * For initial INVITEs: R-URI is sip:kamailiob.net
>       o If B1 is down, the request is retried to B2 => OK
>   * For in-dialog requests: Route header in incoming request is
>     sip:kamailiob.net so it is set as next destination with
>     /loose/_/route/ function
>       o If B1 is down, the request is retried to B2 for ReINVITE => OK
>       o But once the ACK comes in, with the same Route header
>         (sip:kamailiob.net), Kamailio tries to send it to B1 only (no
>         retries to B2, and even no retransmissions to B1 either).
>       o When B1 is back UP again a few seconds later, Kamailio does
>         not try to relay the ACK again. The ACK request is attempted
>         to be retransmitted only once to B1. It fails and no more
>         retries after that.
>
>  
>
> Is it the expected behavior? Or is it something misconfigured on
> Kamailio A? Or is it a TLS connection issue?
>
>  
>
> Here is the DNS configuration on Kamailio A (TM module is enabled):
>
> dns_try_naptr=yes
>
> use_dns_failover=yes
>
> use_dns_cache=yes
>
> dns_srv_lb=yes
>
>  
>
> enable_tls=yes
>
> tcp_max_connections=4096
>
> tls_max_connections=4096
>
> tcp_reuse_port=yes
>
> tcp_connect_timeout=10
>
> tcp_send_timeout=10
>
> tcp_connection_lifetime=3600
>
>  
>
> I had a look into the DNS tutorial
> (https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt)
> without finding any hint about this.
>
>  
>
> If anyone has already played with SIP DNS failover in Kamailio, your
> help would be appreciated, thanks!
>
>  
>
> Julien
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users at lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
  March 28-31, 2022 (Europe Timezone)
  * https://www.asipto.com/sw/kamailio-advanced-training-online/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220223/509cb8f0/attachment.htm>