[OpenSIPS-Users] serialize_branches() and timeouts

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Jun 28 06:37:40 UTC 2023


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....
>




More information about the Users mailing list