[OpenSIPS-Users] serialize_branches() and timeouts

[Alexander Kogan]

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