[OpenSIPS-Users] serialize_branches() and timeouts

[Alexander Kogan]

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