<div dir="ltr">
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Hi Daniel,</span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Thar is correct, the top Via header branch param differs (has a .1 instead of .0 at the end), that doesn't seem to count according to<span> </span><a href="https://tools.ietf.org/html/rfc3261#section-8.2.2.2" target="_blank" style="color:rgb(17,85,204)">RFC 3271 section 8.2.2.2</a></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">Looking at the sip trace, the ACK for 415 is sent out before the 2nd branch INVITE.</div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><img src="cid:ii_jgwanyyq0_1633ad5a36c3be55" width="526" height="169" class="gmail-CToWUd gmail-a6T" tabindex="0" style="cursor: pointer; outline: 0px;"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Unfortunately, inserting a 2 seconds sleep didn't help :(</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Regards,</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">--Sergiu</div>
<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 7, 2018 at 6:21 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hello,</p>
<p>the branch parameter value in top Via header is different, so
this should indicate is not the same branch.</p>
<p>Have you look at the network traffic, is the ACK for 415 getting
first to device, before the 2nd branch INVITE? A that moment, the
transaction should be considered terminated and a new one started.</p>
<p>My understanding of "merging request" is that it should be done
if two requests arrive at the same time, both still being active,
without a final response sent back.</p>
<p>What you can try to see what happens is to add a sleep() of few
seconds for the 2nd branch and see if this time the device cleared
the previous transaction. Of course, not like a really good
solution, but can reveal what the device is doing.<br>
</p>
<p>Cheers,<br>
Daniel<br>
</p><div><div class="h5">
<br>
<div class="m_269558229522448204moz-cite-prefix">On 04.05.18 20:43, Sergiu Pojoga wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">In continuation of <a href="https://marc.info/?l=sr-users&m=150730146302404&w=2" target="_blank">previous </a>thread
about none/optional/compulsory SRTP handling...
<div>
<div>
<div><br>
</div>
<div>I used the suggested approach of <i>t_reuse_branch()</i>
in a <i>tm:branch-failure</i> detected
by t_check_status("(415)|(488)<wbr>") replies, with the
only difference of me doing it vice-versa from the
suggested mantra of offer SRTP first then fallback to RTP.</div>
</div>
</div>
<div><br>
</div>
<div>It works... well, for some UACs, not so with others.</div>
<div><br>
</div>
<div>The 'good' UACs happily accept an updated branch, like for
e.g. Yealink, will reply with "<i>488 Not Acceptable Here</i>"
at first followed by a <i>200 OK</i>.</div>
<div><br>
</div>
<div>The 'bad' UACs, like for e.g. Bria || Zoiper, will issue a
"<i>415 Unsupported Media Type</i>" at first, and then a "<i><b>482
Merged Request</b></i>" after receiving and updated branch
with a different RTP profile.</div>
<div><br>
</div>
<div>Rightfully so, they decided that the updated branch is a
retransmission, since both branches have the same CSeq,
Call-ID and From tag. </div>
<div>The branch ID however differs, so does the RTP profile
obviously.</div>
<div><br>
</div>
<div><b>Any suggestion on how to convince all UACs that the 2nd
attempt is different than the 1st one?</b></div>
<div>
<pre style="white-space:pre-wrap;word-wrap:break-word;width:1352.88px;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">According to RFC 3261, a request is a merged request if ...
"8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction."</pre>
<br>
</div>
</div>
<br>
<fieldset class="m_269558229522448204mimeAttachmentHeader"></fieldset>
<br>
</div></div><pre>______________________________<wbr>_________________
Kamailio (SER) - Users Mailing List
<a class="m_269558229522448204moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>
<a class="m_269558229522448204moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<pre class="m_269558229522448204moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="m_269558229522448204moz-txt-link-abbreviated" href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a class="m_269558229522448204moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Kamailio World Conference - May 14-16, 2018 - <a class="m_269558229522448204moz-txt-link-abbreviated" href="http://www.kamailioworld.com" target="_blank">www.kamailioworld.com</a></pre>
</font></span></div>
</blockquote></div><br></div>