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
