[OpenSIPS-Users] serialize_branches() and timeouts

[Alexander Kogan]

BTW, we have the line in log when 200 has been received for timed out 
branch:

/usr/sbin/opensips[9653]: DBG:tm:reply_received: org. status uas=180, 
*uac[1]=408* local=0 is_invite=1)

Of course, it's a fake reply generated on timeout. Does it mean that if 
OpenSIPS receives a real final reply >=300 and after that it will 
receive 200, it will pass 200 to the caller?

Best regards,
Alexander Kogan,
Director of R&D
5g Future
http://5gfuture.com


On 28.06.2023 15:01, Alexander Kogan wrote:
> 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....
>>>>>>>
>>>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230628/3d512aa4/attachment.html>