<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>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.</p>
<p>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.</p>
<p>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 ...<br>
</p>
<p>Moreover, ACK does not belong to INVITE transaction and can have
a different path than the INVITE, being a matter of record-route
headers.</p>
<p>So lack (or limitations) of DNS failover for ACK comes from the
above.</p>
<p>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).</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 23.02.22 15:59, Julien Klingenmeyer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4220B0DE-EE1A-4822-B548-48B5EC2685B0@contoso.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:Courier;
panose-1:0 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style>
<div class="WordSection1">
<p class="MsoNormal">Hello,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">I use DNS failover
feature for routing some calls, and I wonder about its
limitations.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Let’s say I have
Kamailio A relaying requests to a pool of Kamailios B1 and
B2 in TLS.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">DNS records are the
below ones.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">kamailiob.net. 60 NAPTR 20 100 S
SIPS+D2T _sips._tcp.kamailiob.net.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">_sips._tcp.kamailiob.net. 60 SRV 1 10
5061 kamailiob-1.net.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">_sips._tcp.kamailiob.net. 60 SRV 2 10
5061 kamailiob-2.net.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">If B1 is down, I expect
requests being relayed to B2 (because of priority 2 in the
SRV record).<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level1 lfo1"><span
lang="EN-US">For initial INVITEs: R-URI is
<a href="sip:kamailiob.net" moz-do-not-send="true"
class="moz-txt-link-freetext">sip:kamailiob.net</a> <o:p></o:p></span>
<ul style="margin-top:0cm" type="circle">
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level2 lfo1"><span
lang="EN-US">If B1 is down, the request is retried to
B2 => OK<o:p></o:p></span></li>
</ul>
</li>
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level1 lfo1"><span
lang="EN-US">For in-dialog requests: Route header in
incoming request is
<a href="sip:kamailiob.net" moz-do-not-send="true"
class="moz-txt-link-freetext">sip:kamailiob.net</a> so
it is set as next destination with
<i>loose</i>_<i>route</i> function<o:p></o:p></span>
<ul style="margin-top:0cm" type="circle">
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level2 lfo1"><span
lang="EN-US">If B1 is down, the request is retried to
B2 for ReINVITE => OK<o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level2 lfo1"><span
lang="EN-US">But once the ACK comes in, with the same
Route header (<a href="sip:kamailiob.net"
moz-do-not-send="true" class="moz-txt-link-freetext">sip:kamailiob.net</a>),
Kamailio tries to send it to B1 only (no retries to
B2, and even no retransmissions to B1 either).<o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level2 lfo1"><span
lang="EN-US">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.<o:p></o:p></span></li>
</ul>
</li>
</ul>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Is it the expected
behavior? Or is it something misconfigured on Kamailio A? Or
is it a TLS connection issue?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Here is the DNS
configuration on Kamailio A (TM module is enabled):<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">dns_try_naptr=yes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">use_dns_failover=yes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">use_dns_cache=yes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">dns_srv_lb=yes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">enable_tls=yes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">tcp_max_connections=4096<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier">tls_max_connections=4096<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier">tcp_reuse_port=yes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">tcp_connect_timeout=10<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">tcp_send_timeout=10<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US">tcp_connection_lifetime=3600<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Courier"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I had a look into the
DNS tutorial (<a
href="https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt</a>)
without finding any hint about this.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">If anyone has already
played with SIP DNS failover in Kamailio, your help would be
appreciated, thanks!<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Julien<o:p></o:p></span></p>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* <a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a>
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* <a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - Online
March 28-31, 2022 (Europe Timezone)
* <a class="moz-txt-link-freetext" href="https://www.asipto.com/sw/kamailio-advanced-training-online/">https://www.asipto.com/sw/kamailio-advanced-training-online/</a></pre>
</body>
</html>