Hi,
See https://www.ietf.org/rfc/rfc3261.html#section-16.7, top page 110
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,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 6/29/23 4:21 PM, Alexander Kogan wrote:
Ohh... I've looked through 3261 again, and haven't found the case....
Could you please point me?
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?
Best regards,
Alexander Kogan,
Director of R&D
5g Future
http://5gfuture.com
On 29.06.2023 16:05, Bogdan-Andrei Iancu wrote:
YEs, 200 OK is accepted on top of any previous negative
reply...that's the RFC :)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 6/28/23 4:38 PM, Alexander Kogan wrote:
BTW, we have the line in log when 200 has been received for timed
out branch:
/usr/sbin/opensips[9653]: DBG:tm:reply_received: org. status
uas=180, *uac[1]=408* local=0 is_invite=1)
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?
Best regards,
Alexander Kogan,
Director of R&D
5g Future
http://5gfuture.com
On 28.06.2023 15:01, Alexander Kogan wrote:
Well, it would have worked if I didn't need loops....
Best regards,
Alexander Kogan,
Director of R&D
5g Future
http://5gfuture.com
On 28.06.2023 14:06, Bogdan-Andrei Iancu wrote:
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...
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.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 6/28/23 11:05 AM, Alexander Kogan wrote:
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...
Best regards,
Alexander Kogan,
Director of R&D
5g Future
http://5gfuture.com
On 28.06.2023 11:52, Bogdan-Andrei Iancu wrote:
Hi Alexander.
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.
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.
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.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 6/28/23 10:13 AM, Alexander Kogan wrote:
Hi,
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...
Best regards,
Alexander Kogan,
Director of R&D
5g Future
http://5gfuture.com
On 28.06.2023 10:37, Bogdan-Andrei Iancu wrote:
Hi Alexander,
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.
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.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 6/27/23 5:59 PM, Alexander Kogan wrote:
Hello,
I've got such a call flow:
Client OpenSIPS
|--INVITE-->|
|<--100-----| Vendor1
| |--INVITE-->|
| |--INVITE-->|
| |--INVITE-->|
| | | Vendor2
| |--INVITE------------- >|
| |<--100-----------------|
| |<--180-----------------|
|<--180-----| |
| |<--200-----------------|
|<--200-----| |
| | |
| |<--200-----| |
|<--200-----| |
| | | |
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....
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
