Subject: Re: [sipcore] option tag (was RFC4028 : bug in 11 Security Considerations)

From: Paul Kyzivat <[email-masked]>
Date: Wed, 1 Jul 2020 11:54:27 -0400

On 6/30/20 8:49 PM, OKUMURA Shinji wrote:
> Paul,
> 
>> I think this probably suggests that an option tag for support of the 
>> updated ST draft would be helpful.
> 
> Defining a new header that limits the double-meaning of a transaction 
> may be useful for other issues.

Can you say more of what you are thinking?

I was only suggesting an option tag that indicates support for the 
revisions in this bis. That gives a little more flexibility in how 
things work. It sounds like you something more specific in mind.

	Thanks,
	Paul

> Regards,
> Shinji
> 
> On 2020/06/28 3:38, Paul Kyzivat wrote:
>> Some further thoughts on this...
>>
>> On 6/27/20 11:45 AM, Paul Kyzivat wrote:
>>> On 6/27/20 7:02 AM, OKUMURA Shinji wrote:
>>>> Hi Paul,
>>>>
>>>> All I want to confirm is one point. If a UA receives a session 
>>>> refresh request during another session refresh transaction, the UA 
>>>> MUST reject it with a 491 response, or MAY reject it with a 491 
>>>> response.
>>>
>>> If we want to follow the precedent of O/A glare, then I think it is 
>>> MUST reject.
>>>
>>>> A UA accepts both requests, compares two results, (if necessary) 
>>>> sends additional request for confirmation. I don't have to worry 
>>>> that my desired implementation is a protocol violation, right?
>>>
>>> I'm sure there are situations where the two ends can arrive at a 
>>> common understanding without raising the 491. But I think the 
>>> complexity of spelling out the cases so things are deterministic is 
>>> not worth the added effort and resulting complexity in the spec.
>>
>> I subsequently realized that if we specify the use of 491 for ST then 
>> we must consider what happens in cases of interop with an older 
>> implementation that doesn't do that.
>>
>> If we have one UA supporting the extension and one that doesn't we 
>> first will have to decide whether to use an option tag so the two can 
>> know who does and doesn't support them. If so, then the 491 would not 
>> be used by either end in ST glare cases, and everything would work as 
>> currently.
>>
>> If no option tag is used, then the UA that supports it may send a 491 
>> to indicate glare, but the other end won't, and also won't know 
>> precisely what to do when receiving one. We will then have to figure 
>> out what the end that does support the extension can do to fix things 
>> as best it can.
>>
>> In that case, it may be ok to allow the use of 491 to be optional, 
>> with the alternative being to proceed as if the other end doesn't 
>> support the extension.
>>
>> I think this probably suggests that an option tag for support of the 
>> updated ST draft would be helpful.
>>
>>>      Thanks,
>>>      Paul
>>>
>>>> Regards,
>>>> Shinji
>>>>
>>>> On 2020/06/26 4:24, Paul Kyzivat wrote:
>>>>> Roman,
>>>>>
>>>>> On 6/25/20 2:20 PM, Roman Shpount wrote:
>>>>>> Hi Paul,
>>>>>>
>>>>>> First of all, the issue with target refresh that Shinjit was 
>>>>>> raising is not new. It affects session description updates as much 
>>>>>> as it does session timers.
>>>>>>
>>>>>> Second, I am not sure there is an actual problem. Target refresh 
>>>>>> is done via a SIP transaction, so it does not happen 
>>>>>> instantaneously. SIP transactions can be delayed due to proxy 
>>>>>> processing or network delays, as well as due to a packet loss. The 
>>>>>> delay introduced by 491 error response is generally comparable to 
>>>>>> transaction delay, so it normally does not introduce any new 
>>>>>> problems. All that should happen due to a 491 response, is that 
>>>>>> the transaction should be retried with some delay and target 
>>>>>> refresh should happen slightly later.
>>>>>>
>>>>>> Considering that this is an existing design consideration which is 
>>>>>> not specific to SIP session timer, I do not think it warrants a 
>>>>>> discussion in the session timer document.
>>>>>
>>>>> My text was mostly just me explaining my reasoning for purposes of 
>>>>> the discussion. I'm inclined to agree that it doesn't need to be 
>>>>> discussed in the ST draft. It is not a new concern as far as 
>>>>> whether to use 491 to resolve ST glare.
>>>>>
>>>>> I have a feeling we are all in agreement that the notion of glare 
>>>>> during session timer refresh is a real thing, and that extending 
>>>>> the use of 491 to apply to that situation is appropriate.
>>>>>
>>>>> It isn't strictly backward compatible. But if a UAS uses it, I bet 
>>>>> there is a pretty good chance that a UAC receiving the 491 in that 
>>>>> context will do the right thing, or at least something reasonable, 
>>>>> even if it hasn't been updated for this change. Worst case is for 
>>>>> the call to fail.
>>>>>
>>>>>      Thanks,
>>>>>      Paul
>>>>>
>>>>>> Best Regards,
>>>>>> _____________
>>>>>> Roman Shpount
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat 
>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>     ISTM that the key issue Shinji is raising is that it could be
>>>>>>     problematic to raise an error to an UPDATE that is doing a target
>>>>>>     refresh. This is true regardless of what else the UPDATE is 
>>>>>> doing - an
>>>>>>     offer, session timer refresh, or maybe nothing else.
>>>>>>
>>>>>>     The bottom line here is that if you have an urgent need to do 
>>>>>> a target
>>>>>>     refresh, you should do it with a request that has little to no
>>>>>>     chance of
>>>>>>     being rejected.
>>>>>>
>>>>>>     This is of course under the control of the UAC. If the UAC 
>>>>>> chooses
>>>>>>     to do
>>>>>>     a target refresh with an UPDATE, and in conjunction with a 
>>>>>> session time
>>>>>>     refresh (and/or offer) then it should be prepared for the 
>>>>>> consequences
>>>>>>     if the UPDATE is rejected (with 491 or anything else.)
>>>>>>
>>>>>>     I guess we could discuss how much (if any) of this logic ought 
>>>>>> to be
>>>>>>     included in the document.
>>>>>>
>>>>>>     I don't think this alters the validity of using 491 for a 
>>>>>> session timer
>>>>>>     glare situation.
>>>>>>
>>>>>>              Thanks,
>>>>>>              Paul
>>>>>>
>>>>>>     On 6/24/20 3:19 PM, Roman Shpount wrote:
>>>>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji
>>>>>>     <[email-masked] <mailto:[email-masked]>
>>>>>>      > <mailto:[email-masked] 
>>>>>> <mailto:[email-masked]>>> wrote:
>>>>>>      >
>>>>>>      >      >> 1. Handling of UPDATE with no SDP glare
>>>>>>      >      >> I'm not going to deny the solution with the 491 
>>>>>> response,
>>>>>>     but I
>>>>>>      >     think it has a big impact.
>>>>>>      >      >
>>>>>>      >      > The situation with session timers is different from 
>>>>>> target
>>>>>>      >     refresh. Target refresh is updated for each UA 
>>>>>> independently.
>>>>>>      >     Session timer is negotiated for the entire session, so 
>>>>>> more
>>>>>>      >     collision scenarios are possible. One of such scenarios is
>>>>>>     both UA
>>>>>>      >     sending UPDATE at the same time. If these 
>>>>>> UPDATE requests do not
>>>>>>      >     carry SDP, currently they should be accepted. Resulting 
>>>>>> session
>>>>>>      >     timer state is ambiguous. The only reliable way to prevent
>>>>>>     ambiguous
>>>>>>      >     session timer state in this case is to refuse the 
>>>>>> UPDATE message,
>>>>>>      >     similar to the session description collision. This is 
>>>>>> why 491 was
>>>>>>      >     suggested.
>>>>>>      >
>>>>>>      >     First of all, is a 491 rejected solution planned for bis?
>>>>>>      >
>>>>>>      >
>>>>>>      > It was discussed but nothing is final.
>>>>>>      >
>>>>>>      >     If so, the UPDATE for target-refresh and the one for
>>>>>>     session-refresh
>>>>>>      >     are combined, as such they affect each other. And I 
>>>>>> think the
>>>>>>     result
>>>>>>      >     will be rarely ambiguous, if there is no change in the
>>>>>>     session timer
>>>>>>      >     policy of each entity(UAC, proxies and UAS). Even so, 
>>>>>> should UAs
>>>>>>      >     reject the UPDATE request? If the UPDATE with new
>>>>>>     remote-target-uri
>>>>>>      >     is rejected, the UA will be unreachable.
>>>>>>      >
>>>>>>      >
>>>>>>      >   This should be no different than the UPDATE with SDP 
>>>>>> collision.
>>>>>>     I am
>>>>>>      > not sure what problem you are talking about.
>>>>>>      >
>>>>>>      >      >> 2. Handling of UPDATE transactions during initial 
>>>>>> INVITE
>>>>>>      >      >> RFC6141 says, if in doubt, send a refresh request 
>>>>>> to confirm.
>>>>>>      >      > This is exactly the reason why handling of UPDATE 
>>>>>> transaction
>>>>>>      >     collisions needs to be resolved. If session timer ends 
>>>>>> up in an
>>>>>>      >     ambiguous state, it is likely ambiguous for both UA and 
>>>>>> both
>>>>>>     UA will
>>>>>>      >     initiate an UPDATE refresh request to confirm, which will
>>>>>>     result in
>>>>>>      >     a collision.
>>>>>>      >
>>>>>>      >     I suggest the method in RFC3261 Section 14.1 as a 
>>>>>> procedure
>>>>>>     to avoid
>>>>>>      >     collisions on retransmission. And we also need to 
>>>>>> decide how UAs
>>>>>>      >     detect collisions.
>>>>>>      >
>>>>>>      >
>>>>>>      > I am not sure what you are talking about.
>>>>>>      > _____________
>>>>>>      > Roman Shpount
>>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 1 Jul 2020 12:04:11 -0400

On 6/29/20 5:02 PM, Roman Shpount wrote:
> On Mon, Jun 29, 2020 at 3:53 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Perhaps we should simply declare it is glare if there are overlapping
>     INVITE or UPDATE in opposite directions regardless of what they
>     contain.
>     That would certainly simplify things.
> 
> 
> This will simplify things but break existing call scenarios. One of the 
> use cases for UPDATE is to negotiate SDP during the early dialog. It 
> should be possible to send an UPDATE with SDP after 183 response with 
> SDP while the original INVITE transaction is still in progress.

OK. It seemed like a good idea at the moment, but doesn't fly.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 2 Jul 2020 14:35:05 +0900

Hi,

UPDATE and PRACK transactions perform SDP negotiation, session timer negotiation, etc., but also have the function of indicating the target URI and confirming the provisional response. A 200 OK is interpreted as a success response for all meanings, but we sometimes want to reject a part of them.

I think that new header can specify the intended function in the request or the unintended function in the response.

This is what I'm currently thinking about.

Regards,
Shinji

On 2020/07/02 0:54, Paul Kyzivat wrote:
>>> I think this probably suggests that an option tag for support of the updated ST draft would be helpful.
>>
>> Defining a new header that limits the double-meaning of a transaction may be useful for other issues.
> 
> I was only suggesting an option tag that indicates support for the revisions in this bis. That gives a little more flexibility in how things work. It sounds like you something more specific in mind.
> 
>      Thanks,
>      Paul
> 
> 
>> Regards,
>> Shinji
>>
>>>>> All I want to confirm is one point. If a UA receives a session refresh request during another session refresh transaction, the UA MUST reject it with a 491 response, or MAY reject it with a 491 response.
>>>>
>>>> If we want to follow the precedent of O/A glare, then I think it is MUST reject.
>>>>
>>>>> A UA accepts both requests, compares two results, (if necessary) sends additional request for confirmation. I don't have to worry that my desired implementation is a protocol violation, right?
>>>>
>>>> I'm sure there are situations where the two ends can arrive at a common understanding without raising the 491. But I think the complexity of spelling out the cases so things are deterministic is not worth the added effort and resulting complexity in the spec.
>>>
>>> I subsequently realized that if we specify the use of 491 for ST then we must consider what happens in cases of interop with an older implementation that doesn't do that.
>>>
>>> If we have one UA supporting the extension and one that doesn't we first will have to decide whether to use an option tag so the two can know who does and doesn't support them. If so, then the 491 would not be used by either end in ST glare cases, and everything would work as currently.
>>>
>>> If no option tag is used, then the UA that supports it may send a 491 to indicate glare, but the other end won't, and also won't know precisely what to do when receiving one. We will then have to figure out what the end that does support the extension can do to fix things as best it can.
>>>
>>> In that case, it may be ok to allow the use of 491 to be optional, with the alternative being to proceed as if the other end doesn't support the extension.
>>>
>>> I think this probably suggests that an option tag for support of the updated ST draft would be helpful.
>>>
>>>>      Thanks,
>>>>      Paul
>>>>
>>>>> Regards,
>>>>> Shinji
>>>>>
>>>>>>> First of all, the issue with target refresh that Shinjit was raising is not new. It affects session description updates as much as it does session timers.
>>>>>>>
>>>>>>> Second, I am not sure there is an actual problem. Target refresh is done via a SIP transaction, so it does not happen instantaneously. SIP transactions can be delayed due to proxy processing or network delays, as well as due to a packet loss. The delay introduced by 491 error response is generally comparable to transaction delay, so it normally does not introduce any new problems. All that should happen due to a 491 response, is that the transaction should be retried with some delay and target refresh should happen slightly later.
>>>>>>>
>>>>>>> Considering that this is an existing design consideration which is not specific to SIP session timer, I do not think it warrants a discussion in the session timer document.
>>>>>>
>>>>>> My text was mostly just me explaining my reasoning for purposes of the discussion. I'm inclined to agree that it doesn't need to be discussed in the ST draft. It is not a new concern as far as whether to use 491 to resolve ST glare.
>>>>>>
>>>>>> I have a feeling we are all in agreement that the notion of glare during session timer refresh is a real thing, and that extending the use of 491 to apply to that situation is appropriate.
>>>>>>
>>>>>> It isn't strictly backward compatible. But if a UAS uses it, I bet there is a pretty good chance that a UAC receiving the 491 in that context will do the right thing, or at least something reasonable, even if it hasn't been updated for this change. Worst case is for the call to fail.
>>>>>>
>>>>>>      Thanks,
>>>>>>      Paul
>>>>>>
>>>>>>> Best Regards,
>>>>>>> _____________
>>>>>>> Roman Shpount
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 24, 2020 at 6:50 PM Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>>     refresh. This is true regardless of what else the UPDATE is doing - an
>>>>>>>     The bottom line here is that if you have an urgent need to do a target
>>>>>>>     This is of course under the control of the UAC. If the UAC chooses
>>>>>>>     to do
>>>>>>>     a target refresh with an UPDATE, and in conjunction with a session time
>>>>>>>     refresh (and/or offer) then it should be prepared for the consequences
>>>>>>>     I guess we could discuss how much (if any) of this logic ought to be
>>>>>>>     I don't think this alters the validity of using 491 for a session timer
>>>>>>>     glare situation.
>>>>>>>
>>>>>>>              Thanks,
>>>>>>>              Paul
>>>>>>>
>>>>>>>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>>      >
>>>>>>>      >      >> I'm not going to deny the solution with the 491 response,
>>>>>>>     but I
>>>>>>>      >      > The situation with session timers is different from target
>>>>>>>      >     refresh. Target refresh is updated for each UA independently.
>>>>>>>      >     Session timer is negotiated for the entire session, so more
>>>>>>>      >     sending UPDATE at the same time. If these UPDATE requests do not
>>>>>>>      >     carry SDP, currently they should be accepted. Resulting session
>>>>>>>      >     session timer state in this case is to refuse the UPDATE message,
>>>>>>>      >     similar to the session description collision. This is why 491 was
>>>>>>>      >     suggested.
>>>>>>>      >
>>>>>>>      >     are combined, as such they affect each other. And I think the
>>>>>>>     result
>>>>>>>      >     policy of each entity(UAC, proxies and UAS). Even so, should UAs
>>>>>>>      >   This should be no different than the UPDATE with SDP collision.
>>>>>>>     I am
>>>>>>>      >      >> 2. Handling of UPDATE transactions during initial INVITE
>>>>>>>      >      >> RFC6141 says, if in doubt, send a refresh request to confirm.
>>>>>>>      >      > This is exactly the reason why handling of UPDATE transaction
>>>>>>>      >     collisions needs to be resolved. If session timer ends up in an
>>>>>>>      >     ambiguous state, it is likely ambiguous for both UA and both
>>>>>>>     UA will
>>>>>>>      >     I suggest the method in RFC3261 Section 14.1 as a procedure
>>>>>>>     to avoid
>>>>>>>      >     collisions on retransmission. And we also need to decide how UAs
>>>>>>>      >     detect collisions.
>>>>>>>      >
>>>>>>>      >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 2 Jul 2020 10:39:56 -0400

On 7/2/20 1:35 AM, OKUMURA Shinji wrote:
> Hi,
> 
> UPDATE and PRACK transactions perform SDP negotiation, session timer 
> negotiation, etc., but also have the function of indicating the target 
> URI and confirming the provisional response. A 200 OK is interpreted as 
> a success response for all meanings, but we sometimes want to reject a 
> part of them.
> 
> I think that new header can specify the intended function in the request 
> or the unintended function in the response.
> 

Hmm.

Are you thinking of using the header with a 200 response, so that the 
transaction succeeds while still signaling that some aspect failed?

Or using it with a failure response to identify what aspects failed? (So 
that a retry might fix the bad part while leaving other parts alone.)

I'm interested to hear what others think. This wouldn't be hard to add. 
But the logic to act on the receipt of this header could be quite complex.

	Thanks,
	Paul

>>>> I subsequently realized that if we specify the use of 491 for ST 
>>>> then we must consider what happens in cases of interop with an older 
>>>> first will have to decide whether to use an option tag so the two 
>>>> can know who does and doesn't support them. If so, then the 491 
>>>> would not be used by either end in ST glare cases, and everything 
>>>> would work as currently.
>>>>
>>>> If no option tag is used, then the UA that supports it may send a 
>>>> 491 to indicate glare, but the other end won't, and also won't know 
>>>> out what the end that does support the extension can do to fix 
>>>> things as best it can.
>>>>
>>>>>>>> raising is not new. It affects session description updates as 
>>>>>>>> much as it does session timers.
>>>>>>>>
>>>>>>>> processing or network delays, as well as due to a packet loss. 
>>>>>>>> The delay introduced by 491 error response is generally 
>>>>>>>> comparable to transaction delay, so it normally does not 
>>>>>>>> introduce any new problems. All that should happen due to a 491 
>>>>>>>> response, is that the transaction should be retried with some 
>>>>>>>> delay and target refresh should happen slightly later.
>>>>>>>>
>>>>>>>> Considering that this is an existing design consideration which 
>>>>>>>> is not specific to SIP session timer, I do not think it warrants 
>>>>>>>> a discussion in the session timer document.
>>>>>>>
>>>>>>> My text was mostly just me explaining my reasoning for purposes 
>>>>>>> of the discussion. I'm inclined to agree that it doesn't need to 
>>>>>>> be discussed in the ST draft. It is not a new concern as far as 
>>>>>>> It isn't strictly backward compatible. But if a UAS uses it, I 
>>>>>>> bet there is a pretty good chance that a UAC receiving the 491 in 
>>>>>>> that context will do the right thing, or at least something 
>>>>>>> reasonable, even if it hasn't been updated for this change. Worst 
>>>>>>> case is for the call to fail.
>>>>>>>
>>>>>>>      Thanks,
>>>>>>>      Paul
>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> _____________
>>>>>>>> Roman Shpount
>>>>>>>>
>>>>>>>>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Jul 2020 11:29:11 -0400

Paul,

I can see how we can add a new option timer2 tag and include it in
negotiation. If UAS sees a Supported: timer2 in the INVITE/UPDATE, and it
supports the new procedures, it must include Require timer2 in the
response. This will indicate that both UAS and UAC follow the session timer
procedures in the new draft. The new timer2 can be included in parallel
with the existing timer option tag.
_____________
Roman Shpount

On Thu, Jul 2, 2020 at 10:40 AM Paul Kyzivat <[email-masked]> wrote:

> >>>>>>>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji
> >>>>>>>>      > <mailto:[email-masked]
> >>>>>>>>      >      >> 1. Handling of UPDATE with no SDP glare
> >>>>>>>>      >      >> I'm not going to deny the solution with the 491
> >>>>>>>> response,
> >>>>>>>>     but I
> >>>>>>>>      >     think it has a big impact.
> >>>>>>>>      >      >
> >>>>>>>>      >      > The situation with session timers is different
> >>>>>>>> from target
> >>>>>>>>      >     refresh. Target refresh is updated for each UA
> >>>>>>>> independently.
> >>>>>>>>      >     Session timer is negotiated for the entire session,
> >>>>>>>> so more
> >>>>>>>>      >     collision scenarios are possible. One of such
> >>>>>>>> scenarios is
> >>>>>>>>     both UA
> >>>>>>>>      >     sending UPDATE at the same time. If these
> >>>>>>>> UPDATE requests do not
> >>>>>>>>      >     carry SDP, currently they should be accepted.
> >>>>>>>> Resulting session
> >>>>>>>>      >     timer state is ambiguous. The only reliable way to
> >>>>>>>> prevent
> >>>>>>>>     ambiguous
> >>>>>>>>      >     session timer state in this case is to refuse the
> >>>>>>>> UPDATE message,
> >>>>>>>>      >     similar to the session description collision. This is
> >>>>>>>> why 491 was
> >>>>>>>>      >     suggested.
> >>>>>>>>      >
> >>>>>>>>      >     First of all, is a 491 rejected solution planned for
> >>>>>>>> bis?
> >>>>>>>>      >
> >>>>>>>>      >
> >>>>>>>>      > It was discussed but nothing is final.
> >>>>>>>>      >
> >>>>>>>>      >     If so, the UPDATE for target-refresh and the one for
> >>>>>>>>     session-refresh
> >>>>>>>>      >     are combined, as such they affect each other. And I
> >>>>>>>> think the
> >>>>>>>>     result
> >>>>>>>>      >     will be rarely ambiguous, if there is no change in the
> >>>>>>>>     session timer
> >>>>>>>>      >     policy of each entity(UAC, proxies and UAS). Even so,
> >>>>>>>> should UAs
> >>>>>>>>      >     reject the UPDATE request? If the UPDATE with new
> >>>>>>>>     remote-target-uri
> >>>>>>>>      >     is rejected, the UA will be unreachable.
> >>>>>>>>      >
> >>>>>>>>      >
> >>>>>>>>      >   This should be no different than the UPDATE with SDP
> >>>>>>>> collision.
> >>>>>>>>     I am
> >>>>>>>>      > not sure what problem you are talking about.
> >>>>>>>>      >
> >>>>>>>>      >      >> 2. Handling of UPDATE transactions during initial
> >>>>>>>> INVITE
> >>>>>>>>      >      >> RFC6141 says, if in doubt, send a refresh request
> >>>>>>>> to confirm.
> >>>>>>>>      >      > This is exactly the reason why handling of UPDATE
> >>>>>>>> transaction
> >>>>>>>>      >     collisions needs to be resolved. If session timer
> >>>>>>>> ends up in an
> >>>>>>>>      >     ambiguous state, it is likely ambiguous for both UA
> >>>>>>>> and both
> >>>>>>>>     UA will
> >>>>>>>>      >     initiate an UPDATE refresh request to confirm, which
> >>>>>>>> will
> >>>>>>>>     result in
> >>>>>>>>      >     a collision.
> >>>>>>>>      >
> >>>>>>>>      >     I suggest the method in RFC3261 Section 14.1 as a
> >>>>>>>> procedure
> >>>>>>>>     to avoid
> >>>>>>>>      >     collisions on retransmission. And we also need to
> >>>>>>>> decide how UAs
> >>>>>>>>      >     detect collisions.
> >>>>>>>>      >
> >>>>>>>>      >
> >>>>>>>>      > I am not sure what you are talking about.
> >>>>>>>>      > _____________
> >>>>>>>>      > Roman Shpount
> >>>>>>>>
> >>>>>>>
> >>>>>

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 3 Jul 2020 13:48:17 +0900

Paul,

> Are you thinking of using the header with a 200 response, so that the transaction succeeds while still signaling that some aspect failed?

For a 200 response, Yes.
About session timer, this header means that I(UAS) respond 200 but didn't agree about a session timer .

> This wouldn't be hard to add. But the logic to act on the receipt of this header could be quite complex.

I agree. It might not be so good.

Regards,
Shinji

On 2020/07/02 23:39, Paul Kyzivat wrote:
> Are you thinking of using the header with a 200 response, so that the transaction succeeds while still signaling that some aspect failed?
> 
> Or using it with a failure response to identify what aspects failed? (So that a retry might fix the bad part while leaving other parts alone.)
> 
> I'm interested to hear what others think. This wouldn't be hard to add. But the logic to act on the receipt of this header could be quite complex.
> 
>      Thanks,
>      Paul
> 
>> Regards,
>> Shinji
>>

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 3 Jul 2020 14:13:44 +0900

Paul,

If we use the 491 response to solve this issue, we might have to update the RFC 3311. Because this solution changes the way UAs treat UPDATE in general, not just session timer.

Regards,
Shinji