[OpenSIPS-Users] serialize_branches() and timeouts
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Jul 3 09:00:28 UTC 2023
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/d3d39a05/attachment.html>
More information about the Users
mailing list