Subject: [sipcore] RFC4028 : Clarification of "cleared" in 7.4

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 6 Jun 2020 14:44:03 +0900

HI,

========================================================================
7.4.  Generating Subsequent Session Refresh Requests
    The value of the Min-SE header field present in a session refresh
    request MUST be the largest value among all Min-SE header field
    values returned in all 422 responses or received in session refresh
    requests, on the same dialog, if a dialog has been established.  If
    no dialog has been established, the Min-SE header field value is set
    to the largest value among all Min-SE header field values returned in
    all 422 responses for an INVITE request with the same Call-ID.  A
    result of this rule is that the maximum value of the Min-SE is
    effectively 'cleared' once the dialog is established, and from that
    point on, only the values from proxies known to be on the proxy path
    will end up being used.
========================================================================

My interpretation is as shown in the figure below.

    Alice      Proxy P1
      |(1) INVITE  |
      |SE: 1200    |
      |MSE: 300    |
      |----------->|   <-- initial MSE is 300
      |(2) 422     |
      |MSE: 900    |
      |<-----------|   <-- MSE is set to 900
      |(3) ACK     |
      |----------->|
      |(4) INVITE  |
      |SE:1200     |
      |MSE:900     |
      |----------->|
      |(5) 200 OK  |
      |SE:900      |
      |<-----------|   <-- dialog is established and MSE is cleared
      |(6) ACK     |
      |----------->|
      |(7) UPDATE  |
      |SE:900      |
      |MSE:300     |
      |----------->|   <-- MSE is 300

In order to understand this description clearly, I think it is necessary 
to show concrete examples. And when an early dialog is established, 
another examples is necessary.

Regards,
Shinji

---

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

Shinji,

This seems like a clarification, not a correction. I think it only should
be addressed if there are known issues caused by this.
_____________
Roman Shpount

On Sat, Jun 6, 2020 at 1:44 AM OKUMURA Shinji <[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 9 Jun 2020 11:17:36 +0900

Roman,

This is a clarification. So this does not cause any issues.
But I think it's unclear that a Min-SE header in UPDATE is initialized as a result.
Do you agree on this point?

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jun 2020 00:29:10 -0400

Shinji,

Each change that you propose, even if it is editorial or a simple
clarification, would cause the group to analyse and review the whole
affected section as if it was written from scratch. This can result in
additional months of work for people writing and reviewing the document.
This is why the scope for the current document update was limited to fixing
the glare issue and any other issues that are causing current interop
issues.

Does the thing you have mentioned cause any known interop issues? If it
does not, we are not going to touch this.

BTW, your example is incorrect. If (1) INVITE  had SE set to 1200, it
should not get the 422 response with Min-SE 900. Since the value of SE in
the INVITE was higher than Min-SE required by proxy, INVITE should have
been proxied, and the Min-SE value in the INVITE request increased.
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 9 Jun 2020 15:11:22 +0900

Roman,

I think my suggestions are not just editorial or a simple clarification.
I'm saying that current RFC4028 causes any interop issues.

The session-timer glare is the main scope, I see. I see also a new invention is out of scope, but Errata, bug-fix and clarification are in the scope. 4028bis does not only update RFC4028, but obsoletes it. Also, I don't think a full revision is necessary. If necessary, I will write it.

For my example, there are other proxies omitted from the diagram.
P1 reduces SE to 300.
P2 rejects by 422.

Regards,
Shinji

On 2020/06/09 13:29, Roman Shpount wrote:
> Shinji,
> 
> Each change that you propose, even if it is editorial or a simple clarification, would cause the group to analyse and review the whole affected section as if it was written from scratch. This can result in additional months of work for people writing and reviewing the document. This is why the scope for the current document update was limited to fixing the glare issue and any other issues that are causing current interop issues.
> 
> Does the thing you have mentioned cause any known interop issues? If it does not, we are not going to touch this.
> 
> BTW, your example is incorrect. If (1) INVITE  had SE set to 1200, it should not get the 422 response with Min-SE 900. Since the value of SE in the INVITE was higher than Min-SE required by proxy, INVITE should have been proxied, and the Min-SE value in the INVITE request increased.
> _____________
> Roman Shpount
> 
> 
> On Mon, Jun 8, 2020 at 10:17 PM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Roman,
> 
>      > On Sat, Jun 6, 2020 at 1:44 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      >> HI,
>      >>
>      >> [email-masked] <mailto:[email-masked]>

---

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

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

> The session-timer glare is the main scope, I see. I see also a new
> invention is out of scope, but Errata, bug-fix and clarification are in the
> scope. 4028bis does not only update RFC4028, but obsoletes it. Also, I
> don't think a full revision is necessary. If necessary, I will write it.
>

I think clarifications are in-scope and they address real issues in the
field.

> For my example, there are other proxies omitted from the diagram.
I see. This is interesting since this will cause subsequent UPDATE to be
refused with 422 by the proxy P2 and then resent  by UAC with higher Min-SE
and lower SE value.

Do you see this happening in practice?

Thank You,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 9 Jun 2020 18:20:29 +0900

Roman,

And more interesting, if P2 is not present in a dialog, SE may be lower than 900.
But I've not seen. To be exact, I wouldn't notice it, if it happens.

Regards,
Shinji

On 2020/06/09 15:37, Roman Shpount wrote:
> On Tue, Jun 9, 2020 at 2:11 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I think clarifications are in-scope and they address real issues in the field.
> 
> I see. This is interesting since this will cause subsequent UPDATE to be refused with 422 by the proxy P2 and then resent  by UAC with higher Min-SE and lower SE value.
>