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

On 9/19/18 10:23 AM, Christer Holmberg wrote:
> 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.

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

> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> On 17/09/18 10:06, "R.Jesske@telekom.de" <R.Jesske@telekom.de> wrote:
> 
>      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:sipcore-bounces@ietf.org] Im Auftrag von internet-
>      > drafts@ietf.org
>      > Gesendet: Donnerstag, 30. August 2018 12:38
>      > An: i-d-announce@ietf.org
>      > Cc: sipcore@ietf.org
>      > 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
>      > sipcore@ietf.org
>      > https://www.ietf.org/mailman/listinfo/sipcore
>      
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 