[OpenSIPS-Users] serialize_branches() and timeouts

[Bogdan-Andrei Iancu]

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