<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>Thank you, I've got your point. But I think, there is a
misunderstanding here. This chapter says a proxy has to collect
negative final responses from <i>different</i> outgoing
transaction, and wait for the 200 response from any non-finished
outgoing transaction. And there is nothing about allowing several
final responses for the same outgoing transaction.</p>
<p>The behavior when we receive two final responses brakes the state
machine of a transaction layer, according to 17.1.1.2, because
it's in the "Completed" state, where it only can resend ACK for
the same negative response. So I think the 200 received after
3xx-6xx for the same outgoing transaction should be interpreted as
error on transaction layer and shouldn't been passed to uac level.</p>
<pre class="moz-signature" cols="72">Best regards,
Alexander Kogan,
Director of R&D
5g Future
<a class="moz-txt-link-freetext" href="http://5gfuture.com">http://5gfuture.com</a>
</pre>
<div class="moz-cite-prefix">On 03.07.2023 13:00, Bogdan-Andrei
Iancu wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1e6d169b-7650-77ad-5ac0-371ede88e730@opensips.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<font face="monospace">Hi,<br>
<br>
See <a class="moz-txt-link-freetext"
href="https://www.ietf.org/rfc/rfc3261.html#section-16.7"
moz-do-not-send="true">https://www.ietf.org/rfc/rfc3261.html#section-16.7</a>,
top page 110<br>
<br>
</font><br>
<pre class="newpage"> After a final response has been sent on the server transaction,
the following responses MUST be forwarded immediately:
- Any 2xx response to an INVITE request
Regards,
</pre>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="https://www.opensips-solutions.com" moz-do-not-send="true">https://www.opensips-solutions.com</a>
<a class="moz-txt-link-freetext" href="https://www.siphub.com" moz-do-not-send="true">https://www.siphub.com</a></pre>
<div class="moz-cite-prefix">On 6/29/23 4:21 PM, Alexander Kogan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e4c8e27c-f00d-9c49-870b-fc717f91cb48@5gfuture.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Ohh... I've looked through 3261 again, and haven't found the
case.... Could you please point me?</p>
<p>The RFC says a proxy makes a separate client transaction for
each outgoing branch. Each client transaction is finished with
the first final response received (or generated internally
according to 8.1.3.1 Transaction Layer Errors - "When a
timeout error is received from the transaction layer, it MUST
be treated as if a 408 (Request Timeout) status code has been
received") and any other final responses for this transaction
are out of state, isn't it?<br>
</p>
<pre class="moz-signature" cols="72">Best regards,
Alexander Kogan,
Director of R&D
5g Future
<a class="moz-txt-link-freetext" href="http://5gfuture.com" moz-do-not-send="true">http://5gfuture.com</a>
</pre>
<div class="moz-cite-prefix">On 29.06.2023 16:05, Bogdan-Andrei
Iancu wrote:<br>
</div>
<blockquote type="cite"
cite="mid:48a8d102-15be-06a8-808c-fd3c08ba3747@opensips.org">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<font face="monospace">YEs, 200 OK is accepted on top of any
previous negative reply...that's the RFC :)<br>
<br>
Regards,<br>
</font>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="https://www.opensips-solutions.com" moz-do-not-send="true">https://www.opensips-solutions.com</a>
<a class="moz-txt-link-freetext" href="https://www.siphub.com" moz-do-not-send="true">https://www.siphub.com</a></pre>
<div class="moz-cite-prefix">On 6/28/23 4:38 PM, Alexander
Kogan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3306381c-677a-fa07-b911-1e080498cb0c@5gfuture.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>BTW, we have the line in log when 200 has been received
for timed out branch:</p>
<p>/usr/sbin/opensips[9653]: DBG:tm:reply_received: org.
status uas=180, <font color="#ff0000"><b>uac[1]=408</b></font>
local=0 is_invite=1)</p>
<p>Of course, it's a fake reply generated on timeout. Does
it mean that if OpenSIPS receives a real final reply
>=300 and after that it will receive 200, it will pass
200 to the caller?<br>
</p>
<pre class="moz-signature" cols="72">Best regards,
Alexander Kogan,
Director of R&D
5g Future
<a class="moz-txt-link-freetext" href="http://5gfuture.com" moz-do-not-send="true">http://5gfuture.com</a>
</pre>
<div class="moz-cite-prefix">On 28.06.2023 15:01, Alexander
Kogan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0014a55b-dd98-d6a3-d61c-38dced0308e0@5gfuture.com">Well,
it would have worked if I didn't need loops.... <br>
<br>
Best regards, <br>
Alexander Kogan, <br>
Director of R&D <br>
5g Future <br>
<a class="moz-txt-link-freetext"
href="http://5gfuture.com" moz-do-not-send="true">http://5gfuture.com</a>
<br>
<br>
<br>
On 28.06.2023 14:06, Bogdan-Andrei Iancu wrote: <br>
<blockquote type="cite">True, multiple 200 OK replies will
mess up the dialog module, as the module is not able to
separately keep track of the calls deriving from the
same original dialog... <br>
You may have good chances to get it work almost
correctly if using the sip only dialog matching (in
dialog module), as the to-tag will make the difference
between the two calls resulted from the original dialog.
<br>
<br>
Regards, <br>
<br>
Bogdan-Andrei Iancu <br>
<br>
OpenSIPS Founder and Developer <br>
<a class="moz-txt-link-freetext"
href="https://www.opensips-solutions.com"
moz-do-not-send="true">https://www.opensips-solutions.com</a>
<br>
<a class="moz-txt-link-freetext"
href="https://www.siphub.com" moz-do-not-send="true">https://www.siphub.com</a>
<br>
<br>
On 6/28/23 11:05 AM, Alexander Kogan wrote: <br>
<blockquote type="cite">Agreed, it's really ugly. But on
practice it means that the caller has two confirmed
dialogs with the same did, but opensips has only one.
And when caller sends BYE for one of its dialogs it
ruins the dialog on OpenSIPS.... So it seems much
better to make an ugly solution... <br>
<br>
Best regards, <br>
Alexander Kogan, <br>
Director of R&D <br>
5g Future <br>
<a class="moz-txt-link-freetext"
href="http://5gfuture.com" moz-do-not-send="true">http://5gfuture.com</a>
<br>
<br>
<br>
On 28.06.2023 11:52, Bogdan-Andrei Iancu wrote: <br>
<blockquote type="cite">Hi Alexander. <br>
<br>
The problem here is not related to the ability or
inability of OpenSIPS to drop the late 200 OK - the
problem is you MUST not drop it, as you will break
the signaling. Again, a callee party sending a 200
OK expects an ACK and nothing else. <br>
If you drop (on OpenSIPS level) the late 200 OK, the
vendor 1 will remain inconsistent - it will keep
retransmitting the 200 OK as it expected the ACK for
it. <br>
<br>
Of course, there is the ugly approach of "playing
dead", dropping every single late 200 OK from Vendor
1, forcing it to generate a BYE (eventually) and
close the call. But this is something really ugly. <br>
<br>
Regards, <br>
<br>
Bogdan-Andrei Iancu <br>
<br>
OpenSIPS Founder and Developer <br>
<a class="moz-txt-link-freetext"
href="https://www.opensips-solutions.com"
moz-do-not-send="true">https://www.opensips-solutions.com</a>
<br>
<a class="moz-txt-link-freetext"
href="https://www.siphub.com"
moz-do-not-send="true">https://www.siphub.com</a>
<br>
<br>
On 6/28/23 10:13 AM, Alexander Kogan wrote: <br>
<blockquote type="cite">Hi, <br>
<br>
I got the point. Nevertheless, isn't it a good
idea to have a way to discard messages of branches
that have already been timed out instead of
reanimating them? E.g. t_check() could return -2
in reply_received(), or drop() action could be
allowed for 200... <br>
<br>
Best regards, <br>
Alexander Kogan, <br>
Director of R&D <br>
5g Future <br>
<a class="moz-txt-link-freetext"
href="http://5gfuture.com"
moz-do-not-send="true">http://5gfuture.com</a> <br>
<br>
<br>
On 28.06.2023 10:37, Bogdan-Andrei Iancu wrote: <br>
<blockquote type="cite">Hi Alexander, <br>
<br>
According to RFC3261, there is noting a proxy
should/must do about a received 200 OK rather
than sending further to the caller (even if the
200 OK is received on an old branch). Basically,
if for whatever reasons you end up getting 200
OK from several branches of the same
transaction, you need to forward them all to
caller - why? as in SIP, once a 200 OK was fired
by a callee device, there is no signaling
/mechanism available to
"cancel"/"reject"/"discard" that it. The only
way to handle "unwanted" 200 OK is to accept it,
ack it and then send a BYE for it. <br>
Now, as a proxy does not have the necessary
"logic" to decide which 200 OK to keep and which
to BYE, there is nothing to be done than
"moving" this decision to the caller - so pass
all the 200 OK to caller and let it decide which
to keep or not. <br>
<br>
Regards, <br>
<br>
Bogdan-Andrei Iancu <br>
<br>
OpenSIPS Founder and Developer <br>
<a class="moz-txt-link-freetext"
href="https://www.opensips-solutions.com"
moz-do-not-send="true">https://www.opensips-solutions.com</a>
<br>
<a class="moz-txt-link-freetext"
href="https://www.siphub.com"
moz-do-not-send="true">https://www.siphub.com</a>
<br>
<br>
On 6/27/23 5:59 PM, Alexander Kogan wrote: <br>
<blockquote type="cite">Hello, <br>
<br>
I've got such a call flow: <br>
<br>
Client OpenSIPS <br>
|--INVITE-->| <br>
|<--100-----| Vendor1 <br>
| |--INVITE-->| <br>
| |--INVITE-->| <br>
| |--INVITE-->| <br>
| | | Vendor2 <br>
| |--INVITE------------- >| <br>
| |<--100-----------------| <br>
| |<--180-----------------| <br>
|<--180-----| | <br>
| |<--200-----------------| <br>
|<--200-----| | <br>
| | | <br>
| |<--200-----| | <br>
|<--200-----| | <br>
| | | | <br>
<br>
The first branch was timed out and we switched
up to the next one. A bit later we received
200 OK from the first one. The question is -
how to avoid passing 200 to the first leg?
drop() doesn't work for final responses. I
also can't use t_cancel_branches() because it
works in onreply_route only which is not
called in case of timeout.... <br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>