[OpenSIPS-Users] serialize_branches() and timeouts

Alexander Kogan akogan at 5gfuture.com
Mon Jul 3 10:13:04 UTC 2023 

Hi,

Thank you, I've got your point. But I think, there is a misunderstanding 
here. This chapter says a proxy has to collect negative final responses 
from /different/ outgoing transaction, and wait for the 200 response 
from any non-finished outgoing transaction. And there is nothing about 
allowing several final responses for the same outgoing transaction.

The behavior when we receive two final responses brakes the state 
machine of a transaction layer, according to 17.1.1.2, because it's in 
the "Completed" state, where it only can resend ACK for the same 
negative response. So I think the 200 received after 3xx-6xx for the 
same outgoing transaction should be interpreted as error on transaction 
layer and shouldn't been passed to uac level.

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


On 03.07.2023 13:00, Bogdan-Andrei Iancu wrote:
> Hi,
>
> See https://www.ietf.org/rfc/rfc3261.html#section-16.7, top page 110
>
>
>           After a final response has been sent on the server transaction,
>           the following responses MUST be forwarded immediately:
>
>           -  Any 2xx response to an INVITE request
>
>
> Regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    https://www.opensips-solutions.com
>    https://www.siphub.com
> On 6/29/23 4:21 PM, Alexander Kogan wrote:
>>
>> Ohh... I've looked through 3261 again, and haven't found the case.... 
>> Could you please point me?
>>
>> The RFC says a proxy makes a separate client transaction for each 
>> outgoing branch. Each client transaction is finished with the first 
>> final response received (or generated internally according to 8.1.3.1 
>> Transaction Layer Errors - "When a timeout error is received from the 
>> transaction layer, it MUST be treated as if a 408 (Request Timeout) 
>> status code has been received") and any other final responses for 
>> this transaction are out of state, isn't it?
>>
>> Best regards,
>> Alexander Kogan,
>> Director of R&D
>> 5g Future
>> http://5gfuture.com
>>
>>
>> On 29.06.2023 16:05, Bogdan-Andrei Iancu wrote:
>>> 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/20230703/763e150c/attachment-0001.html>

More information about the Users mailing list