Subject: [sipcore] RFC4028 : sessiontimer-race

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 18 Jun 2020 18:48:05 +0900

Christer,

Will you apply the following solutions to bis?

draft-ietf-sipcore-sessiontimer-race-02
1.2.  Solution

    This document updates [RFC4028], by clarifying the procedures for
    negotiating usage of the Session Initiation Protocol (SIP) [RFC3261]
    session timer mechanism [RFC4028].  The following clarifications are
    provided:

    o  A Session-Expires header field can only be included in a session
       refresh request if there is no ongoing negotiation of usage of the
       session timer mechanism, and if there is no ongoing INVITE
       transaction.
    o  A user agent shall, if it receives a session refresh request with a
       Session-Expires header field during an ongoing negotiation of
       usage of the session timer mechanism, or when there is an ongoing
       INVITE transaction, send a 491 (Request Pending) response to the
       request.
    o  The absence of a Session-Expires header field in a response will
       disable usage of the session timer mechanism only if the
       associated request contained a Session-Expires header field.

Assuming all entities(UAC, UAS and proxies) keep a consistent policy for their own session-timer, even if transactions conflict, I think the results are also consistent.
Does the request still need to be reject with 491 in spite of no glare?
And an UPDATE request is used for updating a remote-target-uri as well as the session timer.
Should UAs reject the UPDATE?

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Jun 2020 02:44:24 -0400

This is broken and not the solution for the session timer
collision problem.

Session-Expires is inserted by proxies. Proxies cannot reliably determine
that another transaction is in progress. UA refusing session expires if
another transaction is in progress will break existing implementations.
_____________
Roman Shpount

On Thu, Jun 18, 2020 at 5:48 AM OKUMURA Shinji <[email-masked]>
wrote:

> Assuming all entities(UAC, UAS and proxies) keep a consistent policy for
> their own session-timer, even if transactions conflict, I think the results
> are also consistent.
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 22 Jun 2020 18:15:19 +0900

Roman,

I thought you were in favor of the draft proposal, but were you against it?
And if both session refresh requests are rejected with 491, will the proxy be negatively affected?

Regards,
Shinji

On 2020/06/22 15:44, Roman Shpount wrote:
> This is broken and not the solution for the session timer collision problem.
> 
> Session-Expires is inserted by proxies. Proxies cannot reliably determine that another transaction is in progress. UA refusing session expires if another transaction is in progress will break existing implementations.
> _____________
> Roman Shpount
> 
> 
> On Thu, Jun 18, 2020 at 5:48 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Christer,
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Jun 2020 05:20:58 -0400

Shinji,

This draft was severely out of date. Proposals in it have known problems.
_____________
Roman Shpount

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

> > Session-Expires is inserted by proxies. Proxies cannot reliably
> determine that another transaction is in progress. UA refusing session
> expires if another transaction is in progress will break existing
> implementations.
> > _____________
> > Roman Shpount
> >
> >
> >     Assuming all entities(UAC, UAS and proxies) keep a consistent policy
> for their own session-timer, even if transactions conflict, I think the
> results are also consistent.

---

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

Hi,

The race condition resolution should be in the main scope, but where is the latest proposal for this part?

Regards,
Shinji

On 2020/06/22 18:20, Roman Shpount wrote:
> On Mon, Jun 22, 2020 at 5:15 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Roman,
> 
>      > On Thu, Jun 18, 2020 at 5:48 AM OKUMURA Shinji <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Christer,
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jun 2020 09:34:25 +0000

Hi,

There is no text proposal yet. We have a high-level agreement on how to solve the issue, and the plan is to generate text based on that.

Note that the current version of the bis draft is a copy of the RFC. No changes have been implemented yet.

Regards,

Christer

-----Original Message-----
From: OKUMURA Shinji <[email-masked]> 
Sent: maanantai 22. kesäkuuta 2020 12.29
To: Roman Shpount <[email-masked]>
Cc: SIPCORE <[email-masked]>; Christer Holmberg <[email-masked]>
Subject: Re: [sipcore] RFC4028 : sessiontimer-race

Hi,

Regards,
Shinji