<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">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">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">https://www.opensips-solutions.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.siphub.com">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">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">https://www.opensips-solutions.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.siphub.com">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">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">https://www.opensips-solutions.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.siphub.com">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>
</body>
</html>