<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><p class="">Indeed, at this stage there is no dialog established and there can be many To-tags in 1xx provisional responses (eg, a parallel forking scenario) -- the to-tag of the dialog has to be taken from 200ok.</p></div></blockquote></div><div class="">As far as I read this is not correct. Also a provisional dialog is a dialog according to RFC3261. Only in the case that the request did not contain a to-tag the provisional messages may insert their own to-tags:</div><div class=""><br class=""></div><div class=""><pre class="newpage">"1xx and 2xx responses may be involved in the establishment of
dialogs. When a request does not contain a To tag, the To tag
in the response is used by the UAC to distinguish multiple
responses to a dialog creating request. A proxy MUST NOT
insert a tag into the To header field of a 1xx or 2xx response
if the request did not contain one. A proxy MUST NOT modify
the tag in the To header field of a 1xx or 2xx response.”</pre><pre class="newpage"><a href="https://tools.ietf.org/html/rfc3261#page-111" class="">https://tools.ietf.org/html/rfc3261#page-111</a></pre></div><div class=""><br class=""></div><div class="">In any case, this bug is not a about provisional messages. The 500 message terminates the dialog for the UAC (yate) and the UAC needs to be able to identify it. An UAC identifies the dialog by the call-id, local tag and remote tag.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" cite="mid:CAFZQphzM=C--zqrSSHfGvJSusWZaytM80Yosbuhhc6sBesvrZg@mail.gmail.com" class=""><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div link="blue" vlink="purple" lang="DE" class=""><div class="m_-5300728039720019352WordSection1"><div class=""><div class=""><h2 class="" style="margin-left: 35.4pt;"><a href="https://tools.ietf.org/html/rfc3261#section-12" target="_blank" moz-do-not-send="true" class=""><span class=""><span class="" style="font-family: Arial, sans-serif;">12</span></span><span class=""></span></a><span class=""></span><span class="" style="font-family: Arial, sans-serif;"> Dialogs</span></h2><h2 class="" style="margin-left: 35.4pt;"><span class="" style="font-family: Arial, sans-serif;">A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag…"</span></h2></div><div class=""></div></div></div></div></blockquote></div></div></blockquote></div></blockquote></div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 23 Jul 2020, at 10:07, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com" class="">miconda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Indeed, at this stage there is no dialog established and there
can be many To-tags in 1xx provisional responses (eg, a parallel
forking scenario) -- the to-tag of the dialog has to be taken from
200ok.</p><p class="">This parameter is probably to have a shortcut of doing:</p><p class="">failure_route[REMAP503] {</p><p class=""> if(t_check_status("503")) {</p><p class=""> t_reply("500", "Server error");<br class="">
exit;</p><p class="">}</p><p class="">Being like the server application is generating the 500 (so using
own tag), instead of forwarding the 503. Not a bug, but if anyone
is willing to add an option to allow re-using the to-tag from
received reply, I am fine with it.</p><p class="">Anyhow, even if this would be fixed, I am wondering how yate is
going to work in parallel/serial forking scenarios where different
to-tags flow for a while and the final failure response can have
any to-tag, including a new one (e.g., from a device not sending
any 1xx or again from kamailio (e.g., when last target doesn't
reply at all)).</p><p class="">Cheers,<br class="">
Daniel<br class="">
</p>
<div class="moz-cite-prefix">On 23.07.20 06:08, M S wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:CAFZQphzM=C--zqrSSHfGvJSusWZaytM80Yosbuhhc6sBesvrZg@mail.gmail.com" class="">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
<div class="">
<div dir="auto" class="">The SIP code 503 is tricky in the sense that i
can indicate either server maintenance or server overload. In
both cases it can send Retry-After header and any subsequent
requests from same source are ignored for the duration of
Retry-After interval. [1].</div>
</div>
<div dir="auto" class=""><br class="">
</div>
<div dir="auto" class="">Additionally RFC3261 and RFC3263 define that
transport failures (generally due to fatal ICMP errors in UDP
and connection failures in TCP) should be treated as 503
response. [2].</div>
<div dir="auto" class=""><br class="">
</div>
<div dir="auto" class="">So in all above cases, it is most likely that
dialog does not establishes at all and 503 response is treated
similar to stateless response. Therefore, a to-tag can be
added/replaced before sending it to UAC.</div>
<div dir="auto" class=""><br class="">
</div>
<div dir="auto" class="">Theoretically, kamailio should check and use
to-tag from 503 response when converting it to 500 response and
only create new to-tag if it is absent.</div>
<div dir="auto" class=""><br class="">
</div>
<div dir="auto" class="">References:</div>
<div dir="auto" class=""><br class="">
</div>
<div dir="auto" class="">
<div class="">[1] <a href="https://tools.ietf.org/html/rfc3261#section-21.5.4" moz-do-not-send="true" class="">https://tools.ietf.org/html/rfc3261#section-21.5.4</a></div>
<div dir="auto" class=""><br class="">
</div>
<div class="">[2] <a href="https://tools.ietf.org/html/draft-hilt-sip-correction-503-01#section-4" moz-do-not-send="true" class="">https://tools.ietf.org/html/draft-hilt-sip-correction-503-01#section-4</a></div>
<br class="">
</div>
<div dir="auto" class=""><br class="">
</div>
<div dir="auto" class="">Hope this helps.</div>
<div dir="auto" class=""><br class="">
</div>
<div dir="auto" class=""><br class="">
</div>
<div class=""><br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 22 Jul 2020 at
21:08, Henning Westerholt <<a href="mailto:hw@skalatan.de" moz-do-not-send="true" class="">hw@skalatan.de</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="DE" class="">
<div class="m_-5300728039720019352WordSection1"><p class="MsoNormal"><span class="">Hello,</span></p><div class=""><span class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span lang="EN-GB" class="">Apparently, this
is the way the code works:</span></p><div class=""><span lang="EN-GB" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span lang="EN-GB" class="">t_reply.c:</span></p><p class="MsoNormal"><span lang="EN-GB" class="">
if (relayed_code==503 && tm_remap_503_500){</span></p><p class="MsoNormal"><span lang="EN-GB" class="">
/* replace a final 503 with a 500:</span></p><p class="MsoNormal"><span lang="EN-GB" class="">
* generate a "FAKE" reply and a
new to_tag (for easier</span></p><p class="MsoNormal"><span lang="EN-GB" class="">
* debugging)*/</span></p><div class=""><span lang="EN-GB" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span lang="EN-GB" class="">Lets see if
maybe others can comment as well. Otherwise you
could just open an issue on our tracker, it is
probably not that hard to change this.</span></p><div class=""><span lang="EN-GB" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span lang="EN-GB" class="">Cheers,</span></p><div class=""><span lang="EN-GB" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span lang="EN-GB" class="">Henning</span></p>
<div class=""><div class=""><span lang="EN-GB" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span lang="EN-GB" class="">-- </span></p><p class="MsoNormal"><span lang="EN-GB" class="">Henning
Westerholt –
</span><span class=""><a href="https://skalatan.de/blog/" target="_blank" moz-do-not-send="true" class=""><span style="color:#0563c1" lang="EN-GB" class="">https://skalatan.de/blog/</span></a></span><span lang="EN-GB" class=""></span></p><p class="MsoNormal"><span lang="EN-GB" class="">Kamailio
services –
</span><span class=""><a href="https://gilawa.com/" target="_blank" moz-do-not-send="true" class=""><span style="color:#0563c1" lang="EN-GB" class="">https://gilawa.com</span></a></span><span class="">
<span lang="EN-GB" class=""></span></span></p>
</div><div class=""><span lang="EN-GB" class=""> </span><br class="webkit-block-placeholder"></div>
<div class="">
<div style="border:none;border-top:solid #e1e1e1
1.0pt;padding:3.0pt 0cm 0cm 0cm" class=""><p class="MsoNormal" style="margin-left:35.4pt"><b class="">From:</b>
sr-users <<a href="mailto:sr-users-bounces@lists.kamailio.org" target="_blank" moz-do-not-send="true" class="">sr-users-bounces@lists.kamailio.org</a>>
<b class="">On Behalf Of </b>Gerry | Rigatta<br class="">
<b class="">Sent:</b> Wednesday, July 22, 2020 8:58 PM<br class="">
<b class="">To:</b> Kamailio (SER) - Users Mailing List
<<a href="mailto:sr-users@lists.kamailio.org" target="_blank" moz-do-not-send="true" class="">sr-users@lists.kamailio.org</a>><br class="">
<b class="">Subject:</b> [SR-Users] bug ? remap_503_500
breaks dialogs</p>
</div>
</div><div style="margin-left: 35.4pt;" class=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal" style="margin-left:35.4pt">Hi,</p>
<div class=""><div style="margin-left: 35.4pt;" class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal" style="margin-left:35.4pt">I am
using Kamailio 5.2. </p>
</div>
<div class=""><div style="margin-left: 35.4pt;" class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal" style="margin-left:35.4pt">Apparently
the remapping of 503 to 500 codes in the tm module
does also change the to-tag. This behaviour breaks
dialogs with yate and therefore calls hang and the
503 remains unacknowledged. After disabling the 503
to 500 remapping with modparam("tm",
"remap_503_500", 0) all works fine again.</p>
</div>
<div class=""><div style="margin-left: 35.4pt;" class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal" style="margin-left:35.4pt">Changing
the to-tag in a dialog seems to contradict RFC3261,
or do I see this wrongly?</p>
</div>
<div class="">
<h2 style="margin-left:35.4pt" class=""><a name="m_-5300728039720019352_section-12" moz-do-not-send="true" class=""></a><a href="https://tools.ietf.org/html/rfc3261#section-12" target="_blank" moz-do-not-send="true" class=""><span class=""><span style="font-family:"Arial",sans-serif" class="">12</span></span><span class=""></span></a><span class=""></span><span style="font-family:"Arial",sans-serif" class="">
Dialogs</span></h2>
<h2 style="margin-left:35.4pt" class=""><span style="font-family:"Arial",sans-serif" class="">A
dialog is identified at each UA with a dialog ID,
which consists of a Call-ID value, a local tag and
a remote tag…"</span></h2>
</div>
<div class=""><div style="margin-left: 35.4pt;" class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal" style="margin-left:35.4pt">Thanks
for looking into this.</p>
</div>
<div class=""><div style="margin-left: 35.4pt;" class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal" style="margin-left:35.4pt">Gerry</p>
</div>
<div class=""><div style="margin-left: 35.4pt;" class=""> <br class="webkit-block-placeholder"></div>
</div>
</div>
</div>
_______________________________________________<br class="">
Kamailio (SER) - Users Mailing List<br class="">
<a href="mailto:sr-users@lists.kamailio.org" target="_blank" moz-do-not-send="true" class="">sr-users@lists.kamailio.org</a><br class="">
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank" moz-do-not-send="true" class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br class="">
</blockquote>
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a>
<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>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla">https://www.paypal.me/dcmierla</a></pre>
</div>
_______________________________________________<br class="">Kamailio (SER) - Users Mailing List<br class=""><a href="mailto:sr-users@lists.kamailio.org" class="">sr-users@lists.kamailio.org</a><br class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users<br class=""></div></blockquote></div><br class=""></div></body></html>