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
