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

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 26 September 2018 12:11 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDB51252B7 for <sipcore@ietfa.amsl.com>; Wed, 26 Sep 2018 05:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.757
X-Spam-Level:
X-Spam-Status: No, score=-4.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSwU9bzQiSs2 for <sipcore@ietfa.amsl.com>; Wed, 26 Sep 2018 05:11:16 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0C0130E94 for <sipcore@ietf.org>; Wed, 26 Sep 2018 05:11:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537963874; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=f9o2HxRDoPtxlaxTxhhu7h6OaqloWrCJGcJX/xnUXVU=; b=QEwtU2Mm34mj4uxDghCn80dvoU7QSsWAVOLbCp30a56x8JsxT0Qo3WZx8cSNyaXR MmkUFVUXMr2RyEOm08D1Q/bVSdKi7BQ2rAhXqD7MNkNwiTGhewXwLAMuFuZH6Nth WvgWtYVlqkY+AeflSyBhmbRMwlWRRlzLS4xteOtC9jw=;
X-AuditID: c1b4fb3a-395ff70000003197-2a-5bab7762ddd0
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 08.2A.12695.2677BAB5; Wed, 26 Sep 2018 14:11:14 +0200 (CEST)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 26 Sep 2018 14:11:14 +0200
Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Wed, 26 Sep 2018 14:11:14 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "R.Jesske@telekom.de" <R.Jesske@telekom.de>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-02.txt
Thread-Index: AQHUQE2Gq5aJjv9xH0eiXw9Q9NnsCKT0IyRQgAO4SACAAPecIIAJ4QWA
Date: Wed, 26 Sep 2018 12:11:14 +0000
Message-ID: <DCC20C33-FCD8-4226-95E4-C9E0B21512C4@ericsson.com>
References: <153562545519.3315.10133281272170915663@ietfa.amsl.com> <FRXPR01MB0135BED571519D3EA4FE12CCF91E0@FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE> <2CB92AFA-E837-4533-A7E8-5D4E228A5A2D@ericsson.com> <FRXPR01MB01351771201D6950BDC72F49F9130@FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <FRXPR01MB01351771201D6950BDC72F49F9130@FRXPR01MB0135.DEUPRD01.PROD.OUTLOOK.DE>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-originating-ip: [153.88.183.157]
Content-Type: text/plain; charset="utf-8"
Content-ID: <462053803FAC5E44942FC56DAAD9A7F8@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2J7iW5S+epog6+T5Cya7nSxWXz9sYnN gcljyZKfTB5tLxUCmKK4bFJSczLLUov07RK4Mr7uXcJacMGj4sfdqAbGB25djJwcEgImEh/+ LGbsYuTiEBI4yijx6ukfKOcbo8Sdzl1sEM4yRoljWycBORwcbAIWEt3/tEG6RQQiJFbfPswE YgsL+EksOLSUCSIeKHH7/1oWCNtN4sDzFWwgNouAqsSGR7OYQWxeAXuJa9ta2SHmz2WSuLL6 NytIglMgRmLBh82MIDajgJjE91NrwIYyC4hL3HoynwnibAGJJXvOM0PYohIvH/9jBblNVEBf YtrlAIiwksSW3i1MIGFmAU2J9bv0IaZYSyz9sYgRwlaUmNL9kB3iHEGJkzOfsExgFJ+FZNks hO5ZSLpnIemehaR7ASPrKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzASDu45bfVDsaDzx0P MQpwMCrx8PLHrY4WYk0sK67MPcQowcGsJMLLXQYU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuU ZhElJJCeWJKanZpakFoEk2Xi4JRqYFS35BBzXHN15qMzB1QjnDX2TlNvv6r57ouLiaC10Onp MRuN2l9fblUVOi+q88l+xiaG1x6Jp3dvWWboYC4ZcCSOUTS2cubciaHM/O3RG051/Qy6V8Zs V3gyd0pK8Mc00Zvf/G7mPjkR2vWaI/al8q6TJ68HGxgsuKG2xjTtz3nvk5Vfs6/7VSuxFGck GmoxFxUnAgBfKTxIsAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/ZKvYpGwfCXDI_gWMbtlWOL6FmIg>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-02.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2018 12:11:20 -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, "R.Jesske@telekom.de" <R.Jesske@telekom.de> wrote:

    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 <christer.holmberg@ericsson.com>
    > Gesendet: Mittwoch, 19. September 2018 16:23
    > An: Jesske, Roland <R.Jesske@telekom.de>; sipcore@ietf.org
    > 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, "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
    >