Subject: [sipcore] RFC4028 : bug in 11 Security Considerations

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 5 Jun 2020 16:34:27 +0900

Hi,

11.  Security Considerations
    Next, consider the case of a rogue UAS that wishes to force a UAC to
    generate refreshes at a rapid rate.  In that case, the UAC has to
    support session timer.  The initial INVITE arrives at the rogue UAS,
    which returns a 2xx with a very small session interval.  The UAC uses
    this timer and quickly sends a refresh.  Section 7.4 requires that
    the UAC copy the current session interval into the Session-Expires
    header field in the request.  This enables the proxies to see the
    current value.  The proxies will reject this request and provide a
    Min-SE with a higher minimum, which the UAC will then use.  Note,
    that if the proxies did not reject the request, but rather proxied
    the request with a Min-SE header field, an attack would still be
    possible.  The UAS could discard this header field in a 2xx response
    and force the UAC to continue to generate rapid requests.

If the rogue UAS returns again a 2xx with a very small session interval, the attack will continue. To prevent this case, I think the UAC and proxies SHOULD make sure that the SE-value and MSE-value in the response are greater than or equal to the MSE-value in a sent request. And ... what should the UAC and proxies do? Should they modify the response?

Is this included in the scope of the bis?

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Jun 2020 07:45:53 +0000

Hi,

If what you describe is a technical bug that causes interoperability problems, then it is within the scope.

However, if there is a rogue UAS, the UAC can simply terminate the session.

Regards,

Christer

-----Original Message-----
From: OKUMURA Shinji <[email-masked]> 
Sent: perjantai 5. kesäkuuta 2020 10.34
To: [email-masked]
Cc: Christer Holmberg <[email-masked]>
Subject: RFC4028 : bug in 11 Security Considerations

Hi,

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Fri, 5 Jun 2020 05:35:21 -0400

Proxy, if it receives a 2xx response with Min-SE header set to a value
lower then Min-SE set by the proxy in the corresponding request, should
increase Min-SE to the desired proxy value.

UAC, if it receives a 2xx response with Session-Expires set to a value
below Min-SE in the response or original request from the UAC. should
immediately terminate a call.

Unfortunately, proxy has no graceful way to terminate a call, so if both
UAC and UAS are rogue, this will result in frequent session refresh
transactions.

In practice, this is not an issue, since proxy, when communicating with
untrusted end points, typically have a some sort of dynamic rate limiter to
prevent denial of service attacks such as opensips PIKE module (
https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to
efficiently drop SIP message from badly behaving clients.

Best Regards,
_____________
Roman Shpount

On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> If the rogue UAS returns again a 2xx with a very small session interval,
> the attack will continue. To prevent this case, I think the UAC and proxies
> SHOULD make sure that the SE-value and MSE-value in the response are
> greater than or equal to the MSE-value in a sent request. And ... what
> should the UAC and proxies do? Should they modify the response?
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 5 Jun 2020 22:26:27 +0900

Hi,

A 200 response has no Min-SE header.

My suggestion is below.

In this case, the UAC and proxies should follow the procedures defined 
in section 7.2 and 8.2 as if the Session-Expires header field were not 
in the 2xx response.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Jun 2020 04:19:23 -0400

Shinji,

My instinct would be to allow Session-Expires header to pass through even
if it is below Min-SE value, and then let either UAC disconnect the call or
denial of service filter do its job and drop the session if it starts
sending too many requests.

Best Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 8 Jun 2020 18:13:34 +0900

Hi,

Sometimes only a proxy can notice the problem. If the value returned by a UAS is fine for the UAC, the UAC does not notice the problem.

Regards,
Shinji

On 2020/06/08 17:19, Roman Shpount wrote:
> Shinji,
> 
> My instinct would be to allow Session-Expires header to pass through even if it is below Min-SE value, and then let either UAC disconnect the call or denial of service filter do its job and drop the session if it starts sending too many requests.
> 
> Best Regards,
> _____________
> Roman Shpount
> 
> 
> On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>      > [email-masked] <mailto:[email-masked]>> wrote:
>      >
>      >> Hi,
>      >>
>      >> From: OKUMURA Shinji <[email-masked] <mailto:[email-masked]>>
>      >> To: [email-masked] <mailto:[email-masked]>
>      >> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]>>
>      >> [email-masked] <mailto:[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Jun 2020 16:49:35 -0400

Shinji,

Yes, only proxy is going to notice the problem, but since proxy needs to
deal with denial of service attacks anyway, it will deal with clients that
set Session-Timer to a value which is too small.

My view is that Min-SE is advisory. UA can disregard both Min-SE and
Session-Expires and send re-INVITE or UPDATE at any rate it wants. Proxy
would need to gracefully deal with it. We can update security
considerations to mention this, but once again, unless this is causing
known interop issues, I would prefer not to touch this.

Best Regards,
_____________
Roman Shpount

On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji <[email-masked]> wrote:

> Hi,
>
> Sometimes only a proxy can notice the problem. If the value returned by a
> UAS is fine for the UAC, the UAC does not notice the problem.
>
> Regards,
> Shinji
>
> > My instinct would be to allow Session-Expires header to pass through
> even if it is below Min-SE value, and then let either UAC disconnect the
> call or denial of service filter do its job and drop the session if it
> starts sending too many requests.
> >
> > Best Regards,
> > _____________
> > Roman Shpount
> >
> >
> >      >> If what you describe is a technical bug that causes
> interoperability
> >      >> problems, then it is within the scope.
> >      >>

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 9 Jun 2020 14:59:38 +0900

Roman,

This issue occurs really when current RFC-compliant UAC and proxies encounter such UAS. I don't know why you don't think this is a problem. And I don't like the policy that we don't have to do anything, as a good proxy will solve all the issues.

Regards,
Shinji

On 2020/06/09 5:49, Roman Shpount wrote:
> Shinji,
> 
> Yes, only proxy is going to notice the problem, but since proxy needs to deal with denial of service attacks anyway, it will deal with clients that set Session-Timer to a value which is too small.
> 
> My view is that Min-SE is advisory. UA can disregard both Min-SE and Session-Expires and send re-INVITE or UPDATE at any rate it wants. Proxy would need to gracefully deal with it. We can update security considerations to mention this, but once again, unless this is causing known interop issues, I would prefer not to touch this.
> 
> Best Regards,
> _____________
> Roman Shpount
> 
> 
> On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>      > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi,
>      >
>      >      > Proxy, if it receives a 2xx response with Min-SE header set to a value
>      >      > lower then Min-SE set by the proxy in the corresponding request, should
>      >      > increase Min-SE to the desired proxy value.
>      >      >
>      >      > UAC, if it receives a 2xx response with Session-Expires set to a value
>      >      > below Min-SE in the response or original request from the UAC. should
>      >      > immediately terminate a call.
>      >      >
>      >      > Unfortunately, proxy has no graceful way to terminate a call, so if both
>      >      > UAC and UAS are rogue, this will result in frequent session refresh
>      >      > transactions.
>      >      >
>      >      > In practice, this is not an issue, since proxy, when communicating with
>      >      > untrusted end points, typically have a some sort of dynamic rate limiter to
>      >      > prevent denial of service attacks such as opensips PIKE module (
>      >      > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to
>      >      > efficiently drop SIP message from badly behaving clients.
>      >      >
>      >      > Best Regards,
>      >      > _____________
>      >      > Roman Shpount
>      >      >
>      >      >
>      >      > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg <christer.holmberg=
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >      >
>      >      >> Hi,
>      >      >>
>      >      >> If what you describe is a technical bug that causes interoperability
>      >      >> problems, then it is within the scope.
>      >      >>
>      >      >> However, if there is a rogue UAS, the UAC can simply terminate the session.
>      >      >>
>      >      >> Regards,
>      >      >>
>      >      >> Christer
>      >      >>
>      >      >>
>      >      >>
>      >      >> -----Original Message-----
>      >      >> From: OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >> Sent: perjantai 5. kesäkuuta 2020 10.34
>      >      >> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >> Subject: RFC4028 : bug in 11 Security Considerations
>      >      >>
>      >      >> Hi,
>      >      >>
>      >      >> 11.  Security Considerations
>      >      >>      Next, consider the case of a rogue UAS that wishes to force a UAC to
>      >      >>      generate refreshes at a rapid rate.  In that case, the UAC has to
>      >      >>      support session timer.  The initial INVITE arrives at the rogue UAS,
>      >      >>      which returns a 2xx with a very small session interval.  The UAC uses
>      >      >>      this timer and quickly sends a refresh.  Section 7.4 requires that
>      >      >>      the UAC copy the current session interval into the Session-Expires
>      >      >>      header field in the request.  This enables the proxies to see the
>      >      >>      current value.  The proxies will reject this request and provide a
>      >      >>      Min-SE with a higher minimum, which the UAC will then use.  Note,
>      >      >>      that if the proxies did not reject the request, but rather proxied
>      >      >>      the request with a Min-SE header field, an attack would still be
>      >      >>      possible.  The UAS could discard this header field in a 2xx response
>      >      >>      and force the UAC to continue to generate rapid requests.
>      >      >>
>      >      >> If the rogue UAS returns again a 2xx with a very small session interval,
>      >      >> the attack will continue. To prevent this case, I think the UAC and proxies
>      >      >> SHOULD make sure that the SE-value and MSE-value in the response are
>      >      >> greater than or equal to the MSE-value in a sent request. And ... what
>      >      >> should the UAC and proxies do? Should they modify the response?
>      >      >>
>      >      >> Is this included in the scope of the bis?
>      >      >>
>      >      >> Regards,
>      >      >> Shinji
>      >      >> _______________________________________________
>      >      >> sipcore mailing list
>      >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >> https://www.ietf.org/mailman/listinfo/sipcore
>      >      >>
>      >      >
>      >
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jun 2020 02:45:24 -0400

Shinji

I am saying this issue is not a real issue since it should not affect any
real deployments. Do you see this causing problems anywhere?

Your solution, on the other hand, is potentially problematic since it will
cause a call to connect and then drop due to session timer expiration. I
would prefer normative behavior would not change unless someone is actually
affected by this. Any proxy which deals with untrusted UA should already
deal with this problem using denial of service protection. UAC should
disconnect the call if Session-Expires is less then it is willing to
support.
_____________
Roman Shpount

On Tue, Jun 9, 2020 at 1:59 AM OKUMURA Shinji <[email-masked]> wrote:

> Roman,
>
> This issue occurs really when current RFC-compliant UAC and proxies
> encounter such UAS. I don't know why you don't think this is a problem. And
> I don't like the policy that we don't have to do anything, as a good proxy
> will solve all the issues.
>
> Regards,
> Shinji
>
> >     Sometimes only a proxy can notice the problem. If the value returned
> by a UAS is fine for the UAC, the UAC does not notice the problem.
> >
> >     Regards,
> >     Shinji
> >
> >      > My instinct would be to allow Session-Expires header to pass
> through even if it is below Min-SE value, and then let either UAC
> disconnect the call or denial of service filter do its job and drop the
> session if it starts sending too many requests.
> >      >
> >      > Best Regards,
> >      > _____________
> >      > Roman Shpount
> >      >
> >      >
> >      > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>> wrote:
> >      >
> >      >     Hi,
> >      >
> >      >      > [email-masked] <mailto:
> [email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
> >      >      >
> >      >      >> Hi,
> >      >      >>
> >      >      >> From: OKUMURA Shinji <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>
> >      >      >> To: [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >      >      >> Cc: Christer Holmberg <[email-masked]
> <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>>
> >      >      >> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 10 Jun 2020 11:56:34 +0900

Roman,

Fortunately. I've not seen this problem. I don't think it really matters if it really happens. It's too late to rewrite the RFC after things happen.

When this security concern is left unchanged, as I noted previously, UAC may be satisfied with the SE value and start a session timer. In that case, there will be an infinite loop of 422 responses and the UAS returning a 200 response with a short SE value.
You argue that this overload does not need to be dealt with because the proxy handles it by other means.
I don't deny that solution either, but I don't see any harm in defining how it should be handled within the protocol as well.
On the other hand, you argue that my suggestion causes a disconnect after connecting. Even if it did, would that be a problem? You are arguing that the call should be disconnected.

#In a way, this seems to be another infinite loop.

Regards,
Shinji

On 2020/06/09 15:45, Roman Shpount wrote:
> Shinji
> 
> I am saying this issue is not a real issue since it should not affect any real deployments. Do you see this causing problems anywhere?
> 
> Your solution, on the other hand, is potentially problematic since it will cause a call to connect and then drop due to session timer expiration. I would prefer normative behavior would not change unless someone is actually affected by this. Any proxy which deals with untrusted UA should already deal with this problem using denial of service protection. UAC should disconnect the call if Session-Expires is less then it is willing to support.
> _____________
> Roman Shpount
> 
> 
> On Tue, Jun 9, 2020 at 1:59 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Roman,
> 
>      > On Mon, Jun 8, 2020 at 5:13 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi,
>      >
>      >      > Shinji,
>      >      > My instinct would be to allow Session-Expires header to pass through even if it is below Min-SE value, and then let either UAC disconnect the call or denial of service filter do its job and drop the session if it starts sending too many requests.
>      >      >
>      >      > Best Regards,
>      >      > _____________
>      >      > Roman Shpount
>      >      >
>      >      >
>      >      > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     Hi,
>      >      >
>      >      >     A 200 response has no Min-SE header.
>      >      >
>      >      >     My suggestion is below.
>      >      >
>      >      >     In this case, the UAC and proxies should follow the procedures defined
>      >      >     in section 7.2 and 8.2 as if the Session-Expires header field were not
>      >      >     in the 2xx response.
>      >      >
>      >      >     Regards,
>      >      >     Shinji
>      >      >
>      >      >     On 2020/06/05 18:35, Roman Shpount wrote:
>      >      >      > Proxy, if it receives a 2xx response with Min-SE header set to a value
>      >      >      > lower then Min-SE set by the proxy in the corresponding request, should
>      >      >      > increase Min-SE to the desired proxy value.
>      >      >      >
>      >      >      > UAC, if it receives a 2xx response with Session-Expires set to a value
>      >      >      > below Min-SE in the response or original request from the UAC. should
>      >      >      > immediately terminate a call.
>      >      >      >
>      >      >      > Unfortunately, proxy has no graceful way to terminate a call, so if both
>      >      >      > UAC and UAS are rogue, this will result in frequent session refresh
>      >      >      > transactions.
>      >      >      >
>      >      >      > In practice, this is not an issue, since proxy, when communicating with
>      >      >      > untrusted end points, typically have a some sort of dynamic rate limiter to
>      >      >      > prevent denial of service attacks such as opensips PIKE module (
>      >      >      > https://opensips.org/docs/modules/3.1.x/pike.html ) , which are used to
>      >      >      > efficiently drop SIP message from badly behaving clients.
>      >      >      >
>      >      >      > Best Regards,
>      >      >      > _____________
>      >      >      > Roman Shpount
>      >      >      >
>      >      >      >
>      >      >      > On Fri, Jun 5, 2020 at 3:46 AM Christer Holmberg <christer.holmberg=
>      >      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >      >
>      >      >      >> Hi,
>      >      >      >>
>      >      >      >> If what you describe is a technical bug that causes interoperability
>      >      >      >> problems, then it is within the scope.
>      >      >      >>
>      >      >      >> However, if there is a rogue UAS, the UAC can simply terminate the session.
>      >      >      >>
>      >      >      >> Regards,
>      >      >      >>
>      >      >      >> Christer
>      >      >      >>
>      >      >      >>
>      >      >      >>
>      >      >      >> -----Original Message-----
>      >      >      >> From: OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >> Sent: perjantai 5. kesäkuuta 2020 10.34
>      >      >      >> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      >> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >> Subject: RFC4028 : bug in 11 Security Considerations
>      >      >      >>
>      >      >      >> Hi,
>      >      >      >>
>      >      >      >> 11.  Security Considerations
>      >      >      >>      Next, consider the case of a rogue UAS that wishes to force a UAC to
>      >      >      >>      generate refreshes at a rapid rate.  In that case, the UAC has to
>      >      >      >>      support session timer.  The initial INVITE arrives at the rogue UAS,
>      >      >      >>      which returns a 2xx with a very small session interval.  The UAC uses
>      >      >      >>      this timer and quickly sends a refresh.  Section 7.4 requires that
>      >      >      >>      the UAC copy the current session interval into the Session-Expires
>      >      >      >>      header field in the request.  This enables the proxies to see the
>      >      >      >>      current value.  The proxies will reject this request and provide a
>      >      >      >>      Min-SE with a higher minimum, which the UAC will then use.  Note,
>      >      >      >>      that if the proxies did not reject the request, but rather proxied
>      >      >      >>      the request with a Min-SE header field, an attack would still be
>      >      >      >>      possible.  The UAS could discard this header field in a 2xx response
>      >      >      >>      and force the UAC to continue to generate rapid requests.
>      >      >      >>
>      >      >      >> If the rogue UAS returns again a 2xx with a very small session interval,
>      >      >      >> the attack will continue. To prevent this case, I think the UAC and proxies
>      >      >      >> SHOULD make sure that the SE-value and MSE-value in the response are
>      >      >      >> greater than or equal to the MSE-value in a sent request. And ... what
>      >      >      >> should the UAC and proxies do? Should they modify the response?
>      >      >      >>
>      >      >      >> Is this included in the scope of the bis?
>      >      >      >>
>      >      >      >> Regards,
>      >      >      >> Shinji
>      >      >      >> _______________________________________________
>      >      >      >> sipcore mailing list
>      >      >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      >> https://www.ietf.org/mailman/listinfo/sipcore
>      >      >      >>
>      >      >      >
>      >      >
>      >
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jun 2020 16:35:30 -0400

On 6/9/20 1:59 AM, OKUMURA Shinji wrote:
> encounter such UAS. I don't know why you don't think this is a problem. 
> And I don't like the policy that we don't have to do anything, as a good 
> proxy will solve all the issues.

I've been doing my best to keep my mouth shut on this thread. I'm going 
to violate that once and then go back to being silent.

I don't understand the desire to bound the scope so severely. RFC4028 is 
15 years old, and the majority of the content is closer to 20 years old. 
There has been ongoing confusion about it over the entire 15 years. Once 
the effort is made to open it I find it nonsensical to close it again 
while leaving known issues untouched.

ISTM is whether there is energy to make other fixes. If Shinji is 
willing to do the work to cover other things then why not accept that work?

	Thanks,
	Paul

>> Yes, only proxy is going to notice the problem, but since proxy needs 
>> to deal with denial of service attacks anyway, it will deal with 
>> clients that set Session-Timer to a value which is too small.
>>
>> Session-Expires and send re-INVITE or UPDATE at any rate it wants. 
>> Proxy would need to gracefully deal with it. We can update security 
>>     Sometimes only a proxy can notice the problem. If the value 
>> returned by a UAS is fine for the UAC, the UAC does not notice the 
>> problem.
>>
>>     Regards,
>>     Shinji
>>
>>      > My instinct would be to allow Session-Expires header to pass 
>> disconnect the call or denial of service filter do its job and drop 
>> the session if it starts sending too many requests.
>>      >
>>      > Best Regards,
>>      > _____________
>>      > Roman Shpount
>>      >
>>      >
>>      > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji 
>> <[email-masked] <mailto:[email-masked]> 
>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>      >
>>      >     Hi,
>>      >
>>      >      > [email-masked] 
>> <mailto:[email-masked]> 
>> <mailto:[email-masked] 
>>      >      >> From: OKUMURA Shinji <[email-masked] 
>> <mailto:[email-masked]> <mailto:[email-masked] 
>> <mailto:[email-masked]>>>
>>      >      >> To: [email-masked] <mailto:[email-masked]> 
>> <mailto:[email-masked] <mailto:[email-masked]>>
>>      >      >> Cc: Christer Holmberg <[email-masked] 
>> <mailto:[email-masked]> 
>> <mailto:[email-masked] 
>> <mailto:[email-masked]>>>
>>      >      >> [email-masked] <mailto:[email-masked]> 
>> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Jun 2020 17:29:03 -0400

> willing to do the work to cover other things then why not accept that work?
First of all, I really think this is a hypothetical problem which has no
good backwards compatible solution. Fixing it will cause more trouble then
leaving it be.

Second, I am interested in a document update that targets existing interop
problems with minimal changes to the rest of the document. This
increases the chances of the specification actually being implemented. If
changes are too drastic (even if they make the document clearer and more
readable), there is a much higher chance that implementers will just ignore
the whole update. As far as I am concerned, there are certain things that
make my life easier which I need fixed as quickly as possible. I can accept
things that make other people's lives easier if they do not slow down the
progress of the overall document too much. If something did not cause any
real issues over the past 20 years, as far as I am concerned, it can stay
unchanged.

Finally, there was a group consensus on what this update was about (fixing
session timer glare and session timer configuration when multiple
transactions are in progress). We either need to ask a group for consensus
to widen the scope or potentially do it in the subsequent update.

Best Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Jun 2020 10:14:20 +0900

Thank you, Paul.

My proposal contains insufficient detail, but I would like to discuss it further here. If necessary, I will try to cooperate in documentation as much as possible.

Regards,
Shinji

On 2020/06/11 5:35, Paul Kyzivat wrote:
> I've been doing my best to keep my mouth shut on this thread. I'm going to violate that once and then go back to being silent.
> 
> I don't understand the desire to bound the scope so severely. RFC4028 is 15 years old, and the majority of the content is closer to 20 years old. There has been ongoing confusion about it over the entire 15 years. Once the effort is made to open it I find it nonsensical to close it again while leaving known issues untouched.
> 
> ISTM is whether there is energy to make other fixes. If Shinji is willing to do the work to cover other things then why not accept that work?
> 
>      Thanks,
>      Paul
> 
>> Regards,
>> Shinji
>>
>>>      > On Fri, Jun 5, 2020 at 9:26 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>      >
>>>      >     Hi,
>>>      >
>>>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>      >      >
>>>      >      >> Hi,
>>>      >      >>
>>>      >      >> From: OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>>      >      >> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>      >      >> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>>      >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Jun 2020 10:47:57 +0900

Hi,

> First of all, I really think this is a hypothetical problem which has no good backwards compatible solution. Fixing it will cause more trouble then leaving it be.

If you think that my proposal has no good backwards compatible solution, please point out your concerns more specifically. So we can proceed with the discussion.
  
> Second, I am interested in a document update that targets existing interop problems with minimal changes to the rest of the document. This increases the chances of the specification actually being implemented. If changes are too drastic (even if they make the document clearer and more readable), there is a much higher chance that implementers will just ignore the whole update. As far as I am concerned, there are certain things that make my life easier which I need fixed as quickly as possible. I can accept things that make other people's lives easier if they do not slow down the progress of the overall document too much. If something did not cause any real issues over the past 20 years, as far as I am concerned, it can stay unchanged.

We've waited 20 years, so it doesn't matter if it takes a few more months...
What do you need to fix as quickly as possible?

> Finally, there was a group consensus on what this update was about (fixing session timer glare and session timer configuration when multiple transactions are in progress). We either need to ask a group for consensus to widen the scope or potentially do it in the subsequent update.

It will be needed.

Regards,
Shinji

On 2020/06/11 6:29, Roman Shpount wrote:
> On Wed, Jun 10, 2020 at 4:35 PM Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
> 
> First of all, I really think this is a hypothetical problem which has no good backwards compatible solution. Fixing it will cause more trouble then leaving it be.
> 
> Second, I am interested in a document update that targets existing interop problems with minimal changes to the rest of the document. This increases the chances of the specification actually being implemented. If changes are too drastic (even if they make the document clearer and more readable), there is a much higher chance that implementers will just ignore the whole update. As far as I am concerned, there are certain things that make my life easier which I need fixed as quickly as possible. I can accept things that make other people's lives easier if they do not slow down the progress of the overall document too much. If something did not cause any real issues over the past 20 years, as far as I am concerned, it can stay unchanged.
> 
> Finally, there was a group consensus on what this update was about (fixing session timer glare and session timer configuration when multiple transactions are in progress). We either need to ask a group for consensus to widen the scope or potentially do it in the subsequent update.
> 
> Best Regards,
> _____________
> Roman Shpount
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 12 Jun 2020 03:16:33 -0400

Shinji,

First of all, we are dealing with a situation where a lot of original SIP
shortcomings prevent us from developing a good fix. Specifically the
following things makes good implementations of session timer possible:

1. Session Timer should have been required. In a properly designed system,
all dialogs must be initiated with expected duration. This prevents
occurance of "zombie" sessions. The fact that Session-Timer is optional and
can fail to negotiate makes proper implementation of this difficult.

2. UPDATE without SDP should be exclusively used for session refresh. The
fact that UPDATE implementation is optional, produces a lot of issues as
well

3. Proxy should be able to terminate the dialog. Without this proxy has no
way to handle an invalid data present in the 2XX response and most of the
time can only silently observe, even though the call should have been
terminated.

4. Parallel proxying is badly broken. It is underspecified, almost never
properly implemented and causes multiple issues when anyone attempts to
actually use it.

This being said, I will try to answer your questions inline

On Thu, Jun 11, 2020 at 9:48 PM OKUMURA Shinji <[email-masked]>
wrote:

> If you think that my proposal has no good backwards compatible solution,
> please point out your concerns more specifically. So we can proceed with
> the discussion.
>

You are proposing a significant proxy behavior change, forcing the proxy to
remove Session-Expires from a 2XX response when it is less than Min-SE in
the original request. This will cause calls, which were operational
(session refreshes more often then Min-SE but not often enough to trigger
rate based blocking) to fail. It will also cause a delayed failure with no
visible cause to UAC, which is undesirable from the operational standpoint
since it makes things hard to troubleshoot.

> > Second, I am interested in a document update that targets existing
> interop problems with minimal changes to the rest of the document. This

We need to fix the following:
1. Handling of UPDATE with no SDP glare
2. Handling of UPDATE transactions during initial INVITE

These things cause issues when preconditions are used and multiple UPDATE
are sent during the initial call setup. We have not used preconditions for
the past 20 years and these failures are something that started affecting
real deployments for the past couple of years only. This caused the pain
level to rise enough so that people decided to update the Session-Timer
specification. Realistically, what would be ideal is the document that
addresses these issues and nothing else. It would make it easier to point
this document to people who face them and offer it as a solution. If the
same document fixes 100 other unrelated issues, it would make a lot harder
to figure out which changes are required to address the specific problem
actually affecting people.

The initial plan was to write a separate document which only fixes this
specific problem and updates RFC 4028. As we started writing this document,
we saw that fixes affect multiple sections of RFC 4028, so the resulting
document was becoming very hard to read. So, the consensus was do an RFC
4028 bis, but only change the portions needed to fix this specific problem.

Best Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Jun 2020 18:08:12 +0900

Roman,

Your E-Mail is so diverse, so I will reply to a part of them.

> You are proposing a significant proxy behavior change, forcing the proxy to remove Session-Expires from a 2XX response when it is less than Min-SE in the original request. This will cause calls, which were operational (session refreshes more often then Min-SE but not often enough to trigger rate based blocking) to fail. It will also cause a delayed failure with no visible cause to UAC, which is undesirable from the operational standpoint since it makes things hard to troubleshoot.

At 1st, I didn't suggest that the proxy should remove SE from 2xx. I suggested that the proxy should increase SE-value greater than Min-SE in the original request.
In the first place, the response of UAS is against the rules, so the problem is not that the connection fails, but that the connection succeeds with incorrect parameters.
If proxy increases SE-value to a reasonable level, the UAC can refresh the session with a reasonable frequency.

This is it for now.

Regards,
Shinji

On 2020/06/12 16:16, Roman Shpount wrote:
> Shinji,
> 
> First of all, we are dealing with a situation where a lot of original SIP shortcomings prevent us from developing a good fix. Specifically the following things makes good implementations of session timer possible:
> 
> 1. Session Timer should have been required. In a properly designed system, all dialogs must be initiated with expected duration. This prevents occurance of "zombie" sessions. The fact that Session-Timer is optional and can fail to negotiate makes proper implementation of this difficult.
> 
> 2. UPDATE without SDP should be exclusively used for session refresh. The fact that UPDATE implementation is optional, produces a lot of issues as well
> 
> 3. Proxy should be able to terminate the dialog. Without this proxy has no way to handle an invalid data present in the 2XX response and most of the time can only silently observe, even though the call should have been terminated.
> 
> 4. Parallel proxying is badly broken. It is underspecified, almost never properly implemented and causes multiple issues when anyone attempts to actually use it.
> 
> On Thu, Jun 11, 2020 at 9:48 PM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
> You are proposing a significant proxy behavior change, forcing the proxy to remove Session-Expires from a 2XX response when it is less than Min-SE in the original request. This will cause calls, which were operational (session refreshes more often then Min-SE but not often enough to trigger rate based blocking) to fail. It will also cause a delayed failure with no visible cause to UAC, which is undesirable from the operational standpoint since it makes things hard to troubleshoot.
> 
> These things cause issues when preconditions are used and multiple UPDATE are sent during the initial call setup. We have not used preconditions for the past 20 years and these failures are something that started affecting real deployments for the past couple of years only. This caused the pain level to rise enough so that people decided to update the Session-Timer specification. Realistically, what would be ideal is the document that addresses these issues and nothing else. It would make it easier to point this document to people who face them and offer it as a solution. If the same document fixes 100 other unrelated issues, it would make a lot harder to figure out which changes are required to address the specific problem actually affecting people.
> 
> The initial plan was to write a separate document which only fixes this specific problem and updates RFC 4028. As we started writing this document, we saw that fixes affect multiple sections of RFC 4028, so the resulting document was becoming very hard to read. So, the consensus was do an RFC 4028 bis, but only change the portions needed to fix this specific problem.
> 
> Best Regards,
> _____________
> Roman Shpount
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 13 Jun 2020 01:03:10 +0900

Hi,

> 1. Handling of UPDATE with no SDP glare

Specifically what is this issue?

> 2. Handling of UPDATE transactions during initial INVITE

I think the simplest solution is that SE and MSE headers should be ignored during early dialog. Because with respect to a session-timer, 2xx response is the only answer to an initial INVITE.

Regards,
Shinji

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 12 Jun 2020 22:53:19 +0600

Hi,  in-line below.
ThanksSamir

On 6/12/2020 at 9:33 PM, "OKUMURA Shinji"  wrote:Hi,

> 2. Handling of UPDATE transactions during initial INVITE

I think the simplest solution is that SE and MSE headers should be
ignored during early dialog. Because with respect to a session-timer,
2xx response is the only answer to an initial INVITE.

SS>> SE and MSE cannot be ignored in early dialog. Early dialog can be
spanned over for 30 minutes or so. It can be larger than hour.  Long
time to get final answer. Yr wait time is dependent on the rush hour
or so.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Fri, 12 Jun 2020 13:37:59 -0400

> Specifically what is this issue?

If both UA send the UPDATE with no SDP, according to the current
specification it is not considered glare and 491 response is not sent. If
both UPDATE transactions change session timer parameters, such as refresher
at the same time, then the negotiated result can be ambiguous. Best
solution would be to force the 491 response if two UPDATE without SDP
contain session timer parameters.

> I think the simplest solution is that SE and MSE headers should be ignored
> during early dialog. Because with respect to a session-timer, 2xx response
> is the only answer to an initial INVITE.
>

This is not that simple.

You can have an UPDATE transaction which starts before 2XX for the INVITE
transaction is sent with 2XX response for UPDATE arriving before or after
2XX for the INVITE depending on the network paths or network delays. If
different session timer parameters were used for UPDATE and INVITE, the
negotiated session timer is ambiguous. Also, the definition of during the
INVITE transaction is ambiguous as well. Due to network delays, it will be
different for UAC, UAS and proxies in the path.

Another question was when does the session timer start? Is it from the time
that the INVITE/UPDATE message was sent or was it from the time 2XX
response was received.

I am not actually looking for answers in this thread. I am just letting you
know what issues I need resolved. This group actually spent a considerable
amount of time discussing the solutions for all of this, so the best option
would be to restart the discussion for each of those issues in a separate
thread with a quick recap of what was already discussed.

Thank You,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 13 Jun 2020 12:16:01 +0900

Hi,

I don't doubt that a session-timer starts when the 2xx response is received. I think this is another item that should be clarified. So I don't think it's a problem if the early dialog has a longer duration. And the validity of early dialogs depends on the Expires header in an initial INVITE request, doesn't it?

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 13 Jun 2020 18:05:07 +0900

Hi,

> 1. Handling of UPDATE with no SDP glare

This issue should have been a main scope in the first place. And there have been a lot of discussion about this kind of glare at the time of the consideration of RFC 6141.
I think we can adapt the same solution. Rather, I've thought that this text was proposing such a solution.

I'm not going to deny the solution with the 491 response, but I think it has a big impact. It seems strange to me that I would point this out.

> 2. Handling of UPDATE transactions during initial INVITE

First of all, I have no doubt that a session-timer is started when a 2xx response of an initial INVITE is received. In other words, a session-timer is not activated during an early dialog.

And the UPDATE order problem is one of original(RFC3311) SIP shortcomings.
RFC6141 says, if in doubt, send a refresh request to confirm.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Jun 2020 17:17:08 -0400

Hi Shinji,

On Sat, Jun 13, 2020 at 5:05 AM OKUMURA Shinji <[email-masked]>
wrote:

> This issue should have been a main scope in the first place. And there
> have been a lot of discussion about this kind of glare at the time of the
> consideration of RFC 6141.
> I'm not going to deny the solution with the 491 response, but I think it
> has a big impact. It seems strange to me that I would point this out.
>

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, I have no doubt that a session-timer is started when a 2xx
> response of an initial INVITE is received. In other words, a session-timer
> is not activated during an early dialog.
>

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.

Best Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 24 Jun 2020 14:04:12 +0900

Roman,

>> 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?
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 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.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Jun 2020 15:19:51 -0400

On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji <[email-masked]>
wrote:

> > 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.
>

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.

> 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: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Jun 2020 18:50:21 -0400

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]>> wrote:
> 
>      > 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.
> 
>     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.
> 
>      > 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.
> 
>     collisions on retransmission. And we also need to decide how UAs
>     detect collisions.
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Jun 2020 14:20:48 -0400

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.

Best Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jun 2020 15:24:33 -0400

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.
> 
> 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.
> 
> 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:
> 
>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji
>      >      >> 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
>      >      >> 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

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 27 Jun 2020 20:02:24 +0900

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. 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?

Regards,
Shinji

On 2020/06/26 4:24, Paul Kyzivat wrote:
>> 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:
>>
>>      > On Wed, Jun 24, 2020 at 1:04 AM OKUMURA Shinji
>>      > <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
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Jun 2020 11:45:38 -0400

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.

	Thanks,
	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.
>>
>> 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
>>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Jun 2020 14:38:31 -0400

Some further thoughts on this...

On 6/27/20 11:45 AM, Paul Kyzivat wrote:
>> A UA accepts both requests, compares two results, (if necessary) sends 

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.

>>>> is not new. It affects session description updates as much as it 
>>>> does session timers.
>>>>
>>>> due to a 491 response, is that the transaction should be retried 
>>>> with some delay and target refresh should happen slightly later.
>>>>
>>> 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.
>>>

---

From: Roman Shpount <[email-masked]>
Date: Sat, 27 Jun 2020 18:17:24 -0400

I agree on the option tag. It would be helpful to identify UAs which
support the new draft during interop and troubleshooting network issues.

This being said, I do not think we need to worry about UA which would not
handle 491 responses to UPDATE properly. We only expand when 491 repose is
generated.  Handling 491 response is already a SHOULD in
https://tools.ietf.org/html/rfc3311#section-5.3 regardless of the
presence of the offer in the original UPDATE message.

Best Regards,
_____________
Roman Shpount

On Sat, Jun 27, 2020 at 2:38 PM Paul Kyzivat <[email-masked]> wrote:

> >>>>      >      >> I'm not going to deny the solution with the 491
> >>>> response,
> >>>>     but I
> >>>>      >     are combined, as such they affect each other. And I think
> >>>> the
> >>>>     result
> >>>>      >   This should be no different than the UPDATE with SDP
> >>>> collision.
> >>>>     I am
> >>>>      >     ambiguous state, it is likely ambiguous for both UA and
> both
> >>>>     UA will

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 29 Jun 2020 20:53:25 +0900

Hi Paul,

> 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 understand your suggestion. Probably my suggestion might be a bit more complicated than the 491 response.
However, the 491 response may not be so simple. I think we need to differentiate from the 500 response.

                       A                      B
                       |                      |
                       |INVITE                |
                    +->|--------------------->|<-+
Don't send INVITE  |  |                      |  | Don't send INVITE
Don't send UPDATE  |  |                      |  | Don't send UPDATE
491 to INVITE      |  |                      |  | 500 to INVITE
491 to UPDATE      |  |            2xx(offer)|  | 500 to UPDATE
                    +->|<---------------------|<-+
Don't send INVITE  |  |                      |  | Don't send INVITE
Don't send UPDATE  |  |                      |  | Don't send UPDATE
491 to INVITE      |  |                      |  | 500 to INVITE
491 to UPDATE      |  |ACK(answer)           |  | 500 to UPDATE
                    +->|--------------------->|<-+
                    v  |                      |  v

Regards,
Shinji

On 2020/06/28 0:45, Paul Kyzivat wrote:
>> 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.
> 
>      Thanks,
>      Paul
> 
>> Regards,
>> Shinji
>>

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 29 Jun 2020 22:14:04 +0900

According to current regulations, UAs treat UPDATE with SDP as follows:

                       A                      B
                       |                      |
                       |INVITE(offer)         |
                    +->|--------------------->|<-+
Don't send INVITE  |  |                      |  | Don't send INVITE
Don't send UPDATE  |  |                      |  | Don't send UPDATE
491 to INVITE      |  |                      |  | 500 to INVITE
491 to UPDATE      |  |           2xx(answer)|  | 500 to UPDATE
                    +->|<---------------------|<-+
may send INVITE    |  |                      |  | may send INVITE
may send UPDATE    |  |                      |  | may send UPDATE
may accept INVITE  |  |                      |  | may accept INVITE
may accept UPDATE  |  |ACK                   |  | may accept UPDATE
                    |  |--------------------->|  |
                    v  |                      |  v

                       A                      B
                       |                      |
                       |INVITE                |
                    +->|--------------------->|<-+
Don't send INVITE  |  |                      |  | Don't send INVITE
Don't send UPDATE  |  |                      |  | Don't send UPDATE
491 to INVITE      |  |                      |  | 500 to INVITE
491 to UPDATE      |  |                   4xx|  | 500 to UPDATE
                    +->|<---------------------+<-+
                       |                      |  | Don't send INVITE
                       |                      |  | may send UPDATE
                       |                      |  | may accept INVITE
                       |ACK                   |  | may accept UPDATE
                    +->|--------->    ------->|<-+
                    v  |                      |  v
                       |                      |
        (4xx and ACK to it are atomic.)

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jun 2020 15:53:26 -0400

Shinji,

IIUC you are suggesting to use the same rules for ST as for O/A.

I don't think your diagrams are sufficient to describe the rules. They 
only talk about the types of messages, not the content of the messages.

I think maybe we need to consider that there should probably not be 
separate rules for O/A and ST. Rather, a unified set of rules that cover 
both.

For one thing, in all of the messages that are being used for O/A it is 
actually the case that ST is being negotiated, even if only in the negative.

An interesting odd case is if an INVITE is used to initiate an O/A, and 
then an UPDATE is used within it to negotiate ST but not carrying any SDP.

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.

	Thanks,
	Paul

On 6/29/20 9:14 AM, OKUMURA Shinji wrote:
>>> 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.
>>
>>>> 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.
>>>
>>>> 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.
>>>
>>>      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 
>>>>> discussed in the ST draft. It is not a new concern as far as 
>>>>> whether to use 491 to resolve ST glare.
>>>>>
>>>>> during session timer refresh is a real thing, and that extending 
>>>>> the use of 491 to apply to that situation is appropriate.
>>>>>
>>>>> 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:
>>>>>>
>>>>>>     This is of course under the control of the UAC. If the UAC 
>>>>>> chooses
>>>>>>     to do

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Jun 2020 17:02:38 -0400

> 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.

Best Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 30 Jun 2020 13:32:30 +0900

Hi Paul,

My diagrams were drawn assuming there is no SDP in the UPDATE request.
One of the issues is when the ST negotiation(initiated by INVITE) period ends. 20xx, 4xx or ACK?

> I think maybe we need to consider that there should probably not be separate rules for O/A and ST. Rather, a unified set of rules that cover both.

I agree with you. But O/A rules are written based on offer and answer, not transactions, so it's not easy to make a unified set. And this rule is likely to be further complicated by the fact that the ST cannot handle 18x responses.

Regards,
Shinji

On 2020/06/30 4:53, Paul Kyzivat wrote:
> I don't think your diagrams are sufficient to describe the rules. They only talk about the types of messages, not the content of the messages.
> 
> I think maybe we need to consider that there should probably not be separate rules for O/A and ST. Rather, a unified set of rules that cover both.
> 
> For one thing, in all of the messages that are being used for O/A it is actually the case that ST is being negotiated, even if only in the negative.
> 
> An interesting odd case is if an INVITE is used to initiate an O/A, and then an UPDATE is used within it to negotiate ST but not carrying any SDP.
> 
> 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.
> 
>      Thanks,
>      Paul
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 30 Jun 2020 22:51:32 +0900

Sorry.

My diagrams were drawn assuming the UPDATE request contains an SDP offer.

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 1 Jul 2020 09:49:44 +0900

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.

Regards,
Shinji

On 2020/06/28 3:38, Paul Kyzivat wrote:
> 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
>>>