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

[Christer Holmberg <[e-mail]>]

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.
>
>ISTM that the *initial* one is the one that first establishes the timer. 

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



> On 17/09/18 10:06, "[e-mail]" <[e-mail]> 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:[e-mail]] Im Auftrag von internet-
>      > [e-mail]
>      > Gesendet: Donnerstag, 30. August 2018 12:38
>      > An: [e-mail]
>      > Cc: [e-mail]
>      > 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
>      > [e-mail]
>      > https://www.ietf.org/mailman/listinfo/sipcore
>      
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
> 

_______________________________________________
sipcore mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sipcore