[OpenSIPS-Users] serialize_branches() and timeouts

Alexander Kogan akogan at 5gfuture.com
Thu Jun 29 13:21:03 UTC 2023 

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/20230629/98e1c07e/attachment-0001.html>

More information about the Users mailing list