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
