[OpenSIPS-Users] serialize_branches() and timeouts

[Bogdan-Andrei Iancu]

YEs, 200 OK is accepted on top of any previous negative reply...that's 
the RFC :)

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 6/28/23 4:38 PM, Alexander Kogan wrote:
>
> 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/20230629/8e26253b/attachment.html>