<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Vorformatiert Zchn";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";
mso-fareast-language:FR-CA;}
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.HTMLVorformatiertZchn
{mso-style-name:"HTML Vorformatiert Zchn";
mso-style-priority:99;
mso-style-link:"HTML Vorformatiert";
font-family:Consolas;
mso-fareast-language:EN-US;}
span.E-MailFormatvorlage26
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:722295125;
mso-list-template-ids:-828889984;}
@list l0:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:1258829129;
mso-list-template-ids:-554924552;}
@list l2
{mso-list-id:1487740048;
mso-list-template-ids:-654048380;}
@list l3
{mso-list-id:1853253712;
mso-list-template-ids:1096217848;}
@list l3:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4
{mso-list-id:1869021689;
mso-list-template-ids:-1225589856;}
@list l4:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="#0563C1" vlink="purple" style="word-wrap:break-word">
<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-GB">as Daniel pointed out:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA">> If the ACK is not received, the target is supposed to retransmit the 200ok, to force retransmission of the ACK<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA">So the ACK is not supposed to be retransmitted, only the 200OK from the UAS side.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA">The ACK is handled from the UAC side, and it needs send at least one ACK for every 200 OK that it receives. Have a look e.g. here :<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><a href="https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-December/020969.html">https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-December/020969.html</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA">But there are of course differences regarding implementation in user agents.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA">Henning<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR-CA"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB">-- <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Henning Westerholt – </span><a href="https://skalatan.de/blog/"><span lang="EN-GB">https://skalatan.de/blog/</span></a><span lang="EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Kamailio services – </span><a href="https://gilawa.com/"><span lang="EN-GB">https://gilawa.com</span></a><span lang="EN-GB"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:35.4pt"><b><span style="mso-fareast-language:DE">From:</span></b><span style="mso-fareast-language:DE"> sr-users <sr-users-bounces@lists.kamailio.org>
<b>On Behalf Of </b>Julien Klingenmeyer<br>
<b>Sent:</b> Wednesday, February 23, 2022 5:34 PM<br>
<b>To:</b> miconda@gmail.com; Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org><br>
<b>Subject:</b> Re: [SR-Users] ACK and DNS failover<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Thanks, Daniel, for this complete explanation.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">It is clear now why ACKs are not being processed by the DNS failover feature.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Actually, I expect the primary node to be restored quickly. So considering this it is OK if there is ACK retransmission to this primary node only, until it comes up again.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">But from what I could see, Kamailio A does not receive multiple ACK (because of retransmission) all the time, although multiple 200 OK are generated by the peer.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">When Kamailio A receives multiple ACK retransmission, it does relay them to Kamailio B1 each time: great!<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">But some previous hops (not Kamailio ones) can send to it one unique ACK although the multiple 200 OK => is it something RFC-compliant? Could it be due to a TLS connection between these previous
hops and Kamailio A?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">I wonder if some previous hops do not relay the retransmission packets because they know that the initial ACK was already correctly forwarded thanks to the TLS connection. So maybe this is why
they only relay the initial ACK and this does not trigger ACK retransmission.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">If so, would it be possible in the routing script to do a “manual” ACK retransmission (in a failure_route or something) when I detect a broken TLS connection?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">In the logs I do see a failure:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">ERROR: <core> [core/tcp_main.c:4457]: handle_tcpconn_ev(): connect <IP_Kamailio_B1>:5061 failed<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Could I catch it to trigger a retransmission of the ACK request ?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Thanks<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Julien<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:35.4pt"><b><span lang="FR-CA" style="font-size:12.0pt;color:black">De :
</span></b><span lang="FR-CA" style="font-size:12.0pt;color:black">Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>><br>
<b>Répondre à : </b>"<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>" <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>><br>
<b>Date : </b>mercredi 23 février 2022 à 10:50<br>
<b>À : </b>"Kamailio (SER) - Users Mailing List" <<a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a>>, Julien Klingenmeyer <<a href="mailto:julien.klingenmeyer@ovhcloud.com">julien.klingenmeyer@ovhcloud.com</a>><br>
<b>Objet : </b>Re: [SR-Users] ACK and DNS failover</span><span lang="FR-CA" style="font-size:12.0pt;color:black;mso-fareast-language:FR-CA"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="FR-CA"><o:p> </o:p></span></p>
</div>
<p style="margin-left:35.4pt"><span lang="FR-CA">Hello,<o:p></o:p></span></p>
<p style="margin-left:35.4pt"><span lang="FR-CA">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.<o:p></o:p></span></p>
<p style="margin-left:35.4pt"><span lang="FR-CA">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.<o:p></o:p></span></p>
<p style="margin-left:35.4pt"><span lang="FR-CA">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 ...<o:p></o:p></span></p>
<p style="margin-left:35.4pt"><span lang="FR-CA">Moreover, ACK does not belong to INVITE transaction and can have a different path than the INVITE, being a matter of record-route headers.<o:p></o:p></span></p>
<p style="margin-left:35.4pt"><span lang="FR-CA">So lack (or limitations) of DNS failover for ACK comes from the above.<o:p></o:p></span></p>
<p style="margin-left:35.4pt"><span lang="FR-CA">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).<o:p></o:p></span></p>
<p style="margin-left:35.4pt"><span lang="FR-CA">Cheers,<br>
Daniel<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="FR-CA">On 23.02.22 15:59, Julien Klingenmeyer wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="FR-CA">Hello,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="FR-CA"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">I use DNS failover feature for routing some calls, and I wonder about its limitations.</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Let’s say I have Kamailio A relaying requests to a pool of Kamailios B1 and B2 in TLS.</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">DNS records are the below ones.</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">kamailiob.net. 60 NAPTR 20 100 S SIPS+D2T _sips._tcp.kamailiob.net.</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">_sips._tcp.kamailiob.net. 60 SRV 1 10 5061 kamailiob-1.net.
</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">_sips._tcp.kamailiob.net. 60 SRV 2 10 5061 kamailiob-2.net.</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">If B1 is down, I expect requests being relayed to B2 (because of priority 2 in the SRV record).</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:71.4pt;text-indent:-18.0pt;mso-list:l4 level1 lfo3">
<![if !supportLists]><span lang="FR-CA"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">For initial INVITEs: R-URI is <a href="sip:kamailiob.net">
sip:kamailiob.net</a> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:107.4pt;text-indent:-18.0pt;mso-list:l4 level2 lfo3">
<![if !supportLists]><span lang="FR-CA"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">If B1 is down, the request is retried to B2 => OK
</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:71.4pt;text-indent:-18.0pt;mso-list:l4 level1 lfo3">
<![if !supportLists]><span lang="FR-CA"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">For in-dialog requests: Route header in incoming request is
<a href="sip:kamailiob.net">sip:kamailiob.net</a> so it is set as next destination with
<i>loose</i>_<i>route</i> function </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:107.4pt;text-indent:-18.0pt;mso-list:l4 level2 lfo3">
<![if !supportLists]><span lang="FR-CA"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">If B1 is down, the request is retried to B2 for ReINVITE => OK
</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:107.4pt;text-indent:-18.0pt;mso-list:l4 level2 lfo3">
<![if !supportLists]><span lang="FR-CA"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">But once the ACK comes in, with the same Route header (<a href="sip:kamailiob.net">sip:kamailiob.net</a>), Kamailio tries to send it to B1 only (no retries to B2, and even no retransmissions to B1 either).
</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:107.4pt;text-indent:-18.0pt;mso-list:l4 level2 lfo3">
<![if !supportLists]><span lang="FR-CA"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><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.
</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Is it the expected behavior? Or is it something misconfigured on Kamailio A? Or is it a TLS connection issue?</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Here is the DNS configuration on Kamailio A (TM module is enabled):</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">dns_try_naptr=yes</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">use_dns_failover=yes</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">use_dns_cache=yes</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">dns_srv_lb=yes</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">enable_tls=yes</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">tcp_max_connections=4096</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="FR-CA" style="font-family:Courier">tls_max_connections=4096</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="FR-CA" style="font-family:Courier">tcp_reuse_port=yes</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">tcp_connect_timeout=10</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">tcp_send_timeout=10</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier">tcp_connection_lifetime=3600</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="font-family:Courier"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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">https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt</a>)
without finding any hint about this.</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">If anyone has already played with SIP DNS failover in Kamailio, your help would be appreciated, thanks!</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> </span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Julien</span><span lang="FR-CA"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:35.4pt">
<span lang="FR-CA" style="mso-fareast-language:FR-CA"><o:p> </o:p></span></p>
<pre style="margin-left:35.4pt"><span lang="FR-CA">__________________________________________________________<o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA">Kamailio - Users Mailing List - Non Commercial Discussions<o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA"> * <a href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA">Important: keep the mailing list in the recipients, do not reply only to the sender!<o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA">Edit mailing list options or unsubscribe:<o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA"> * <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><o:p></o:p></span></pre>
</blockquote>
<pre style="margin-left:35.4pt"><span lang="FR-CA">-- <o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA">Daniel-Constantin Mierla -- <a href="http://www.asipto.com">www.asipto.com</a><o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA"><a href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a><o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA">Kamailio Advanced Training - Online<o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA"> March 28-31, 2022 (Europe Timezone)<o:p></o:p></span></pre>
<pre style="margin-left:35.4pt"><span lang="FR-CA"> * <a href="https://www.asipto.com/sw/kamailio-advanced-training-online/">https://www.asipto.com/sw/kamailio-advanced-training-online/</a><o:p></o:p></span></pre>
</div>
</body>
</html>