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

[<[e-mail]>]

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.

Thank you and Best Regards

Roland
> -----Ursprüngliche Nachricht-----
> Von: Christer Holmberg <[e-mail]>
> Gesendet: Mittwoch, 19. September 2018 16:23
> An: Jesske, Roland <[e-mail]>; [e-mail]
> Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-02.txt
> 
> 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, "[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
>