Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-02.txt

From: <[email-masked]>
Date: Mon, 17 Sep 2018 07:05:38 +0000

Hi Christer,
Thank you for Updating the draft.
We see this work as important since we have still problems with implementations of the session timer and a lot of discussion with different SP and Vendors.

What we realized is that the definition of the  "Initial Session Refresh Request" is not clear.
You may interpret it out of the whole RFC but not from the definition. 
The definition states:
Initial Session Refresh Request: The first session refresh request
      sent with a particular Call-ID value.

This does not state if it is the Initial INVITE requesting the session timer or if it is the first INVITE refreshing the session?

The Session Refresh Request is defined as:
Session Refresh Request: An INVITE or UPDATE request processed
      according to the rules of this specification.  If the request
      generates a 2xx response, the session expiration is increased to
      the current time plus the session interval obtained from the
      response. 

It states that the session expiration is increased. So what is now increased? Is it also the initial INVITE response with the first session expire value.

>From my point of view it would help when we change the definition section to:
Initial Session Refresh Request: The first session refresh request
      sent with a particular Call-ID value. i.e. initial INVITE sending at minimum a "supported timer" which is answered by an 200 OK with a negotiated session timer.

Question is if is only my view or does others have the same view?

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von internet-
> [email-masked]
> Gesendet: Donnerstag, 30. August 2018 12:38
> An: [email-masked]
> Cc: [email-masked]
> Betreff: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol Core WG of the
> IETF.
> 
>         Title           : Session Initiation Protocol (SIP) Session Timer Glare Handling
>         Author          : Christer Holmberg
> 	Filename        : draft-ietf-sipcore-sessiontimer-race-02.txt
> 	Pages           : 7
> 	Date            : 2018-08-30
> 
> Abstract:
>    This document updates RFC 4028, by clarifying the procedures for
>    negotiating usage of the Session Initiation Protocol (SIP) session
>    timer mechansim, in order to avoid a race condition where both
>    endpoints trigger simultaneous negotiations.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontimer-race/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-race-02
> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sessiontimer-race-
> 02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sessiontimer-race-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Sep 2018 14:23:21 +0000

Hi Roland,

Section 1 says:

   "To resolve this problem, this extension defines a keepalive mechanism
   for SIP sessions.  UAs send periodic re-INVITE or UPDATE [3] requests
   (referred to as session refresh requests) to keep the session alive."

So, to me that makes it clear that a session refresh request is sent within an established dialog.

I agree that "initial" is very confusing, but my initial reaction is that it would be the first session refresh request (as defined above) sent within a session, i.e., the first re-INVITE or UPDATE.

Regards,

Christer

On 17/09/18 10:06, "[email-masked]" <[email-masked]> wrote:

    Hi Christer,

    

    

    Roland

---

From: <[email-masked]>
Date: Thu, 20 Sep 2018 06:29:09 +0000

Hi Christer,
yes that looks like that this is the definition.
But then I miss the procedures for the initial INVITE.
What headers have to be set.
Because 7.1 is stating 
"7.1.  Generating an Initial Session Refresh Request"

There are some hints what in Initial Invite has to be done but it is not really a clear distinction.

Either we rewirte the complete document to make it clear or we clarify this within the Update.

E.G we could define a section 7.0 Generating an initial INVITE requesting session timer.

We have still discussions about the interpretation especially within interconnection cases with other carriers. And not everybody knows what we are discussing within IETF they are only reading the IETF documents.
I think a clear definition and description will help.

Roland
> Von: Christer Holmberg <[email-masked]>
> Gesendet: Mittwoch, 19. September 2018 16:23
> An: Jesske, Roland <[email-masked]>; [email-masked]
> Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-02.txt
> 
> Hi Roland,
> 
> Section 1 says:
> 
> I agree that "initial" is very confusing, but my initial reaction is that it would
> be the first session refresh request (as defined above) sent within a session,
> i.e., the first re-INVITE or UPDATE.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
>     We see this work as important since we have still problems with
> implementations of the session timer and a lot of discussion with different SP
> and Vendors.
> 
>     This does not state if it is the Initial INVITE requesting the session timer or
> if it is the first INVITE refreshing the session?
> 
>     It states that the session expiration is increased. So what is now increased?
> Is it also the initial INVITE response with the first session expire value.
> 
>           sent with a particular Call-ID value. i.e. initial INVITE sending at
> minimum a "supported timer" which is answered by an 200 OK with a
> negotiated session timer.
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2018 12:11:14 +0000

Hi,

When reading more about this, it actually looks like "Initial Session Refresh Request" could be the initial INVITE.

I think the text is very confusing. I don't think we should call the request where the usage of session timer is negotiated a refresh request.

Regards,

Christer

On 20/09/18 09:29, "[email-masked]" <[email-masked]> wrote:

    Hi Christer,

    

    
    Roland

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2018 11:31:45 -0400

> So, to me that makes it clear that a session refresh request is sent within an established dialog.

To me, this has always had the effect of confusing readers. It 
*suggests* that certain reINVITE and UPDATE requests are session refresh 
requests, and others are not. (I know it doesn't say that explicitly, 
but from numerous comments/questions over the years it is evident that 
many read it that way.)

The goal of session timer is to cause in-dialog requests to be sent 
periodically as keep-alives - evidence of liveness of the session at the 
endpoints. It does not *refresh* the session. However, new S-E values in 
those messages can have the effect of extending the timer. That can be 
viewed as a "refresh" of the *timer*, not the session.

But other messages within the dialog, not triggered by timer expiry, 
also serve as evidence of liveness of the session.

Ideally we would rewrite the whole explanation and change the 
terminology. I guess this would be a bis.

> I agree that "initial" is very confusing, but my initial reaction is that it would be the first session refresh request (as defined above) sent within a session, i.e., the first re-INVITE or UPDATE.

ISTM that the *initial* one is the one that first establishes the timer. 
Most of the time this will be the initial INVITE, and hence won't be a 
refresh at all.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2018 19:05:56 +0000

Hi,

...

> The goal of session timer is to cause in-dialog requests to be sent periodically as keep-alives - evidence of liveness 
> of the session at the endpoints. It does not *refresh* the session. However, new S-E values in those messages can 
> have the effect of extending the timer. That can be viewed as a "refresh" of the *timer*, not the session.

When the work on session timer started, many cookies ago, the idea was that it would be possible to re-create sessions if entities had lost session state. That did not work, so it ended up being a mechanism to determine whether a session is alive. 

>But other messages within the dialog, not triggered by timer expiry, also serve as evidence of liveness of the session.

Correct. Using (re-)INVITE and UPDATE is quite heavy - you could do the same thing with INFO.

>Ideally we would rewrite the whole explanation and change the terminology. I guess this would be a bis.

There have been some discussion on whether we should do that - instead of just trying to fix pieces here and there.

But, as I have indicated previously, I first want us to agree on HOW to fix, and then we can discuss how to document it.

>> I agree that "initial" is very confusing, but my initial reaction is that it would be the first session refresh 
>> request (as defined above) sent within a session, i.e., the first re-INVITE or UPDATE.
>

Correct. As I wrote in another reply, I think that is the case.

>Most of the time this will be the initial INVITE, and hence won't be a refresh at all.

Correct.

Regards,

Christer

---

From: [email-masked]
Date: Thu, 27 Sep 2018 15:14:23 +0200

Hi, as I said it would be nice to have an extra chapter for describing the initial INVITE separating it from the initial session refresh.

Best Regards

Roland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Sep 2018 13:19:49 +0000

Don’t worry, once we sort out the technical issues we will create the most beautiful document you have ever seen – including all the chapters you want :)

Regards,

Christer

From: Roland Jesske <[email-masked]>
Date: Thursday 27 September 2018 at 16:14
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-02.txt

Best Regards

Roland

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Sep 2018 10:58:21 -0400

> But, as I have indicated previously, I first want us to agree on HOW to fix, and then we can discuss how to document it.

I'm starting to lose track of the things that have been considered, 
rejected, etc.

ISTM that we are still struggling with what happens in obscure cases. It 
seems that some cases will always break somebody when some parties 
implement the update and others don't. And who has to change to make the 
fix. This will not be entirely pain free.

It would be helpful to me to have some information about what 
implementations of timer exist in the wild, why it is used, and what 
limitations those implementations have.

For instance, I have a sense that a lot of UAs request timers on their 
own. I have no idea why. I would expect it to only be requested by 
proxies. And since a lot of intermediaries are actually b2buas rather 
than true proxies, the demand ought to be even less.

	Thanks,
	Paul